Migrating from Windows Classic Auth to Windows Claims Auth in SharePoint 2010 Part 2

  • Article

NOTE: UPDATED 1/8/2011

I wanted to follow-up on the previous post about migrating authentiation types in SharePoint 2010 that was done here:  https://blogs.technet.com/b/speschka/archive/2010/06/12/migrating-a-web-application-from-windows-classic-to-windows-claims-in-sharepoint-2010.aspx. I still recommend taking a look at that posting if you haven't already because it includes some good background information about the migration process. Recently we've been tweaking with the set ot steps to migrate authentication types and having more success than previously so I wanted to share those steps. These may or may not become the final steps, but it's a pretty good start. 

UPDATED INFO: Folks, one of the things we discovered is that at least one of the issues we were seeing post-migration can be solved if the account that is running the PowerShell commands described below is a) a local administrator on the server where the commands are being run and b) is added to a Full Control web app policy on the web application that is being migrated. The script below already created a Full Control web app policy so I've just updated it to indicate that the user running the script should be used.

So here are the steps:

$WebAppName = "https://yourWebAppUrl"

#THIS SHOULD BE THE ACCOUNT THAT IS RUNNING THIS SCRIPT, WHO SHOULD ALSO BE A LOCAL ADMIN
$account = "yourDomain\yourUser"

$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
# this will prompt about migration, CLICK YES and continue

#This step will set the admin for the site
$wa = get-SPWebApplication $WebAppName
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()

#Once the user is added as admin, we need to set the policy so it can have the right access
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

#Final step is to trigger the user migration process
$wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)

There are a couple of things that may still be a problem for you after doing this that you'll want to take care of or be aware of:

  1. You may find that users cannot log into the site. You enter your credentials and it says you are domain\user but you don't have access rights. If you see that then it's likely you have configured the portalsuperuseraccount and portalsuperreaderaccount properties of the web application prior to migration. You need to go back and change them to use the new claims-based account name. You can get that by looking at the web application policy for the web app after migration and copying from there. Note that if you are not working with publishing sites then adding these accounts to the web app properties may in fact block you from logging into a site, like a team site. Yeah I know, this remains fairly odd and confusing.
  2. Existing alerts may not fire. Right now the only work-around I've seen is to delete and recreate them.
  3. Double-check the web application policies and make sure that the search crawl account shows the new converted account name. If it doesn't, you will need to manually create a new policy for the crawl account.

If you follow these steps and use these troubleshooting tips you should be good to go in most cases.