Answered by:
Clients on WSUS downstream server not reported yet for days

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.
- Stop the Windows Update service.
- Copy the %windir%\SoftwareDistribution\ReportingEvents.log to a safe place.
- Rename the %windir%\SoftwareDistribution folder.
- Start the Windows Update service.
- 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.
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.
- Stop the Windows Update service.
- Copy the %windir%\SoftwareDistribution\ReportingEvents.log to a safe place.
- Rename the %windir%\SoftwareDistribution folder.
- Start the Windows Update service.
- 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