Pre-Announcement: Superseded patch changes for Patches for Windows

Currently, MIME_X-Fixlet-Superseded field is the closest thing that could help you, although I would agree that it doesn’t point to a Fixlet now, it only contains the KB number or (historically) the bulletin number.

We are aware of this impact, therefore the current plan is to set the default to “not evaluate superseded content”, which means unless you explicitly set a client setting, all the superseded content will skip evaluation totally.
Even if the setting is turned on, in the design we have group the superseded content by OS, which means your Win 8.1 machines will not evaluate superseded Win 10 Fixlets.
Also, not sure if you noticed, we regularly clean up superseded content. Any Fixlet that is superseded one year ago will be removed from the site completely.
All these should help to ease the burden of client evaluation time.

1 Like

We do make use of this. Since it isn’t 100% populated, what it is populated with is not consistent, and the reference it makes could potentially match multiple different fixlets, there is still much manual effort needed to fully link them. We have measures in place to assist and record these links… it would just be nice if they were pre-provided and created by the automated tooling that produces the replacement fixlet(s) and updates the titles on the existing fixlets with (Superseded).

Understood. While being able to skip evaluation entirely will be wonderful for many environments, we typically leverage extended deployment processes to allow for additional testing and validation prior to enterprise roll outs. As such, there may be times where new roll-up patches are released before all our systems have been updated so the disabling of content evaluation for all superseded content is of negative benefit to us.

Changing the existing multipart digest organization from Year/Month with no control relevance to OS/[Year/Month?] with control relevance will help, but with the ~104MB of superseded content to parse and potentially evaluate (in Enterprise Security alone), the impact is still sizable and only expected to grow as relevance complexity continues to increase.

Understanding the architecture limitations preventing dynamic relevance adjustments to the control headers, is there a general concern (that can be shared) against upping the evaluation period from 0:0:1 to say 0:2:0, 0:6:0, 0:12:0, or as originally noted 1:0:0? Is it purely because it will induce a potentially noticeable delay in the relevancy re-evaluation of all the superseded fixlets following the successful application of the top-most fixlet in the patch graph? Since superseded content already deviates from the normal expectations (always false vs real applicability), this could be an ideal time to also introduce an evaluation delay as the expectations are already slated to change when released.

This is noticed (and appreciated). The one-year mark is far enough out that for even the most severe feet dragging system owners, we can make (and usually win) the thou-shalt-patch-now argument. But in those very rare and (unfortunate) instances we can’t, we maintain a complete archive of all fixlet content we can deploy as needed to maintain full visibility of patch compliance.

I see, I think I understand your use case now. Do you think capturing a group of Fixlets that you plan to roll out will help? Even if they are superseded in the site, the baseline won’t be updated unless you re-synchronize it.

That is one of the ways we deal with it currently. Ultimately, changing the fixlets to false or otherwise stopping the evaluation of them will impact our reporting ability. This is both a good and bad thing. Good in the sense that until there is a way to successfully automate the superseded patch graph we only see the most current patch and thus systems aren’t double (or more) counted towards the same vulnerability. Bad in that we won’t be able to easily track the total time from first discovered/available to patched.

After this change, when I look at the relevance settings for any fixlet that is listed as Superseded, I now see

Relevance 2 - (value of setting “_BESClient_WindowsOS_EnableSupersededEval” of client as integer = 1) | false

I’m assuming that is now why I see when I try to superseded fixlet within our environment, the fixlet doesn’t install, it just comes back as “Not Relevant”. This has created a huge problem, especially since Microsoft has been pushing out so many revisions to their patches this month, because now all of my tested versions of the patches from my Lab Environment won’t deploy to my Prod environment, because I don’t have the BESClient setting set. Not to mention the fact that I have new servers going in the environment that need even older patches installed on them to get them at the same level of patching as the environment that they are entering

As such, it seems to me as if I’m going to have to enable this setting on every single client in our environment, in order to ensure I can patch the clients when I need to. Might I suggest that a Fixlet be created specifically for enabling this setting, so that clients can easily make the change when required? How would one set this to be the default setting for all new clients added to BES?

Thanks,
Tim

Hi Tim,
Before this change, an explicit FALSE was added as Relevance 2 to all superseded fixlets, so they would not report applicability or be deployed. With the new setting _BESClient_WindowsOS_EnableSupersededEval you can actually override that and allow the fixlet to remain relevant (if the patch is still needed).

To enable this behavior by default, select two computers, then right-click and select ‘Edit Computer Settings…’ In the dialog select or enter _BESClient_WindowsOS_EnableSupersededEval as a Custom Setting with the value 1. On the Target tab, select ‘Dynamically target by property’ and ‘All Computers,’ then OK to deploy this setting as a policy to all endpoints.

Please be careful about deploying any superseded patches with its corresponding superseding patch, as this does not appear to be a tested/planned scenario by Microsoft, and could cause issues.

Hello Steve, these setting are not available in my environment:


Is there any other way, then create custom copy of these fixlets and change this relevance manually?
Thank you

If it is not there already you have to type it in.

There is just drop-down list - no option to type in new (custom) value. Probably some kind of fixlet will be needed, am I right?

I’ve seen this behavior when Console Operators were not Master Operators. I was never sure if that was a quirk of how I configured the Console Operators, or if it was by design.

To get around it, you should be able to create a pair of Fixlets to Enable/Disable the new Client setting value.


Title: Enable Targeted Windows Clients to Evaluate Superseded Content
Relevance:

1 - Windows of Operating System
2 - Not Exists Setting "_BESClient_WindowsOS_EnableSupersededEval" Whose (Exists Value of it AND Value of it = "1") of client

Action:

setting "_BESClient_WindowsOS_EnableSupersededEval" = "1" on "{now}" for client

Title: Disable Targeted Windows Clients from Evaluating Superseded Content
Relevance:

1 - Windows of Operating System
2 - Exists Setting "_BESClient_WindowsOS_EnableSupersededEval" Whose (Exists Value of it AND Value of it = "1") of client

Action:

setting delete "_BESClient_WindowsOS_EnableSupersededEval" on "{now}" for client

NOTE: I originally listed “Client” and it needs to be “client” (note the case difference!)

5 Likes

Hi Tim,
you are right, I’m not Master Operator, but just Console Operator, so its probably the cause.
Anyway I created and tested the fixlets and its working fine.

Thank very much, its appreciated

Hey guys … I know this thread is old … but is there any plans to use a similar property _BESClient_WindowsOS_EnableSupersededEval for Ubuntu patches?
Majority of the Kubernet nodes are being built on Ubuntu, so we have large customers who are relying on BigFix to do patches report for Ubuntu OS.
Our users are always complaining that the superseded patches marked as false disappear from the relevant content and make things difficult to manage their reports.

Yes, we are looking at that, as others you may know :wink: have made the same request: Supersedence handling change for Windows Patches

2 Likes

How do I subscribe to these Release announcements to receive via email?

If you go to the ‘Release Announcements category’, you can subscribe at varying levels by clicking the button next to ‘New Topic’:

Hey @Aram - I have not received any BESAnnoucement email notifications since June 8th… Has this replaced them? If not, how can I continue to receive them?

Thanks! :slight_smile:

We’re looking into the BESAdmin email announcements. The Forum announcements have not replaced them, no, but can be a good supplement.

2 Likes

FYI - I had a few BESAdmin-announcements hit my inbox (4 in the last hour or so).

2 Likes

Same, which is great.

1 Like

I only learned of the existence of this a few years ago and it seems like a very good optimization for lots of different content, including superseded patches. Even setting this to every 6 hours would help eval loops a lot while not causing much issue.

The biggest issue is if someone deploys a superseded patch with this set, it will not appear non-relevant until that loop has elapsed in many cases, which is not entirely expected, though I think there is some hinting in the agent such that it knows to update the applicability of a fixlet based upon a taken action in some cases.

I’m not aware of things outside of analyses / properties that use these, so I’m trying to play with this more and get a better feel for how it works so that it can be used more:

I just discovered this in a fxf file, now that I’m digging into it: X-Relevance-Child-Evaluation-Period

This pulls the existing values, mostly from analyses, but it seems the possible values are inconsistent, which is interesting:

(multiplicity of it, it) of unique values of following texts of firsts "-Evaluation-Period:" of lines containing "X-Relevance-" whose(it contains "-Evaluation-Period:") of files whose(name of it ends with ".fxf") of folders of data folders of client
2 Likes