How we can make Superseded patches for Windows applicable

Hi All,

Can anyone help me to make superseded patch applicable to windows servers based on the KB installation status.


You’ll have to create a custom copy of the fixlet and ensure the relevance statements that re just “false” are removed.

That being said, why would you deploy something Microsoft has superseded?

Hi Martin,

Thanks for the tip… i will try this and update its working or not …

we have very old infra and we want to know applicability.


If a patch is superseded then by definition there is no applicability, though. Depending on the update, it’s most likely been replaced by a newer update. I would recommend reviewing the update information in the MS security catalog to determine which patch you should be installing.

If this is MS17-010 related, there is newer content that should be applicable instead of the fixlets that were released in March .

@mwolff is almost right. Superseded fixlets are just as applicable to a machine as any other fixlet, they’ve just had their job taken over by another, newer fixlet and are no longer truly necessary.

Take a look at the Firefox fixlets. If I have Firefox 53.0 installed, I’m going to (as of today, June 19) see three applicable Fixlets:
Mozilla Firefox 53.0.2 Available (Superseded) Mozilla Firefox 53.0.3 Available (Superseded) Mozilla Firefox 54.0 Available

All three are applicable, as 53.0 is lower than 53.0.2, 53.0.3, AND 54.0. I don’t need to install three Fixlets though … just the last one (for 54.0) which has superseded the others. It has everything that my Firefox 53 install needs, while 53.0.2 and 53.0.3 only have some of what I need. All three are still listed and applicable though.

The same is true for Microsoft patches, particularly the cumulative releases. If I haven’t patched my Windows 10 computer since March (bad boy!), I’ll see the following, all relevant and applicable, but not all necessary:
MS17-APR: Cumulative Security Update for Windows 10 - Windows 10 Version 1511 - KB4015219 (x64) (Superseded) MS17-MAY: Cumulative Update for Windows 10 Version 1511 - Windows 10 Version 1511 - KB4019473 (x64) (Superseded) MS17-JUN: Cumulative Update for Windows 10 Version 1511 - Windows 10 Version 1511 - KB4022714 (x64)

Same thing is true here: I need the stuff in the MS17-APR update, but thus stuff is also in the MS17-MAY and MS17-JUN updates, and the MS17-MAY update stuff is also in the MS17-JUN, so all I NEED to do is install MS17-JUN and I’ll be good, but until I do, MS17-APR and MS17-MAY are just as applicable.

Unless you’ve changed the applicability (or hidden the content globally), anything that’s “(Superseded)” should still show up as applicable.

At least, that’s how things look in my console. :slight_smile:

Simple answer.

When it comes to the Microsoft content from IBM, they add a “FALSE” clause to Fixlets whose payload has been superseded. Since you cannot modify the External content provided by IBM, you need to make a copy of the Fixlets in a new Site. Remove the “FALSE” clauses from the Relevance tab before you save it. Be sure that all of your Windows computers are subscribed to the new site and that the Console Operators who will deploy the new content are also subscribed.

Not quite; you’ll find that most superseded fixlets have a relevance clause added that simply is “false”; machines that were relevant for such fixlets will automatically evaluate false because of this relatively minor change.

IBM definitely does this for superseded Microsoft security updates, I’d have to double check the Windows application updates site to verify, but I’m fairly confident they do the same for fixlets in this (and most) sites.

Hmm … this is very weird. Most of our 1,239 “(Superseded)” fixlets have two FALSE Relevance clauses, but they are still showing up as being relevant for many–in some cases, hundreds–computers. Any idea why this would be?

Most likely because those computers have not reported in and gotten the latest actionsite version, or they’ve haven’t reported in at all. Check your last report date on those endpoints, and make sure they’re reporting to relays with current actionsite versions.

This is a fairly common occurrence in our environment as we have a highly mobile estate, and so some machines are frequently not at the current site version and/or offline for long periods of time, so they show up as what I’d call “artifacts” in that they are non-current reports.

I was gonna say that “old computers” has to be it, but looking at the console now, we’ve got a lot of “live” computers and recent check-ins that are relevant for Superseded fixlets that have been around for months. May need to look into this more. :confused: