I’m currently creating a baseline that contains windows patches in it, and as part of the relevance for this baseline, I want to ensure that other patches are installed already.
So, I figured the best way to do this would be to use the Fixlet object of client relevance to determine if the specific patches’ task is relevant or not on the device.
Here is sample relevance that I am using:
(not exists relevant fixlets whose ((it = 284758) of id of it) of site whose (name of it = "Custom Site for WindowsUpdates"))
This way if the return is TRUE, that fixlet ID 284758 is NOT relevant on the device, it is already patched for that and is ready for the next patch (the baseline in question for this post).
However I am seeing a few issues with this approach.
The first issue is that this does seem to return accurately for me, however the client might not come back as showing relevant for the baseline within the BigFix console for a few hours. Example: Patch A is installed at 1:00 PM, Baseline B with the relevance to make sure that Patch A is no longer relevant won’t show up as relevant until around 3:00PM or later.
After looking around on the forums I see a post about a Breadcrumb Patching Site. This thread has a post pointing to the Fixlet Object website. which says that relevant fixlet of <site> only works for properties, not fixlet evaluations.
So I’m wondering if this delay is due to it not being designed for Fixlet evaluation. Perhaps the Fixlet Object website saying its not for fixlet evaluation is not to say it does not work, but rather should not be used due to performance implications?
Also in regards to the baseline taking so long to evaulate, if there is no reason not to use the Fixlet object in the relevance of the baseline, is there a BESClient settting to control how often a baseline will re-evaluate?
“BES Fixlet” is a session relevance inspector, session relevance are used to extract data stored in the Bigfix server data base. The delay in showing up the actual relevance, is due to the time required to collect all the reports (results) from the agents. This time strongly depends on your infrastructure. The relevance in your example, in order to become true, requires to collect all the reports from all the computers where the fixlet was submitted.
I think there might be some confusion here. BES Fixlet is not the relevance inspector being used in the above example. The above example is client side relevance, not session relevance.
There is some complications that occur with that inspector, and I don’t fully understand all of them but perhaps @AlanM could weigh in.
Consider that when evaluating whether any fixlets are relevant, that could include the current fixlet and thus might not be deterministic. There are also context switches that happen in the client while evaluating any given fixlet - “action” for example may be initialized to the current action.
In general I’d avoid trying to use “fixlet”, “action”, etc. as part of fixlet evaluation - they won’t work as you expect, and are intended to be used by things like the Client Compliance API. Perhaps you could check in to whether there’s a Client Compliance API methid for what you want, where (on the client itself) you “tag” a machine as being ready for the next baseline, which is basically the breadcrumb approach yoy reference.
Maybe we can also revisit why you’d need multiple baselines, or for them to run in sequence. If there is a dependency on order among the components, we’d generally want to keep them in a single baseline instead so the ordering can be enforced.
One method I’ve done (not proud of it, wouldn’t do it again) was that I needed to tell when “all” of a set of baselines had completed so I could trigger a single reboot at the end. Those “fixlet” and “action” inspectors that don’t work during fixlet evaluation, I found do work within an Action. So I had a policy action running every hour while outside of my maintenance window, and every 15 minutes while inside of the window, that would use the “action X” and “fixlet” inspectors. Based on the results, I’d tag client settings on the machine and then use those settings values in my relevance for “reboot the machine” and “close maintenance window” actions.
Reason I’m using two baselines is due to a reboot being required after Patch A, because Patch B won’t install cleanly without the reboot occurring first. I’m assuming I could put the reboot step within this baseline and just tell the baseline to “retry on failure” so that it re-runs after the reboot, but that would cause all devices to show a false failure which isn’t good in my opinion.
Why wouldn’t you do this again? I was planning on doing something very similar.
The lookups I was doing take almost a minute on the client, the action results aren’t documented, and I spent quite a while chasing my tail to reverse-engineer them.
In particular ‘constraint of action’ and ‘system constraint of action’ were complex. Each time I thought I was done figuring out the combinations, a new value would appear that I’d have to track down. Those equate to ‘action failed, will try again after restart’ or ‘action failed, will try again after a delay’ or ‘action maybe succeeded, will re-evaluate after restart’, etc.