Download retry settings

I’ve configured the download retry settings on the root & relay servers, plus clients but it doesn’t seem to be making a difference.

Recently we deployed a baseline that included an update to Chrome. As you may know when Google updates Chrome to a newer version (which they do often) the older version is no longer available to download. These clients were stuck trying to download the file that no longer exists. For hours.

I saw this post about setting the various download parameters to prevent this from happening but it doesn’t seem to have made a difference.

On the root & relay servers, I set:

_BESGather_Download_RetryMinutes to 5
_BESGather_Download_RetryLimit to 3

On each client, I set:

_BESClient_Download_RetryMinutes to 5
_BESClient_Download_RetryLimit to 3

Did I miss something?

Does anybody have an idea about this?

The settings are documented here - https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/r_client_set.html

It doesn’t actually say what should happen when the retry limit is exceeded

The document does have a link ‘BigFixTroubleshooting Downloads’ but it doesn’t actually go to page dealing with that subject

But you don’t appear to have missed anything - it seems reasonable to expect your actions to fail once the retry limit has been exceeded

I’ll also check on the expected behavior, I’m not actually sure what it is if it’s not publicly documented. I’ve also expect the action to fail, but I don’t know whether we should expect a baseline to continue running the other components.

I’ll also check on the expected behavior

Thanks, let me know what you find.

6 posts were split to a new topic: FireFox 109 / 110 Download Issue

The information I have so far is not the answer I’d like, I’m still looking for alternatives.

The logic on the client side for _BESClient_Download_RetryMinutes and _BESClient_Download_RetryLimit is only triggered once the client download actually begins - and the downloads don’t start until the Relay actually has the download cached. Since the Relay never gets the download cached, the Clients never actually start the download, and the retry limits don’t apply to the client. It seems these settings were mostly intended to resolve issues in the Direct Download case, not to handle Relay-downloaded cases.

A potential workaround is to configure the clients to do Direct Downloads - either globally using the _BESClient_Download_Direct setting or on a per-site basis via _BESClient_Download_Direct_Domainlist to configure direct downloads for google.com or mozilla.org or whatever.

A potential workaround is to configure the clients to do Direct Downloads - either globally using the _BESClient_Download_Direct setting or on a per-site basis via _BESClient_Download_Direct_Domainlist to configure direct downloads for google.com or mozilla.org or whatever.

Unfortunately many of our devices are not able to access the Internet so that option wouldn’t work for us.

The information I have so far is not the answer I’d like, I’m still looking for alternatives.

Any more info on this?

Bumping this thread as I got burned by this issue (again). Are there any settings that can be used to avoid this from happening? Even if you have internet access I don’t believe enabling direct downloads will help. The fixlet still needs to check the file size and sha values doesn’t it? Is the pre cache wizard something that can be interacted with via the api. I’m thinking about (if possible) running a daily script that will create a baseline with all the third party/extended 3rd party apps and pre cache the patches as a workaround.

Looks like this has been discussed in the past in other threads. Going to try Jason Walker’s suggestion in this post How to handle Google Chrome?