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: 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:

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:

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.

18 comments

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?

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

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?

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…

Thank you for you informative article. After running thru all the steps, I got a service unavailable 503 message – the apppool was stopped and would stop whenever I accessed the site. I had to reset the apppool identity (user and password) via IIS; select web application; Advanced. Then everything started to work.
macrel