FromTheField

Real world experiences of SharePoint PFE and CTS engineers from Microsoft UK

SharePoint 2013 - December CU - Exception: No mapping between account names and security IDs was done

SharePoint 2013 - December CU - Exception: No mapping between account names and security IDs was done

  • Comments 1
  • Likes

I was recently helping a colleague to troubleshoot an issue that he was running into whilst deploying the December 2013 CU for SharePoint 2013, the following error was being logged in the upgrade log.

Exception: No mapping between account names and security IDs was done 00000000-0000-0000-0000-000000000000
03/03/2014 18:46:19.17 PSCONFIG (0x0EA8) 0x0BCC SharePoint Foundation Upgrade SPUpgradeSession ajxnm ERROR    at Microsoft.Office.Server.Utilities.WindowsSecurity.LookupAccountName(String accountName, String& domainName, SID_NAME_USE& use)     at Microsoft.Office.Server.Utilities.WindowsSecurity.GetNT4AccountName(String name)     at Microsoft.Office.Server.Data.SqlServerManager.GrantLogin(String user)     at Microsoft.Office.Server.Search.Administration.SearchDatabase.GrantAccess(String username, String role)     at Microsoft.Office.Server.Search.Administration.SearchDatabase.SynchronizeAccessRules(SearchServiceApplication searchApp)     at Microsoft.Office.Server.Search.Administration.SearchServiceApplication.SynchronizeDatabases()     at Microsoft.Office.Server.Search.Upgrade.SearchAdminDatabaseSequence.PostUpgrade()     at Microsoft.SharePoint.Upgrade.SPUpgradeSession.Upgrade(Object o, Boolean bRecurse)


I had a look to see what the Microsoft.Office.Server.Search.Administration.SearchDatabase.SynchronizeAccessRules() method was doing, it turns out that this method (amongst other things) validates each user/group that is added as an Administrator to the Search Service Application. If the user account or group no longer exists the lookup fails which causes the above exception and the upgrade process to fail. The fix is fairly simple - remove any users or groups from the permissions list of the Search Service Application within Central Administration that no longer exist. I have written a PowerShell script that outputs all of the account types that are verified by the method, whilst the issue could be with one of the other three types of accounts that the method validates it's not likely as Search or the Farm will be seriously broken if they configured to use an account that no longer exists!

  • Search Service Application Administrators
  • Search Service Process Identity
  • Search Service Application Pool
  • Timer Service Identity

The script makes the presumption that you have a single Search Service Application in the farm.

asnp *sharepoint* -ea SilentlyContinue
$SSA = Get-SPEnterpriseSearchServiceApplication
$SSAAdmins = $SSA.GetAdministrationAccessControl().AccessRules.Name
$SearchService = (Get-SPEnterpriseSearchService).ProcessIdentity
$AppPool = $SSA.ApplicationPool.ProcessAccountName
$TimerService = (Get-SPFarm).TimerService.ProcessIdentity.UserName
Write-Host SSA Admins: $SSAAdmins -ForegroundColor Green
Write-Host Search Service: $SearchService -ForegroundColor Green
Write-Host App Pool: $AppPool -ForegroundColor Green
Write-Host Timer Service: $TimerService -ForegroundColor Green



Brendan Griffin - @brendankarl

Comments
  • A great blog post and one that helped me get my customer patched and healthy in record time! Thanks for the assistance on this one Brendan!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment