Hi team,
For OS patches, my clients always do by quarterly. meaning every 3 months. like for eg. May June July, so when a new month OS patches comes in the July patches will be superseded. So what we will do is to go to console and copy the patch to make it relevant again. My question is, if we sync with source, will the patches be sync with July or Aug and also is there a faster way to make those superseded relevant again instead of copying the patch individually. Thanks
If you add them to a Baseline, and don’t re-synchronize the baseline, the original, non-superseded Fixlets are preserved there.
Hi @JasonWalker,
Thanks for the prompt reply. So meaning i shouldnt be syncing the source, else it will go to the new patch? But my clients need the patch for July.
Synching the baseline won’t change the patches from July to August, but will change the July to the Superseded version of July.
Hi Jason, as per my question earlier, what we will do is to go into each patch and delete the following relevance to make the patch relevant again.
(value of setting “_BESClient_WindowsOS_EnableSupersededEval” of client as integer = 1) | false
May i know is there a faster way to delete this relevance for each patch or we have to do it like how i do it.
You could create a Baseline of the patches before they’re Superseded, or custom-copy the Fixlets to a custom site before they’re Superseded.
Or you could configure the clients to Enable Superseded Evaluation (the task is either in “Patches for Windows” or in “BES Support”, I don’t recall which). Then the clients will continue to evaluate & report on the Superseded patches - but all the Superseded patches, so this can slow the client evaluations considerably
Wouldn’t it be easier to just add that setting to each windows computer ( “_BESClient_WindowsOS_EnableSupersededEval”=1) so they evaluate the Superseded fixlets?
Doesn’t that accomplish the same thing?
I would agree with @Jared for the easiest approach. Maybe the one thing to consider before that is what impact it could have on the client evaluation cycles. If my understanding is correct, superseded patches are not normally part of the client eval cycles and by adding the setting, its potentially going to require the endpoint to process all superseded fixlets, which is content contained in a 350Mb file? (C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\Enterprise Security\SupersededControlled.fxf)
Maybe enable client performance counters first and capture the eval cycle averages of some test endpoints then enable the setting and review the counters to see what the impact was before deciding if that is the right approach for you.
It would be very helpful for there to be a baseline switch/drop-down of some kind that would allow components of superseded fixlets to still evaluate, that would allow for that and trickle down to all components, or even component level would be great.
It’s probably not that easy, but it would get rid of having to evaluate ALL superseded content. @JasonWalker I had them in a baseline before being superseded, and I synced it a week later like a moron, had to go back and create the custom versions of them. It solved for not having to evaluate all superseded content, but it a pain 