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:
- Recreate the web application and all its content databases in a Test farm
- 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).
- 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
- 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:
- 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
- Run Mount-SPContentDatabase etc.
- 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.
Thanks a lot! works a treat. was hoping there was a way to do it after the fact. There’s enough steps involved in the migration without the laborious pre-migration authentication change 😉
Much appreciated.
Nice Post. But I´m still having a problem, getting this error :
Exception calling “MigrateUsersToClaims” with “3” argument(s): “Access denied.”
Any idea what this could be?
Thomas,
If you are using the Farm account as the first parameter to MigrateUsersToClaims and also running PowerShell as the farm account then the second parameter should be $false, otherwise the second parameter should be $true.
Khalid
I am getting the exact same error – this script has worked for me before a number of times (on the same DB, same farm, no less!). Even though I am running it as the farm account, I did try switching the second parameter to $true, but got the same error.
The only difference I can think of is that we applied some Windows patches between runs. Could something have changed my farm account’s permissions?
Most likely your permissions have changed. Ensure that your farm account has dbowner permissions for the DB in SQL Server. If you have another DB which does work, compare permissions with that DB.
Permissions were all OK, I’m just very dumb. There were two other unused content DBs in that web app (this is the pilot env) that I thought were in a different web app. We dropped the DBs without detaching them.
For whatever reason, the script checks access on all the content DBs associated with the web app (not just the one I’m upgrading), and since it couldn’t connect to those two – authentication error. The clue was in the diagnostic logs. Detached the DBs and everything ran smoothly.
What’s the difference between using:
$acc = ‘DOMAIN\SP_Farm’
and
$acc = ‘domain\user’
and why do we change this:
$wa.MigrateUsersToClaims($acc, $true, $arguments)
to this (depending on the above)?
$wa.MigrateUsersToClaims($acc, $false, $arguments)
Ricky, Chris Weldon has done a good job of explaining this difference at http://www.chrisweldon.net/systems%20administration/migrateuserstoclaims-operation-is-not-valid-due-to-the-current-state-of-the-object/ I have fixed the broken link in my article above. Thanks.
I am getting: Exception calling “MigrateUsersToClaims” with “3” argument(s): “Object reference not set to an instance of an object.”
It works when I sent the bool to $false but the database has not updated the users tp_Login
The second parameter should be $false if you are using the Farm account as the first parameter to MigrateUsersToClaims and also running PowerShell as the farm account, otherwise it should be $true. Also ensure that your farm account or the account you are running the script as has dbowner permissions for the DB(s) in SQL Server.
Thanks, I have another question. I have multiple domains and the database only updates the domain of my farm account. E.G. Domain_ABC\farm_account will update Domain_abc\bobs_login to i:0#.w|abc\bobs_login in Userinfo tp_login but Domain_DEF\bobs_login remains the same.