For those of you who had the "pleasure" (okay, slight sarcasm there) of watching me in the SharePoint Ignite materials talk about distributed cache, you may recall that our guidance at the time SharePoint 2013 shipped was that you should not patch AppFabric on SharePoint servers independently - meaning that if it needed patching the expectation was that it would be delivered with a SharePoint patch and AppFabric patches should not be applied. Since that time, we've reviewed the plans there and have decided that in fact patching AppFabric directly is how it should be managed going forward. So you will see a KB article here that describes doing just that: http://support.microsoft.com/kb/2843251.
This has been causing a bit of confusion recently so we were lucky enough to get final clarification on this so folks can move forward. That being said now, you can (and should) go look for CU4 for AppFabric, because it has some bug fixes and performance improvements that will help you out in SharePoint land. You can find that at http://support.microsoft.com/kb/2800726.
Thanks for the update Steve. The first KB article mentions the new GC methods but doesn't describe adding the backgroundGC key to the Distributed Cache configuration file (explained in AppFabric CU3). Do you know if there will be a future SharePoint update
that will update this file to make use of the feature?
Sorry, I read the first KB too fast. It does reference CU3 and adding the key. Still would like to know if there is a plan for a future update to add this key automatically.
I was surprised to see that the first KB article you quote is dated May *2013*. So there are two possibilities. a) it's an old article and not the recent information your blog seems to indicate or b) it was recently revised but the person doing the revision
did not update the date of the article (as he/she should) when updating the version number to 2.0. [Over the past few years only major (n.0) KB article revisions have received new dates - leaving the date the same would have been correct if the version number
had been upped to 1.1.), here it is not.])
There's a number of reasons why the documented decisions may not be in sync, couldn't we just be happy that they now are? I recommend looking on the bright side every now and then...
Do you have to stop the distributed cache service instance (gracefully) first before patching or can you just launch the update on a running service without a problem?