locked
False positive KB2478662 after Server Cleanup Wizard RRS feed

  • 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.
    Monday, December 22, 2014 7:35 PM

Answers

  • Okay, I think I've worked out exactly how I wound up where I was.  All that's required is a slight difference between the supersedence detection logic in the Windows Update Agent and in the WSUS Server Cleanup Wizard.  If it's there, you've been absolutely correct with the explanations you've offered, and yet I could still have seen the behavior I reported.

    We agree that all four updates would have been in the original synchronization on 11/03.  On most of the WSUS clients, KB2972100 had already been installed through Automatic Updates.

    But our Server 2008 R2 box had a problem with Automatic Updates, and one Windows 7 client had AU turned off, so when I first started using WSUS here, I approved KB2972100 for Server 2008 R2 and Windows 7 x64.  KB2972100 got installed on the server and the last workstation.  I didn't approve the earlier, superseded updates, and once KB2972100 was installed everywhere they no longer appeared on the "failed or needed" list.  So far, so good.

    It appears that WSUS can detect a chain of supersession, as long as none of the links in the chain have been declined.  As long as KB2539635 and KB2633873 (the two middle updates that explicitly supersede KB2478662 and are explicitly superseded by KB2972100) still had a status of "not approved", WSUS could follow the chain of supersedence from KB2972100 back to KB2478662, and no client reported the oldest update as "needed".

    Then, last Friday, I ran the Server Cleanup Wizard.  The two middle updates, neither one approved, both explicitly superseded by approved KB2972100, were--quite properly--declined by the wizard.  However, KB2478662 was not.  Now when WUA checked, there was no longer an intact chain of supersedence from KB2478662 to KB2972100.  WUA--quite properly--reported KB2478662 as needed.

    This morning, as a test, I went into WSUS and changed KB2539635 and KB2633873 from "declined" to merely "not approved".  Then I ran wuauclt on the clients, and Lo! KB2478662 no longer appeared as "needed".  Then I approved KB2539635 and ran the Cleanup Wizard, and KB2478662--quite properly--got marked as declined.

    With one minor difference between the Windows Update Agent and the Server Cleanup Wizard, the entire chain of events is perfectly plausible.  If WUA's detection logic will follow a chain of superseding updates, but the Cleanup Wizard is only satisfied when an immediately superseding update is approved, then you'd get exactly the behavior I've seen.

    • Marked as answer by Steven_Lee0510 Wednesday, January 7, 2015 9:37 AM
    Friday, December 26, 2014 10:39 PM
  • This discrepancy is because KB2539635 is explicitly superseded by both KB2633873 and KB2972100.  The Cleanup Wizard, working backward from the approved KB2972100, would have a direct link to both KB2538635 and KB2633873, but would have to go through one or the other of them to reach KB2478662.

    There is NO difference in how supersession logic is processed by either WSUS, the SCW, or the WUA. It's actually a very simple list, which manifests as a double-linked list in the console, and upon sync of a superseding update triggers the setting of a flag value in superseded updates.

    An update contains a simple list of PackageIDs which identify the packages that are superseded by that update. However, the length of this list is finite, and rarely is it a comprehensive list of ALL superseded updates, particularly as the list grows to a certain size, or covers a certain period of time.

    • KB2972100 identifies two updates that it supersedes: KB2633873 and KB2539635.
    • KB2633873 identifies two updates that it supersedes: KB2539635 and KB2478662.
    • KB2539635 identifies one update that it supersedes: KB2478662.

    Why the Server Cleanup Wizard failed to automatically decline KB2478662 is the question. But, as always, the most likely reason is that the update failed to pass the rules required by the Server Cleanup Wizard to be eligible for declination, to wit: not approved, not needed for at least 30 days, and having an approved superseding update.

    Of course, noting that KB2972100 does not list KB2478662 as a superseded update means that KB2478662 did NOT have an approved superseding update, and thus could NOT be automatically declined by the Server Cleanup Wizard. You artificially satisifed this rule by removing the declination and approving the intermediate update, which resulted in the SCW doing what it was tasked to do correctly.

    The core issue here is that KB2972100 does not contain a comprehensive list of superseded updates, nor is there ever a guarantee that any update will. Ergo, I believe you're trying to attribute a scenario to complex architectural logic, when to be frank, the only error is human error -- failing to manually decline an update that should have been declined the day the server was deployed (because the update had already been superseded for over three years, and was already superseded by two additional update releases.)

    This is not the first time we've seen somebody have issues with legacy updates that weren't declined, nor is it even the tenth or twentieth.... and I highly doubt it will be the last.

    Bottom line: Manual administration of approvals/declines on legacy updates is a task that needs to be performed regularly, from the very first day a WSUS server is deployed.


    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.

    • Marked as answer by jjjdavidson Wednesday, January 7, 2015 3:49 PM
    Wednesday, December 31, 2014 6:21 PM

All replies

  • This morning WSUS gave me false positives for several clients.

    I've rarely seen a false positive (not even knowing what exactly you, personally, mean by this appellation)... but I'm absolutely sure that running the Server Cleanup Wizard had nothing to do with such occurrences.

    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.

    So, immediately we have a couple of anomalies here.

    First, if the Server Cleanup Wizard was properly run, this legacy superseded .NET update from 2011 would have been declined, and as such a client would not be capable of reporting ANY status.

    Second, this also requires understanding the realities and limitations of supersession. A new update lists a nominal (reasonable!) amount of older updates as superseded, but it cannot list every one that has ever existed. At some point the WSUS administrator should be removing those ancient superseded updates from active status, in which case a client would never actually report any status.

    Consider this scenario: Updates 'A' through 'L' released over the past half dozen years are all reported as NotApplicable, because update 'M', which supersedes the previous dozen, is already installed. Now, imagine also there is an update 'N' and an update 'O', neither of which are installed. Both will be reported as "Needed" and when update 'O' is installed, then update 'N' now becomes Not Applicable. Now further consider the release of update 'P', which only lists the previous =12= updates as superseded. That leaves updates 'A', 'B', and 'C' as no longer superseded. It's entirely *possible*, depending on how the detection logic for those ancient updates was written, that the WUA will evaluate those updates as "Not Installed", even though their state is actually ancient and not relevant. The missing link here is that those superseded and Not Applicable updates should have been Declined, and if they were, then the WUA would never be able to see those first three updates to report a "false positive" on them.

    I can only assume that running the Cleanup Wizard Friday somehow left WSUS in a state where this false positive could result.

    Running the Server Cleanup Wizard did not cause this. There is *nothing* that the Server Cleanup Wizard can do that would change the state of how an update's applicability rules are evaluated by the Windows Update Agent.

    However, failing to remove approvals from those ancient updates did prevent the Server Cleanup Wizard from doing what it would have done which would have prevented those "false positives" from occuring in the first place.


    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.

    Monday, December 22, 2014 10:33 PM
  • Thanks for your detailed explanation.  At least I don't have to worry about the Cleanup Wizard; that's clearly coincidence.

    Perhaps I can clarify a few things.  First, I installed WSUS less than two months ago, on November 3 (my predecessor didn't bother with it), so I don't have a years-long database of approved updates.  KB2478662 has never appeared before (as I noted, KB2972100 was broadly installed in October) and has never had any approvals at all.  I've never had the opportunity to decline it, because it's never appeared as "needed".

    None of the four updates I mention came out since I installed WSUS.  If WSUS thinks KB2478662 is superseded, I have no idea why the Cleanup Wizard hasn't already handled it.  If WSUS doesn't think it's superseded, I have no idea why it waited until this morning instead of appearing the week after I installed WSUS.

    Any further thoughts?

    Monday, December 22, 2014 10:59 PM
  • 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.

    Tuesday, December 23, 2014 6:49 PM
  • KB2478662 has never appeared before (as I noted, KB2972100 was broadly installed in October) and has never had any approvals at all.

    What I meant was that KB2478662 has never appeared as "needed" before.  Yes, KB2972100 was installed on Windows 7 systems by Automatic Updates, and on Server 2008 R2 through WSUS.

    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).

    And on my WSUS console the update details for "Security Update for .NET Framework 3.5.1 on Windows 7 and Windows Server 2008 R2 SP1 for x64-based Systems (KB2478662)" say: "This update is superseded by another update," and continue, "Updates superseding this update: Security Update for .NET Framework 3.5.1 on Windows 7 and Windows Server 2008 R2 SP1 for x64-based Systems (KB2633873) / Security Update for .NET Framework 3.5.1 on Windows 7 and Windows Server 2008 R2 SP1 for x64-based Systems (KB2539635)". What's more, the details for both KB2633873 and KB2539635 (x64-based) say that they supersede the x64-based KB2478662.

    If I'm confused, I came by it honestly, by reading the WSUS console.

    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.

    And that's exactly what I meant by my first reply: All four of these updates should have been in the very first synchronization.  So, if KB2478662 is really needed by Windows 7 and Server 2008 R2, why didn't it show up as "needed" 7 weeks ago, when I started adding Windows 7 clients to WSUS?

    Whether it's superseded or not, whether it's really needed or not, I'm still wondering: What changed between Friday 12/19, when no client was reported as needing it, and Monday 12/22, when Server 2008 R2 and Windows 7 clients both started reporting it?  I haven't approved or declined anything; none of the Windows 7 clients have even rebooted.  That question is why I first thought the Cleanup Wizard might have been responsible.

    Wednesday, December 24, 2014 4:26 PM
  • What I meant was that KB2478662 has never appeared as "needed" before.

    I will concede that you did not personally notice this update as NEEDED before, but I promise you, it DID exist as a NEEDED update from the day those clients were first configured to use this WSUS server. (The REAL question is why the heck that update wasn't installed on these systems Way Back When!?)

    And on my WSUS console the update details for "Security Update for .NET Framework 3.5.1 on Windows 7 and Windows Server 2008 R2 SP1 for x64-based Systems (KB2478662)" say: "This update is superseded by another update," and continue, "Updates superseding this update: Security Update for .NET Framework 3.5.1 on Windows 7 and Windows Server 2008 R2 SP1 for x64-based Systems (KB2633873) / Security Update for .NET Framework 3.5.1 on Windows 7 and Windows Server 2008 R2 SP1 for x64-based Systems (KB2539635)".

    Hmmm! My Mistake! I totally missed that when I looked at it the first time.

    So, if KB2478662 is really needed by Windows 7 and Server 2008 R2, why didn't it show up as "needed" 7 weeks ago, when I started adding Windows 7 clients to WSUS?

    If that's really what happened, the answer is that seven weeks ago it wasn't needed. But you also have to understand that the state of superseded updates is FLUID depending on when new updates are released and how you manage the approvals and declinations of those updates. The bottom line is that you have SUPERSEDED updates that are NOT DECLINED.. and *THAT* will produce unexpected (but precisely predictable) behaviors.

    Whether it's superseded or not, whether it's really needed or not, I'm still wondering: What changed between Friday 12/19, when no client was reported as needing it, and Monday 12/22, when Server 2008 R2 and Windows 7 clients both started reporting it?

    I couldn't say "What changed?" That's for you to investigate and find out. As a starting point it would take forensic evaluation of the state of the WSUS server and each client across every event that occurred on each machine during that period of time. If you think it's worth the effort, I'll do what I can to help you through that process, but my inclination is to let it go and work with what you have today, which as far as I can tell is an accurate reflection of reality, and consistent with what should be reported.

    Otherwise, the only thing I can really do for you is explain to you how the process actually works.

    To be blunt, some of the things you describe as "factual" are actually logically impossible given the facts that are verifiable.

    Taking into consideration the correction on the question of the supersession of KB2478662, the ONLY way that update could be reported as NEEDED is if NONE of the supersededing updates (KB2539635, KB2633873, or KB2972100) were actually installed. As soon as any one of those three updates is installed, KB2478662 WILL be reported as NotApplicable. That's how supersession works.


    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.

    Thursday, December 25, 2014 1:44 AM
  • Okay, I think I've worked out exactly how I wound up where I was.  All that's required is a slight difference between the supersedence detection logic in the Windows Update Agent and in the WSUS Server Cleanup Wizard.  If it's there, you've been absolutely correct with the explanations you've offered, and yet I could still have seen the behavior I reported.

    We agree that all four updates would have been in the original synchronization on 11/03.  On most of the WSUS clients, KB2972100 had already been installed through Automatic Updates.

    But our Server 2008 R2 box had a problem with Automatic Updates, and one Windows 7 client had AU turned off, so when I first started using WSUS here, I approved KB2972100 for Server 2008 R2 and Windows 7 x64.  KB2972100 got installed on the server and the last workstation.  I didn't approve the earlier, superseded updates, and once KB2972100 was installed everywhere they no longer appeared on the "failed or needed" list.  So far, so good.

    It appears that WSUS can detect a chain of supersession, as long as none of the links in the chain have been declined.  As long as KB2539635 and KB2633873 (the two middle updates that explicitly supersede KB2478662 and are explicitly superseded by KB2972100) still had a status of "not approved", WSUS could follow the chain of supersedence from KB2972100 back to KB2478662, and no client reported the oldest update as "needed".

    Then, last Friday, I ran the Server Cleanup Wizard.  The two middle updates, neither one approved, both explicitly superseded by approved KB2972100, were--quite properly--declined by the wizard.  However, KB2478662 was not.  Now when WUA checked, there was no longer an intact chain of supersedence from KB2478662 to KB2972100.  WUA--quite properly--reported KB2478662 as needed.

    This morning, as a test, I went into WSUS and changed KB2539635 and KB2633873 from "declined" to merely "not approved".  Then I ran wuauclt on the clients, and Lo! KB2478662 no longer appeared as "needed".  Then I approved KB2539635 and ran the Cleanup Wizard, and KB2478662--quite properly--got marked as declined.

    With one minor difference between the Windows Update Agent and the Server Cleanup Wizard, the entire chain of events is perfectly plausible.  If WUA's detection logic will follow a chain of superseding updates, but the Cleanup Wizard is only satisfied when an immediately superseding update is approved, then you'd get exactly the behavior I've seen.

    • Marked as answer by Steven_Lee0510 Wednesday, January 7, 2015 9:37 AM
    Friday, December 26, 2014 10:39 PM
  • It appears that WSUS can detect a chain of supersession, as long as none of the links in the chain have been declined.

    Not true, to my knowledge, but functionally irrelevant, as *WSUS* does not do any processing of supersession logic EXCEPT to display hyperlinks in the console.

    *ALL* supersession logic is processed by the Windows Update Agent. Now, to that point, since the WUA cannot SEE a Declined Update, it would stand to reason that any updates that are declined will not be evaluated (nor can the WSUS server display such evaluations), so it's all pretty much a moot point as far as clients are concerned.

    As long as KB2539635 and KB2633873 (the two middle updates that explicitly supersede KB2478662 and are explicitly superseded by KB2972100) still had a status of "not approved", WSUS could follow the chain of supersedence from KB2972100 back to KB2478662, and no client reported the oldest update as "needed".

    While I appreciate your line of reasoning... it's valid from a logical point of view... take note that since it's not WSUS that makes this evaluation, the approval state is not really relevant, although as previously noted, if the update were DECLINED, then the client would not know of its existence.

    However, the WUA *is* capable of recognizing a superseded update, and it DOES ignore ALL SUPERSEDED updates in a supersession chain. In the unique case where the only approved update IS a superseded update, then the WUA honors that approval and will download/install that superseded update if it's not already installed.

    Then, last Friday, I ran the Server Cleanup Wizard.  The two middle updates, neither one approved, both explicitly superseded by approved KB2972100, were--quite properly--declined by the wizard.

    And so they should have been given that they were not needed by anything and had never been approved.

    However, KB2478662 was not.

    KB2478662 should also have been declined by the Server Cleanup Wizard for the same reason that KB2539635 and KB2633873 were declined.

    Now when WUA checked, there was no longer an intact chain of supersedence from KB2478662 to KB2972100.

    This is an appropriate observation. Because the supersession data is actually coded in the metadata of the NEW update. The presentation of the full chain in the console is accomplished by linking backward through that supersession logic. The WSUS server can still see this data, but the *WUA* cannot because the updates were declined.

    But to be direct, the defect here is not the WUA's handling of the situation; the defect is that ALL previous superseded and NotApplicable updates should have been declined. (Which, also, BTW, is a great reason for why you should not trust the SCW to do these declinations; you should do them yourself as is appropriate for each update.)

    WUA--quite properly--reported KB2478662 as needed.

    Unfortunately, it should not have done so, even with a broken supersession chain. If the newest update, KB2972100, was installed, and since these are Security Updates, then ALL of the requirements of KB2478662 should have already been met and the update still should have been evaluated as Not Applicable on its own merit. The fact that it was not tells me there is a detection logic defect in that update package... but it's never going to get fixed so this is an academic point at best.

    This morning, as a test, I went into WSUS and changed KB2539635 and KB2633873 from "declined" to merely "not approved".  Then I ran wuauclt on the clients, and Lo! KB2478662 no longer appeared as "needed".

    But only because it was suppressed for being superseded; not because the detection logic actually evaluated to that result. Being superseded overrides being "Not Installed".

    Then I approved KB2539635 and ran the Cleanup Wizard, and KB2478662--quite properly--got marked as declined.

    Most interesting. By all rights, KB2478662 should have been declined by the SCW by virtue of the presence of the approval of KB2972100. At the same time as the other two updates.

    With one minor difference between the Windows Update Agent and the Server Cleanup Wizard, the entire chain of events is perfectly plausible.  If WUA's detection logic will follow a chain of superseding updates, but the Cleanup Wizard is only satisfied when an immediately superseding update is approved, then you'd get exactly the behavior I've seen.

    This is not the case, and you've already disproven it by the mere fact that KB2539635 *AND* KB2633873 were both declined as a result of the presence of the approval for KB2972100. If your premise were true, then KB2539635 would not have been declined as a result of the non-existence of an approval on KB2633873.

    I believe there's still an open question as to why KB2478662 was not declined by the Server Cleanup Wizard, and given that we've already suggested the existence of defective detection logic in KB2478662, it's entirely possible that one or more systems were already reporting that update as Needed BEFORE you ran the Server Cleanup Wizard, which would have directly caused it's exclusion from the SCW's declination.


    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.

    Friday, December 26, 2014 11:57 PM
  • *WSUS* does not do any processing of supersession logic EXCEPT to display hyperlinks in the console.

    *ALL* supersession logic is processed by the Windows Update Agent.

    Of course, you're correct: the WUA does all the processing for--and on--the clients. WSUS merely reports a status of needed or otherwise according to what the clients report to it; I was oversimplifying.

    KB2478662 should also have been declined by the Server Cleanup Wizard for the same reason that KB2539635 and KB2633873 were declined.
    Then I approved KB2539635 and ran the Cleanup Wizard, and KB2478662--quite properly--got marked as declined.
    Most interesting. By all rights, KB2478662 should have been declined by the SCW by virtue of the presence of the approval of KB2972100. At the same time as the other two updates.
    And this behavior is why I suggested that the Cleanup Wizard and WUA don't use exactly the same supersession logic.
    WUA--quite properly--reported KB2478662 as needed.

    Unfortunately, it should not have done so, even with a broken supersession chain. If the newest update, KB2972100, was installed, and since these are Security Updates, then ALL of the requirements of KB2478662 should have already been met and the update still should have been evaluated as Not Applicable on its own merit. The fact that it was not tells me there is a detection logic defect in that update package...

    On this point I'm completely out of my depth, but as you say, it's academic by now.

    If WUA's detection logic will follow a chain of superseding updates, but the Cleanup Wizard is only satisfied when an immediately superseding update is approved, then you'd get exactly the behavior I've seen.

    This is not the case, and you've already disproven it by the mere fact that KB2539635 *AND* KB2633873 were both declined as a result of the presence of the approval for KB2972100. If your premise were true, then KB2539635 would not have been declined as a result of the non-existence of an approval on KB2633873.

    This discrepancy is because KB2539635 is explicitly superseded by both KB2633873 and KB2972100.  The Cleanup Wizard, working backward from the approved KB2972100, would have a direct link to both KB2538635 and KB2633873, but would have to go through one or the other of them to reach KB2478662.

    I should point out that even if the Cleanup Wizard's detection logic is different from WUA's, this situation could only arise when a superseding and superseded update such as KB2538635 has not been approved--in this case, because WSUS was newly installed and I only approved the most recent update.  Henceforth, if I keep WSUS tidy, approving superseding updates and declining superseded updates in a timely fashion, a similar situation shouldn't easily arise.

    (There is, of course, one other way I could have caused the original situation myself: by approving KB2478662, then removing the approval too recently for the Cleanup Wizard's 30-day window.  That could explain some of what I called false positives in the past, I suppose; I never said, but I used WSUS for about 10 years at another company.  But I've used WSUS such a brief time here that I haven't yet started removing approvals on old updates.  I can be certain, in this case, that KB2478662 has never been approved for install.)

    Wednesday, December 31, 2014 4:16 PM
  • This discrepancy is because KB2539635 is explicitly superseded by both KB2633873 and KB2972100.  The Cleanup Wizard, working backward from the approved KB2972100, would have a direct link to both KB2538635 and KB2633873, but would have to go through one or the other of them to reach KB2478662.

    There is NO difference in how supersession logic is processed by either WSUS, the SCW, or the WUA. It's actually a very simple list, which manifests as a double-linked list in the console, and upon sync of a superseding update triggers the setting of a flag value in superseded updates.

    An update contains a simple list of PackageIDs which identify the packages that are superseded by that update. However, the length of this list is finite, and rarely is it a comprehensive list of ALL superseded updates, particularly as the list grows to a certain size, or covers a certain period of time.

    • KB2972100 identifies two updates that it supersedes: KB2633873 and KB2539635.
    • KB2633873 identifies two updates that it supersedes: KB2539635 and KB2478662.
    • KB2539635 identifies one update that it supersedes: KB2478662.

    Why the Server Cleanup Wizard failed to automatically decline KB2478662 is the question. But, as always, the most likely reason is that the update failed to pass the rules required by the Server Cleanup Wizard to be eligible for declination, to wit: not approved, not needed for at least 30 days, and having an approved superseding update.

    Of course, noting that KB2972100 does not list KB2478662 as a superseded update means that KB2478662 did NOT have an approved superseding update, and thus could NOT be automatically declined by the Server Cleanup Wizard. You artificially satisifed this rule by removing the declination and approving the intermediate update, which resulted in the SCW doing what it was tasked to do correctly.

    The core issue here is that KB2972100 does not contain a comprehensive list of superseded updates, nor is there ever a guarantee that any update will. Ergo, I believe you're trying to attribute a scenario to complex architectural logic, when to be frank, the only error is human error -- failing to manually decline an update that should have been declined the day the server was deployed (because the update had already been superseded for over three years, and was already superseded by two additional update releases.)

    This is not the first time we've seen somebody have issues with legacy updates that weren't declined, nor is it even the tenth or twentieth.... and I highly doubt it will be the last.

    Bottom line: Manual administration of approvals/declines on legacy updates is a task that needs to be performed regularly, from the very first day a WSUS server is deployed.


    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.

    • Marked as answer by jjjdavidson Wednesday, January 7, 2015 3:49 PM
    Wednesday, December 31, 2014 6:21 PM
  • Sorry for the long delay.  I think between us we've about beaten this one to death.  All the updates concerned are now declined or installed as required, and if it happens again in the future I'll have a much better idea of what I should check.

    Thanks for all the time you put into this; I hope you left yourself time for the holidays!

    (By the way, I've been reading your PatchZone blog posts, particularly the ones about keeping the database tidy.  I've never had timeout errors, but I wish I'd found such clear information about database maintenance years ago.)

    Wednesday, January 7, 2015 3:58 PM