SharePoint 2013 SSRS Migration “User cannot be found”
A recent project I worked on involved a SharePoint 2010 to 2013 migration, part of this migration was to migrate an SSRS 2012 install from SP2010 to SP2013, the steps are well documented in MSDN http://msdn.microsoft.com/en-gb/library/hh759331.aspx
As part of the migration process we moved from classic to claims authentication, this is a straight forward 2 step process
1 ) Create a web app in classic mode in the 2013 farm and mount the content database from SP2010.
2) Call the Convert-SPWebApplication cmdlet to migrate the user accounts to claims authentication.
To perform the SSRS migration we installed SSRS 2012 SP1, moved across the reporting database and Encryption key, when testing the reports a few worked but lots were showing the error “User Cannot be Found” error as outlined in this blog post.
The post above suggests that a user has been deleted from the content db, we checked this but no accounts were marked as deleted.
The next step was to run a SQL trace while opening the reports and see what is being called.
The site ID was DDDC5D75-A52C-4FD9-8DE9-405246F54C4A, in the trace file I found the following
proc_SecGetPrincipalById @SiteId=’DDDC5D75-A52C-4FD9-8DE9-405246F54C4A’,@PrincipalId=9,@GetSTSToken=0,@GetExternalToken=0,@RequestGuid=’0873A39C-9913-7078-5AE6-AF4064C5D2B6′
proc_SecGetPrincipalById @SiteId=’DDDC5D75-A52C-4FD9-8DE9-405246F54C4A’,@PrincipalId=10,@GetSTSToken=0,@GetExternalToken=0,@RequestGuid=’0873A39C-9913-7078-5AE6-AF4064C5D2B6′
Checking back in the content db UserInfo table both ID’s were for valid users but Id 9 was for a migrated user (an account that starts i:0#.w|domain\username) however Id 10 was a non-migrated user account (an account in the format domain\username) .
Checking the account for Id 10 there was no matching entry in AD, I can only assume this user account had been previously deleted from AD but not removed from SharePoint, hence the “User cannot be found” error.
Some more searching turned up this MS support article http://support.microsoft.com/kb/2781008 describing the same issue but different circumstances, the fix is rolled into SQL Server 2012 SP1 CU2, installing this patch fixed the issue for us and we could open all the reports again.