We have a Baseline with many uninstall components, followed by a reboot, and then an installation (which is about 1.3 GB). The installation fixlet by itself is not relevant until some of the uninstall tasks complete, but we can assume that it will be relevant upon reboot.
That being said, to reduce the install delay after the reboot, we would like the install to kick off with the files already being there, without first having to download and compare SHA.
I know that one of the BESData folders clears itself on reboot, so that may limit my cache options. I know I can place the files outside of the BES file structure, but I rather not.
Do I have any other options where I can download the files, keep them there after a reboot, and when the task becomes relevant after the reboot, it starts the install?
Just to clarify on your request, your pre-caching only to your primary relays and not to the endpoints because the later is still not available in BigFix.
Even we do vulnerability assessment and to overcome the delay in Installation, I create a separate baseline for the installation tasks and pre-cache them on the relays before the actual deployment. So, this reduces the overall time during the actual execution of the baseline that contains both uninstall and install tasks.
This isn’t a relay thing. This is a download to endpoint thing even when baseline contains a non-relevant fixlet (which will become relevant soon after).
Example: Baseline contains A and B. B is not relevant until A completes. I want both A and B on the endpoint from the start.
Closest I could suggest is to try using the logic from this thread to build a list of downloads, and create an action from those downloads to cache the files on the endpoint.
If the total size is smaller than the client cache, I think the downloads would still be available from the client’s cache folder.
You’d need to filter to the baselines you wish to precache.
This is definitely an RFE but very unlikely to be honest. You’re asking for non relevant items to perform their downloads anyway but that isn’t something the client does specifically because of space constraints when baselines are used etc. If the client always downloads the payload, even if the fixlet isn’t relevant, then that’s a lot of resources used.
There are things we can do to make things a bit better performance wise from the hash of the download, which I believe already has an RFE ,but its a very much edge case you’re talking about and is out of the normal paradigm of BigFix which is don’t do things you don’t need to do (and the client has no idea that a fixlet is going to become relevant)
Thanks for the response. This scenario is common when you want to uninstall something first, then install something else. You want to use existing fixlets that you don’t have to modify and use them in a baseline so that its all one task.
In my example, I have an Antivirus Program A and B. I’ve already created and have been using single fixlets for each that install and uninstall. Now I want to move from A to B.
Rewriting existing, proven fixets or creating a staged fixlet approach of course is do-able, but not as easy and putting them in a baseline. That’s all I’m saying here. A checkbox next to a fixlet in a baseline that says to cache regardless would work.
BigFix should remain efficient; that’s its power house, so I’m totally on board with not introducing request if they at all threaten that.
We’ve used two different approaches. One is what Jason suggested. Create a task with only the download prefetches for your installers. Run that in advance so it caches on the clients local relay. This approach assumes a good relay structure and that a local relay is available. The benefit is that existing tasks wouldn’t need to be modified.
Another option is to make a local folder (perhaps c:\software). When you run the pre-cache task containing downloads mentioned above, add a step to copy the __download contents into that local structure (perhaps c:\software\AntivirusB folder).
When your install baseline runs, those tasks would execute out of c:\software\AntivirusB folder. The downside would be the need to modify tasks.