The distributed cache was a great idea introduced with SharePoint 2013. \u00a0It truly allows for a load balanced, highly available SharePoint farm where a user no longer needs to retain server affinity. \u00a0If I logged in on web front end 1 somehow get routed to web front end 2, no issues, lets just pull your login tokens, viewstate, and news feeds\u00a0from this new cache shared across all the servers.<\/p>\n
That said, so far maintaining it in a large enterprise environment has been a challenge. I have the opportunity(curse) of working in an environment of hundreds of SharePoint servers on premises. Our 2013 footprint is quickly growing; quickly enough that we can’t keep on top of say, manually, gracefully shutting down our distributed cache services every time an OS patch window rolls around.<\/p>\n
Oh and what about those times that Windows just doesn’t want to play nice and a server blue screens, or worse just hangs. At this point we’re left with a server with an empty cache, which every other server in the farm thinks should have all of our logon tokens!<\/p>\n
SP: Access Denied!!!
\nBrowser: but I have a valid FedAuth cookie still!
\nSP: Yeah well I have no idea what happened to your claims so I’m not sharing
\nBrowser: but…FedAuth
\nSP:\u00a0I’m just trying to be nice, but I just don’t think this site has been shared with you.<\/p>\n
So where do we go from here. The ideal situation is that before a cache server is restarted, the service is gracefully stopped, then removed.<\/p>\n
Stop-SPDistributedCacheServiceInstance -Graceful
\nRemove-SPDistributedCacheServiceInstance
\n*thank the MS Gods\u00a0for autocomplete…<\/p>\n
And after reboot, re-added.<\/p>\n
Add-SPDistributedCacheServiceInstance<\/p>\n
But, can we fire that automatically for all reboot situations? Well, no, not easily.<\/p>\n
1) Any shutdown tasks will not save you in the case of a blue screen, hardware failure, or a guy in the data center tripping over the power cord. \u00a0 The other servers in the farm will not know to rebuild the cache, it’ll just keep sending the requests to the bads server.<\/p>\n
2) There is no ideal\u00a0way to run the Powershell on start up, as a farm account, and please don’t tell me your farm account is Local Service or Network Service on a multi-server farm. \u00a0The closes you can come is a start up script assigned to the local policy that calls a secondary script that has hardcoded credentials to impersonate a farm admin account.<\/p>\n
What we’re doing:<\/p>\n
1) record the last time each server had its distributed cache gracefully started. \u00a0SPServer.Properties is a good place for that<\/p>\n
2) Every 30 minutes or so, check this against the server’s last boot time (WMI)<\/p>\n
3) If the last reboot is more recent than the last graceful dist cache start up, tell the farm to rebuild that server’s cache.<\/p>\n
Sprinkle in some (lots of) error handling and call it a day.<\/p>\n","protected":false},"excerpt":{"rendered":"
The distributed cache was a great idea introduced with SharePoint 2013. \u00a0It truly allows for a load balanced, highly available SharePoint farm where a user no longer needs to retain server affinity. \u00a0If I logged in on web front end 1 somehow get routed to web front end 2, no issues, lets just pull your … Continue reading My frustrations with the Distributed Cache<\/span>