SharePoint 2013 April 2014 CU Claims Conversion Bug

6/11/2014 Update:

This bug is resolved in the June 2014 Cumulative Update.


6/6/2014 Update:

Microsoft Product Support Services has provided a workaround for this issue. Simply migrate each user and group post Web Application conversion. This can be done via stsadm or Move-SPUser. For example:

This will migrate the user across the entire farm. If you have other Web Applications that remain in Classic mode within the same farm with the same user accounts, this will migrate the user to Claims format within those databases. In this scenario, the workaround is not valid.


There is a fatal bug in the April 2014 Cumulative Update as well as MS14-022 for SharePoint 2013 when attempting to use the Convert-SPWebApplication cmdlet. With this cmdlet came a large code base change in order to add significant new functionality, but it unfortunately broke the Classic (Windows) to Claims migration functionality.

This cmdlet also comes with some new parameters, undocumented in either the cmdlet help (perhaps to be updated via Update-SPHelp in the future) or on TechNet. For reference, it now has a -From and -To switch:

-From accepts the following string values: Legacy, Claims-Windows, Claims-Trusted-Default

-To accepts the following string values: Claims, Claims-Windows, Claims-Trusted-Default, Claims-SharePoint-Online

For the purposes of this post, the values in use are -From Legacy -To Claims -RetainPermissions

When the migration process starts, the migrator loops through each Content Database, and for each online Content Database, each Site Collection, and finally each User/Group. In this example, we’re taking NT AUTHORITY\Authenticated Users and converting to c:0!.s|windows. The major break appears to occur in Microsoft.SharePoint.Administration.SPWebApplicationMigrator in the method GetEntityMigrationDataFromOldCallBack(SPMigrationEntity entity).

Near the top of the method, a value is set:

This is a fair thing to set, assume we’re going to fail the migration, and make sure we’ll succeed for each user instead. Good idea, honestly. And for this user, we do actually succeed at making a valid claim, and I’ll show you that.

In this same method, we pass through this portion where the conversion process from Classic to Claims is actually performed, with no errors:

Where the bug appears to be happening is after the conversion. That failure variable is never updated to Success.


Here we can see that the str2 variable is not null and skipUser is also not set. AlreadyMigrated is also not set, but in addition, the failure variable has not been updated to Success either, hence the migration never is allowed to move forward.

Here is another view after having left the last method where the failure variable should have been updated to Success:


In the end, what should happen is that we skip over a bunch of other validation methods to to make sure that SPMigrateEntityCallbackResult does not equal Success, and finally if the entity does equal Success, add it to the Migration Cache to be migrated, and finally execute the migration.

In this example, I have the following users in my UserInfo table. The first user you see in Claims format is placed there automatically by the conversion process in order to start the conversion process.

Next, running through each user, manually updating from Failure to Success after the internal conversion (again, the conversion in SQL has not happened yet) from Classic to Claims using the following method in the SPMigrateEntityCallbackResult MigrateEntity(SPClaimMigrationContext context, SPMigrationEntity entity) method:


Each user is added to a new “migration cache”. I didn’t dive too deeply into this cache, but needless to say, the migration is successful. Examining the UserInfo table again, post manual variable change:

After the SQL query completes execution, from here I am able to log in as any specified user that has been migrated successfully. Otherwise, if the Web Application has been migrated to Claims but the users have not, the user will receive Access Denied in their Windows (“Classic”) login format.

Unfortunately the old SharePoint 2010 MigrateUsers($true) method (deprecated) also runs through the same code, so it will produce the same results. In the end, we’ll need to wait for a patch from Microsoft on this issue.


  1. I am running into this issue currently with a 2010 foundation to 2013 sp1 foundation migration. My claims conversion fails Statistics: ContentDatabases ‘1’, Site Collections ‘2’, Users Succeeded ‘0’, Users Failed ‘153’. Is there any workaround for this currently or are we waiting on a MS patch?

    • There is no workaround for existing farms with MS14-022 or the April 2014 CU applied. The only work around is to take the database pre-upgrade into a SharePoint 2013 farm that does not have MS14-022 or the April 2014 CU applied, use Convert-SPWebApplication there, then take the upgraded database into the final farm running MS14-022 or the April 2014 CU.

  2. Has this been fixed via a CU? I’m on 2013 SP1 and it appears to exist.

  3. We have September 2014 CU on Production Farm but error is still occurring, I believe Sep 2014 CUs cover all previous updates as well. Please suggest…

  4. Pingback: SharePoint 2013 April 2014 CU Claims Conversion Bug | @SPSamer

  5. We are also struggling with this issue even after latest patch applied, we are on Aug 2014 CU

  6. The issue still exists, with the latest CU, from November 2015.

    But I found a solution:

    Convert-SPWebApplication -Identity http://Your-Server-Name -To Claims -RetainPermissions -From LEGACY

    At least, that has solved the issue, for me.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.