|Authentication Type||SharePoint 2007 convention||SharePoint 2010 convention|
|Individual Windows User (NTLM)||domainusername||i:0#.w|domainusername|
|Active Directory Group (NTLM)||domaingroupname||c:0+.w|s-1-1-11-111111111-1111111111-111111111-1111 (SID for group)|
|Claims Authentication (custom provider)||i:0e.t|providername|username|
The IT Leader's Guide to Multicloud Readiness
This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.
Download the Guide
Microsoft added a method on the SPWebApplication object that you can call to migrate your users, you can call it in powershell like so:
$w = Get-SPWebApplication “http://yoursharepointsite.com/”
This command will change all usernames from the 2007 convention to the 2010 convention.
It seems a little too easy and too good to be true. Upon running this method the first time the conversation between me and the support engineer I was working with went a little bit like so (language in real life may have been a tad more colorful):
Me: Did you run it? I still get access denied on the web application.
Support: Yes, it finished with no errors too. Oh crap, I get access denied too! I’m giving your account full access to the web application with a user policy in CA, try it again.
Me: I’m still getting a darn access denied message. No frickin’ way, did we just kill SharePoint?
Support: SharePoint declared deceased at 3pm on 8/5/2011. Shucks.
After we stopped freaking out, we tried re-attaching a copy of the content database taken before running the MigrateUsers method. This didn’t help, we still got access denied everywhere on the web application even with a Farm Administrator account. We ended up having to recreate the web application and re-attaching the earlier copy of the content database to get it back up and running. After trying this multiple times and having it fail every time I did some searching on the web. I found a few mentions of updating the PortalSuperUser and PortalSuperReader account for the web application so they were in the correct user format before the user migration. After trying this a couple times and getting the same result as before we found the problem!
We were creating our web application with a powershell script. When we set the PortalSuperUser and PortalSuperReader accounts in the script we were using the old format (domainuser) and it seemed to be persisting somewhere in the content database causing the user migration to break all permissions on the web application. To fix this we updated our powershell script to create the web application with the super user and super reader accounts using the new format (i:0#.w|domainusername) and this fixed the broken permissions after running the MigrateUsers method.
If you need to customize your usernames further (i.e. your user’s domain is changing or you are moving from forms to claims authentication) you can modify the username string directly. If your SharePoint 2010 application has the latest patches applied Microsoft made a callback available in one of the cumulative updates so you can hook into the MigrateUsers method and run your custom code. If you are still on the RTM version you can modify the user profile properties directly through powershell.