Support Tip: Avoiding sync problems when WSUS computers share SUSDB
Hi everyone, my name is Bindusar Kushwaha and I’m a Support Escalation Engineer on the Configuration Manager team. I ran into an interesting case the other day so I thought I’d take a minute to share it with you in case you happen to see it in your environment.
The Problem
Let’s say you’re running multiple WSUS computers, maybe integrated with Configuration Manager Software Update Points (SUPs), maybe not, and they share the same SUSDB as the master front end server, which is the only server allowed to go online and sync. Everything works fine for a while, then all of the sudden you find that your security compliance is changed and the sync with Microsoft Update is NOT working. You receive the following timeout error when trying to contact the update server:
WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 134.170.53.30:443
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetAuthConfig()
at Microsoft.UpdateServices.ServerSync.ServerSyncLib.InternetGetServerAuthConfig(ServerSyncProxy proxy, WebServiceCommunicationHelper webServiceHelper)
at Microsoft.UpdateServices.ServerSync.ServerSyncLib.Authenticate(AuthorizationManager authorizationManager, Boolean checkExpiration, ServerSyncProxy proxy, Cookie cookie, WebServiceCommunicationHelper webServiceHelper)
at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.SyncConfigUpdatesFromUSS()
at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
Note that you are able to go to manually connect to the IP address listed in the error just fine using the System context.
Why This Happens
As per the blog post below, the first installed WSUS computer should go online and sync, and the rest should accept the changes since they use the same SUSDB:
Normally that all works fine. Now as you may know, the first WSUS computer installed gets ownership of SUSDB (called MasterFrontEndServer), and when a sync is triggered, the computer with ownership of SUSDB must be allowed to go online to sync. However, let’s say that the MasterFrontEndComputer that has ownership of SUSDB is turned off, or that the WSUS service is stopped. When this happens, spUpdateServerHealthStatus checks the next WSUS computer with componentName=WSUSService and isRunning=1 and fires a stored procedure to update this computer as the new owner of SUSDB (New MasterFrontEndServer) in the tbReference table. This is as expected, however if this new MasterFrontEndServer is not allowed to go online then you will get the error mentioned above. This happens even after the previous owner comes back online because it’s no longer listed as the owner of SUSDB or MasterFrontEndServer.
The Solution
In order to keep this from happening you have a couple options:
Option 1: Do not share the SUSDB used by the MasterFrontEndServer with any other WSUS computers. Let all WSUS computers that are sharing the same SUSDB sync with another local server instead.
Option 2: If you do share a master front end server's SUSDB, allow all WSUS computers that share that SUSDB to go online and sync so that a change of MasterFrontEndServer should not impact connectivity.
If you are unable to implement option 1 or 2 above you can complete the following steps to get things working again:
1. Stop the WSUS service on all other WSUS computers that don't have Internet access and that share the same SUSDB.
2. Trigger a WSUS sync on the computer you want to be the SUSDB owner\MasterFrontEndServer.
3. Once the sync starts, start the WSUS service on all other WSUS computers sharing same SUSDB.
That should get things straightened out for the moment, but if you choose not to change your configuration, be sure to always keep an eye on things and make sure the MasterFrontEndServer’s WSUS service is not stopped during a scheduled sync time.
Note: If WSUS is integrated with Configuration Manager, this setting can be pushed by ConfigMgr as well. This setting is configured in Site Control File. We recommend that customers open a support case with Microsoft product support before making any changes to the database.
Hopefully this will help you avoid this potential issue in your environment.
Bindusar Kushwaha | Support Escalation Engineer