When planning a System Center ConfigMgr Manager and Nomad implementation or when integrating Nomad into an existing ConfigMgr environment, I'm often asked "How big does the ConfigMgr client cache need to be to accommodate Nomad?" Or, "Do we need to change the ConfigMgr client's cache size to accommodate Nomad?"
The short answer is, "It doesn't matter."
Now, when I say "It doesn't matter", I don't mean that the size of the ConfigMgr client cache doesn't matter at all. On the contrary, it’s a critically important design decision. If it's too small, software distribution success may suffer. If it's too big, you risk the ConfigMgr client's cache growing to completely fill the drive's remaining space. Either way, an improperly sized client cache size will lead to operational headaches… Nomad or not. I say it doesn't matter, because when determining the proper ConfigMgr cache size for your environment you don't need to factor in, or accommodate for Nomad.
Many incorrectly presume that a larger, or oversized, ConfigMgr client cache allows Nomad to operate more efficiently because the more content that remains in ConfigMgr client's cache means more content is available to Nomad for local redistribution. The fact is, however; an oversized ConfigMgr client cache doesn't benefit Nomad. The best thing you can do to ensure Nomad operates optimally is to ensure that ConfigMgr software distribution works reliably by selecting a properly sized ConfigMgr client cache.
Before I share two factors that should determine the proper cache size for your ConfigMgr clients, let's review some fact about how the ConfigMgr cache operates and its interaction with Nomad.

  • The ConfigMgr client and Nomad each independently maintain and manage their respective cache directories.
    • The ConfigMgr client's default cache size is a static size of 5 GB.
    • Nomad's default cache size is more dynamic and based on the currently available disk space. (Nomad's cache never grow such that less than 10% of total disk space remains available.)
  • Files downloaded by Nomad are hard-linked to the ConfigMgr cache directory. (Hard-linking allows the cached content to appear in both locations without doubling the required storage.)
  • Content downloaded directly by the ConfigMgr client (outside of Nomad) is not hard-linked to the Nomad cache.
  • When Nomad determines some of its content must be removed to clear space for incoming content (Automatic Cache Cleaning), Nomad also removes the selected content from the ConfigMgr cache. This is also the case when content is removed using the Nomad CacheCleaner.exe utility. Below is a snippet of the NomadBranch.log deleting version 2 of package XYZ0001D from both the Nomad and ConfigMgr cache.

PrepareDeletion XYZ0001D(2) CacheManager
ConfigMgr:DeleteCacheContent XYZ0001D(2) CacheManager
Nomad:DeleteCacheContent XYZ0001D(2) CacheManager
Deleting C:\ProgramData\1E\NomadBranch\XYZ0001D_Cache_deleting(2) CacheManager

  • However, when the ConfigMgr client removes content from its cache, even when it is hard-linked to the Nomad cache, it remains in the Nomad cache (and is still available from redistribution to its peers on the subnet via Nomad). Yes, you could call this is a one-way street.
  • Before the ConfigMgr client ever invokes Nomad to download content, the ConfigMgr client checks the available ConfigMgr cache space. If additional space is required for the download, the ConfigMgr cache begins deleting packages from its cache to make space. (Again, any content the ConfigMgr client removes still remains in the Nomad cache.)
  • Any content placed in the ConfigMgr cache, has a default "tombstone age" of 24 hours. This means that ConfigMgr will never remove this newly/recently downloaded content until the tombstone age has passed, regardless of circumstance.
  • When the ConfigMgr cache cannot create sufficient space for the incoming content, the client returns an error to ConfigMgr, never invoking Nomad.

Based on these facts, we can see that a reasonable and properly-sized ConfigMgr client cache setting allows Nomad the space it needs.
Most likely, the default ConfigMgr Cache size of 5 GB is going to be too small in your environment, but exactly how big should it be? I recommend you size the ConfigMgr client cache to accommodate the larger of following two items:

  1. The largest single application, package, or operating system image you'll want to deploy in your environment. (Now and in the foreseeable future).
  2. The amount of content you expect to be deployed to a system in a 24 hour period (refer to the default "tombstone age", above).

Identify the size of each, select the larger value and add a reasonable "buffer". For most of the enterprises I've worked with, we found the optimal cache size to be somewhere between 15-25 GB.