We group our patches to be deployed into a baseline, created a few days after Patch Tuesday and then scheduled to be deployed during our defined patch weekends.
Most of the time by the time that patch weekend rolls around, Google Chrome has been updated and the fixlet will hang as it tries to download a file that no longer exists. We have the Action set to retry 3 times in the event of a failure, as you can imagine this causes problems.
The majority of the clients update themselves but there are some that donāt have Internet access, those we update with BigFix.
Any suggestions about how to handle this? I could download the latest version each month and create a custom fixlet to be included in the baseline but thereās got to be a better way?
If you download and pre-cache the Google Chrome executable when the Fixlet is released, the OOB Fixlet action will work in your Baseline when it runs later in the month. The key is having the file in the cache that matches the SHA-1 and SHA-256 values present in the OOB Fixlet.
Maybe you could use a daily script to leverage the REST API to check for new Chrome fixlets released in the past x number of days and if a fixlet is detected, create an action to a group of test machines, may even just an empty group (not sure if that would be enough to cache the file on the BES server) so the file that matches the fixlet in your baselines is already cached on your server.
I use a similar concept to automate deploying new fixlets for some 3rd party apps so we release as pilot / prod deployments within 24-48 hrs of the fixlets being gathered. Fixlet age sometimes needs to be tweaked to cater from times where fixlets may, in some cases, take a bit longer due to overlapping with patch Tuesday. Pulling the fixlet ID to then issue via REST could be something like
(ids of it) of bes fixlets whose (name of it as lowercase contains "chrome" and name of it as lowercase does not contain "superseded" and name of site of it = "Updates for Windows Applications" and (source release date of it > (current date - 3 * day)))
If you want to be on the latest Browser I would recommend using Patch Policy - restrict it to Browser content only and then schedule it to be deployed daily.
With that option you will also cache the content.
If you donāt wanna do that but you still want to cache the binary, you can still use the same method but just schedule it to some test machine with Google Chrome, and donāt allow it to auto update.
Of course, you can use other methods with REST API and suchā¦ but the simpler method is the best
If you download and pre-cache the Google Chrome executable when the Fixlet is released, the OOB Fixlet action will work in your Baseline when it runs later in the month. The key is having the file in the cache that matches the SHA-1 and SHA-256 values present in the OOB Fixlet.
I could use the File Pre-Cache Wizard to take care of that, right?
I was just working on a batch file for that, hereās the process Iāve come up with so far
:: SETUP:
:: Assumes performing this all on the Root Server
:: Download BESDownloadCacher.exe from https://software.bigfix.com/download/bes/util/BESDownloadCacher.exe
:: Create directory "C:\BES\DownloadCacher and copy BESDownloadCacher.exe there
:: create directory "C:\BES\DownloadCacher\mastheads"
::
::
:: locate 'Updates for Windows Applications' masthead and copy to .\mastheads. Any copy of the .efxm is ok.
:: C:\BES>dir /s /b "C:\BES\Server\wwwrootbes\bfsites\*Updates for Windows Applications.efxm"
:: C:\BES\Server\wwwrootbes\bfsites\actionsite_0_470\Updates for Windows Applications.efxm
:: C:\BES\Server\wwwrootbes\bfsites\actionsite_0_471\Updates for Windows Applications.efxm
:: C:\BES\Server\wwwrootbes\bfsites\actionsite_0_472\Updates for Windows Applications.efxm
:: copy /y "C:\BES\Server\wwwrootbes\bfsites\actionsite_0_470\Updates for Windows Applications.efxm" "C:\BES\DownloadCacher\mastheads"
:: Normal Usage
:: 1. Generate a list of *all* downloads from the "Updates for Windows Applications" site, to 'all-site-downloads.txt'
:: 2. Filter the downloads to only the Chrome downloads, without the MANUAL_BES_CACHING_REQUIRED string, output to a new file 'chrome-downloads.txt'
:: 3. Perform downloads of the files listed in chrome-downloads.txt (many may fail due to hash mismatches, this method seems to include superseded Chrome fixlets)
echo Generating list of all downloads from "Updates for Windows Applications" site
BESDownloadCacher.exe -m "mastheads\Updates for Windows Applications.efxm" -w all-site-downloads.txt
echo Filtering to Chrome downloads
type all-site-downloads.txt |find "googlechromestandaloneenterprise" |find /v "MANUAL_BES_CACHING_REQUIRED" > chrome-downloads.txt
echo Performing chrome downloads
BESDownloadCacher.exe -o chrome-downloads.txt -l
Oops, I needed to step back from the problem a bit.
The issue is that Google always replaces the same URL with the latest copy of their download, soā¦this batch script was a bit of overkill. We can have BESDownloadCacher just try that URL directly.
When run on the root server, BESDownloadCacher automatically renames the file to match its sha1, and puts in the download cache at wwwrootbes/bfmirror/downloads/sha1
There is already a lot of good advice in this thread. Just wanted to mention the same thing in another way.
Simply deploy Google Chrome to a test machine. Then when you are ready to deploy a few days later, right click on the action and ācustom-copyā the action or baseline, and deploy as you wish. You will be deploying the original Google Chrome version from a few days ago since it was cached with the action.
Jason, Can you help me out a bit more? You are caching locally, does that mean the fixlet will pickup from that location from then on without returning to the web? Will it also pickup from that location if the fixlet is added to a baseline?
Yes on both counts. The idea behind using the Download Cacher is to get the browser downloaded and cached on the root server before Google replaces it, so we have a version that matches whatever Fixlet weāre using. Itās an alternative to āhurry up & send a action so the download gets cachedā.
You could run the Download Cacher as a scheduled task. Run it a few times a day if necessary.
An alternative to that is a Fixlet I posted to BigFix.me that just deploys āwhatever version of Chrome is available nowā (at the time you click Take Action). It does not verify the hashes though so you never acknowledge what version of Chrome you end up with until you take the action.
Hereās a new task I just uploaded to BigFix.me, that will download the BESDownloadCacher and then use the Download Cacher to precache Google Chrome downloads.
The task is built to run on the BigFix Root Server running on Windows (if you have a need for this on a Linux-based root let me know and Iāll look into it). To make sure we donāt miss a Chrome version update, recommend running this at least once a day and preferable 2-4 times a day; this can be done with the action settings āReapply while Relevant, waiting 6 hours between reapplicationsā.
Every time the action runs, it will download and precache the current x32 and x64 versions of Chrome (even if itās already been downloaded), so expect ~ 200 MB of downloads each time.
If the Chrome download file(s) have not changed, they will be overwritten (the file is renamed to match its sha1 value and stored in wwwrootbes\bfmirror\downloads\sha1). If the version has changed it will be saved to a new file matching the new sha1, and the older versions also remain in the cache (until removed by the normal cache cleanup if the download cache size limits are exceeded)