locked
Clients on WSUS downstream server not reported yet for days RRS feed

  • Question

  • I have a new WSUS server deployment on Windows 2012. Currently, there are two servers, a primary in one office and a downstream server in the second office. Primary office computers are connecting and updating without much trouble. However, on the new downstream server, all the clients that are connecting to it are with the status of Not reported yet. I have checked the GPO, that is applying well and without problems.

    The downstream server is set as a replica server, but is set not to store updates locally, as it is ment for branch offices that have significantly better WAN links than LAN links. WSUS version is 6.2.9200.16384.

    All the client computers are Windows 7 Profressional or Enterprise. I have looked at ones WindowsUpdate log and it shows that its connecting to the update server, however, there are some errors.

    2014-10-13    10:57:30:387     580    1adc    AU    ###########  AU: Policy change processed  ###########
    2014-10-13    10:57:30:387     580    1adc    AU      # Policy changed, AU refresh required = No
    2014-10-13    10:57:30:387     580    1adc    AU      # WSUS server: http://xxxx:8530
    2014-10-13    10:57:30:387     580    1adc    AU      # Detection frequency: 22
    2014-10-13    10:57:30:387     580    1adc    AU      # Target group: UK-Usk
    2014-10-13    10:57:30:387     580    1adc    AU      # Approval type: Scheduled (Policy)
    2014-10-13    10:57:30:387     580    1adc    AU      # Scheduled install day/time: Every day at 10:00
    2014-10-13    10:57:30:387     580    1adc    AU      # Auto-install minor updates: Yes (Policy)
    2014-10-13    10:57:30:387     580    1adc    AU      # Will interact with non-admins (Non-admins are elevated (User preference))
    2014-10-13    10:57:30:387     580    1adc    AU      # Will display featured software notifications (User preference)
    2014-10-13    10:57:30:387     580    1adc    AU    AU settings changed through Policy.
    2014-10-13    10:57:30:392     580    1adc    AU    Setting AU scheduled install time to 2014-10-14 09:00:00
    2014-10-13    10:57:30:392     580    1adc    AU    Successfully wrote event for AU health state:0
    2014-10-13    10:57:30:607     580    1adc    AU    Successfully wrote event for AU health state:0
    2014-10-13    10:57:35:379     580    130c    Report    CWERReporter finishing event handling. (00000000)
    2014-10-13    12:09:16:264     580    1a60    AU    Triggering AU detection through DetectNow API
    2014-10-13    12:09:16:264     580    1a60    AU    Triggering Online detection (non-interactive)
    2014-10-13    12:09:16:274     580    1adc    AU    #############
    2014-10-13    12:09:16:274     580    1adc    AU    ## START ##  AU: Search for updates
    2014-10-13    12:09:16:274     580    1adc    AU    #########
    2014-10-13    12:09:16:314     580    1adc    AU    <<## SUBMITTED ## AU: Search for updates [CallId = {889370E7-6855-4098-B987-CDACD8E5E1FF}]
    2014-10-13    12:09:16:314     580    554    Agent    *************
    2014-10-13    12:09:16:314     580    554    Agent    ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2014-10-13    12:09:16:314     580    554    Agent    *********
    2014-10-13    12:09:16:314     580    554    Agent      * Online = Yes; Ignore download priority = No
    2014-10-13    12:09:16:314     580    554    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"
    2014-10-13    12:09:16:314     580    554    Agent      * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2014-10-13    12:09:16:314     580    554    Agent      * Search Scope = {Machine}
    2014-10-13    12:09:16:334     580    554    Setup    Checking for agent SelfUpdate
    2014-10-13    12:09:16:344     580    554    Setup    Client version: Core: 7.6.7600.320  Aux: 7.6.7600.320
    2014-10-13    12:09:19:114     580    554    Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab with dwProvFlags 0x00000080:
    2014-10-13    12:09:19:189     580    554    Misc     Microsoft signed: NA
    2014-10-13    12:09:19:189     580    554    Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\TMPD839.tmp with dwProvFlags 0x00000080:
    2014-10-13    12:09:19:229     580    554    Misc     Microsoft signed: NA
    2014-10-13    12:09:19:234     580    554    Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab with dwProvFlags 0x00000080:
    2014-10-13    12:09:19:239     580    554    Misc     Microsoft signed: NA
    2014-10-13    12:09:19:294     580    554    Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab with dwProvFlags 0x00000080:
    2014-10-13    12:09:19:299     580    554    Misc     Microsoft signed: NA
    2014-10-13    12:09:19:349     580    554    Setup    Determining whether a new setup handler needs to be downloaded
    2014-10-13    12:09:19:399     580    554    Misc    Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\Handler\WuSetupV.exe with dwProvFlags 0x00000080:
    2014-10-13    12:09:19:399     580    554    Misc     Microsoft signed: NA
    2014-10-13    12:09:19:399     580    554    Setup    SelfUpdate handler update NOT required: Current version: 7.6.7600.320, required version: 7.6.7600.320
    2014-10-13    12:09:19:399     580    554    Setup    Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.6.7600.320"
    2014-10-13    12:09:20:469     580    554    Setup    Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.6.7600.320" is already installed.
    2014-10-13    12:09:20:469     580    554    Setup    Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.320"
    2014-10-13    12:09:20:504     580    554    Setup    Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.320" is already installed.
    2014-10-13    12:09:20:504     580    554    Setup    Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.320"
    2014-10-13    12:09:20:534     580    554    Setup    Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.6.7600.320" is already installed.
    2014-10-13    12:09:20:534     580    554    Setup    SelfUpdate check completed.  SelfUpdate is NOT required.
    2014-10-13    12:09:28:294     580    554    PT    +++++++++++  PT: Synchronizing server updates  +++++++++++
    2014-10-13    12:09:28:294     580    554    PT      + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://xxxx:8530/ClientWebService/client.asmx
    2014-10-13    12:09:28:329     580    554    PT    WARNING: Cached cookie has expired or new PID is available
    2014-10-13    12:09:28:329     580    554    PT    Initializing simple targeting cookie, clientId = 49aaaa21-630b-45dc-ba10-a5f301e24e7b, target group = UK-Usk, DNS name = xxxx
    2014-10-13    12:09:28:329     580    554    PT      Server URL = http://xxx:8530/SimpleAuthWebService/SimpleAuth.asmx
    2014-10-13    12:09:47:034     580    554    PT    +++++++++++  PT: Synchronizing extended update info  +++++++++++
    2014-10-13    12:09:47:034     580    554    PT      + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://xxxx:8530/ClientWebService/client.asmx
    2014-10-13    12:09:47:619     580    554    PT    WARNING: GetExtendedUpdateInfo failure, error = 0x8024400E, soap client error = 7, soap error code = 400, HTTP status code = 200
    2014-10-13    12:09:47:619     580    554    PT    WARNING: SOAP Fault: 0x000190
    2014-10-13    12:09:47:619     580    554    PT    WARNING:     faultstring:Fault occurred
    2014-10-13    12:09:47:619     580    554    PT    WARNING:     ErrorCode:InternalServerError(5)
    2014-10-13    12:09:47:619     580    554    PT    WARNING:     Message:(null)
    2014-10-13    12:09:47:619     580    554    PT    WARNING:     Method:"http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetExtendedUpdateInfo"
    2014-10-13    12:09:47:619     580    554    PT    WARNING:     ID:25a64b16-7012-4320-930f-0b1d7699f299
    2014-10-13    12:09:47:619     580    554    PT    WARNING: PTError: 0x8024400e
    2014-10-13    12:09:47:619     580    554    PT    WARNING: GetExtendedUpdateInfo_WithRecovery: 0x8024400e
    2014-10-13    12:09:47:619     580    554    PT    WARNING: Sync of Extended Info: 0x8024400e
    2014-10-13    12:09:47:619     580    554    PT    WARNING: SyncServerUpdatesInternal failed : 0x8024400e
    2014-10-13    12:09:47:634     580    554    Agent      * WARNING: Exit code = 0x8024400E
    2014-10-13    12:09:47:634     580    554    Agent    *********
    2014-10-13    12:09:47:634     580    554    Agent    **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2014-10-13    12:09:47:634     580    554    Agent    *************
    2014-10-13    12:09:47:634     580    554    Agent    WARNING: WU client failed Searching for update with error 0x8024400e
    2014-10-13    12:09:47:664     580    1ed4    AU    >>##  RESUMED  ## AU: Search for updates [CallId = {889370E7-6855-4098-B987-CDACD8E5E1FF}]
    2014-10-13    12:09:47:664     580    1ed4    AU      # WARNING: Search callback failed, result = 0x8024400E
    2014-10-13    12:09:47:664     580    1ed4    AU      # WARNING: Failed to find updates with error code 8024400E
    2014-10-13    12:09:47:664     580    1ed4    AU    #########
    2014-10-13    12:09:47:664     580    1ed4    AU    ##  END  ##  AU: Search for updates [CallId = {889370E7-6855-4098-B987-CDACD8E5E1FF}]
    2014-10-13    12:09:47:664     580    1ed4    AU    #############
    2014-10-13    12:09:47:664     580    1ed4    AU    Successfully wrote event for AU health state:0
    2014-10-13    12:09:47:664     580    1ed4    AU    AU setting next detection timeout to 2014-10-13 16:09:47
    2014-10-13    12:09:47:664     580    1ed4    AU    Setting AU scheduled install time to 2014-10-14 09:00:00
    2014-10-13    12:09:47:664     580    1ed4    AU    Successfully wrote event for AU health state:0
    2014-10-13    12:09:47:664     580    1ed4    AU    Successfully wrote event for AU health state:0
    2014-10-13    12:09:52:634     580    554    Report    REPORT EVENT: {822491D6-CC9F-4027-8010-027583646AFD}    2014-10-13 12:09:47:634+0100    1    148    101    {00000000-0000-0000-0000-000000000000}    0    8024400e    AutomaticUpdates    Failure    Software Synchronization    Windows Update Client failed to detect with error 0x8024400e.
    2014-10-13    12:09:52:724     580    554    Report    CWERReporter::HandleEvents - WER report upload completed with status 0x8
    2014-10-13    12:09:52:724     580    554    Report    WER Report sent: 7.6.7600.320 0x8024400e 00000000-0000-0000-0000-000000000000 Scan 101 Managed
    2014-10-13    12:09:52:724     580    554    Report    CWERReporter finishing event handling. (00000000)

    Any insight into how to solve this issue would be greatly appreciated.

    Tuesday, October 14, 2014 7:50 AM

Answers

  • I have done that on the main server. However, even after a few replications between the servers the clients connecting to the replica server still seem to be looking for it.

    Which action did you take on the main server?

    DELETE does not replicate. If you deleted the update on the main server, you'll have to explicitly delete the update on the downstream servers.

    Expire/Decline will replicate (and it's important when DSS are involved to expire/decline and sync downstream servers before deleting from the USS; once the expire/decline is synchronized, then the Server Cleanup Wizard can be used to delete the update/files as appropriate.

    In addition, for systems where the update was evaluated as potentially applicable, the metadata is cached in the client-side datastore, so it's also important for the expire/decline action to be obtained by the client systems before deleting the update.

    If the update is orphaned on the downstream servers, the clients will continue to see it until it's deleted from the downstream servers.

    If the update is orphaned in the client datastore, you'll need to rebuild the client datastore, as there's no way for the client to discover the update has been expired/declined.

    1. Stop the Windows Update service.
    2. Copy the %windir%\SoftwareDistribution\ReportingEvents.log to a safe place.
    3. Rename the %windir%\SoftwareDistribution folder.
    4. Start the Windows Update service.
    5. Copy the saved ReportingEvents.log back to %windir%\SoftwareDistribution. (This may require another stop/start of the service if the target file is locked.)

    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 Urmas Kask Tuesday, October 21, 2014 7:40 AM
    Wednesday, October 15, 2014 2:26 PM

All replies

  • Ok, seems I have narrowed down the problem. Looking at the softwaredistributionlogs on the new server theres an error for a missing file.

    Error    w3wp.11    ClientImplementation.GetExtendedUpdateInfo    System.ArgumentException: The database does not contain a URL for the file 24BE37400A93E9BBAC727639B2E4D2490F700CA1.
    Parameter name: fileDigests
       at Microsoft.UpdateServices.Internal.DataAccess.ExecuteSpGetFileLocations(Byte[][] fileDigests)
       at Microsoft.UpdateServices.Internal.DataAccessCache.GetFileLocations(Byte[][] fileDigests, DataAccess da)
       at Microsoft.UpdateServices.Internal.ClientImplementation.GetExtendedUpdateInfo(Cookie cookie, Int32[] revisionIds, XmlUpdateFragmentType[] fragmentTypes, String[] locales)
       at Microsoft.UpdateServices.Internal.ClientImplementation.GetExtendedUpdateInfo(Cookie cookie, Int32[] revisionIds, XmlUpdateFragmentType[] fragmentTypes, String[] locales)
       at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
       at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Web.Services.Protocols.LogicalMethodInfo.Invoke(Object target, Object[] values)
       at System.Web.Services.Protocols.WebServiceHandler.Invoke()
       at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
       at System.Web.Services.Protocols.SyncSessionlessHandler.ProcessRequest(HttpContext context)
       at System.Web.Script.Services.ScriptHandlerFactory.HandlerWrapper.ProcessRequest(HttpContext context)
       at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
       at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
       at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)
       at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)
       at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)
       at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
       at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
       at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)
       at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)
       at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
       at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)

    I suspect this might be a leftover from a test with custom update package on the main WSUS server. However, now the question becomes, how can this be fixed.

    • Edited by Urmas Kask Tuesday, October 14, 2014 12:33 PM
    Tuesday, October 14, 2014 12:27 PM
  • I suspect this might be a leftover from a test with custom update package on the main WSUS server. However, now the question becomes, how can this be fixed.

    Find the update in whatever tool you used to publish the package and decline/expire/delete the package so that the client cannot see it in the scan.

    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, October 14, 2014 1:55 PM
  • I have done that on the main server. However, even after a few replications between the servers the clients connecting to the replica server still seem to be looking for it.
    Wednesday, October 15, 2014 7:16 AM
  • I have done that on the main server. However, even after a few replications between the servers the clients connecting to the replica server still seem to be looking for it.

    Which action did you take on the main server?

    DELETE does not replicate. If you deleted the update on the main server, you'll have to explicitly delete the update on the downstream servers.

    Expire/Decline will replicate (and it's important when DSS are involved to expire/decline and sync downstream servers before deleting from the USS; once the expire/decline is synchronized, then the Server Cleanup Wizard can be used to delete the update/files as appropriate.

    In addition, for systems where the update was evaluated as potentially applicable, the metadata is cached in the client-side datastore, so it's also important for the expire/decline action to be obtained by the client systems before deleting the update.

    If the update is orphaned on the downstream servers, the clients will continue to see it until it's deleted from the downstream servers.

    If the update is orphaned in the client datastore, you'll need to rebuild the client datastore, as there's no way for the client to discover the update has been expired/declined.

    1. Stop the Windows Update service.
    2. Copy the %windir%\SoftwareDistribution\ReportingEvents.log to a safe place.
    3. Rename the %windir%\SoftwareDistribution folder.
    4. Start the Windows Update service.
    5. Copy the saved ReportingEvents.log back to %windir%\SoftwareDistribution. (This may require another stop/start of the service if the target file is locked.)

    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 Urmas Kask Tuesday, October 21, 2014 7:40 AM
    Wednesday, October 15, 2014 2:26 PM
  • I expired the update. Then deleted. So I was a bit too rash on the deletion part. Rebuilding the datastore helped, thanks.
    Tuesday, October 21, 2014 7:40 AM