ConfigMgr 2012 Client Cache – Part 1: Overview

ConfigMgr 2012 Client Cache – Part 1: Overview

I’ve been asked a few times lately about how the Client Cache works in Configuration Manager, where is it, what size it should be set to, how it behaves etc. so I thought that maybe it was time for a blog!

I’m intending for this to be split into two parts:

1 – Overview

2 – Enumerating the Client Cache

 

What is it, where is it, and how big is it?

Essentially the client cache is a temporary download location for software, applications and software updates that are deployed to a client. By default the client cache is located %windir%\ccmcache but you do have the option of changing this at install time by using the SMSCACHEDIR parameter e.g. CCMSetup.exe SMSCACHEDIR=C:\Temp.

By default the cache size is 5120 MB, but again we can change this by using the SMSCACHESIZE parameter at install time e.g. CCMSetup.exe SMSCACHESIZE=10240. This would install the client with a cache size of 10GB. You can also change these settings post install either directly on the client itself using the Control Panel applet (See below), or for larger scale changes, by deploying a script.

 

 

 

Determining the size of the cache

So, what determines how big the cache should be, and what do I have to bear in mind when I set the cache size? Essentially, you need to ensure that your cache size is larger than any deployment you are going to send to a client. Software updates also use the client cache, but software updates are NOT restricted by the cache size and will always attempt to download to the cache

If the client attempts to download content that is greater than the size of the cache, the deployment will fail due to insufficient cache size and Configuration Manager generates a status message with the ID of 10050.

If the client attempts to download content that is less than the size of the cache but the cache is currently full, all required deployments keep retrying until the cache space is available, until the download times out, or until the retry limit is reached for the cache space failure. If the cache size is increased later, the Configuration Manager client attempts to download the package again during the next retry interval. The client tries to download the content every four hours until it has tried 18 times.

If the cache size is increased later, the behaviour of required programs and required applications are different. A required program will not automatically retry to download, you need to redeploy the content. As Applications are state-based, the client will automatically retry the download when it next receives client policy

Bear in mind that if there are required dependencies on an application, these will also be downloaded as part of a deployment. So actual total cache cost of application = Application + Dependencies

Cache Maintenance

So, does the cache actually maintain itself? Well, content remains in the cache for at least 24 hours, after that time it’s available to be overwritten by new content if it requires the space. If you configure your packages to persist content in the client cache, the client will not automatically delete the package/overwrite content in the cache. If the client cache space is used by packages that have been downloaded within the last 24 hours and the client must download new packages, you can either increase the client cache size or choose the delete option within the control panel applet of the client to delete contents of the cache. (See screenshot above)

 

So, that’s it for Part 1, an overview of the cache, the way it behaves, and how it’s maintained. For Part 2 we’ll look at how we can enumerate the client cache and pull back some more information on it back into Configuration Manager, so that we can then report on it.