Pages

Tuesday, August 19, 2014

Migrate from Classic Mode Authentication SharePoint 2010 to Claims Based SharePoint 2013 and Retain Permissions

If you do a database detach method of migration from SharePoint 2010 to SharePoint 2013, you will lose your permissions and have to redo them manually since SharePoint 2010 generally uses classic mode authentication and SharePoint 2013 uses claims based authentication by default.

The solution is to convert the classic mode authentication to claims based.  You have several choices on timing for when this can be done - either when the database is still in 2010 or after you migrate to 2013. 

Method One - Create a Classic Web App in 2013, then convert Web App to Claims

1. Created a web application in the new 2013 instance on a different port than my main port that uses classic mode authentication. I chose 3000 for the port, but you can choose anything.
New-SPWebApplication -Name "Content Migration" -ApplicationPool "ContentMigrationAppPool" -AuthenticationMethod "NTLM" -ApplicationPoolAccount (Get-SPManagedAccount  DOMAIN\Service_Account") -Port 3000 -URL http://sp2013
2. Copy the 2010 content databases over into the SQL instance for 2013 and use this command to mount them to the 2013 classic mode authentication web application.  This upgrades the 2010 database. 
Mount-SPContentDatabase "MyContentDB" -DatabaseServer "DB_Server_Name" -WebApplication "http://sp2013:3000"
3. After you are done migrating all of the databases, change the authentication to claims based by running the following command on the migrated/upgraded content database.
Convert-SPWebApplication -Identity "http:// <servername>:port" -To Claims
-RetainPermissions -Force
This will pop up after you run the command:
Cmdlet Convert-SPWebApplication at command pipeline position 1
Supply values for the following parameters:
From: Legacy
The From parameter is a new addition to the command that is not well-documented.  It was added in the April 2014 CU.  It takes one of several parameters (Legacy, Claims-Windows, Claims-Trusted-Default).
In my case, I enter Legacy.  It can take awhile to run, as it loops through all content databases, and converts all users and groups, as well as the web app.  Sometimes this can run forever and never finish on screen, hence the second method below.

After it has run, I like to detach the content databases and re-attach to a Web App I created in with claims based authentication.  It is likely overkill, but I have seen too many "legacy" issues from things that have been converted.

Method Two - Create Claims Based Web App in 2013, Migrate, then Convert Users

  1. Create Web App in target (your new 2013 installation) the normal way - you can create it via the central admin GUI or powershell.
  2. Do a database detach migration and use the Mout-SPContentDatabase command to upgrade the 2010 databases (shown in the previous method).  At this point, although your sites are there, your users will all get "access denied" when trying to access sites.  Their IDs have not yet been converted to claims based.
  3. Run a powershell command to convert the users to claims.
$webapp = Get-SPWebApplication -Identity "http://serverURL"$webapp.MigrateUsers($true)
 When this is done running, a good way to verify if the users have been migrated is to look in the users table of each content database. The easist way to o find this table (if SQL isn't your forté), expand the plus sign next to the database name in SQL Management Studio, then expand the Tables folder. Right-click on dbo.UserInfo and Select Top 1000 rows.  Look in the tp_Login column.  When the script is finished, most users will have a user name that starts with a series of characters "i:0#w|".  If some don't, they are users who are no longer in your Active Directory, are not active or are system accounts.






3 comments:

  1. Bless you! This was driving me crazy. I had run this prior to April 2014 CU and worked fine, then ran after and was so thrown by the "from." Thank you so much.

    ReplyDelete