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.
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.
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.
@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.
@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: http://www-01.ibm.com/support/docview.wss?uid=swg21505562.
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.
@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.
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?
Might try tracking the remediation of March’s “Security Only Quality Update” instead. While still a bundle, they are not rollups. Thus, they are not superseded each month. We deploy the “Monthly Security Monthly Quality Rollup” fixlets, but for questions regarding MS17-010, I mostly use the fixlets classified as “Security Only Quality Update” bundles. I also only have to support patching on Windows Server OSes only so this may not work for the client OSes.
Windows 2008 - Custom copy of KB4012598 because it has been superseded by KB4018466
Windows 2008 R2/7 - KB4012212
Windows 2012 - KB4012214
Windows 2012 R2 - KB4012213
Windows 2016 - KB4013429
If customers are still complaining because the exact KB# wasn’t deployed, might need to take the time to educate on the new servicing model for Windows OS.
