This Fixlet is from the C3 Patching offering. I’ve already modified the fixlet with the correct SHA1, SHA256, and Size of the installer. I’ve renamed the installer to the SHA1 and placed it on the BES in the downloads/sha1 directory. I’m still getting "“Unexpected HTTP response: 404 Not Found” when deploying the fixlet. I was under the impression that any URL with “MANUAL_BES_CACHING_REQUIRED” in its path tells the BES to assume it is already cached and to grab it from the aforementioned directory on the BES. I also know sometimes it takes some time for it to take affect.
So my questions are, are my assumptions mentioned above true and if not, do I need to modify the below portion of the fixlet?
I’ve modified the download portion to match what I have in BES Server\wwwrootbes\Uploads and it of course works. I’m just wondering if I need to do that when MANUAL_BES_CACHING_REQUIRED is in the path.
It was under wwwrootbes/bfmirror/downloads/sha1 (where you just rename the file itself). I later removed that and created the directory under wwwrootbes/Uploads and placed the file within (its normal file name). That worked and cached it as the sha1 under downloads/sha1 as expected. My question is around having to modify the fixlet.
The “MANUAL_BES_CACHING_REQUIRED” doesn’t really mean anything to BigFix though, that’s just for the benefit of us humans to know that caching is required. BigFix checks the sha1 folder before doing every download. Those of use with Airgapped systems have to precache everything by storing the downloads in the sha1 folder.
In fact, BigFix repeatedly checks the sha1 folder. There have been several times where I’ve sent an action before precaching the download, and realized my mistake when the action download status is showing a server unreachable message. When I obtain the download and import it into the sha1 folder, the open action recognizes the newly-cached file and resumes the distribution to clients.
If you can reproduce the behavior, this is probably worth a PMR. Unless it’s possibly a mistake in renaming the file to match its sha1? In my experience, even where a sha256 is available on the download statement, the file should be named to match its sha1 value.
Hi, I am not sure since when, but with recent version, I don’t think name matters. I can just put the file downloaded into sha1 folder without renaming it and server recognizes the file.
Of course, using sha1 name is good practice to avoid conflict of names since files will be from multiple sites.
As you mention, server checks sha1 folder with some interval. I had an experience that the server does not recognize the existence of file I have just placed, but after some time server recognized my file.
Using Fixlet 1100363 “Windows 10 Enterprise Version 1607 Available - Windows 10 (x64) (English (United States))” as an example. I deploy this with success and I didn’t change the fixlet at all; I just pre-cached the ISO. MANUAL_BES_CACHING_REQUIRED still shows in the URL.
Based on that and comments here, it seems that MANUAL_BES_CACHING_REQUIRED doesn’t mean anything to BigFix, but that regardless of the URL being valid or not, BigFix will check the pre-cache folder based on sha1/size values.
I think the expected behavior can be summarized as:
BigFix Server periodically checks contents of sha1 folder for size and hash, and maintains list of size/hash of files in sha1 folder.
When file is needed by prefetch or download command, Server checks list for specified size and hash, and if there is a file with matching size and hash, it is used regardless of URL.
When there are no matching entry in the list, the Server tries to download file from URL.
The string “MANUAL_BES_CACHING_REQUIRED” does not have special meaning to BigFix server, but when URL contains this string, the URL does not point actual file because no vendor hosts file with such URL, and cannot be downloaded.
When URL contains MANUAL_BES_CACHING_REQUIRED, the file must be either cached in sha1 folder, or in many cases, placed in Custom Repository you specified using dashboard or task in Patching Support site. If your cache is large enough, simply place file in sha1 folder will be the best choice, but when your cache size is limited, file(s) in sha1 folder may be deleted when total size of files exceeds maximum cache size (default is 1G).
Yes indeed.
As an alternative, many of these ‘manual download’ fixlets recognize a Custom Repository option. If you use the tasks to define a Custom Repository, you can host the files elsewhere and not rename them.
One example would be to define the custom repository as https://besrootserver:52311/CustomRepo. Then you create a folder on the root server at BES Server\wwwrootbes\CustomRepo and store the files there (without renaming them, use the original filenames). (It doesn’t have to be on the root server, bringing your own web server would be better, but in practice this is pretty common).
The reasons to host the files outside of the sha1 folder, are that it can be easier for you as the administrator to host the files; and at some point the root server’s automatic cleanup of the sha1 folder could remove the files you have manually staged there and make the fixlet stop working.
I put this on the whitelist "https://besrootserver:52311/BES Server/wwwrootbes/CustomRepo/.*"
and created a folder “BES Server\wwwrootbes\CustomRepo” where my downloads are stocked.
But when I tried to deploy the PDF part 1 fixlet, it dont look to the customrepo folder I made instead it look to the folder sha1 where i also put the installer after the download failed.
Is there anything that I missed?
Thank you so much
Sorry, but this thread has taken on many twists and turns.
When defining a custom repo on the root server, the path is relative to wwwrootbes; so you would set whitelist to “https://besrootserver:52311/CustomRepo/.*” in your case.
Only particular fixlets are coded to enable a custom repo, this needs to be included in the action script. A good example are the Java upgrade fixlets for Windows, where the prefetch actionscript line reads
If the client has the custom setting defined, then the custom repo URL is used; otherwise MANUAL_BES_CACHING_REQUIRED still applies.
You have to configure the client to request downloads from the custom repo path. Check Task 43 in “Patching Support”, “Set or update Custom Repository Setting (Windows)”.
I’m not sure what the “PDF part 1 fixlet” is that you reference, or whether that fixlet is coded to recognize the custom repo setting.
@JasonWalker Sir I tried it all and hoping to test it today. appreciate much your support.
and about the “PDF part 1 fixlet” its just a example scenario I encountered during deployment of fixlet “BES Web reports: Enable PDF reports” cause i cant download it via bigfix, I manually cache it to the server.
