Changing Service Accounts on a Distributed Cache Cluster in SharePoint 2013

Reading Time: 4 minutes

[Update March 30, 2017] These steps also work on SharePoint Server 2016.

It is a recommended security best practice to run the AppFabricCachingService in SharePoint 2013 as an account other than the farm account. You will see this as a health warning in Central Administration with the rule “The server farm account should not be used for other services.”

This post is to tell you about my experience when changing the account of a Distributed Cache Cluster in SharePoint 2013.

TLDR – skip below to the COMPLETE STEPS section for the correct steps on how to do this…

The steps to change the account are simple. Technet has the PowerShell to change the account documented here: .  Please note, NOWHERE in the steps does it advise you to stop the Distributed Cache service on the host before doing it. Now smarter people than me would likely have thought to do it anyway, but I didn’t and can only assume there are a few of you out there like me (either lazy or overly optimistic that somehow it would work without stopping it). I ran the PowerShell in a single-server farm environment (without stopping the Distributed Cache) and lo and behold it worked awesome!  Laziness had won the day (this time)!

I then moved on to a multi-server farm environment (2 web servers, 2 app servers, 1 db server) where 3 of the 4 SharePoint servers were Distributed Cache hosts as part of the Distributed Cache Cluster.

I started on the first cache host and tried performing the same PowerShell as above (again, WITHOUT first gracefully stopping the distributed cache service on the host).


The account was in fact changed on the service; however execution of the command removed the host out of the cache cluster and left the cache host in a “Disabled” state. It threw an error on the Deploy() step saying “TCP port 22234 is already in use.”

I entered Get-CacheHost to see what hosts were in the cluster and I could see that it wasn’t listed in the cluster anymore. I could also see the cache host was in a disabled state by executing the PowerShell below and looking for the Distributed Cache Service Instance on the server I had changed the account on:

Get-SPServiceInstance –server servername

Not to worry! TechNet had a resolution for me to repair the cache host. (It’s like they could see me coming…) The steps to document this are here:

$s = Get-SPServiceInstance GUID

These commands were completed.  No errors were returned, but it did NOT add the cache host for the server back into the cluster. Hmmmm, now what? Any further attempts I made to work with the cache generated a plethora of errors including “Specified host is not present in cluster.” and “cacheHostInfo is null”

I then started seeing a new Health Analyzer warning appear for the server which I had just attempted to change the password on: “This Distributed Cache host may cause cache reliability problems.”  Technet’s resolution for this is either to start the Distributed Cache service on the server (already tried this and it didn’t work) OR remove the cache host from the cache cluster.  Link to this here:

I removed the cache host from the cache cluster (Remove-SPDistributedCacheServiceInstance) and then added the same cache host back into the cache cluster (Add-SPDistributedCacheServiceInstance). Alas, this fixed the problem!

Want to avoid these problems?  Read on. 🙂


Here are the correct PowerShell steps to change the service account of the AppFabricCachingService on each host in the Distributed Cache cluster :

Set the context of your PowerShell session to your cache cluster:


Gracefully stop the host you want to change the password on:  Stop-CacheHost –hostname hostname –cacheport 22233 -graceful


Wait until the service is in a stopped state (DOWN): Get-CacheHost


Remove the distributed cache host from the cluster:   Remove-SPDistributedCacheServiceInstance


Change the service account:

$farm = Get-SPFarm
$cacheService = $farm.Services | where {$_.Name -eq “AppFabricCachingService”}
$accnt = Get-SPManagedAccount -Identity <domain\accountname>
$cacheService.ProcessIdentity.CurrentIdentityType = “SpecificUser”
$cacheService.ProcessIdentity.ManagedAccount = $accnt

Add the distributed cache host back into the cluster:  Add-SPDistributedCacheServiceInstance


You can now verify the account has changed via services.msc – check the Log On As account for the AppFabric Caching Service


Once you have done these steps for all hosts in the cluster, cross your fingers and rerun the health analyzer rule “The server farm account should not be used for other services.”.  The AppFabricCachingService Windows service should no longer be listed.


My key takeaway from this experience is to ALWAYS gracefully stop a distributed cache service host and remove it from the cluster whenever doing any kind of maintenance on it.  This is always the safe and prudent thing to do.

Thanks for reading.



  1. Hi! Thank you very much, this helped a lot! One note: there’s a typo in the cacheport parameter in your script. it should be port 22233.

  2. Question on this… I recently migrated to SharePoint 2016 and am getting the warning in the Health Analyzer and so I would like to change the service account for the Distributed Cache. The Health Analyzer indicates that I can change it via Central Administration. Should I be doing this with the PowerShell commands instead or was this optimized in 2016 and I can therefore do this via Central Administration in the Configure Service Accounts page?

    1. Hi NWChickie,

      I would use PowerShell as I doubt changing the service account via Central Admin would gracefully shut down the hosts in your cluster before making the change – I’ve never tried, but I wouldn’t do it.
      You can also refer to Microsoft’s latest guidance on this where they also recommend using PowerShell: the service account

      However… that isn’t taking into account a distributed cache cluster with multiple hosts and how you would change it for those – this is what my blog post covers. I’m not sure if you have multiple hosts in your configuration or not, but if you do, you need to ensure you complete the change for each host in a controlled, graceful manner.

      Hope that helps,

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.