SharePoint 2010 Converting From Classic to Claims Authentication Lessons Learned
August 18th, 2011 § 14 Comments
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! 
[...] SharePoint 2010 Converting From Classic to Claims Authentication Lessons Learned (The SharePoint Swiss Army Knife)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: [...]
So I have a content database from 2010 using classic, but when I attach to a claims web app the data is not associated with the users. Is there a way to convert the data to map the data to the new claims users?
Hey Eric, you have to attach the content database to a classic auth enabled web app in 2010 first and then convert to claims.
Bingo, thanks. I’ll use this article next time that comes up. I found a PowerShell command to convert, but I think this post is more detailed.
http://blah.winsmarts.com/2010-3-Enable_Claims_based_Auth_on_a_SP2010_website,_after_it_has_been_provisioned.aspx
$w = Get-SPWebApplication http://webappurlhere
$w.UseClaimsAuthentication = “True”;
$w.update()
Thanks much…I have converted classic to Claims before…But did not follow some of the steps that you have mentioned here…
Hello Henry, are yo still a sharepoint PFE in Irvine? I found a PFE Windows platform position open in Irvine, please can you please connect me with the recruiter for this. I will really appreciate it, I will love to work as a PFE. The Job ID is 755520-41057. my contact is isaac dot oben at gmail dot com
Thank you,
Isaac
Hi Henry,
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.
I got this Error Message.
What I have to do now?
Can I go ahead with next steps after error. Or If I am doing further steps their will be any other problems will occur?
Can I create a new site follow your steps for testing.
Regards,
Sree
My guess would be the job has not ran yet, so try to either run all jobs, stsadm -o -execadmsvcjobs , or reboot the WFE.
Thats just my guess without reading the step you are on, etc.
Hi Sree, you’ll want to follow through the steps that I’ve outlined then it should be ok.
Hi Henry & Eric,
Thanks for your reply. I continued with your steps on same site and succeed.
Your Post Helped me a lot…
Thanks & Regards,
Sree
Hi Henry & Eric,
When I am trying the same in other site today. While running the below migrate users command…
$wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)
I am getting error like, Exception calling migrating users with “1″ argument(s): Access denied.
Henry- Do alerts and My Links still work after the conversion?
Hey Eric, alerts might have to be tweaked after the conversion. You’ll want to test. If it doesn’t work, check out this Technet article – http://technet.microsoft.com/en-us/library/cc508847.aspx.
My Links no longer exist in SharePoint 2010. They’ve been replaced by the tagging capabilities.
Excellent great article…and worked great as I have a similar sharepoint farm setup….Excepting One issue that I have faced after running Migrateusers is, people picker in my central admin with reference to this web app fails to resolve any name
…..which means that I’m unable to create a site collection to this web app because I cannot add the primary and secondary site collection admins…..
However, people picket works fine outside of the central admin on the same application…
Please let me know if you you know what the issue could be…
Thanks in advance
Aravind