WSUS 3.0 Replica Server Sync Error

All Replies

• Tuesday, December 04, 2012 1:55 AM

  Moderator

   

   
  

  0

  I have a problem that I am having with a WSUS3 installation. This server is a Windows 2003 SP2 server and has WSUS 3.0 SP2 Version 3.2.7600.226 (WSUS30-KB9742455-x86.exe). In addition, it has the patch WSUS-KB2734608-x86.exe installed as well.

  A pedandic point.. but if it has KB2734608 installed then it is not version 3.2.7600.226.

  The WSUS server in Domain B (which I maintain) is required to be set up as a replica server from the WSUS server within Domain A. This server is using the built in database installed on installation of WSUS. The problem occurs when once I initiate a synchronisation, the WSUS (within Domain B) gets to Status: Synchronizing..., Progress: 99%. This will stay at 99% for approximately 19 minutes and then fails with the following error within console:
  
  An error occurred with the server's data store.
  SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

  Does the Upstream Server in Domain A also have KB2734608 installed?

  This issue is discussed ad infinitum (perhaps even ad nauseum now), at least weekly, in this forum. In most cases, a timeout issue during server synchronization is caused by an improperly maintained upstream server. Recently we've also seen the issue appear when mass declines have been performed on the upstream server. In either event, it's an issue at the upstream server and there's nothing you can do at the replica to get around it.

  The interesting thing is if I change this server back to a non-replica server the synchronization will complete at 100% without failure.

  Thus confirming that the primary issue is being able to successfully replicate approval events from the upstream server.

  How many updates are within this server? (Before Cleanup Wizard Run)
      -    Unapproved Updates (Status: Any): 25136 updates of 31653 shown, 31653 total
      -    Approved Updates (Status: Any): 2385 updates of 31653 shown, 31653 total
      -    Declined Updates (Status: Any):4132 updates of 31653 shown, 31653 total

  Well, that certainly confirms the theory that the upstream server is being poorly maintained.

  • =31653= total updates;
  • =25136= unapproved updates (probably all drivers);
  • =2385= approved updates (and here's the cruz of your problem .. at least the starting point)

  How many computers attach to this WSUS Server:
      -    Computers: 80 all in the one group 'All Computers'.

  Hmmmm... 80 groups isn't helping matters either... not when joined against the 2,385 approvals.

  How many languages & Update File Settings?
      -    1 x English

  Interesting.... I'll have to research this, but I wasn't aware that an English-only server had gotten to the point of having 31,000+ updates in the catalog. Even so, the only way I think this could actually happen is to select *ALL* product categories and *ALL* update classifications on the upstream server.

  When was the last time the Server Cleanup Wizard was run?
      -    The Server Cleanup Wizard been run several times since I was faced with the synchronization problem with no effect on the synchronization failure.
  
  When was the last time the WSUS DB Maintenance Script was run?
      -    This is a new installation. The maintenance script has never been run.

  In this case it's not when were they run on the replica server... but rather when were they run on the UPSTREAM server.

  Frankly, I would say that not having control over the upstream server is putting you at a serious disadvantage here, and I'd also suggest critically re-evaluating why your server needs to be a replica server rather than an autonomous upstream server.

  Is it your expectation that the people managing (or not) the upstream server are also going to have unilateral authority over what updates are installed in your organization?

  • If so, then I'd argue that it's their responsibility to install a replica server and make it work so that their patch management efforts are successful to the extent they should be.
  • If not, then it begs the question why you're even linking to that server.

  Without a healthy, well-designed, and well-maintained upstream server (of which none of those three seem to apply here), you're going to be in a world of hurt, not just today, but probably for the lifetime of the implementation.

  ---

  Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
  SolarWinds Head Geek
  Microsoft MVP - Software Distribution (2005-2012)
  My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

  • Reply
  • Quote

   
• Friday, December 07, 2012 8:04 AM

  Moderator

   

   
  

  0

  Hi,

  I would like to confirm what is the current situation? If there is anything that I can do for you, please do not hesitate to let me know, and I will be happy to help.

  Regards,

  Clarence

  TechNet Subscriber Support

  If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.

  ---

  Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

  • Reply
  • Quote

   
• Monday, December 10, 2012 2:19 AM

   

   
  

  0

  G'Day Clarence,

  Until now I have not been able to resolve this. This morning after discussions with manangment it was decided to uninstall WSUS 3 and for now reinstall WSUS 2.0 SP1. This should give me a little time to work on this. I proceeded to uninstall WSUS 3 SP2 and reinstall WSUS 2 SP1. On top of that I also installed WSUS20SP1-KB936301.cab (Selfupdate.msp). I did and resynced with the existing WSUS 2 servers within the enviroment. Looking at the Computers tab I see all the servers (Win2003 Servers) listed however 'none' of them are now reporting. I tried all the resetauthorization etc that I could find without success. This is getting bad to worse for me. I checked the Windowsupdate log file and it mentions the following:

  2012-12-10 09:43:01:649  816 690 AU #############
  2012-12-10 09:43:01:649  816 690 AU ## START ##  AU: Search for updates
  2012-12-10 09:43:01:649  816 690 AU #########
  2012-12-10 09:43:01:649  816 690 AU <<## SUBMITTED ## AU: Search for updates [CallId = {3C4EA61C-40D9-4F5F-A5AA-7D6DB626E296}]
  2012-12-10 09:43:01:649  816 e64 Agent *************
  2012-12-10 09:43:01:649  816 e64 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
  2012-12-10 09:43:01:649  816 e64 Agent *********
  2012-12-10 09:43:01:649  816 e64 Agent   * Online = Yes; Ignore download priority = No
  2012-12-10 09:43:01:649  816 e64 Agent   * Criteria = "IsHidden=0 and IsInstalled=0 and DeploymentAction='Installation' and IsAssigned=1 or IsHidden=0 and IsPresent=1 and DeploymentAction='Uninstallation' and IsAssigned=1 or IsHidden=0 and IsInstalled=1 and DeploymentAction='Installation' and IsAssigned=1 and RebootRequired=1 or IsHidden=0 and IsInstalled=0 and DeploymentAction='Uninstallation' and IsAssigned=1 and RebootRequired=1"
  2012-12-10 09:43:01:649  816 e64 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
  2012-12-10 09:43:01:649  816 e64 Agent   * Search Scope = {Machine}
  2012-12-10 09:43:04:492  816 e64 Misc Validating signature for C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default\wuident.cab:
  2012-12-10 09:43:04:492  816 e64 Misc  Microsoft signed: Yes
  2012-12-10 09:43:04:492  816 e64 Misc WARNING: Digital Signatures on file C:\WINDOWS\SoftwareDistribution\SelfUpdate\Default\wuident.cab are not trusted: Error 0x800b0001
  2012-12-10 09:43:04:492  816 e64 Setup FATAL: IsUpdateRequired failed with error 0x800b0001
  2012-12-10 09:43:04:492  816 e64 Setup WARNING: SelfUpdate: Default Service: IsUpdateRequired failed: 0x800b0001
  2012-12-10 09:43:04:492  816 e64 Setup WARNING: SelfUpdate: Default Service: IsUpdateRequired failed, error = 0x800B0001
  2012-12-10 09:43:04:492  816 e64 Agent   * WARNING: Skipping scan, self-update check returned 0x800B0001
  2012-12-10 09:43:04:633  816 e64 Agent   * WARNING: Exit code = 0x800B0001
  2012-12-10 09:43:04:633  816 e64 Agent *********
  2012-12-10 09:43:04:633  816 e64 Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
  2012-12-10 09:43:04:633  816 e64 Agent *************
  2012-12-10 09:43:04:633  816 e64 Agent WARNING: WU client failed Searching for update with error 0x800b0001
  2012-12-10 09:43:04:633  816 d4c AU >>##  RESUMED  ## AU: Search for updates [CallId = {3C4EA61C-40D9-4F5F-A5AA-7D6DB626E296}]
  2012-12-10 09:43:04:633  816 d4c AU   # WARNING: Search callback failed, result = 0x800B0001
  2012-12-10 09:43:04:633  816 d4c AU   # WARNING: Failed to find updates with error code 800B0001
  2012-12-10 09:43:04:633  816 d4c AU #########
  2012-12-10 09:43:04:633  816 d4c AU ##  END  ##  AU: Search for updates [CallId = {3C4EA61C-40D9-4F5F-A5AA-7D6DB626E296}]
  2012-12-10 09:43:04:633  816 d4c AU #############
  2012-12-10 09:43:04:633  816 d4c AU AU setting next detection timeout to 2012-12-10 02:19:03
  2012-12-10 09:43:09:492  816 e64 Report REPORT EVENT: {2199BD7C-7B96-4EA6-9947-698F80D593DB} 2012-12-10 09:43:04:492+1100 1 148 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 0 800b0001 SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x800b0001.
  2012-12-10 09:45:18:585  816 e64 PT WARNING: Cached cookie has expired or new PID is available
  2012-12-10 09:45:18:585  816 e64 PT Initializing simple targeting cookie, clientId = a7a2a07b-6a97-4d13-8d66-37473e362fe1, target group = Windows Server Deployment, DNS name = server.domain.com
  2012-12-10 09:45:18:585  816 e64 PT   Server URL = http://wsusserver:8530/SimpleAuthWebService/SimpleAuth.asmx
  2012-12-10 09:45:18:616  816 e64 Report Uploading 1 events using cached cookie, reporting URL = http://wsusserver:8530/ReportingWebService/ReportingWebService.asmx
  2012-12-10 09:45:18:616  816 e64 Report Reporter successfully uploaded 1 events.

  If anyone is able to provide any further information it would really help right about now...

  Cheers and Thanks in advance

  • Reply
  • Quote

   
• Monday, December 10, 2012 7:51 AM

  Moderator

   

   
  

  0
  0x800B0001 indicate that this can be due to a version mismatch between the Windows update agent and the WSUS server.WSUS needs to be at version 3.2.7600.251 in order to properly communicate with clients at version 7.6.7600.256.
  WSUS 2 is no longer a supported product.Pls try to install the WSUS 3.0sp2 instead.

  ---

  Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

  • Marked As Answer by Clarence ZhangModerator Tuesday, December 18, 2012 2:19 AM
  • Unmarked As Answer by Homith Tuesday, December 18, 2012 2:57 AM
  •  
  • Reply
  • Quote

   
• Monday, December 10, 2012 8:22 PM

   

   
  

  0

  G'Day Clarence,

  Thanks for the feedback on this. Is there any way WSUS 2 can be patched (that you know of) to accept version 7.6.7600.256 clients? All this was functional before I attempted to upgrade to WSUS 3. I am guessing that the self update worked and upgraded all the clients? I cannot think of any other reason why rolling back to WSUS 2 now fails?

  
  Cheers & Thanks in advance for all assistance

  
  Is there a way to uninstall 7.6.7600.256 ?

  • Edited by Homith Monday, December 10, 2012 10:44 PM
  •  
  • Reply
  • Quote

   
• Tuesday, December 11, 2012 6:01 AM

  Moderator

   

   
  

  0

  WSUS 2 is no longer a supported product.Why do you focus on WSUS 2 which has been out of our eyes for several years?To rolling back to WSUS 2,you need to roll back to the WUA on the client side that WSUS 2 can be recognized.It is definitely a tedious and meaningless work.

  ---

  Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

  • Reply
  • Quote

   
• Tuesday, December 11, 2012 6:22 AM

   

   
  

  0

  G'day Clarence,

  Ok I will try to move forward with the WSUS 3 install. I have to go in that direction one at some time in the future anyhow. If you recall in my WSUS 3 SP2 (with Kb273608  installed) I was having a problem with it synchronising. The server sync's ok if set as a stand alone server, however, as soon as I change it to a Replica server it gets to 99% and then fails. I have organised a purchase of support through Microsoft and am interested in getting help from them as well. I have just finished uninstalling the WSUS 2 enviroment and reinstalled WSUS 3. I will collect new logs when available. They will be similar to the previous ones posted tho.

  Kind Regards and Many Thanks In Advance For Any Help

  • Reply
  • Quote

   
• Tuesday, December 18, 2012 2:57 AM

   

   
  

  0

  Well I took the advise and rebuilt the server and installed a fresh copy of WSUS 3 SP2 and installed KB273608. I configured this as a replica server and yet again it reached 99% and then failed with error:

  An error occurred with the server's data store. Details...

  SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
  at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
     at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
     at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
     at System.Data.SqlClient.SqlDataReader.ReadInternal(Boolean setTimeout)
     at System.Data.SqlClient.SqlDataReader.Read()
     at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ReadOneRow()
     at Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlUpdateIds)
     at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid[] hiddenUpdates)
     at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
     at Microsoft.UpdateServic

  I go to change the WSUS server to a NON replica server and the sync works as advertised. I have declined all superseded updates and ran the cleanup wizzard and that didnt make any difference. I guess I am back to square one.

  Here is a copy of the SoftwareDistribution log when configured as a replica server:

  2012-12-16 20:14:20.235 UTC Info WsusService.18 CatalogSyncAgentCore.ReplicaSync DeploymentSync: processing target groups
  2012-12-16 20:14:20.235 UTC Info WsusService.18 CatalogSyncAgentCore.ReplicaSync DeploymentSync: processing accepted EULAs
  2012-12-16 20:14:20.251 UTC Info WsusService.18 CatalogSyncAgentCore.ReplicaSync DeploymentSync: processing deleted deployments
  2012-12-16 20:14:20.251 UTC Info WsusService.18 CatalogSyncAgentCore.ReplicaSync DeploymentSync: processing new deployments
  2012-12-16 20:14:20.469 UTC Info WsusService.18 CatalogSyncAgentCore.ReplicaSync DeploymentSync: processing hidden updates
  2012-12-16 20:14:44.313 UTC Info w3wp.1 ServerImplementation.UpdateCache Database change occured; check if we need to update cache.
  2012-12-16 20:14:47.892 UTC Warning w3wp.7 SoapUtilities.CreateException ThrowException: actor = http://wsusserver:8530/ReportingWebService/ReportingWebService.asmx, ID=4de1a31c-ac8f-42c2-97f8-394a717ce1be, ErrorCode=ConfigChanged, Message=, Client=faf009ab-62e1-4de0-81cb-44724070c3c0
  2012-12-16 20:14:47.892 UTC Error w3wp.7 WebService.ReportEventBatch Exception occured in ReportEventBatch: Fault occurred
     at Microsoft.UpdateServices.Internal.Reporting.WebService.ReportEventBatch(Cookie cookie, DateTime clientTime, ReportingEvent[] eventBatch)
     at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
     at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
     at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
     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.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
     at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
     at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error)
     at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
     at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)
     at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)
     at System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr ecb, Int32 iWRType)
  2012-12-16 20:15:48.798 UTC Warning w3wp.10 SoapUtilities.CreateException ThrowException: actor = http://wsusserver:8530/ReportingWebService/ReportingWebService.asmx, ID=9ed63f64-6332-476b-952a-8009ff01530c, ErrorCode=ConfigChanged, Message=, Client=108338cc-9e1e-4e08-9039-48c5ea7af5fe
  2012-12-16 20:15:48.814 UTC Error w3wp.10 WebService.ReportEventBatch Exception occured in ReportEventBatch: Fault occurred
     at Microsoft.UpdateServices.Internal.Reporting.WebService.ReportEventBatch(Cookie cookie, DateTime clientTime, ReportingEvent[] eventBatch)
     at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
     at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
     at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
     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.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
     at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
     at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error)
     at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
     at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)
     at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)
     at System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr ecb, Int32 iWRType)
  2012-12-16 20:16:44.142 UTC Warning w3wp.1 SoapUtilities.CreateException ThrowException: actor = http://wsusserver:8530/ClientWebService/client.asmx, ID=a08f0aee-3b1d-4aef-a052-7c1821b194a1, ErrorCode=ConfigChanged, Message=, Client=0dfe68f4-4088-4a53-b57a-001fc06f8884
  2012-12-16 20:16:53.908 UTC Error WsusService.18 CatalogSyncAgentCore.ExecuteSyncProtocol System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
     at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
     at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
     at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
     at System.Data.SqlClient.SqlDataReader.ReadInternal(Boolean setTimeout)
     at System.Data.SqlClient.SqlDataReader.Read()
     at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ReadOneRow()
     at Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlUpdateIds)
     at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid[] hiddenUpdates)
     at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
     at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
     at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
     at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.CatalogSyncThreadProcess()
     at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
     at System.Threading.ExecutionContext.runTryCode(Object userData)
     at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
     at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
     at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
     at System.Threading.ThreadHelper.ThreadStart()
  2012-12-16 20:16:53.924 UTC Info WsusService.18 CatalogSyncAgentCore.UpdateSyncResultAndGenerateReportingEvent CatalogSyncThreadProcess: report subscription Local database other error
  2012-12-16 20:16:53.939 UTC Info WsusService.18 EventLogEventReporter.ReportEvent EventId=386,Type=Error,Category=Synchronization,Message=Synchronization failed. Reason: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding..
  2012-12-16 20:16:53.955 UTC Info WsusService.16 CatalogSyncAgent.WaitUntilSyncFinishedOrCancelled Agent signalled done.
  2012-12-16 20:16:53.955 UTC Info WsusService.16 CatalogSyncAgent.SetSubscriptionStateWithRetry Firing event SyncFailToStart...
  2012-12-16 20:16:53.970 UTC Info WsusService.16 CatalogSyncAgent.WakeUpWorkerThreadProc Found no more jobs. CatalogSyncAgent quits but will run rollup before terminating ...
  2012-12-16 20:16:53.986 UTC Info WsusService.16 CatalogSyncAgent.UpdateServerHealthStatusBasedOnError ServerHealth: Updating Server Health for Component: CatalogSyncAgent, Marking as Not Running
  2012-12-16 20:16:54.392 UTC Info WsusService.7 SusEventDispatcher.TriggerEvent TriggerEvent called for NotificationEventName: RollupAgent, EventInfo:
  2012-12-16 20:16:54.392 UTC Info WsusService.26 SusEventDispatcher.DispatchManagerWorkerThreadProc DispatchManager Worker Thread Processing NotificationEvent: RollupAgent
  2012-12-16 20:17:01.596 UTC Warning WsusService.23 DBConnection.OnReceivingInfoMessage  Null value is eliminated by an aggregate or other SET operation.

  Cheers and am thankful for any other advice. Unfort I have to sync with this server (which I have no control over). I have to work with what i have.

  Thanks in advance ;)

  • Reply
  • Quote

   
• Tuesday, December 18, 2012 11:34 PM

  Moderator

   

   
  

  0

  Well I took the advise and rebuilt the server and installed a fresh copy of WSUS 3 SP2 and installed KB273608. I configured this as a replica server and yet again it reached 99% and then failed with error:

  An error occurred with the server's data store. Details...

  SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
  

  [...]

  Cheers and am thankful for any other advice. Unfort I have to sync with this server (which I have no control over). I have to work with what i have.

  The core issue is still the state of the upstream server:

  • =31653= total updates;
  • =25136= unapproved updates (probably all drivers);
  • =2385= approved updates

  ---

  Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
  SolarWinds Head Geek
  Microsoft MVP - Software Distribution (2005-2012)
  My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
  The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

  • Reply
  • Quote

   
• Wednesday, December 19, 2012 12:08 AM

   

   
  

  0
  G'day Lawrence,

   

  Thanks for the feedback on the upstream server. I do appreciate any input at all at this stage. While I do not disagree with you there isn't much I can do about it. I am about to log a support case with Microsoft for assistance hoping they may be able to provide some help as well. The admins for the upstream server told me they had been having issues and ended up rebuilding this server the other night. I have tried again with a sync configured as a NON-Replica server. This is happening as I type and will not finish for some time (which doesn't really help me at the moment). I will report on the number of updates etc once it has finished. They assure me that this upstream server has around 80 downstream servers and out of those there are approx 60 configured as replica servers. Makes me think that I am the only one that is having this problem. In the back of my head I am thinking if us being a 'Trusting' domain from where the upstream server is may be causing these issues? In the mean time, I have a WSUSApprovalsExport.xml of the upstream server I can use to manually approve the updates. Until I can get this replica server working that's the best I can do for now.

   

  Cheers and will keep you all posted on my results.

   

  
  Thanks in advance.
  
  • Reply
  • Quote

   
• Wednesday, December 19, 2012 12:31 AM

  Moderator

   

   
  

  0

  there isn't much I can do about it.

  I fully understand that. I fully understood that a few messages back -- which is why I said that either [a] you shouldn't be installing a downstream server, or [b] the peeps who own the upstream server need to come and install their own downstream server.

  I am about to log a support case with Microsoft for assistance hoping they may be able to provide some help as well.

  You'll likely get one of two things from that effort:

  [a] Exactly the same answer "Fix the upstream server", or worse,

  [b] you'll spend days getting the run-around from Level 1 tech support people who don't have a clue because this issue isn't in their scripts.  :-)

  The admins for the upstream server told me they had been having issues and ended up rebuilding this server the other night.

  This is good news. We'll have to see if they've fixed their issues.

  I have tried again with a sync configured as a NON-Replica server.

  Possibly what you needed anyway, eh? :-)  (Not synchronizing the *approvals* will make a big difference in the results.)

  They assure me that this upstream server has around 80 downstream servers

  Well, there's a second problem... =80= is a LOT of downstream servers to service from a single upstream server. (Particularly on a server that's been hosting 30k+ updates!)

  Makes me think that I am the only one that is having this problem.

  Possibly true if you're the only one trying to do a *FULL* server synchronization of 30,000+ updates .... but then, if they really did rebuild an upstream server with =80= downstream servers, of which =60= are replicas... then I wouldn't be surprised to hear that those other replicas are about to experience their own kind of pain.

  In the back of my head I am thinking if us being a 'Trusting' domain from where the upstream server is may be causing these issues?

  Absolutely not. WSUS is a domain-agnostic service and all server-to-server synchronization activity is done anonymously. Domains and domain membership are irrelevant.

  ---

  Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
  SolarWinds Head Geek
  Microsoft MVP - Software Distribution (2005-2012)
  My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
  The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

  • Reply
  • Quote

   
• Wednesday, December 19, 2012 2:52 AM

   

   
  

  0

  G'day Lawrence,

  Thanks again for the feedback, I do appriciate your imput and knowlage in this area. I have access to the WSUSApprovals.xml and will apply this once the initial sync has completed. The size of this file is 9.81MB. The sync is at 75% and I will report when finished.

  Cheers

  • Reply
  • Quote

   
• Wednesday, December 19, 2012 3:58 AM

   

   
  

  0

  G'Day Again,

  Well the sync has finally finished with some really strange results.  I mean really strange. I attempted a sync configured as a NON-Replica server. This fininshed successfully (as it had done on many occasions). The first think that stands out is the size of the WsusContent directory. This only totalls 30.2 MB (31,670,272 bytes) and contains 635 files and 240 folders. Not looking great so far. Anyhow, I then examine the sync sumary.

  Synchronization Details:

  Started: 19/12/2012 11:12 AM
  Finished: 19/12/2012 2:41 PM
  Result:  Succeeded
  Type:  Manual
  Errors:  0
  New Updates: 29041
  Revised Updates:0
  Expired Updates:1422

  If I then examine the Updates/All Updates, with Approval of Approved and Status of Any: 8 updates of 30436 shown, 30436 total

  Something is really wrong somewhere. Oh well time to attack it again in the morning :)

  Cheers

  • Reply
  • Quote

   
• Wednesday, December 19, 2012 2:10 PM

  Moderator

   

   
  

  0

  The first think that stands out is the size of the WsusContent directory. This only totalls 30.2 MB (31,670,272 bytes) and contains 635 files and 240 folders.

  Those numbers are Absolutely Normal! for an autonomous downstream server immediately after the initial synchronization.

  If I then examine the Updates/All Updates, with Approval of Approved and Status of Any: 8 updates of 30436 shown, 30436 total

  Unfortunately, until the DRIVERS Update Classification is turned off on the Upstream Server -- this problem is not going to be resolvable.

  Something is really wrong somewhere.

  Why do you think this? You said you configured this server as a NON-replica server. Are you aware of the fundamental difference between a REPLICA server and a NON-replica (AUTONOMOUS) server?

  ---

  Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
  SolarWinds Head Geek
  Microsoft MVP - Software Distribution (2005-2012)
  My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
  The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

  • Reply
  • Quote

   
• Wednesday, December 19, 2012 7:45 PM

   

   
  

  0

  G'day Lawrence,

  Thanks again for your reply. Ok maybe I am not seeing something here. My understanding if a REPLICA server is a server that will hold bacially a 'replica' of all the updates and approvals of an upstream server. In addition, my understanding of a AUTONOMOUS server is a server that has a copy/replica of all the updates that has been approved. Knowing that none has been approved yet on this downstream server makes me now understand why the directory is the size it is. What I do not understand is where these 8 approved updates came from? The 8 approved updates are:

  Microsoft Windows Installer 3.1
  Update for Background INtelligent Transfer System (BITS) 2.0 and WinHTTP 5.1 (KB842773)
  Update for Background INtelligent Transfer System (BITS) 2.0 and WinHTTP 5.1 (KB842773)
  Update for Background INtelligent Transfer System (BITS) 2.0 and WinHTTP 5.1 (KB842773)
  Update for Windows Server 2003 (KB938759)
  Update for Windows Server 2003 for Itanium-based Systems (KB938759)
  Update for Windows Server 2003 x64 Edition (KB938759)
  Wupdate for Windows XP (KB898461)

  EDIT: I now know where these approvals came from. I had selected Automatically approve WSUS updates... Doh!!! ;) Sorry :)

  I expect once I import the approvals the approved updates will be downloaded from the upstream server? I hope I have my understanding correct (The selection to 'Download update files to this server only when updates are approved' is selected).

  Looking at the Products and Classifications, All I see selected is 'Critical Updates' Definition Updates', and 'Security Updates'. And the only language selected is English.

  Cheers & thanks again in advance.

  
  

  • Edited by Homith Wednesday, December 19, 2012 8:59 PM
  •  
  • Reply
  • Quote

   
• Thursday, December 20, 2012 12:14 AM

   

   
  

  0

  G'day Again :)

  Well, some progress I guess. This is what I have done so far.

  I Installed a fresh copy of WSUS 3.0 SP2 (with WSUS30-KB9742455-x86.exe)

  I then sync'd the server a an Autonomous server. Ensuring I would only download approved updates which were none at this stoage.

  I then declined any superceeded updates.

  Executted the WSUS cleanup wizzard.

  I then imported the WSUS_Approvals.xml Approvals None.

  Then ran the wizzard again.

  Now I have the following statistics:

  Server Statistics
  Unapproved updates: 25036
  Approved updates: 1629
  Declined Updates: 3792
  Computers: 81
  Computer groups: 1

  The size of the WSUSContent directory is now 4.29GB

  • Reply
  • Quote

   
• Friday, December 28, 2012 1:30 AM

  Moderator

   

   
  

  0

  My understanding if a REPLICA server is a server that will hold bacially a 'replica' of all the updates and approvals of an upstream server.

  Correct, the key words being those that are boldfaced. On a NON-replica server, you're not synchronizing Approval State. On a replica server, you are. It's the attempt to replicate 4132 DECLINES and 2385 APPROVALS (times howEverMany GROUPS those approvals are applied to) that is causing the problem.

  In addition, my understanding of a AUTONOMOUS server is a server that has a copy/replica of all the updates that has been approved.

  No. And that does explain a bit. An Autonomous Server has a replica of *ALL* updates synchronized to the upstream server (and the console view filtered by the products and update classifications selected for synchronization), it just doesn't have any information about the approvals for those updates.

  What I do not understand is where these 8 approved updates came from?

  These are the eight MANDATORY updates (i.e. "WSUS Updates" -- a poorly chosen moniker, if you ask me) -- the ones that MUST be applied to a system before any other updates, and before WSUS will work. They're all dated prior to 2006 (IIRC), so the impact from a realistic perspective is NIL. Every one of those updates was superseded by XP SP3, Win2003SP2, and Win2008/Vista.

  EDIT: I now know where these approvals came from. I had selected Automatically approve WSUS updates... Doh!!! ;) Sorry :)

  You did not 'select' that option. It's ON by default, and should be left ON. (Presuming that we ever have a Mandatory update again. I'm still trying to grasp why KB2720211 wasn't a Mandatory Update -- although, in hindsight, the ugliness would have been Seven Shades of Hell greater if it had been.)

  I expect once I import the approvals the approved updates will be downloaded from the upstream server?

  One can hope. :-)

  Looking at the Products and Classifications, All I see selected is 'Critical Updates' Definition Updates', and 'Security Updates'.

  That could be problematic. Does it match the Update Classifications selected on the Upstream Server? If not, then your Approval import may probably crap all over the updates it cannot find. Also... what's your plan for Service Packs, Updates, Update Rollups, and Feature Packs?

  ---

  Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
  SolarWinds Head Geek
  Microsoft MVP - Software Distribution (2005-2012)
  My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
  The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

  • Reply
  • Quote

   
• Friday, December 28, 2012 1:37 AM

  Moderator

   

   
  

  0

  Now I have the following statistics:

  Server Statistics
  Unapproved updates: 25036
  Approved updates: 1629
  Declined Updates: 3792
  Computers: 81
  Computer groups: 1

  The size of the WSUSContent directory is now 4.29GB

  Glad it worked. Definitely healther than it's upstream big-brother.

  However, I would argue that the 1629 approved updates is probably four times what it should be (such is the bane of using a provided list rather than choosing your own). I rarely have more than 500 approved updates on my own WSUS server. (And if I do, it's because I've not been doing required approval maintenance.)

  So, is it your plan to leave this as an autonomous server going forward? ... in which case I'd ask why you ever replicated it in the first place, rather than just installing it as an upstream server and synchronizing from Microsoft.

  And, if you're going to convert it to a replica (now), be aware that it's going to mess it up seven ways to Sunday as a result because you don't have a 'replica' of the upstream server, and trying to make it a 'replica' now could be an entirely new headache unto itself.

  ---

  Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
  SolarWinds Head Geek
  Microsoft MVP - Software Distribution (2005-2012)
  My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
  The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

  • Reply
  • Quote

   
• Wednesday, January 02, 2013 9:45 PM

   

   
  

  0

  G'day Lawrence,

  Thanks for your replies and valuable input on this. I am now back at work and ready to continue with this server. This server is actually a part of a network that is not connected to the internet. The updates are exported from a server connected to the Microsoft update server, checked and cleared for use and then imported into this upstream server that I am attempting to sync as a replica server with. It is on this server that the internal approvals are made. They also create an approval export. The reason I am trying to sync with this server and not Microsofts is our servers do not have access to the internet as well. The approvals on this server hve been authorised for use within the enviroment. The upstream server is actually in another state.

  As you mentioned in your previous post, converting it to a replic server ('again') did not go well. Time to start again.

  Cheers

  John

  • Reply
  • Quote

   
• Tuesday, January 08, 2013 1:02 AM

   

   
  

  0

  G'day,

  This is actually proving more of a problem then its worth. As the older WSUS2 servers are still in production I may just go and rebuild at WSUS 2 and replicate from them. The only problem I will have is the clients which I have while will register with the older WSUS server will not report as they have an updated client which will not work with the older WSUS server. I may have to find out how to roll back each client version (If that can be done).

  Cheers

  • Reply
  • Quote

   
• Saturday, January 12, 2013 12:06 AM

  Moderator

   

   
  

  0

  G'day,

  This is actually proving more of a problem then its worth. As the older WSUS2 servers are still in production I may just go and rebuild at WSUS 2 and replicate from them. The only problem I will have is the clients which I have while will register with the older WSUS server will not report as they have an updated client which will not work with the older WSUS server. I may have to find out how to roll back each client version (If that can be done).

  The clients that have already registered with your WSUS v3 (presumably PLUS KB2720211) server, likely have an updated Windows Update Agent (v7.6). That WUAgent is incapable of communication with a WSUS v2 server (not to mention the fact that a WSUS v2 server also cannot patch Windows 7, Windows 8, Windows Server 2008 R2, or Windows Server 2012) systems.

  There is no supported methodology for downgrading a Windows Update Agent (except reinstalling the operating system), although there are some 'hacks' described in blog posts and forums.

  Ultimately the people you're trying to get your updates from are going to have to fix their server for you to have a functional WSUS-based patch management environment, given the restrictions you've identified.

  Or else you'll have to figure out a way to implement your own 'connected' server.

  ---

  Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
  SolarWinds Head Geek
  Microsoft MVP - Software Distribution (2005-2012)
  My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
  The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

  • Reply
  • Quote

   
• Sunday, January 13, 2013 8:08 PM

   

   
  

  1

  Good Morning,

  Welll some interesting developments over the weekend. The organisation responsible for the upstream WSUS server has finally admitted that the WSUS installation they maintain isnt very stable. After providing them with sections of this thread and alot of supporting log files they have this week contracted Microsoft to come in and work with them to get this fully functional. I guess I will watching this space and see what happens.

  Cheers Lawernece and once again thanks for your input.

  
  

  • Edited by Homith Sunday, January 13, 2013 8:09 PM
  •  
  • Reply
  • Quote