Change SharePoint Service Account
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:
- Ran the below command to get domain\spadmin accounts that were existent on SharePoint.
COMMAND
Get-SPManagedAccount "domain\spadmin" | select sidRESULT
Sid
---
S-1-5-21-3855947664-3092534411-819001659-1127
S-1-5-21-3855947664-3092534411-819001659-2514
- Hence, we ran the below commands to delete the old duplicate account "domain\spadmin"
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
- Change the SharePoint Service Applications Application Pools:
We ran the below command in order to list all the SharePoint Service Applications Application pools
COMMAND
Get-SPServiceApplicationPool | format-listRESULT
- Name : SecurityTokenServiceApplicationPool
ProcessAccount : S-1-5-21-3855947664-3092534411-819001659-1127
TypeName : Microsoft.SharePoint.Administration.SPIisWebServiceApplicationPool
DisplayName : SecurityTokenServiceApplicationPool
Id : ea6fdac5-f1d5-4284-8fc4-b70d633fac90
Status : Online
Parent : SPIisWebServiceSettings Name=SharePoint Web
Services
Version : 2852
Properties : {}
Farm : SPFarm Name=Sharepoint_Config
UpgradedPersistedProperties : {}
ProcessAccountName : - Name : SharePoint Hosted Services
ProcessAccount : S-1-5-21-3855947664-3092534411-819001659-1128
TypeName : Microsoft.SharePoint.Administration.SPIisWebServiceApplicationPool
DisplayName : SharePoint Hosted Services
Id : 6183b7e5-8939-474b-bbed-40f04a8c925a
Status : Online
Parent : SPIisWebServiceSettings Name=SharePoint Web
Services
Version : 9772
Properties : {}
Farm : SPFarm Name=Sharepoint_Config
UpgradedPersistedProperties : {}
ProcessAccountName : - Name : SharePoint Search Application Pool
ProcessAccount : S-1-5-21-3855947664-3092534411-819001659-1128
TypeName : Microsoft.SharePoint.Administration.SPIisWebServiceApplicationPool
DisplayName : SharePoint Search Application Pool
Id : ad785e4f-d5f3-4ec1-81c2-9ef6850381a9
Status : Online
Parent : SPIisWebServiceSettings Name=SharePoint Web
Services
Version : 10236
Properties : {}
Farm : SPFarm Name=Sharepoint_Config
UpgradedPersistedProperties : {}
ProcessAccountName : - Name : SharePoint Web Services System
ProcessAccount : S-1-5-21-3855947664-3092534411-819001659-1127
TypeName : Microsoft.SharePoint.Administration.SPIisWebServiceApplicationPool
DisplayName : SharePoint Web Services System
Id : a4007afd-aa3b-4a96-95be-7721cbf9357e
Status : Online
Parent : SPIisWebServiceSettings Name=SharePoint Web
Services
Version : 2883
Properties : {}
Farm : SPFarm Name=Sharepoint_Config
UpgradedPersistedProperties : {}
ProcessAccountName :
- Name : SecurityTokenServiceApplicationPool
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'
- Ran the below command to get spfarm accounts that were existent on SharePoint.
COMMAND
Get-SPManagedAccount "domain\spfarm" | select sidRESULT
Sid
---
S-1-5-21-3855947664-3092534411-819001659-1128
S-1-5-21-3855947664-3092534411-819001659-2516
- Hence, we found out that the old account SID is "S-1-5-21-3855947664-3092534411-819001659-1128"; Therefore, we ran the below commands to delete the managed account:
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
- Changing the Service Applications Application Pools was OK, and done using the same above commands Set-SPServiceApplicationPool.
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.
Comments
- Anonymous
April 09, 2018
Nice listing of steps for changing key SharePoint services. Very helpful, thanks.