by Martin Laukkanen | Jul 31, 2010 | SharePoint 2010, Troubleshooting
When restoring SharePoint 2010 databases or sites I have recently come across the following problem:
Access Denied to all Sites for all users, including Site Collection Admins.
This appears similar to old 2007 restore issues which were fixed using the STSADM MigrateUser command, however in this case it seems that the STSADM (or PowerShell move-spuser) commands doesn’t fix the issue. And I have definitely made certain to change the Site Collection admin on the restored site collections using Central Admin.
A little investigation revealed that the reason is the use of Claims (or Forms) Authentication in either the source or destination web application, so in my case where my Test environment used Claims (both NTLM and LDAP) but my Prod was only going to use NTLM authentication the restored sites were inaccessible (including PWA!).
Fortunately in my case I found a workaround; setup my new Web App to use Claims, however only enable NTLM authentication, effectively resulting in a pure NTLM setup. However that won’t always work, in fact I have another case where the source data (from an old 2007 portal) is using NTLM and I want to migrate it to 2010 using Claims, in that case another solution will be required.
I plan to investigate further using the "move-spuser" powershell command as that seems to be the solution, it just seems that something is preventing it from migrating the users as expected. I’ll update this blog with my results.
by Martin Laukkanen | Jun 6, 2010 | SharePoint 2010
I just spent some time setting up my first claims based authenticated Project Server 2010 and thought I would post my experiences here, maybe that will help someone avoid the issues I had.
Firstly Bill Baer’s TechNet Blog has a great how-to article on the setup of claims-based authentication, unfortunately there are a few mistakes and omissions in the post that will cause some issues if you follow the steps as provided.
To clarify one mistake I noticed (where Bill asks you to update the Central Admin web.config twice) you must configure the web.config of the following:
- Central Administration Web Application
Security Token Service Error:
Secondly when updating the Security Token Service, in my default install I found that there was no <system.web> tag, and so placing the config after the </system.net> as instructed by Bill, caused the following error when trying to login:
ProtocolException: The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (application/soap+msbin1). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. T
Once I enclosed my <membership> and <rolemanager> tags in a <system.web> </system.web> all was good. Thanks to this thread for that solution.
Secure Store Error:
Finally once I got it all setup the I was getting errors trying to open my Excel data connections via Excel Services, the ULS log error was the following:
06/04/2010 12:52:42.78 w3wp.exe (0x1AA4) 0x1D94 Secure Store Service Secure Store 7493 Critical The Microsoft Secure Store Service application Secure Store Service failed to retrieve credentials. The error returned was ‘Access is denied.’. For more information, see the Microsoft SharePoint Products and Technologies Software Development Kit (SDK). e994ce5b-fcde-43e8-a32b-c2427a86fc6d
This one turned out to be very simple, I forgot to add my new claims ‘role’ group to the Target Application Members configured and used by my data connections. Editing the Target Application under the Secure Store Service Application and adding to the Members those users logging in using claims fixed that one.
by Martin Laukkanen | May 17, 2010 | Project 2010, SharePoint 2010, SQL
With SharePoint 2010 adding a good number of new databases to the default configuration one thing that is sorely missing is the ability to easily name those databases.
Is it just me who has to conform to strict database naming conventions in most installations of Project Server?
I’ve just been working on what I think is a pretty typical Project Server 2010 installation and found that in-order to simply prefix my databases names with something rather than let them be automatically named with a GUID I faced the following:
- Central Admin and the farm configuration is the same as 2007, the PSCONFIG command line will let you name both of those databases.
- Session State Service Application – the first hurdle, this one requires a PowerShell command to give the database a name, e.g.:
$serviceApp = New-SPStateServiceApplication -Name "State Service"
New-SPStateServiceDatabase -Name "MyPrefix_State_Service" -ServiceApplication $serviceApp
New-SPStateServiceApplicationProxy -Name "State Service" -ServiceApplication $serviceApp –DefaultProxyGroup
- Secure Store Application – Central Admin fortunately will let you name the database through the usual creation process.
- Search Service Application – Next hurdle and this one much bigger, three databases are required now for the Search service; Administration, Crawl and Property databases are created, this blog post has a nice PowerShell script to create the service with named databases but with 50 odd lines for the script I’m not going to repeat it here. Fortunately if you’re happy with not naming just one of those three databases, it is actually possible to create new Crawl and Property databases with specified names after creating the three using Central Admin.
- PerformancePoint Service – Well for this one I have not found a way to name the database?! I need to revisit this as there must be a way, but looking at the PowerShell command line options and searching TechNet I couldn’t find one!
- User Profile Service, Excel Services and WSS Usage are all well behaved and through Central Admin you can name the databases.
So it’s about time to get that installation PowerShell script done, as unless your happy with the default wizard configuration then this setup is getting quite long “just” to get Project Server 2010 installed.
by Martin Laukkanen | May 14, 2010 | SharePoint 2010
Typically this is one I never noticed until installing in production, the drive space requirements of the best practice analyser is quite significant see below:
- A Warning will occur if any drive on the SharePoint server has less than 5x the total physical memory in free space, so that’s 40GB for a ‘recommended’ 8GB server.
- A Critical alert will occur if the drive space of any drive on the server falls below 2x the total physical memory, so 16GB for a recommended spec server.
So the second one is fair, I get scared when the drive space in any server drops below 15GB or so, but the 5x warning is really annoying, basically with a ‘standard’ server with at least two drives (System and Apps) that’s 80GB minimum of wasted space to conform to the best practices. Ouch, sorry mister SAN admin!
by Martin Laukkanen | May 14, 2010 | Project 2010, SharePoint 2010, SQL
Found this one out the hard way this week; it seems that currently the only supported version of SSRS for the SharePoint 2010 SRS Add-in is SQL 2008 R2. At least one forum poster from MSFT has confirmed this.
Annoying as it can be surprisingly hard enough to convince customers to install Windows 2008 let alone upgrade their SQL servers! Ah, well at least SRS can be separated from the SQL DB servers making it a bit easier.
Update 12/07: This has now been addressed by Microsoft in the SQL 2008 SP1 CU8 release which adds support to reporting services 2008 to work with the R2 add-in.
