False positive KB2478662 after Server Cleanup Wizard

Question

This morning WSUS gave me false positives for several clients.  I've seen FPs before, but I've never discovered what causes them.  In fact, I'm finding it hard to even ask a useful question.
On Friday I ran the WSUS Cleanup Wizard.  On Monday I found that our Server 2008 R2 box and all but two of our Windows 7 boxes report as needing .NET update KB2478662 - a long-superseded update from 2011.
I ran "wmic qfe list" to learn that neither KB2478662 nor its two superseding patches (KB2633873 and KB2539635) were installed on any of the unhappy clients.  However, KB2972100 supersedes KB2633873 and KB2539635 (but not the earlier KB2478662),
and is installed on all the clients involved.  KB2972100 is not listed as superseding KB2478662, the earliest in the chain, so it appears this sort of leapfrogging supersession may not be detected well by WSUS.
However: KB2972100 was installed two months ago, and KB2478662 didn't show before Friday; according to the Microsoft Catalog, none of the update packages has been updated recently; and I'm not finding reports from other admins of the ghost of KB2478662 emerging
from the shadows.  I can only assume that running the Cleanup Wizard Friday somehow left WSUS in a state where this false positive could result.
Like I said, I can't decide what question to ask.  Am I likely correct in blaming the Cleanup Wizard?  If so, is there some way of cleaning up after the wizard?  Or of preventing this sort of false positive in the first place?  Or is there
some other common cause for this sort of FP?
I seem to get two or three of these FPs a year, and I always end up researching the chain of superseding updates, manually scanning clients until I'm sure the latest update is really in place - and then I decline the false positive.  But I'd love to know
a better way to handle these, or to avoid them.

Answer 1

so I don't have a years-long database of approved updates.
That remains to be seen. It only takes one hour of overambitious update approvals to generate five years of content on a WSUS server. :-)
KB2478662 has never appeared before
KB2478662 is an update contained in MS11-039 and has existed since June, 2011. If your WSUS server is only a couple of months old, I'm pretty confident in stating that KB2478662 was part of your original synchronization. KB247862 (MS11-039) is not a superseded
update.
It's much more likely that you just did not notice it before.. but it's always been there.
(as I noted, KB2972100 was broadly installed in October) and has never had any approvals at all.
I can't speak to the question of approvals, but if it was broadly installed, then I'd guess that  happened before you deployed this WSUS server and those updates were installed as a result of Automatic Updates. Given that it was released on Oct 14th,
that makes perfect sense.
I've never had the opportunity to decline it, because it's never appeared as "needed".
Those two statements are totally noncongruent. You don't decline an update because it is or is not needed, or was or was not ever reported as needed, you decline an update because it will **NEVER** be needed again at all.
None of the four updates I mention came out since I installed WSUS.
Correct, but not really relevant.
KB2478662 (MS11-039, Jun 2011) - already explained. NOT superseded, except for ITANIUM systems, which was superseded by MS11-069.
KB2539635 (MS11-069, Aug 2011) - SUPERSEDED by KB2633873 (MS12-016, Feb 2012), KB2604115 (MS12-035, May 2012), KB2729452 (MS12-074, Nov 2012), KB2742599 (MS13-004, Jan 2013), and KB2972100 (MS14-057, Oct 2014).
KB2633873 (MS12-016, Feb 2012) - SUPERSEDED by KB2604115 (MS12-035, May 2012), KB2729452 (MS12-074, Nov 2012), KB2742599 (MS13-004, Jan 2013), and KB2972100 (MS14-057, Oct 2014).
KB2972100 (MS14-057, Oct 2014) - The *CURRENT* update.
So since they all came out before you installed WSUS that means that ALL of them were ON your server the day you installed it, and TWO of them were relevant from Day One. The other two should have been immediately declined if KB2972100 was reported as 100%
NotApplicable.
If WSUS thinks KB2478662 is superseded, I have no idea why the Cleanup Wizard hasn't already handled it.
There's no "think" about it. Either the update is superseded, or it is not, and whether it's superseded and what supersedes it and what it supersedes is displayed in the Update Details in the WSUS console. One need only read the screen to get the
facts. In this case KB2478662 is NOT superseded (unless you have an Itanium server), and nothing "thinks" that it is (except you).
As for why the Server Cleanup Wizard hasn't dealt with it, one need only understand what the Server Cleanup Wizard DOES do with superseded updates. Superseded updates are declined *IF* (and only IF):
The update is superseded and has not been approved for at least 30 days.
The update is superseded and not needed by any client systems or downstream servers.
The update is superseded and the superseding update is APPROVED.
So... the ITANIUM instance of KB2478662 will not be handled by the Server Cleanup Wizard, because you have likely not approved any ITANIUM updates that supersede it. And the other instances of KB2478662 will not be handled by the Server Cleanup Wizard because
they are not superseded.
So, back to your original message.
KB2478662 WILL be "Needed" on any system where it is NOT installed, because this update is NOT superseded. Your original premise that this update is superseded is the root of all confusion.
Furthermore, neither KB2633873 nor KB2539635 superseded that package, but they are superseded by a newer update (KB2972100) which predates the existence of your WSUS server, so the presence of KB2972100 and the absence of BK2633873 and KB2539635 is 100%
normal and expected.
You were correct in noting that KB2972100 does not supersede KB2478662, but that's the point at which your logic broke down and asking yourself how 'D' supersedes 'C' and 'B', and 'C' and 'B' supersede 'A', but 'D' does not supersede 'A' might have led to
a re-evaluation of your conclusions.
Ergo... there are *NO* false positives. What is reported is FACTUAL.
HINT: (I've written this over a hundred times in the past five years).... The question you should be asking in such situations is NOT "What's wrong with the update?", but rather "What's wrong with the client?" or "What's wrong with
my analysis?" The WUA evaluates applicability based on a defined set of rules, and reports the update status to the WSUS server based on the evaluation of those rules. If the update is more than a week old.. I absolutely PROMISE you that there is *NOTHING*
wrong with the detection logic in that update and you need to focus your investigation on things other than the updates.
As for how to handle superseded updates and update approvals, you may find some benefit from this article:
Removing unneeded update approvals
Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.