Ask Learn
Preview
Please sign in to use this experience.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Normally, changing the SharePoint service accounts should not be a big deal. However, in our case we had to do this using PowerShell, as we could not access the managed accounts page (Central Administration >> Security >> Configure Managed Accounts). Unfortunately, accessing it was giving us the below error:
Sorry, something went wrong
Item has already been added. Key in dictionary: 'domain\spadmin' Key being added: 'domain\spadmin'
Frankly, the above error should be easy to be fixed by deleting one of the duplicate managed accounts using Remove-SPManagedAccount. However, doing so was failing as follows:
COMMAND
Get-SPManagedAccount "domain\spadmin" | select sid
RESULT
Sid
---
S-1-5-21-3855947664-3092534411-819001659-1127
S-1-5-21-3855947664-3092534411-819001659-2514
COMMAND
$account = Get-SPManagedAccount | ?{$_.sid -eq "S-1-5-21-3855947664-3092534411-819001659-1127"}
$account.Delete()
RESULT
Exception calling "Delete" with "0" argument(s): "The account domain\spadmin is still being used by these components:
Microsoft SharePoint Foundation Sandboxed Code Service
Security Token Service Application
Application Discovery and Load Balancer Service Application."
At line:1 char:1 + $account.Delete() + ~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [], MethodInvocationException + FullyQualifiedErrorId : InvalidOperationException
Based on the above error, the journey started...
Changed the SharePoint farm account by running the below command via SharePoint management shell.
stsadm.exe -o updatefarmcredentials -userlogin "domain\spadmin" -password "Password"
N.B., changed the above highlighted text with the farm account password
We ran the below command in order to list all the SharePoint Service Applications Application pools
COMMAND
Get-SPServiceApplicationPool | format-list
RESULT
As we are interested in the SID "S-1-5-21-3855947664-3092534411-819001659-1127", we ran the below commands via SharePoint management shell in order to replace the old service accounts with the new ones.
Set-SPServiceApplicationPool "SecurityTokenServiceApplicationPool" -Account "domain\spadmin"
Set-SPServiceApplicationPool "SharePoint Web Services System" -Account "domain\spadmin"
Change Sandboxed Code Service Service Account: we ran the below command via SharePoint management shell on the SharePoint server:
Get-SPServiceInstance | %{if($_.TypeName -eq "Microsoft SharePoint Foundation Sandboxed Code Service") {$_.Service.ProcessIdentity.Username ="domain\spadmin"; $_.Service.ProcessIdentity.Update(); $_.Service.ProcessIdentity.Deploy();}}
Hereafter, we deleted the account again using the below command via SharePoint management shell which ran successfully:
$account = Get-SPManagedAccount | ?{$_.sid -eq "S-1-5-21-3855947664-3092534411-819001659-1127"}
$account.Delete()
Unfortunately, when we accessed the "Configure Managed Accounts" page via Central Administration, we got another error for another service account, as follows:
Item has already been added. Key in dictionary: 'domain\spfarm' Key being added: 'domain\spfarm'
COMMAND
Get-SPManagedAccount "domain\spfarm" | select sid
RESULT
Sid
---
S-1-5-21-3855947664-3092534411-819001659-1128
S-1-5-21-3855947664-3092534411-819001659-2516
COMMAND
$account = Get-SPManagedAccount | ?{$_.sid -eq "S-1-5-21-3855947664-3092534411-819001659-1128"}
$account.Delete()
RESULT
Exception calling "Delete" with "0" argument(s): "The account
domain\spfarm is still being used by these components:
Microsoft SharePoint Foundation Application Pool: mysite.com
User Profile Synchronization Service
Microsoft SharePoint Foundation Tracing
Distributed Cache
Microsoft SharePoint Foundation Application Pool: SharePoint – 80
SharePoint Server Search
Search Host Controller Service
Secure Store Service
PowerPoint Conversion Service Application
PerformancePoint Service
Excel Services Application
Subscription Settings Service
Business Data Connectivity Service
Work Management Service Application
Visio Graphics Service
Managed Metadata Service
Word Automation Services
User Profile Service Application
Search Administration Web Service for Search Service Application
Search Service Application."
At line:1 char:1
+ $account.Delete()
+ ~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : InvalidOperationException
Change User Profile Service Account: we ran the below command via SharePoint management shell
Get-SPServiceInstance | %{if($_.TypeName -eq "User Profile Synchronization Service") {$_.Service.ProcessIdentity.Username ="domain\spfarm"; $_.Service.ProcessIdentity.Update(); $_.Service.ProcessIdentity.Deploy();}}
Change the Distributed Cache Service Account: , we ran the below commands:
$farm = Get-SPFarm
$cacheService = $farm.Services | where {$_.Name -eq "AppFabricCachingService"}
$accnt = Get-SPManagedAccount | ?{$_.sid -eq "S-1-5-21-3855947664-3092534411-819001659-2516"}
$cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$cacheService.ProcessIdentity.ManagedAccount = $accnt
$cacheService.ProcessIdentity.Update()
$cacheService.ProcessIdentity.Deploy()
N.B., the above highlighted SID is the new account's SID
Change the Tracing Service Service Account: we ran the below commands via SharePoint management shell.
$farm = Get-SPFarm
$tracingService = $farm.Services | where {$_.Name -eq "SPTraceV4"}
$managedAccount = Get-SPManagedAccount | ?{$_.sid -eq "S-1-5-21-3855947664-3092534411-819001659-2516"}
$tracingService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$tracingService.ProcessIdentity.ManagedAccount = $managedAccount
$tracingService.ProcessIdentity.Update()
$tracingService.ProcessIdentity.Deploy()
N.B., the above highlighted SID is the new account's SID
Change Search Service Account: we ran the below commands via SharePoint management shell to replace the Search service account.
$procId = (Get-SPEnterpriseSearchService).get_ProcessIdentity()
$procId.CurrentIdentityType = "SpecificUser"
$myManagedAcount = Get-SPManagedAccount | ?{$_.sid -eq "S-1-5-21-3855947664-3092534411-819001659-2516"}
$procId.ManagedAccount = $myManagedAcount
$procId.Update()
N.B., the above highlighted SID is the new account's SID
Change the Search Host Controller Service Service Account: we ran the below commands via SharePoint management shell.
Get-SPServiceInstance | %{if($_.TypeName -eq "Search Host Controller Service") {$_.Service.ProcessIdentity.Username ="domain\spfarm"; $_.Service.ProcessIdentity.Update(); $_.Service.ProcessIdentity.Deploy();}}
Change the SharePoint Web Applications Application Pools: we ran the below commands via SharePoint management shell:
$ManagedAccount = Get-SPManagedAccount | ?{$_.sid -eq "S-1-5-21-3855947664-3092534411-819001659-2516"}
$WebApplication = Get-SPWebApplication | %{$_.ApplicationPool.ManagedAccount = $ManagedAccount; $_.ApplicationPool.Update();$_.ProvisionGlobally();$_.Update()}
Eventually, we deleted the old managed account by running the below commands via SharePoint management shell:
$account = Get-SPManagedAccount | ?{$_.sid -eq "S-1-5-21-3855947664-3092534411-819001659-1128"}
$account.Delete()
One more observation:
The above resolved the managed account error "Item has already been added. Key in dictionary"; However, we noticed some access denied errors on the SQL server logs, while investigating this issue. Digging deeper showed that the old service accounts have permissions on the SharePoint databases, but not the new accounts as both accounts have the same display name but different SIDs. Therefore, we ran the below commands on SQL server on all the SharePoint databases which changed the old user with the new user.
ALTER USER [domain\spadmin] WITH LOGIN = [domain\spadmin];
ALTER USER [domain\spfarm] WITH LOGIN = [domain\spfarm];
Finally, to ensure that everything is OK, we ran the SharePoint Products Configuration Wizard on all the SharePoint servers.
Please sign in to use this experience.
Sign in