Environment
2 x SharePoint Server 2010 Web Front Ends
2 x SharePoint Server 2010 Application Servers
1 x SQL Server 2008 R2 DB Server
SSL and load-balanced enabled web application
What we’re trying to do
After upgrading a SharePoint 2007 content database to a SharePoint 2010 farm, we wanted to convert to Claims Authentication. Following the TechNet documentation on this, we came across an error message after trying to set the authentication provider as shown below:
Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
Error Message
Set-SPWebApplication: An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=SharePoint Sites was updated by domain\serviceAccount, in the OWSTIMER process, on machine SPServer. View the tracing log for more information about the conflict.
After spending over 20 hours going through a multitude of workarounds and scenarios including those that are commonly known like deleting the file cache, I think I’ve come up with a series of steps that is repeatable and reliable (at least in my environment).
Steps
1. Perform all actions below using the farm account.
2. Create your web app in classic authentication mode, attach content DB, etc. as appropriate. In my environment the base line web application included host headers, SSL and load-balancing already configured. We also had the appropriate content database attached and upgraded. One lesson learned here was that you’ll want to do a backup of your content database after a successful mount-spcontentdatabase and upgrade (if you’re upgrading from SharePoint 2007) prior to performing any more actions on it. Depending on how large your content database is, it will behoove you to back it up since the upgrade process could be very time consuming on large content databases.
3. Log on to each non-database server in the farm and stop the “SharePoint 2010 Timer” service. You can get to this by going to Start > Run > Services.msc
4. Pre-emptively clear the file cache on each of the non-database servers. The file cache can typically be found on each server here: C:\ProgramData\Microsoft\SharePoint\Config. If you don’t see some files/folders, you may have to unhide file extensions and hidden files/folders. Now you’ll notice that there may be more than 1 folder with GUIDs. You’ll want to open them and find the one that contains nothing but XML files and one “cache.ini” file. Go ahead and delete all the XML files. With the lonely cache.ini file that’s left over, open it up, delete all the contents and replace it with “1”. Make sure you do this on all non-database servers. You’ll know that you correctly stopped the SharePoint Timer Service if the XML files don’t come back.
5. Now let’s move forward with the claims authentication conversion. You can follow all of the instructions on TechNet here. To summarize, you’ll want to perform the following commands in Powershell via the SharePoint 2010 Management Shell:
$WebAppName = "http://yourWebAppUrl"
$account = "yourDomain\farmaccount"
$wa = get-SPWebApplication $WebAppName
Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
Press 'Y' for Yes when prompted
$wa = get-SPWebApplication $WebAppName
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()
$wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)
6. What the above commands will do is convert the authentication mechanism for the web application to claims-based as well as convert all the user objects in your content database to the claims format (“i:0#.w|domain\account”). Now a thing to note here is that through experimentation, I found that even when/if I get the failure/error message (in red above) after the “Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default” command, my content database is not corrupted. So no need to restore/re-upgrade. It seems to have performed the proper claims updates to the content database and then tries to update the web application. If the error occurs, you’ll want to dismount the content database, delete the web application, re-create the web application in classic authentication mode and then start over with Step 1 above. If you don’t get any error messages, then continue below.
7. Time to update the Portal Super User and Super Reader Accounts using the same Powershell session as above. If you had closed it already, you’ll need to grab the web application object again before performing the commands below:
$wa.Properties["portalsuperuseraccount"] = "i:0#.w|domain\yourSuperuserAccount"
$wa.Properties["portalsuperreaderaccount"] = "i:0#.w|domain\yourSuperReaderAccount"
$wa.Update()
8. Time to start all of the SharePoint Timer Jobs (services.msc). When you perform this action, you’ll notice that all of the cache files you had deleted previously will be recreated and the number in the cache.ini file will show a number other than 1. After a few minutes, the timer service will propagate all of the changes that we’ve been performing to all of the web front end servers. You can monitor this by checking on the status of the timer jobs @ http://centraladmin/_admin/Timer.aspx.
9. Now you should be able to login to your site and everything should work! You should not get any Access Denied messages. If you do, you probably didn’t do Step 7 properly. If you look at the permissions and users in your claims-based SharePoint site, you’ll notice that almost all users will be in the claims format (“i:0#.w|domain\account”). If they are not, they are most likely users that no longer exist in Active Directory. If they are valid users and for some reason didn’t have their login name changed then you have some other problems that I haven’t come across yet. Another place to review to make sure that claims is working properly is to look at the user policy for your web app. There’s a “User Policy” button in the ribbon of this Central Admin page: http://centraladmin/_admin/WebApplicationList.aspx.
Happy claiming! 🙂
As of last week, I’m now working as one of two internal SharePoint keepers of the farm at 
The SharePoint Swiss Army Knife 
You must be logged in to post a comment.