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!



Catch 22 with SPD workflow and checking in documents

I recently had to build a workflow in SharePoint Designer to model a fairly lengthy approval process for policy documents involving multiple stages of review, each of which has to be passed before the draft document moves to the next review stage. The workflow itself was quite long but essentially boiled down to a series of repeated steps. Each step involved assigning a task to a reviewer (or reviewers) and then updating the status of the document to show what stage it was at. The Policies document library has enforced check in/out, version control, and content approval all turned on. I also needed a field called Review Stage to show what stage the document was at – that was a simple choice field with 7 different stages.

Version History

The obvious thing was to add the Review Stage field to the document library.  After some playing around with the workflow, however, I decided to do things a more complex way.  I created a new list called Document Review Stages with two fields, one was the choice field Review Stage and the other was a number field called DocumentID.  For each policy document in the document library, there is a corresponding entry in the Policy Review Stages list.  The DocumentID holds the ID (the built-in column that SharePoint populates automatically) of the policy document.  In other words, I effectively created a one-to-one relationship between the Policies document library and the Policy Review Stages list.  Of course, this being SharePoint and not a full-blown database, this isn’t a proper relationship – there’s no enforced referential integrity, no cascading updates, etc.  But the basic principle is the same.

So why did I do it in this convoluted way?  Well because the Policies document library has enforced check-in/out and major/minor version control.  So suppose I had the Review Stage column on the Policies document library itself.  That would mean any change to the document, even just changing its metadata, would create a new version.   And that means that the workflow, if it wants to progress the document to the next review stage, would have to first check out the document, then set the Review Stage field, then check the document back in again.  And you’d then have 2 versions of that document, both exactly the same in content, but with different Review Stage metadata values.  This would result in a confusing version history for each document, with some genuinely different versions of the document (edited by different reviewers) but also many identical copies of each document created automatically by the workflow as it moves the document through the review stages.  By moving the  Review Stage column to a different list, the workflow can update the Review Stage field without creating a fresh copy of the document in the version history. That makes the version history much cleaner and more readable.

Approval Catch-22

This being a SharePoint Designer workflow, not a Visual Studio one, I had to attach it to the Policies document library.  I got the workflow to find the Policy Review Stages list item related to its corresponding policy document, and update the Review Stage column on the list.  So far so good, but then right at the end of the workflow, the last step was to make the document go live by setting its approval status to be “Approved”.  There’s a special workflow action to do just that, so it seems easy enough.  But there’s a catch.  If you want to make the document Approved status, you have to change it, and the workflow complains if you try to change it without first checking it out.  OK, so you change your workflow to check the document out first, and then approve it.  But now the workflow complains because you can’t approve a document that is checked out.  Catch-22!

So how do you get round this?  Well you can use the Start Another Workflow action to start the normal Approval workflow on the document.  The built-in Approval workflow can work with a document that’s not checked out.  So you end your workflow early, before the final approval task is allocated, and hand off control to a standard Approval workflow to manage the final approval step.