Quantcast
Channel: The SharePoint Farm
Viewing all articles
Browse latest Browse all 184

SharePoint 2013 April 2014 CU Claims Conversion Bug

0
0

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: [crayon-538c3c27da8f4974780610/] 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: [crayon-538c3c27da904798525530/] Where the bug appears to be happening is after the conversion. That failure variable is never updated to Success. [crayon-538c3c27da90e946484441/] 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. [crayon-538c3c27da91b183425366/] 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: [crayon-538c3c27da925805549047/] 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.

The post SharePoint 2013 April 2014 CU Claims Conversion Bug appeared first on Nauplius.


Viewing all articles
Browse latest Browse all 184

Latest Images

Trending Articles





Latest Images