Migrate from classic-mode to claims-based authentication in SharePoint 2013 the easy way

When migrating a content database from a SharePoint 2010 web application using classic-mode authentication to a SharePoint 2013 web application using claims-based authentication Microsoft recommends converting the web application and all its content databases to claims-based authentication in SharePoint 2010 first and then migrating the web application and all its content databases over to SharePoint 2013. See Migrate from classic-mode to claims-based authentication in SharePoint 2013 for all the painful details.

That is a laborious way to do it, because it implies the following process:

  1. Recreate the web application and all its content databases in a Test farm
  2. Convert the web application to claims-based authentication in the Test farm (unless you feel this is something you want to do in your Production farm just to keep your job interesting).
  3. Detach the database(s) from the SharePoint 2010 Test farm’s SQL Server, copy them over to the SharePoint 2013 Production farm’s SQL Server and attach them
  4. Run Mount-SPContentDatabase etc.

If you are the kind of person who craves this kind of excitement in their lives stop reading now because you will be disappointed by the simplicity of the process described below.

The quick and easy way to do the above:

  1. Detach the database(s) from the SharePoint 2010 Production farm’s SQL Server, copy them over to the SharePoint 2013 Production farm’s SQL Server and attach them
  2. Run Mount-SPContentDatabase etc.
  3. Run the PowerShell below to convert the content database(s) to claims-based authentication
$wa = Get-SPWebApplication http://www.mydomain.com
$acc = 'DOMAIN\SP_Farm'
$arguments = New-Object Microsoft.SharePoint.Administration.SPWebApplication+SPMigrateUserParameters
$arguments.AddDatabaseToMigrate($wa.ContentDatabases[0])
# The line above only adds the first content database in
# the web application for demonstration purposes. You may
# need to iterate through your databases and add them all.
$wa.MigrateUsersToClaims($acc, $false, $arguments)

The second easier method above gives you the same results as the first laborious process but with considerably less pain.

Thanks to Steve Peschka for providing the PowerShell commands above and Chris Weldon for making the PowerShell commands behave in a civilized manner. A couple of points to note from their blog posts, first do not change the name of the parameter “$arguments” to anything else as this causes problems. Second, if you use the SharePoint farm account as I did above then make sure the second parameter to the MigrateUsersToClaims method is set to $false.

For migrations Microsoft always talks about Detach/Attach for migrating databases but I prefer Backup/Restore, but that is something I will discuss in more detail in another post.

SharePoint “We hit a snag”

PROBLEM

Click on a site link in the Sites I’m following section and get the message “We hit a snag. This link doesn’t work anymore, likely because the item was moved or deleted. You might have luck searching for it and following it in its new location”.

SOLUTION

Ensure that the application pool service account that your My Sites are running under have SPDataAccess permissions on the content database that contains the site whose link you clicked on.

FURTHER DETAILS

I followed a site in SharePoint 2013, then went to the Sites page and clicked on the site link in the Sites I’m following section and got the message “We hit a snag. This link doesn’t work anymore, likely because the item was moved or deleted. You might have luck searching for it and following it in its new location”

Snag01

I was able to copy the link and open it another browser tab successfully so it hasn’t moved or been deleted. So technically “we” didn’t hit a snag, “you” SharePoint hit a snag and took me along for the bumpy ride.

Even with the diagnostic logging levels turned up to verbose for everything I could not find any indication of a problem in the trace or event logs. I am not sure if this is just my development environment suffering from this lack of verbosity or this is something more widespread. I suspect the latter as I was not able to find anything in the logs at a customer’s farm suffering from the same snag. I finally tracked down the issue thanks to Derek Campanile.

My Portal web application and MySite Host web application use different service accounts for the application pools in IIS as ideally they should do.

Snag02

It seems that when you click on the link in Sites I’m following SharePoint tries to access the content database that the site is stored in. When I checked in SQL Server for the My Sites service account…

Snag03

…I found that the service account did not have permissions to access to the content database

Snag04

I gave the service account SPDataAccess permissions…

Snag05

…and was able to successfully click on the link to my followed site.

This means that every time you add a new content database to your farm you must manually go and assign SPDataAccess permissions to the My Sites application pool service account assuming you are following best practice and using a different service account.

I’m sure Microsoft has a good reason for complicating things for the lowly SharePoint administrator, but I can’t imagine what it is right now.