Following my post earlier this week Administering Distributed Cache in SharePoint 2013, today I will explain how to export and import the Distributed Cache in SharePoint 2013 – this is a very useful quick-get-me-out-the-doghouse process, but more importantly will hopefully help you grasp an even deeper understanding of SharePoint 2013. The tutorial here will assume that you either have a) a known-working Distributed Cache server in your Farm or, b) a suitable Farm that reflects your Production environment. Either way, I suppose the assumption is you actually have a working Distributed Cache server somewhere. There are a number of reasons that you would need this process in your arsenal; disaster recovery, re-configuration, curiosity, etc. Whatever your reasons, please bear in mind that the Distributed Cache can be a sensitive beast and needs to be treated with a little care and attention… that is to say; don’t do anything you’re not confident doing, always check your spelling and syntax, and if in doubt call in an expert.
Exporting
First things first, you probably want to know how to look at the configuration, right? Yeah, me too 🙂 From your Distributed Cache server, open an elevated Management Shell and execute this cmdlet, of course replacing everything in [square brackets] with the variables to suit your environment / preference:
Use-CacheCluster
Export-CacheClusterConfig [C:DistCacheConfig.xml]
Remember, always execute the Use-CacheCluster cmdlet before starting any work with the Distributed Cache. Now, open that configuration file you just exported in your favourite editor and have a look, it’s all pretty self-explanatory. Tip: It’s not uncommon nor bad practice to include the export in your backup regime.
Import
So, how about that import? Well, it’s just a little bit more involved than simply importing a file. Before we get going, I know I’m about to go against my own words of “do not manage SharePoint from Windows Services”, but chances are if you are importing the configuration, it’s because you are already in a disaster recovery situation, so going against the standard guidelines is ok, within reason. The process here will only instruct you how to import the configuration, not repair or change it.
- It should go without saying, but export the configuration first and save the XML to a safe location
- Open Server Manager and disable the AppFabric Caching Service from within the Windows Services container
- Once you have set the service to “Disabled” and applied the changes, go ahead and stop the service (do not do this before apply the changes otherwise SharePoint will see the service stop and restart it for you)
- Repeat those steps on all your Distributed Cache servers until all instances are disabled and stopped in the Farm
- Now, from your Management Shell (elevated of course), execute this cmdlet:
Use-CacheCluster
Import-CacheClusterConfig [C:DistCacheConfig.xml] -Confirm:$false
- If the Import-CacheClusterConfig fails with an error “Import-AFCacheClusterConfiguration : ErrorCode<ERRCAdmin001>:SubStatus<ES0001>:Hosts are already running in the cluster” you probably still have AppFabric Caching Service instances running
- After the import has completed, re-enable (do not start) the AppFabric Caching Service from within the Windows Services container on all your Distributed Cache servers
- From the Management Shell opened previously, execute this cmdlet:
Start-CacheCluster
- All your Distributed Cache servers should now show “UP”
HostName : CachePort Service Name Service Status Version Info ——————————————————————- Server1.contoso.com:22233 AppFabricCachingService UP 3 [3,3][1,3]
Server2.contoso.com:22233 AppFabricCachingService UP 3 [3,3][1,3]
- Finally, why not carry out a few sanity checks to ensure everything is healthy again? Execute these cmdlets and make sure everything looks good:
Get-CacheClusterHealth
Get-Cache
Configuration File
Before I finish, I wanted to share a scenario where a client had lost a Distributed Cache server and re-built it with a different hostname (I wouldn’t recommend this as a disaster recovery process by the way). Obviously I have sanitised the actual data but assume the scenario is two Distributed Cache servers (CacheServer1 and CacheServer2) and one server broke (CacheServer2) and was re-built (CacheServer3). When I exported the configuration file, I jumped to the <hosts> element and could see where the problem was:
<hosts> <host replicationPort=”22236″ arbitrationPort=”22235″ clusterPort=”22234″ hostId=”123456″ size=”800″ leadHost=”true” account=”contososa_sps_services“ cacheHostName=”AppFabricCachingService” name=”CacheServer1.contoso.com” cachePort=”22233″ /> <host replicationPort=”22236″ arbitrationPort=”22235″ clusterPort=”22234″ hostId=”345678″ size=”400″ leadHost=”true” account=”contososa_sps_services” cacheHostName=”AppFabricCachingService” name=”CacheServer2.contoso.com” cachePort=”22233″ /> <host replicationPort=”22236″ arbitrationPort=”22235″ clusterPort=”22234″ hostId=”987654″ size=”400″ leadHost=”true” account=”contososa_sps_services” cacheHostName=”AppFabricCachingService” name=”CacheServer3.contoso.com” cachePort=”22233″ /> </hosts>
So, I removed the offending element from the XML file as such:
<hosts> <host replicationPort=”22236″ arbitrationPort=”22235″ clusterPort=”22234″ hostId=”123456″ size=”800″ leadHost=”true” account=”contososa_sps_services“ cacheHostName=”AppFabricCachingService” name=”CacheServer1.contoso.com” cachePort=”22233″ /> <host replicationPort=”22236″ arbitrationPort=”22235″ clusterPort=”22234″ hostId=”987654″ size=”400″ leadHost=”true” account=”contososa_sps_services” cacheHostName=”AppFabricCachingService” name=”CacheServer3.contoso.com” cachePort=”22233″ /> </hosts>
Then I followed the import process outlined above and the Distributed Cache started up with no problems and, once reanalysed, the associated Health Analyzer messages cleared!
Hope this was a useful post and have a great day!
