If you’ve ever taken an action on a Fixlet (or more annoyingly on a Baseline) and a specific component just sits there with a never changing status of “Pending Downloads” then you might have been a victim of the dreaded “MANUAL_BES_CACHING” scenario.
Note that there may be a host of reasons why your action is just sitting in “Pending Downloads”
- The payload of the particular Fixlet is large and will, in fact, take a long time to download
- The payload failed to download and is in a waiting-to-retry state
- The payload is actually downloading (so be patient)
This article deals specifically with the scenario in which the action script prefetch line of the Fixlet contains the words “MANUAL_BES_CACHING” in the URL:
Because BigFix goes to the source (i.e. Microsoft, Red Hat, etc.) to get the Fixlet’s payload this can sometimes be the weak link in the chain. While many patches can be downloaded directly from a URL there are some that the vendors have determined need “special attention”. What this means is that there is an additional dialog between the URL and the download that must be viewed by the user. In some cases, there is an additional EULA that must be accepted. Sometimes there is a list from which a specific file must be downloaded.
Some Java Fixlets have become known for this behavior, but this is actually Oracle’s mandate, not IBM’s or BigFix’s. Microsoft also has a few of these so don’t think it’s just Oracle.
In the past the way to deal with this was to download the Fixlet’s payload, find its SHA1 hash value, rename it to that value and place it in the appropriate directory on the Root Server. This way the Fixlet would find it there during the action’s prefetch stage and it wouldn’t have to try to go out to the “non-existent” URL for it.
Recently though (v9.0+), BigFix introduced a client setting called “AllowCustomRepoDownloads” which is enabled using the Fixlet “Create or Update Custom Repository (Windows)”. Much in the way that the Linux Custom repository allows YUM to find patches there rather than having to go out to Red Hat’s site, the Windows custom repository lets the server know that it should look in there for the patch payload before going out to the internet to find it.
Note: This Fixlet exists in both the “Patching Support” and “Updates for Windows Applications” content sites.
You may choose either as they are identical. In essence what it does is create a client setting called “_BESClient_AllowCustomRepoDownloads”
In order to create this custom repository, you must already have a folder in mind where you will place all your payloads. Along with a few other steps it will then allow you to download and place files in this folder that the BES Server will look through whenever it encounters the “MANUAL_BES_CACHING REQUIRED” URL in a prefetch action script line.
The steps to properly set this are detailed in a very well written WikiPage by Charmalaine Limson of IBM Singapore so I won’t waste time re-posting them here.
Once you create the client repo setting remember to upload the payload files to that location. If your repo client setting URL is: http://myrootserver:52311/Uploads/Repository
then you will need to place the files in your root server at the location:
<BES Server Install Dir>\wwwrootbes\Uploads\Repository
I will also say that one of the most important things to remember when creating this repo is to add the location of the repo to the BES Server’s DownloadWhitelist.txt file. This is the only way the server knows this download location is valid. If not in the file the server will reject the download with the error:
“The requested URL does not pass this deployment’s download whitelist”
If already created you will find this file in the folder:
<BES Server Install Folder>\Mirror Server\Config
Lastly, bear in mind that the format of the file is “Perl Regex”; therefore, you must escape certain characters such as periods (.) with a backslash (\). Below is an example of a line in this file:
Notice the “\” before each period.
Once you’ve configured the repository your deployments will go smoothly.