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 Claims1. 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://sp20132. 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 ClaimsThis will pop up after you run the command:
Cmdlet Convert-SPWebApplication at command pipeline position 1The 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).
Supply values for the following parameters:
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
- Create Web App in target (your new 2013 installation) the normal way - you can create it via the central admin GUI or powershell.
- 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.
- 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.