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: https://technet.microsoft.com/en-us/library/jj219613.aspx#changesvcacct .  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).

AND THIS IS WHERE MY TROUBLES BEGAN…

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: https://technet.microsoft.com/en-us/library/jj219613.aspx#repair

$s = Get-SPServiceInstance GUID
$s.delete()
Add-SPDistributedCacheServiceInstance

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: https://technet.microsoft.com/en-ca/library/jj891108.aspx

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. 🙂

---

COMPLETE STEPS

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:

Use-CacheCluster
Get-CacheHost

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
$cacheService.ProcessIdentity.Update()

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.

---

THE END

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.

-JCK