none
Any way to view the update detection logic?

    Pergunta

  • We are seeing a few patches that are continuously reporting as vulnerable, yet the server / application owner has applied the patch. Is there a utility / tool to show the detection logic of a given patch within WSUS or Software Updates?  The update has not been superseded or expired, but the binaries on the servers in question have been updated to the patch levels.  I am wondering if anyone has seen or heard of a tool or method to view the update detection logic to determine why Windowsupdate or WSUS believes that the servers in question are still vulnerable for these updates.  Thank you in advance for any assistance.
    quarta-feira, 25 de maio de 2011 15:05

Respostas

  • >theoretically one can extract the SDP XML from the WSUS database, and find the appropriate rules within the XML

    While I might be 'doing it wrong', I've tried to put this particular theory into practice and failed.  See this thread.  It would seem that only locally published updates allow for this.

    Well.. considering that the WUAgent doesn't know the difference between a "Microsoft-published" update and a "Locally-published" update, and it's the Windows Update Agent that must extract and evaluate those rules defined in the XML -- it stands to reason that the information IS available.

    Now, that ExportPackageMetdata() only works for Locally Published updates -- that makes perfect sense. A number of API methods in the WSUS code are hard-filtered to only work on Locally Published updates.

    Consider this angle... the Windows Update Agent caches the metadata in the client-side datastore -- which is a Jet database.

    Two possibilities to pursue here:

    1. How does the WUAgent query the WSUS server to acquire the update definitions?

    2. What's in the client-side datastore.edb?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    quinta-feira, 26 de maio de 2011 21:02
    Moderador

Todas as Respostas

  • We are seeing a few patches that are continuously reporting as vulnerable, yet the server / application owner has applied the patch. Is there a utility / tool to show the detection logic of a given patch within WSUS or Software Updates?
    There is not, however, theoretically one can extract the SDP XML from the WSUS database, and find the appropriate rules within the XML.
    The update has not been superseded or expired, but the binaries on the servers in question have been updated to the patch levels.
    It's not impossible, though highly unlikely, that the update rules are defective. Specifically which update(s) are you observing this behavior with -- and on what systems?
    I am wondering if anyone has seen or heard of a tool or method to view the update detection logic to determine why Windowsupdate or WSUS believes that the servers in question are still vulnerable for these updates.

    Forgive my pedanticism, but I'm a stickler for using the correct vocabulary because I've found that when I make assumptions, usually I assume incorrectly. So.. first.. WSUS does not report any information about "vulnerabilities"; it only displays information about an update and the state of that update on a machine.  The update is either Installed, NotInstalled, or NotApplicable.

    Assuming that what you are intending to state here is that the update continues to be reported as NotInstalled, even when each and every file contained in the update has been physically verified as present on the machine, then there are a couple of things to be considered here.

    • First: What is the Last Reported Date for these client systems? I.e. Is the client actually reporting to the WSUS server? If it's not reporting . . . then no change in state would be an expected indication.
    • Second: How, exactly, was the patch actually applied to the system?
    • Third: As noted above, a critical component of this process is the update(s) and system(s) themselves, so we need to know which update(s) are involved, and information about the system(s) that these updates have (or have not) been installed onto.

    Generally speaking, what is reported by the Windows Update Agent to the WSUS server is, almost always, entirely accurate. So the real question to start with here is not:

    • What is defective in the update?

    but, rather

    • What is defective on these machines?

    If you install a virgin instance of the operating system and apply these update(s), do they install and report correctly?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    quarta-feira, 25 de maio de 2011 20:20
    Moderador
  • >theoretically one can extract the SDP XML from the WSUS database, and find the appropriate rules within the XML

    While I might be 'doing it wrong', I've tried to put this particular theory into practice and failed.  See this thread.  It would seem that only locally published updates allow for this.

    quinta-feira, 26 de maio de 2011 19:49
  • >theoretically one can extract the SDP XML from the WSUS database, and find the appropriate rules within the XML

    While I might be 'doing it wrong', I've tried to put this particular theory into practice and failed.  See this thread.  It would seem that only locally published updates allow for this.

    Well.. considering that the WUAgent doesn't know the difference between a "Microsoft-published" update and a "Locally-published" update, and it's the Windows Update Agent that must extract and evaluate those rules defined in the XML -- it stands to reason that the information IS available.

    Now, that ExportPackageMetdata() only works for Locally Published updates -- that makes perfect sense. A number of API methods in the WSUS code are hard-filtered to only work on Locally Published updates.

    Consider this angle... the Windows Update Agent caches the metadata in the client-side datastore -- which is a Jet database.

    Two possibilities to pursue here:

    1. How does the WUAgent query the WSUS server to acquire the update definitions?

    2. What's in the client-side datastore.edb?


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    quinta-feira, 26 de maio de 2011 21:02
    Moderador
  • One other note.. since you're digging deep into undocumented/unsupported territory here anyway . . . don't restrict yourself to what can be done with the API.

    As noted, the **DATA** is in the database, and most likely stored as raw XML -- somewhere. ;-)


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    quinta-feira, 26 de maio de 2011 21:04
    Moderador
  • Did anyone figure out how to pull the detection logic out of SUSDB? We are troubleshooting some issues were WUA is incorrectly reporting an update as applicable. We would like to see the logic used to troubleshoot.

    Levi Stevens

    sexta-feira, 13 de julho de 2018 22:24