locked
Peculiar wuauclt startup detection behavior RRS feed

  • Question

  • I've noticed an odd change in the way wuauclt behaves on startup after installing previously detected updates.   It still does a detection but it's now inaccurate.

    There's a workaround but if you aren't careful, you might be fooled into thinking your system needs updates it doesn't actually need (and vice versa).

    My typical procedure for checking update status in my test environment has been to monitor C:\windows\windowsupdate.log (via dir) after a reboot, and when the file stops changing, look at the tail of the file to se if it says "0 updates detected", then do a <tt>wuauclt /reportnow</tt>, refresh the group view in the WSUS console and see if any new updates are needed.

    But now, unnecessary updates are appearing as needed and necessary updates are not appearing.   windowsupdate.log's detection status says "0 updates detected" and the time stamp is post-reboot, but WSUS reports that some superseded updates are still needed.  The updates that had just been installed appeared as installed.  The superseding updates have no status.

    The workaround appears to be doing a manual <tt>wuauclt /detectnow</tt> after the client has settled down post-restart.  

    After this extra /detectnow then /reportnow cycle, the superseded updates appear as not needed for the system in the WSUS console, and the superseding updates appear as needed.

    The latest episode was with 2953522 superseding 2964358 on Server 2008.  (It was disconcerting to see that the update with the lower KB number was the newer update, BTW).


    Monday, June 2, 2014 7:54 PM

Answers

  • The first challenge here is the interpretation of "0 updates detected" as meaning that no more updates are needed. In fact, it only means that there are no more updates available to that system at that moment.

    This is further complicated by a recently identified change in behavior of the WUA. It used to be that a full detection was performed after an installation or installation-and-reboot. But this is no longer the case, and as a result, some now-applicable updates that should be detected after reboot, are not being properly detected until the next scheduled full detection.

    Superseded updates still being "needed" are no different than they've always been. Once the system is restarted, then 10-20 minutes later the WUA reports those updates as Installed. Only after a new update is reported as Installed can the superseded update be reported as Not Applicable.

    Your 'workaround' of performing a /detectnow after reboot is effectively forcing that full detection that is no longer performed by default.


    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, June 3, 2014 1:00 AM

All replies

  • The first challenge here is the interpretation of "0 updates detected" as meaning that no more updates are needed. In fact, it only means that there are no more updates available to that system at that moment.

    This is further complicated by a recently identified change in behavior of the WUA. It used to be that a full detection was performed after an installation or installation-and-reboot. But this is no longer the case, and as a result, some now-applicable updates that should be detected after reboot, are not being properly detected until the next scheduled full detection.

    Superseded updates still being "needed" are no different than they've always been. Once the system is restarted, then 10-20 minutes later the WUA reports those updates as Installed. Only after a new update is reported as Installed can the superseded update be reported as Not Applicable.

    Your 'workaround' of performing a /detectnow after reboot is effectively forcing that full detection that is no longer performed by default.


    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, June 3, 2014 1:00 AM
  • The first challenge here is the interpretation of "0 updates detected" as meaning that no more updates are needed. In fact, it only means that there are no more updates available to that system at that moment.

    One would have hoped that it would at least mean 'no updates are available until you approve some more.'

    This is further complicated by a recently identified change in behavior of the WUA. It used to be that a full detection was performed after an installation or installation-and-reboot. But this is no longer the case, and as a result, some now-applicable updates that should be detected after reboot, are not being properly detected until the next scheduled full detection.

    This is the real answer.   I'd guess that Microsoft inverted the order of something.  At some point someone will have to explain what a "full detection" is (or at least what types of less-than-full detections there are).

    Your 'workaround' of performing a /detectnow after reboot is effectively forcing that full detection that is no longer performed by default.

    Yes, I understand that my 'workaround' is now a required action. It's disappointing, as it adds a lot of delay and makes for a lot of manual intervention when there's time pressure to get a server fully updated.


    Tuesday, June 3, 2014 2:22 PM
  • The first challenge here is the interpretation of "0 updates detected" as meaning that no more updates are needed. In fact, it only means that there are no more updates available to that system at that moment.

    One would have hoped that it would at least mean 'no updates are available until you approve some more.'

    There are many reasons why updates may not be available to a client and approvals are but only one of them. This forum discusses these scenarios at least monthly, so searching through recent posts is sure to turn up a recent conversation on these various reasons.

    This is further complicated by a recently identified change in behavior of the WUA. It used to be that a full detection was performed after an installation or installation-and-reboot. But this is no longer the case, and as a result, some now-applicable updates that should be detected after reboot, are not being properly detected until the next scheduled full detection.

    This is the real answer.   I'd guess that Microsoft inverted the order of something.

    More likely that somebody on the WUA team determined that such behavior was no longer necessary for use with Windows Update and completely failed to evaluate the potential impact on the enterprise. Such has been the reality of many recent changes to the Windows Update Agent since the release of Windows 7.

    At some point someone will have to explain what a "full detection" is (or at least what types of less-than-full detections there are).

    The detection event is a two part event. In the first part the WUA retrieves just enough information to determine whether an update is applicable or not. If the update is applicable, then in the second part it caches all of the relevant metadata in the local WUA datastore and processes the update for download and installation.

    However, the key here is those updates evaluated as Not Applicable are not cached. The detection performed after installation/reboot only uses cached metadata; it does not actually retrieve metadata from the WSUS server. A "full detection" will retrieve the missing metadata and cache it locally. The evidence of this is the "no extended metadata" message in the WindowsUpdate.log. 

    Yes, I understand that my 'workaround' is now a required action.

    Well, not really required. The only required action is to just let the WUA do its job the way it is now designed to do its job.

    To be fair, it's only your "need" to have immediate feedback that necessitates forcing the /detectnow after reboot.


    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, June 3, 2014 6:24 PM