New user of Bigfix here, and so far so good, except for the delay in downloading patches.
When I select multiple fixlets to install to a single Windows server, the main bigfix server only downloads one patch every 10 minutes. How do I configure it so that it can download multiple files at a time, and/or download them more frequently than every 10 minutes?
Downloading 6 files an hour is terrible! Imagine if I have servers that need 50+ patches (8+ hours to download) the same day.
A bit more background info:
UDP is not enabled as this is a NATâd environment, so I am only using the Command Polling.
Something doesnât sound right there⌠I donât see these kinds of delays (but I usually do configure my actions ahead of time, with an âAction Start Timeâ set in the future, so I might not notice if there were download delays).
Even if the BES Server is only downloading one file at a time (which I donât expect is the case), it shouldnât wait ten minutes between downloads.
The _BESClient_Download_RetryMinutes affects how long it takes the server to retry, after a download fails. _BESClient_Download_CheckAvailabilitySeconds affects how frequently a client/relay checks to see whether the file is available from its upstream relay (in cases like yours where the UDP notifications wonât make it down to the client).
Thanks Jason, I guess those settings arenât relevant in this scenario. Surely there must be something else though.
It definitely doesnât download more than one fixlet at a time in a multiple action group.
If there are 2 files (ie: x86 & x64) in a fixlet, it will download the 2nd file immediately after the first file is finished downloading rather than waiting 10 mins.
The â\BigFix Enterprise\BES Server\wwwrootbes\bfmirror\downloads\sha1â folder on the Bigfix server shows the timestamps of each file. They are all 10 mins apart.
Oh, ok.
I donât have a particular insight on that, but I can posit a theory to fit the results. What it looks like to me, is that itâs waiting for your client to request the downloads before the server goes to fetch them. 10 minutes would fit well with the client report interval. The client, having received a baseline, may only be requesting the next download after completing the previous component.
Try checking the box for âStart client downloads before constraints are satisfiedâ checkbox on the Take Action / Execution tab, and see whether that helps.
No luck unfortunatelyâŚ
One of those batches in the image above was using that option.
I tried again just now and still 10 mins between each download.
These latest files are less than 1mb in size and still have to wait 30 mins to download 3 files that total 1.8MB
Just to let you know, that is not expected behavior, looks like there may be something wrong in your environment. I think you should open a PMR and let the support team go through the logs with you to determine whatâs going on.
Hereâs a sample shot from my serverâs downloadsâŚ
After 20+ mins the status hasnât changed in the console.
It says âPending Downloads (member action 00-728)â which is the first of the 3 fixlets. It has downloaded all 3 though.
I get that itâs because itâs not updating the status immediately since we are in NAT environment, but does that affect the downloading of file from Microsoft from the Bigfix server as well?
I created the action from the bigfix server because those patches were relevant to the agent. Does the server then download what has been configured in the action, or does the agent need to request them after itâs told that it can have them?
Just to be sure, the screenshot you posted earlier with the timestampsâŚthat was a directory on your BES Root server? By default C:\Program Files (x86)\BigFix Enterprise\BES Server\wwwrootbes\bfmirror\downloads\sha1 ?
The âPending Downloads (member action 00-728)â message is actually an action status from the client. This can be delayed significantly because this status only gets updated when the client posts a report - so itâll say âpending downloadsâ while the server downloads the file, while the relay downloads it from the server, and while the client downloads it from the relay. Once the client downloads the file, its report back up to the server can be delayed while the client is busy running the downloaded patch, or waiting for its next scheduled report interval.
To see the file download status at the server, youâd need to look at the Summary tab of the Action History. For a Baseline, youâd need to select the component individually and look at its Summary tab. Example
This could have statuses of âCached on serverâ; âDownloadingâ (and showing the bytes downloaded / bytes total counts); or several different failure codes (file not present on website, website unreachable, downloaded file doesnât match expected sha1, etc.)
Please let us know the results of the support case.
There are some settings with which you might experiment on the server/relays, but I honestly havenât needed to tune these. The full list is at IBM Documentation
Servers/Relays:
_BESGather_Download_ChannelThreshold
BigFix Gather can simultaneously download two files at a time by using one âmain channelâ and one âthin channelâ. The main channel is used for all downloads, but if the main channel is currently downloading a large file, the thin channel can be used to download smaller files if the download size is less than the specified threshold. If this setting is set high, BigFix Gather will use the thin channel to download larger files, which could slow down actions because two large files may be downloading at the same time (each using half the bandwidth) instead of one file after the other. If this setting is set low, the thin channel will be used for only very small file downloads.
Clients:
_BESClient_Download_MinimumDiskFreeMB
This setting stops both stages of downloading (normal stage and pre-caching stage) if the free space of the disk on which the client stores downloads is less than the value of this setting.
_BESClient_Download_NormalStageDiskLimitMB
This setting stops normal stage downloading if the client is already using this much normal stage download disk space. Actions marked for normal downloads will report constrained if the total space used for downloads exceeds this limit.
Note
Normal stage downloads may exceed this limit by borrowing some space from the pre-cache stage space if it is not full.
_BESClient_Download_PreCacheStageDiskLimitMB
This setting stops pre-cache stage downloading if the client is already using this much pre-cache stage download disk space. Actions marked for pre-caching will report constrained if the total space used for downloads exceeds this limit.
_BESClient_Download_ChannelThreshold
The BigFix Client can simultaneously download two files at a time by using one âmain channelâ and one âthin channelâ. The main channel is used for all downloads, but if the main channel is currently downloading a large file, the thin channel can be used to download smaller files if the download size is less than the specified threshold. If this setting is set high, the BigFix Client will use the thin channel to download larger files, which could slow down actions because two large files may be downloading at the same time (each using half the bandwidth) instead of one file after the other. If this setting is set low, the thin channel will be used for only very small file downloads.
_BESClient_Download_DownloadsCacheLimitMB
This configuration setting sets the BigFix Client download cache limit (TEM 6.0+). The Endpoint Manager client keeps all files that were cached in the same day, regardless of the download cache limit. If there is only one file which is larger than the configured download cache size, the Endpoint Manager client keeps this file, regardless of the age or the download cache limit.
I think I got it. Itâs working much better now.
Thanks Jason for sharing that link. I went through all config options listed on that webpage and added this one to retry every 1 minute.
Now the files are downloading quicker.
_BESGather_Download_RetryMinutes
When BigFix Gather fails to download a file from the Internet or its parent during an action, it will wait for the specified amount of time then try again.
Default value 10
Setting type Numeric (minutes)
Value range 0 - 1440
Server, Relay
Iâm glad itâs helping, but this also implies that the first attempt at each download is failing. I think you should still investigate why each first attempt fails.
I think what is happening is the client requests the download from the relay, the relay requests it from itâs parent, but itâs parent doesnât already have it so that request fails. The parent relay gets the download and then notifies the child relay over UDP but the child relay doesnât get it, so then it takes 10 minutes for it to check again.
I would recommend making sure that your BigFix Root Server and Relay caches are set to large enough values so they donât roll over too quickly, but also if UDP isnât working between relays, then setting _BESGather_Download_RetryMinutes to 1 is the right fix, though there are other settings that should ALSO be adjusted to help in these situations.
