Converting A Classic Auth Content Database to Claims Auth in SharePoint 2013

In previous blogs for SharePoint 2010 I've talked about how to do claims migration - https://blogs.technet.com/b/speschka/archive/2010/07/20/migrating-from-windows-classic-auth-to-windows-claims-auth-in-sharepoint-2010-part-2.aspx and others. In SharePoint 2013 we have a new cmdlet for doing that called Convert-SPWebApplication, which I may cover at a future time. As you can tell from the name though, that cmdlet's scope is the web application. We believe of course that as you attach content databases to create your new SharePoint 2013 farms, you will want a "lighter" method to migrate databases that still use Windows classic authentication. In this scenario, I'll assume that you already have a Windows claims web application running in SharePoint 2013 and you've already attached your SharePoint 2010 content database using the Mount-SPContentDatabase cmdlet. So - assuming you have 1 content database from when you created the SPWebApplication and you just added your 2nd that is Windows Classic mode, here's how you can convert only that content database to using Windows claims. Please NOTE - super important - that you use " $arguments" for the arguments parameter. I'm not the brightest PowerShell guy in the world (not even close), so I stubbed my toe and banged my head on the desk repeatedly because I called mine "$args". After one hour of bloody toe and forehead I realized that it all works if I just called it $arguments. Somewhere, somehow, I'm sure someone will tell me this is my fault. :-)

$wa = Get-SPWebApplication https://yourWebAppUrl
$acc = 'domain\user'
$arguments = New-Object Microsoft.SharePoint.Administration.SPWebApplication+SPMigrateUserParameters

#based on scenario above, content DB 0 is the one that was created with the web app, so 1 is the DB that was added with Mount-SPContentDatabase

$arguments.AddDatabaseToMigrate($wa.ContentDatabases[1])
$wa.MigrateUsersToClaims($acc, $true, $arguments)

After you run this you should be good to go. I tested on a content DB with a handful of users and a combination of SharePoint groups and unique permissions and it all worked great. And by the way, yes, that really is a plus sign between SPWebApplication and SPMigrateuserParameters.

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  July 23, 2012
  The comment has been removed

• Anonymous
  July 23, 2012
  Good to know.  One thing that's been holding me back on this is how this affects Kerberos - or rather those things that require Kerberos.  Reporting Services, PowerPivot, PerformancePoint, etc. require Kerberos for some scenarios.  Will making this switch 'break' those scenarios?

• Anonymous
  April 30, 2013
  Great post, Steve! One of the things that I ran into, however, was an "Operation is not valid due to the current state of the object." error. I documented my findings and added some elaboration in my following blog post: www.chrisweldon.net/.../migrateuserstoclaims-operation-is-not-valid-due-to-the-current-state-of-the-object

• Anonymous
  September 18, 2014
  The comment has been removed