Changing the Distributed Cache Service from One Server to another

Not gonna make this a long one because things are really busy. If you are getting to this post you should have an idea what the Distributed cache service is all about, if not here is a summary…

The Distributed Cache service is either required by or improves performance of the following features:

  • Authentication
  • Newsfeeds
  • OneNote client access
  • Security Trimming
  • Page load performance

For an overview of the Distributed Cache service, see or in plain English

I have some SharePoint 2013 environments I use for demos and the likes. one such environment has 4 servers, on Domain controller, a VPN server for networking, another for SharePoint 2013 as a web front end and the last one a SharePoint 2013 server dedicated specifically for managing the Distributed cache service. Now I have inherited this particular set of environments from Microsoft with dummy content on so I don’t have to work too hard at developing features for demos and POCs. My lap top has a max 16GB RAM so running all 4 servers in my hyper v is very resource consuming so I needed to find a way of minimizing the RAM requirements so I could use the machines all together without compromising on performance.

Although not totally necessary to have the distributed cache on a dedicated server unless you have a large farm, I decided to remove the need for the dedicated Distributed cache server as the farm is for use of about 100 users. That would save me about 8gb RAM! So no need for a dedicated cache server. But I do need to preserve the data on there and somehow transfer it to somewhere else where there is a valid service for the distributed cache, available to consume the data, the other web front end perhaps? Correcto! And then remove the service from the dedicated server and put the beast to rest.

So in Lamen’s terms…

Web Front End with Distributed Cache Service (dedicated) = WFE-DC

Web Front End with The Rest Of the SharePoint Services available = WFE-ALL

Some constants –

WFE-ALL has App fabric installed, necessary for the Distributed Cache and firewall is deactivated for the domain or  allows inbound ICMPv4 traffic. If you need Windows Firewall, you can enable this in PowerShell with the Set-NetFirewallRule cmdlet. The name of the rule is “File and Printer SharePoint (Echo request – ICMPv4-In)”. Notice also that it doesn’t take a Boolean ($true), but rather the string “True” as an argument to the -Enabled parameter. Don’t forget to Import-Module NetSecurity first, though! See below…


By now you’ve figured we need to use our new best friend Powershell to execute this master plan. Get used to Powershell if you wanna be a good developer/ architect, it can save you time and effort!

The Distributed Cache is one greedy kid, consuming a max of 10% total memory resource on any server it runs. So be aware of this when allocating memory to the server hosting the  service.

For whatever reason you need to move the Distributed Cache Service in a SharePoint environment,  here’s the master plan….

1.   Add the Distributed Cache Service to the WFE-ALL server to create a Distributed Cache Cluster (Fancy eh?). You need somewhere to move the cache data to when removing the service from the WFE-DC, to avoid data loss.

2.  ‘Gracefully’ shut down the Distributed Cache service on the WFE-DC. This will automatically move over all the data to the WFE-ALL server which is now part of the cluster. Its a long process, expect it to take around 15 mins or more depending on the amount of data in there.

3.  Them remove the service from the WFE-DC and it’s all done.

Now would you believe me if I told you this can be accomplished with 3 lines of Powershell??? Check this out…

1.  On WFE-ALL run the following:


2.   On WFE-DC run the following:

Stop-SPDistributedCacheServiceInstance -Graceful

Wait 15 mins, pour a drink or make a coffee, whichever poison tickles you fancy and then check the service is operational in its new location. Also test microfeed update settings in newsfeeds, this will be a good indicator of its state.

Other stuff you might need to manage at a later date are changing the service account, change the memory allocation or repair the host:

Pretty simple stuff peeps?

Peace, Love and SharePoint!