ConfigMgr 2012 – Cache Management Surprise
(Originally posted 11/27/2013. Reposting for reference)
With disk space being relatively inexpensive these days, limiting the local ConfigMgr cache to 5GB by default seems almost stingy. However, since very few circumstances require one to set content to persist in the local cache, the assumption is that ConfigMgr will do its usual good work in purging out older content to make room for new should the cache bump up against that limit.
As it turns out though, the client behavior can lead to some problems if an exceptionally large volume of content is deployed to the client less than 24 hours from the time the machine was imaged. This was encountered recently with a client who had concerns about machines that were freshly imaged and deployed not receiving a particularly large application that was deployed to it post-image. In this case, the application media (Adobe Acrobat Pro with all available updates and hotfixes included) is approximately 2.5GB in size. The Task Sequence for image deployment contains numerous applications, including Microsoft Office and a few other large applications which comprise more than 3.5GB of content in total. When the client received the policy and looked to download the content, it found there was not enough available space in the cache. The CAS.log file spit back the following:
Not enough non-active cache to delete
Not enough space in Cache
CreateContentRequest failed
What is “non-active cache?” Well, as it turns out, the client has some rules as to how it manages the content cache. Amusingly enough, one has to go back to the SMS 2003 TechNet documentation to see how this works (the ConfigMgr 2012 version of the documentation is not as clear on the issue):
Managing the Advanced Client download cache is important if the client downloads and runs new advertised programs, but the cache is too full of active downloaded packages.
When a package is downloaded it is placed in the cache and locked. SMS does not delete a package from cache if it is locked. A package is unlocked when either of the following events occurs:
After SMS unlocks the package, it cannot be locked again unless it is discarded and then downloaded again.
When a package must be downloaded but the cache cannot accommodate the package, SMS checks the other packages in cache to determine whether deleting any or all of the oldest packages will free enough space to place the new package into the cache. If deleting any or all of the oldest packages does not free enough space, the new package is not placed into the cache. This might be the case if there is a package that is currently locked. If deleting any or all of the oldest packages does free enough space in the cache, SMS does so, and places the new package into the cache.
Does this still apply? It’s easy enough to find out. After re-imaging a test workstation, checking the client settings and c:\windows\ccmcache folder shows roughly 3.9GB of the 5GB cache taken up by content used during imaging:
Initiating deployment of the large application to this machine generated the same errors in CAS.log regarding “not enough space in cache.” To test whether the stipulations set forth in the TechNet article were still applicable, the system date was moved two days forward. When the Application Deployment Evaluation Cycle was run…
…the client immediately began purging content from the cache, starting with the oldest content available. In this case, it removed three of the oldest packages to free up enough space to download the new content.
So, among the available options are:
1. Increase the cache size
2. Manually clear the cache in the Control Panel applet
3. Don’t attempt to deploy significant content to a client until at least 24 hours after imaging
While it is conceivable that this situation could be encountered during regular operations if enough content were deployed in short order, this is most likely to be seen in a scenario similar to that described above, particularly when a large number of applications are included in the Task Sequence.
