I wanted to ask if anyone has a better explanation of these settings than what’s in the Client Settings listing. For example, when are they used (what Action processes kick of their use), when do they clear, etc…
_BESClient_Download_PreCacheStageDiskLimitMB
We set this to 1GB by default. We understand that this cache clears when the Action completes and/or on restart.
_BESClient_Download_NormalStageDiskLimitMB
We set this to 4GB for Windows 10 systems. We found that that worked when deploying the 4GB ISO (to upgrade to build 1607 for example). We’re not sure when this cache clears.
With those settings, we still see a status of “Disk Limited” when deploying the 4GB ISO on some systems. Increasing _BESClient_Download_NormalStageDiskLimitMB didn’t seem to resolve but increasing _BESClient_Download_PreCacheStageDiskLimitMB did. We often use “Start client downloads before constraints are satisfied” if that make a difference.
We don’t have a problem increasing these cache sizes but we don’t want overkill, cause harm, or leave a large cache of files. And with the new Monthly patching methods from Microsoft, wouldn’t it make sense for these to be set higher anyway?
The relays have plenty of space to keep these large files.
_BESClient_Download_PreCacheStageDiskLimitMB – Used when you press “Start downloads before action constraints are satisfied”, essentially this is a pre-cache cache limit.
_BESClient_Download_NormalStageDiskLimitMB – Used for normal downloads (not pre-caching).
_BESClient_Download_MinimumDiskFreeMB – The client will not download any files if doing so would put the client below this much free disk space.
Now whether a download hangs around after an action is finished is determined by:
_BESClient_Download_DownloadsCacheLimitMB – This determines how many downloads to cache from finished actions. All downloads from the same day are always cached (regardless of this value) – downloads from previous days are kept according to this value.
In environments that I manage I set them accordingly:
The way I see it – it’s only going to be used if it’s useful
The minimum free disk space prevents it from rendering clients unusable. For the Normal and PreCache Stage Disk Limit I don’t ever want to push out an action and not have it run because of the arbitrary client setting value. It just can’t ever fill the disk and as long as it doesnt do that I’m happy.
The DownloadsCacheLimit is what keeps things around after deployment (which i believe is useful if you are setting the large patches to re-apply on failure).
Additionally we only “cache” things that are left in the __Download directory after an action is run and generally we will try and download (up to the MinimumDiskFreeMB) a single file even if it is big but obviously will not keep it. This is the general rule but the client will TRY to do what you ask it to even if it doesn’t exactly match the settings.
The harder limits are definitely the PreCacheStageDiskLimitMB… we won’t go past that on the pre caching.
I’m unsure if these messages are related to the changes but I wanted to ask… In deploying a Windows 10 upgrade to Build 1607 as an Offer, the following messages appeared many times in the BigFix client log. Is this just normal processing and they can be ignored?
Thank you… it isn’t causing an issue. I just wanted to make sure it’s not indicative of an issue. It happened following the 1607 install and before the first reboot where it starts the upgrade. I suspect that as expected behavior and as you said, it will clean itself up afterwards.
This was part of the reason for the override command (the job option) as it will wait for spawned tasks. Often an installer will spawn the real work and the original program “ends” and we are left with a still locked file in the __Download folder and thus the next action will have an issue.
