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

  • Article

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