Increase Speed of Patch Installation

Are there things we can do to make the installation of the monthly Microsoft Security Rollup faster? I’ve noticed that WSUS installs take far less time and wanted to know if there were things we could do to make it faster from a BigFix POV.

On AIX I’ve added task “BES Client Setting: CPU Usage” at beginning and end of the baseline to allow higher cpu consumption during patch installation and lowering it afterward.

Might be worth to give it a try.


Pre-caching the installer on the system in the action would also help.

Another option from the CPU perspective might be to keep the CPU level elevated but to turn on client sleep mode.


One step that often takes some time is calculating and verifying the hash of the downloaded patch files. We can improve that step with a few client settings - see


This one setting will make the biggest difference. Strongly recommend it for all clients.

The other thing is to have the bigfix client check in sooner with it’s parent relay if a download is available. This makes a huge difference with baselines especially.

This is what it looks like in clientsettings.cfg format, not actionscript:


What does _BESClient_Download_RetryMinutes actually do? It tells the client to try to download the file from the relay, then again after 1 minute, then it does exponential backoff, where it will try again after 2 minutes, then 4 minutes, then 8 minutes, etc… until it hits it’s retry limit.

If you are only considering the time it takes for BigFix to start the specific actionscript line that does the actual install and then how long it takes for that line to complete, then that is something that should be equivalent to running the same command by hand on the command line. In that case, that is probably not something you can get to install much faster unless there is a command line parameter that would somehow cause it to install faster that we are missing, but I don’t know what that would be.

This will not make as much of a difference if _BESClient_Resource_WorkFastHashVerify is enabled on a supported client. (must be version 10+)

Pre-caching is a good idea in the cases where you are trying to patch within a narrow maintenance window.

I personally am a fan of this approach. Definitely recommend it for laptops, VMs, docker containers, and low CPU systems, but it is viable anywhere.

See here:


As with any change, I would recommend testing any of these options on a few systems first before rolling it out everywhere.

1 Like

These are great options and thank you. I’ve noticed that the primary issue is with the larger MSFT OS security update verses stuff like Firefox or WINSCP. The latter packages update quickly where the OS updates drag for hours sometimes.
Of the settings you mentioned, which would be best for helping that? We do precache files when we have the ability but a lot of times, we are at the whim of our customer’s moving-target maintenance window…

Sorry to go on a tangent but …have you looked into the Maintenance Window Wizard?

You can send one Patch action to all computers, with a constraint to “Run only when - In Maintenance Windows - is True”.

All the computers download the patches and then wait in a ‘Constrained’ status, until their maintenance window starts. And each computer or group can have a different maintenance window date/time/pattern defined.

All of the things mentioned above will help, but especially _BESClient_Resource_WorkFastHashVerify

The issue is that the larger the download is for the update, the longer it takes to compute the hash to verify that it is unmodified, both in terms of CPU, but also DiskIO.

1 Like

Cool cool. I will test this out and report back

for _BESClient_Resource_WorkFastHashVerify, what is the recommended value setting?

I’d start by setting _BESClient_Download_FastHashVerify to 1, to enable the FastHashVerify at all, then start with the default value for _BESClient_Resource_WorkFastHashVerify and see how much difference that makes; then start tuning that value.

The ‘optimum’ value for WorkFastHashVerify may vary based on your processor, disk throughput, and download sizes, but enabling it at all should make a significant improvement.