Troy Wilch

Time to get generous with ConfigMgr R2 client cache sizes

One of the nice things about being a consultant is gaining collective knowledge in how organizations run and operate their SMS/ConfigMgr environments. One of the things I run across from time and time again is, folks are stingy when it comes to client cache sizes.

The down side of setting the cache too small is if you have it set for say 1024 and you now want to deploy a large package(which is not always recommended to run from DP), it needs to bring the entire package down into cache before running. Now it will try and purge the cache to make room, but if it can't make it available or the package is too large, the package fails to install. This happens all too often I've seen.

Remedies:

1. Use the SMSCACHEFLAGS=PERCENTFREEDISKSPACE.
   • You can use this along with SMSCACHESIZE=40 in your client install properties to set the cache to 40% of total free space at the time of installation. So if a machine has 10Gb free space, the cache will be set to 4096 of allowable space. This doesn't mean that after installation, the machine is left with 6Gb of space, only that it can grow to 4Gb of cache.
2. Use the Cache enlarger script.
   • To set the percentages after the client is already installed, you can use the attached script to run against machines to have it determine the value of free space available and then set the cache to a preset percentage.
3. Set Cache Size with Right click tools
   • You could get creative with collections and base the criteria for them off different space available on client machines. Then use the right click menu add-on to set the client cache with a preferred amount. while this may be easier, it's harder to establish what is a good size for a collective amount of machines without going crazy with a bunch of collections.

While SMS 2003 defaulted to only 250Mb of cache size, MS increased this to a default of 5120 unless specified differently. I believe this could be due to OS deployment being a popular feature in ConfigMgr and 250Mb is no size for deployments.

So where am I getting at here with all this Cache Size stuff?

Glad you asked. In Release 2 for ConfigMgr 2007, App-V will make a big hit as it is now being integrated into ConfigMgr. As you already know, SMS/ConfigMgr has had 2 different deployment types to it's clients:

1. Run from DP - This is generally good for smaller-medium size packages as the packages stay on the local distribution point and runs from there. 
2. Download and Execute - transfer a copy of the package to the client cache and install locally from there. If your installing Office 2007, this could take up 1-2Gb alone. After installation, this content is not always removed. There is a cycle that should routinely purge old packages or purge when space is needed. This doesn't always happen though.

Now with App-V, though a little different in name, it is close in principle. With an App-V advertised package, you have 2 choices:

1. Stream from DP - This is where the SFT (main App-V file) is left on the DP and streamed down to the virtual client cache and launched. For this method, the only space being consumed on the client here is the APP-V cache. It's a whole other cache value set, but the ConfigMgr cache is not utilized.
2. Download and execute - It transfers the SFT file for the App-V package to the ConfigMgr cache, then when the application is launched, it also loads the virtual app into the App-V client cache.

The thing to understand and take away is, the space requirements for download and execute of virtual applications double as both caches contain copies of the packages. The SFT file is left pinned to the ConfigMgr cache for any repair needs of the virtual application. But at this time, the normal cleanup process won't remove the SFT files from the ConfigMgr cache. So either plan to use the streaming delivery method when possible or plan to allot the space requirements for Virtual applications.

SMS Cache Enlarger Script