locked
Updates required, but not showing up on some desktops RRS feed

  • Question

  • I have an odd situation where some computers are updating just fine, and others do not seem to update completely.

    We have a WSUS server pulling updates from Microsoft nightly.  Clients check in once per day.

    As an example my desktop shows 24 updates approved and pending on WSUS, but my laptop shows as up to date.  I also ran into a machine today that is on the shelf and has not been updated for a while.  It reports as up to date on the client but has 90+ updates approved and pending.

    Here is what the client log shows after an update check:

    e64 AU AU setting next detection timeout to 2014-04-12 13:15:46
    e64 AU Successfully wrote event for AU health state:0
    e64 AU Successfully wrote event for AU health state:0
    668 Report REPORT EVENT: {121D5AE0-826F-4F3C-AABA-E147CF4864FB} 2014-04-11 12:28:57:327-0400 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates.
    668 Report REPORT EVENT: {8C38B0CB-1781-429A-9CAC-318C433348AD} 2014-04-11 12:28:57:343-0400 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.
    668 Report CWERReporter finishing event handling. (00000000)
    d6c AU Windows Update is disabled by policy for user
    d6c AU Triggering AU detection through DetectNow API
    d6c AU Triggering Online detection (non-interactive)
    fd8 AU #############
    fd8 AU ## START ##  AU: Search for updates
    fd8 AU #########
    fd8 AU <<## SUBMITTED ## AU: Search for updates [CallId = {8C83C1B9-6652-41EA-85C6-90A8529176B4}]
    668 Agent *************
    668 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    668 Agent *********
    668 Agent   * Online = Yes; Ignore download priority = No
    668 Agent   * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
    668 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    668 Agent   * Search Scope = {Machine}
    668 Setup Checking for agent SelfUpdate
    668 Setup Client version: Core: 7.6.7600.256  Aux: 7.6.7600.256
    668 Misc Validating signature for C:\windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    668 Misc  Microsoft signed: Yes
    668 Misc Validating signature for C:\windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    668 Misc  Microsoft signed: Yes
    668 Misc Validating signature for C:\windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
    668 Misc  Microsoft signed: Yes
    668 Misc Validating signature for C:\windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
    668 Misc  Microsoft signed: Yes
    668 Setup Determining whether a new setup handler needs to be downloaded
    Setup SelfUpdate handler is not found.  It will be downloaded
    668 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.6.7600.256"
    688 Setup Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.6.7600.256" is already installed.
    668 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256"
    668 Setup Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" is already installed.
    668 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256"
    668 Setup Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.6.7600.256" is already installed.
    668 Setup SelfUpdate check completed.  SelfUpdate is NOT required.
    668 PT +++++++++++  PT: Synchronizing server updates  +++++++++++
    668 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = web://****/ClientWebService/client.asmx
    668 Agent   * Found 0 updates and 73 categories in search; evaluated appl. rules of 1094 out of 1835 deployed entities
    668 Agent *********
    668 Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    668 Agent *************
    e64 AU >>##  RESUMED  ## AU: Search for updates [CallId = {8C83C1B9-6652-41EA-85C6-90A8529176B4}]
    e64 AU   # 0 updates detected
    e64 AU #########
    e64 AU ##  END  ##  AU: Search for updates [CallId = {8C83C1B9-6652-41EA-85C6-90A8529176B4}]
    e64 AU #############
    e64 AU Successfully wrote event for AU health state:0
    e64 AU Featured notifications is disabled.
    e64 AU AU setting next detection timeout to 2014-04-12 11:07:31
    e64 AU Successfully wrote event for AU health state:0
    e64 AU Successfully wrote event for AU health state:0
    668 Report REPORT EVENT: {47E0AACC-0D9D-4FEB-BADD-3D3257D60C56} 2014-04-11 12:33:46:421-0400 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software Synchronization Windows Update Client successfully detected 0 updates.
    668 Report REPORT EVENT: {6A2C1C72-DA60-4481-B967-F0A3A6BE011D} 2014-04-11 12:33:46:421-0400 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.
    668 Report CWERReporter finishing event handling. (00000000)
    668 Report Uploading 4 events using cached cookie, reporting URL = web://*******/ReportingWebService/ReportingWebService.asmx
    668 Report Reporter successfully uploaded 4 events.

    I've compared this to a log on a computer that is fully up to date and it matches line for line.  I'm really puzzled by this.

    Any suggestions for where to go with this would be appreciated.

    Friday, April 11, 2014 7:29 PM

Answers

  • I realised this afternoon that (I think anyway) our server doesn't download the update until it's approved.

    This is correct. The installation file for an update is downloaded to the WSUS server after the update is first approved.
    So I was updating machines straight after approval thinking they would get all their "needed" updates.
    But the update were not yet available to those client machines because they had not yet been downloaded to the WSUS server.
    But they wont be downloaded until the server has it's first synchronization after approval.
    Not correct. The file downloads are queued immediately. Depending on what version of Windows and BITS you have installed, and how many updates were approved, the downloads may occur serially and take a few hours, or they may occur in parallel and be completed in a few minutes. The good news is that the WSUS console provides status information on this activity, so that's what you should monitor after approving updates.

    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 Daniel JiSun Tuesday, May 6, 2014 10:58 AM
    Tuesday, April 15, 2014 9:23 PM
    • What updates should have been available, and
    • Why were they not available at that time?

    Lets examine the case of the backup that has been on the shelf a while.

    I really would like to help, but this post does not really answer my two questions. If you want to troubleshoot this scenario, we're going to need some HARD information to work with.

    WSUS reported (updates needed report) that there were 90+ updates available and approved for that machine

    The computer reporded that there were no updates available.

    My first eyebrow-raising moment here is the idea that a computer has 90+ updates approved and available (and, ostensibly, cannot find any of them to be downloaded), and my very first question in response to raising that eyebrow is this: And all 90+ of those updates are NOT SUPERSEDED??? To which my second question would be: When was the last time that machine had patches installed?

    I took a look at another computer in the same OU and computer update group with the same initial install image and I see 12 updates available, all not yet approved for that group.

    If the updates are Not Approved, then those updates are also Not Available.

    I'll also point out here that the best way to approach this scenario is to believe what you see and investigate the reason why, rather than questioning the veracity of what's displayed in the console or the logs.

    If the client says there are no updates available for installation, then that's the bottom line, and the proper response is to identify an update that should be available for installation and determine why it's not being downloaded/installed.


    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 Daniel JiSun Tuesday, May 6, 2014 10:59 AM
    Thursday, April 24, 2014 1:41 AM
  • I would dearly love to give you the hard information you need, but I don't know what it might be or where to find it.

    Okay, let's back up all the way to the beginning, and please forgive my impertinence or anything that may sound condescending. It's not my intent to insult, merely to help you get to the point where we can get some useful information to help you address the issue.

    The subject of your message says "Update required, but not showing on desktops".

    In your original post you made this statement:

    ... and others do not seem to update completely.

    So my question for you is this: Based on what factual information do you believe this is true?


    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 Daniel JiSun Tuesday, May 6, 2014 10:59 AM
    Friday, April 25, 2014 11:24 PM

All replies

  • I have this exact problem on a few machines. But I realised this afternoon that (I think anyway) our server doesn't download the update until it's approved. So I was updating machines straight after approval thinking they would get all their "needed" updates. But they wont be downloaded until the server has it's first synchronization after approval. 

    So hopefully tonight when the server syncs it will download the updates and then the next time I run a client update it will then pick up all it's approved updates. 

    Friday, April 11, 2014 10:42 PM
  • Hello,

    What is the current situation? Are these client able to get updates?

    Monday, April 14, 2014 1:26 AM
  • I realised this afternoon that (I think anyway) our server doesn't download the update until it's approved.

    This is correct. The installation file for an update is downloaded to the WSUS server after the update is first approved.
    So I was updating machines straight after approval thinking they would get all their "needed" updates.
    But the update were not yet available to those client machines because they had not yet been downloaded to the WSUS server.
    But they wont be downloaded until the server has it's first synchronization after approval.
    Not correct. The file downloads are queued immediately. Depending on what version of Windows and BITS you have installed, and how many updates were approved, the downloads may occur serially and take a few hours, or they may occur in parallel and be completed in a few minutes. The good news is that the WSUS console provides status information on this activity, so that's what you should monitor after approving updates.

    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 Daniel JiSun Tuesday, May 6, 2014 10:58 AM
    Tuesday, April 15, 2014 9:23 PM
  • My situation has not changed.  Some clients are fine.  Some clients just think they are fine, but require updates.

    Tonight I removed one of the problem computers from the domain and forced an update through Microsoft directly.  It is now happily updating.

    I really don't know where to go from here.

    Edit:  The computer has updated successfully.  Rejoining it to the domain, it correctly reports as up to date, so reporting works just fine.  Why does detection not?
    Friday, April 18, 2014 4:12 AM
  • Why does detection not?

    The answer to this question is best obtained by reviewing the WindowsUpdate.log of the affected client system(s) and determining what DID happen. Once you know what did happen, you can then compare that against what should have happened, and diagnose why it did 'A' when 'B' was the expected behavior.

    In the case of the logfile posted above, what we do know is that the client could not find any available updates to download.

    668 Agent   * Found 0 updates and 73 categories in search; evaluated appl. rules of 1094 out of 1835 deployed entities

    So that becomes the question of focus:

    • What updates should have been available, and
    • Why were they not available at that time?

    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, April 18, 2014 6:07 PM
    • What updates should have been available, and
    • Why were they not available at that time?

    Lets examine the case of the backup that has been on the shelf a while.

    WSUS reported (updates needed report) that there were 90+ updates available and approved for that machine

    The computer reporded that there were no updates available.

    The console indicated that there are 0 updates needing files.

    I took a look at another computer in the same OU and computer update group with the same initial install image and I see 12 updates available, all not yet approved for that group.

    Forcing an update using wuauclt /detectnow generated identical update logs on the two clients and the Last Status Report updated appropriately for both computers.  From this I concluded that my problem computer appeared to be communicating with the server properly.

    The only difference between the two computer is that one was neglected on the shelf for several months and one is in active use and has been updated regularly.

    Out of curiosity I removed the offending computer from our domain and forced a check in directly with Microsoft, found updates, installed them and then rejoined the domain.  After a detect and report, it now it shows as fully up to date.

    Having typed all this, I am no closer to understanding why my server and the client had a different view of what should have been available.  Given the different response from the MS server, I can only guess the issue lies with the WSUS server.

    Tuesday, April 22, 2014 7:17 AM
    • What updates should have been available, and
    • Why were they not available at that time?

    Lets examine the case of the backup that has been on the shelf a while.

    I really would like to help, but this post does not really answer my two questions. If you want to troubleshoot this scenario, we're going to need some HARD information to work with.

    WSUS reported (updates needed report) that there were 90+ updates available and approved for that machine

    The computer reporded that there were no updates available.

    My first eyebrow-raising moment here is the idea that a computer has 90+ updates approved and available (and, ostensibly, cannot find any of them to be downloaded), and my very first question in response to raising that eyebrow is this: And all 90+ of those updates are NOT SUPERSEDED??? To which my second question would be: When was the last time that machine had patches installed?

    I took a look at another computer in the same OU and computer update group with the same initial install image and I see 12 updates available, all not yet approved for that group.

    If the updates are Not Approved, then those updates are also Not Available.

    I'll also point out here that the best way to approach this scenario is to believe what you see and investigate the reason why, rather than questioning the veracity of what's displayed in the console or the logs.

    If the client says there are no updates available for installation, then that's the bottom line, and the proper response is to identify an update that should be available for installation and determine why it's not being downloaded/installed.


    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 Daniel JiSun Tuesday, May 6, 2014 10:59 AM
    Thursday, April 24, 2014 1:41 AM
  • I would dearly love to give you the hard information you need, but I don't know what it might be or where to find it.

    You can relax the eyebrow Spock :-) , the lack of updates issue was an oversight and has been resolved.

    I believe what I see, but it does not reconcile.  I do not know why a small minority of computers in an OU show a different status than their identically configured and located (OU and Update Group) counterparts.

    The client log does not provide any clues.  I have no idea where to look next...

    As far as updates being superseeded, if all 90 were, I would not have been able to grab them from Microsoft directly.  Now that this particular machine is back on our domain, WSUS shows it as up to date.  The most expedient thing would be to take the small number of machines out of sync and update them directly from MS, but I don't learn anything from that.

    Any clue as to where to start looking, or what to start reading if I need to educate myself further in regards to troubleshooting WSUS would certainly help.

    Friday, April 25, 2014 2:23 AM
  • I would dearly love to give you the hard information you need, but I don't know what it might be or where to find it.

    Okay, let's back up all the way to the beginning, and please forgive my impertinence or anything that may sound condescending. It's not my intent to insult, merely to help you get to the point where we can get some useful information to help you address the issue.

    The subject of your message says "Update required, but not showing on desktops".

    In your original post you made this statement:

    ... and others do not seem to update completely.

    So my question for you is this: Based on what factual information do you believe this is true?


    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 Daniel JiSun Tuesday, May 6, 2014 10:59 AM
    Friday, April 25, 2014 11:24 PM