Strange behavior with superseded patches?


In our environment, I’m finding it very strange to find the superseded patches that are deployed a few months back. Here is one example, KB4012215(March) was superseded by KB4015549(April) and this was again superseded by KB4019264(May). Now while creating reports in web reports I’m not able to see KB4012215/KB4015549 and able to see only the KB4019264 as remediated. This might be the product behavior, because even I feel that’s what I would like to see. But there was a concern from our customers, then how do we know if KB4012215 or KB4015549 was deployed on all the machines before KB4019264 was deployed.

Please share your thoughts on this and correct me if am wrong!

To keep a history for specific fixlets, probably the easiest thing to do is to create a Custom Copy of the fixlet in one of your custom sites. Then you can track when that custom copy becomes non-relevant to know the older version of the fixlet was deployed. I do something similar, except that I check for the remediation history on my Baselines. (The Fixlet changing does not affect any Baselines that it was in, unless you sync the baseline to the updated Fixlet version).

that’s right, I do agree with that @JasonWalker So does it mean, I will not able to track the superseded patches now? Is that a product behavior?

I think that’s always been a product behavior, it’s just that now the patches are getting superseded every month by the Rollup Packages.

1 Like

Thanks @JasonWalker. But still that’a big concern with the customer because they want to know how many servers do not have the superseded patches and how many does. Any suggestions on how to tackle this situation?

Here is one other example, where both superseded and the latest are both showing in the report. This is just one example and my customers are pointing alot. So, I’m still confused whether it’s a product behavior or a bug in the product because I’ve spoke to many IBM support persons and they all agree that superseded patches will not show as remediated in the reports, when there is a latest patch deployed on that machine.

False Positive:

@BigFixNinja @JasonWalker @strawgate @Aram @jgstew @All

Need some expert advice on this issue! Please shed some light.

How many are still showing Relevant to a superseded rollup? Should be few to none. The Fixlet Relevance has been changed to include a “FALSE”, so there should be no relevant machines.

What’s likely happening is that there are a few clients that are not reporting in the deployment - they’re turned off, disconnected from the network, or otherwise not checking in - so they’ll keep showing as a Relevant Computer until they check in and report Fixed for the superseded fixlet.

Again, if you want to keep reporting whether a server has installed the old/superseded fix, but not the latest (superseding) version, then you’d need to make Custom Copies of the original fixlet so the clients can keep reporting a status on the old version.

1 Like

One thing to consider here is that if a device recognized that it was relevant for a given Fixlet which is subsequently superseded, then the BigFix Agent will report that the given Fixlet is no longer relevant. Since it was relevant at one point, and now no longer relevant - since it has been superseded - whether or not the patch was applied, Web Reports will report that the Fixlet has been ‘remediated’ (which in essence it has).

To phrase it a different way, ‘remediated’ Fixlets in Web Reports are those that were relevant at one point, but are not currently relevant.

1 Like

@JasonWalker I agree with that, every superseded fixlet will have their relevance to include ‘FALSE’ and I do see 1 or 2 computers as applicable because they have not reported for a long period of time and thanks for the suggestion, I have started following that and this will help us to avoid confusions in the future.

@Aram So, in other words If I have the latest fixlet installed on the server, all the superseded fixlet will report as remediated irrespective of the patch being deployed in the past?

Assuming the agent had recognized that the (now) superseded Fixlets were relevant, and are no longer relevant (given the false clause), then yes. In this case, it doesn’t matter whether or not the latest (non-superseded) Fixlet is installed or not.

1 Like

@Aram But I raised a PMR and he stated the other way around. If the latest fixlet is deployed on the server, then the superseded fixlets will not show as remediated in web reports.

But the more interesting part is, I have servers that say remediated for superseded as well as latest fixlet and servers that say remediated only for the latest fixlet. That’s very strange and confusing!

Can you describe further the reasoning behind reporting against the superseded patches rather than the deployment status/compliance against the current patches?

There was an audit recently due to the ransomware threat. So, they wanted a report to confirm on the patches deployed in the month of March and April. But unfortunately the exported report had information only about the latest patch in the month of may and did not show up the superseded fixlets in the month of March and April as remediated. Please refer my #1 post.

So the problem here is, they think the MS17-10 patches were not deployed in the month of March and April when we actually did and this has turned out to be a BIG concern.

In this case, if you want to accurately report on the deployment of a superseded patch Fixlet, I’d suggest reporting instead on the action deployment history (assuming you still have it) rather than leveraging the ‘remediated’ field within Web Reports (which as suggested above does not provide the context you are looking for).

@Aram the action deployment history will not help us, due to the trial cleaner policy which runs and removes expired actions every 30days. But still I’m trying to figure out the behavior of the superseded fixlets in web reports. So that I can explain our customer stating that’s the product behavior.

Looking at all the gathered inputs so far, It’s still contradictory because PMR engineer stated something different from what we are discussing here. Please refer this post.

Thank you so much @Aram for trying to understand and sort out this issue.

@techadmin, the Patch Management solution is supposed to work that way: e.g., when the May Monthly Rollup fixlet is published, then the superseded April Monthly Rollup fixlet is re-published to be ‘Not relevant’ on every endpoint.
More details are described in this document:

Doing that, all the endpoints that were previously ‘Relevant’ to the April Rollup fixlet will be marked as Remediated on WebReports (it doesn’t matter if the Rollup has been applied or not on the endpoints), because they changed their relevance status from Relevant to Not Relevant.

However, if some endpoints were ‘Not Relevant’ to the April Rollup fixlet (because the patch was already installed or the patch was not applicable) before publishing the superseding May Rollup fixlet, they won’t be reported as Remediated in WebReports because their relevance status didn’t changed.

1 Like

@Emiliano Thanks for your inputs and the link is very useful. I do agree with most of your thoughts. But,

However, if some endpoints were ‘Not Relevant’ to the April Rollup fixlet (because the patch was already installed or the patch was not applicable) before publishing the superseding May Rollup fixlet, they won’t be reported as Remediated in WebReports because their relevance status didn’t changed.

If the patch was already installed through BigFix or manually, it should still report as remediated.

Here is a input from Aram,

The point here however is that the Fixlet must have been reported as relevant at one time, and subsequently not relevant for it to appear as ‘remediated’ in Web Reports. There are various circumstances that could lead to the agent not reporting as relevant for a Fixlet that would have to be explored in this case.

All that said, this sort of scenario can be addressed (currently) in the reporting layer via custom reports that know the supersedence chain of interest.

So I see how this gets complicated really quickly. The Rollup Packages are really to large and complex to write the “usual” relevance check (i.e. checking the versions of every file supplied by the rollup), and ibstead you have to check whether “KBxxxx_Rollup_Package_For” is installed.

And every month it’s a new KB number. So the old rollup would have to change relevance to ‘KBxxx-original_Rollup is not installed AND KBxxx-newmonth_Rollup is not installed’. And every month, you’d have to update the relevance on every old month’s fixlet. Much easier to supersede the old month and then stop changing it.

Could we ask that instead of replacing the old month’s relevance with FALSE, that you instead insert a new FALSE clause? That would make it easier for people who need a history, to custom-copy and then remove the FALSE, instead of trying to determine the original relevance clauses that were changed to false…


@Aram thanks for the Information, that’s something new to me. I will also share the same to the customer during our next call and Can you please share the custom report that you’re talking about?