Common WSUS 2012 Troubleshooting Tasks

Review this article for information related to various timing issues within WSUS infrastructure.

Missing Servers In WSUS

Log on to the server that is missing from WSUS console

Run rsop.msc from the command line

Inspect group policy objects in effect and confirm that WSUS GPO is delivered successfully

If you don’t see the GPO object as being delivered:

repadmin /sync on domain controllers or just wait for WSUS GPO to replicate to all domain controllers

gpupdate /force on the missing server

Confirm that missing server’s computer object is not disabled in AD

If GPO object is delivered successfully, make sure that Windows Update service hasn’t been disabled administratively. It is a good idea to configure this service to start up Automatically (Delayed Start) using the same WSUS GPO that delivers other settings.

Finally, wuauclt /detectnow on the missing server to trigger WSUS call. Note that this call will be delayed by a random offset and will take some time before you will see it in WSUS.

WSUS Replica Server Failing to Synchronize with Master

Depending on which products and languages you select to download from Microsoft, your metadata can grow past 20,000-30,000 updates quickly. At some point you may see that your replica server stopped synchronizing with the master, for no reason. It would sync successfully at 9 AM and start failing from 10 AM onwards on the same day, without any changes or additional patch downloads from Microsoft. Sync would go to 90% or 95% pretty quickly, then hang for 7-12 minutes or so, and error out.

You may get slightly different error messages but they boil down to SQL database timing out (this affects WSUS servers running on Windows internal database, which is essentially a SQL Server Express instance).

SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e)
at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader()
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)

Several people posted solutions to this issue, so you can find them by Googling around. What worked for me was Madan Mohan’s blog post here. The steps I took were:

On the replica server(s), run WSUS Server Cleanup Wizard (from the WSUS console; leave all checkboxes checked in default configuration). If you have multiple replicas, start from the deepest replica in the structure and work your way up

After step #3 is complete, run the same on the master server

Run synchronization between master and replica – it should complete successfully

It is recommended that index defrag script (step 2 above) is scheduled to run once a month on all WSUS servers, but running it without Cleanup wizard may not solve the sync timeout error.

Servers Do Not Detect WSUS-Approved Patches

This may be easy to troubleshoot: allow plenty of time to pass before you approve WSUS patches on the master WSUS server. WSUS needs time to trickle approvals down to replica servers, especially if they are nested more than one level deep. Once approvals are replicated, two more things need to happen: 1) patches need to be downloaded from Microsoft and replicated internally, and 2) servers need to call in to check for updates (this is subject to GPO settings).

To speed up this process, you could trigger a few sync runs on the master and replica servers, as well as use wuauclt /detectnow command on the servers (or simply click on the check updates link in Windows Update applet), but keep in mind that even then the detection chain may not work instantly. If I need to patch my server in a hurry, I resort to checking for updates directly from Microsoft.

Servers Appear in WSUS But Do Not Report Patch Status

In many cases this boils down to a delay within WSUS infrastructure; most likely the server just started calling into WSUS and hasn’t managed to report status yet. To troubleshoot this quickly, run wuauclt /reportnow command on the server that does not report its status, then sync WSUS replica/master servers to roll up the newly reported information into the master server. Note that there is a random delay between running /reportnow command and the actual call into WSUS, so wait for appropriate WSUS server to receive the first status update and only then run the sync.

If you still have Windows 2000 on the network (some people do…) you may need to apply the latest service pack manually to make sure that group policy client and Windows Update services are brought up to a supported/functional state.

WSUS Reports Missing Patches Not Detected by Servers

Under certain circumstances, your fully patched server will continue to show up in WSUS with an exclamation mark, notifying administrator of a missing patch. You would run Windows Update applet on the server (and even check for updates using Microsoft server) only to find out that the server is fully patched – green and happy Windows Update.

When this stubbornness arises, run a WSUS report of missing patches for the server in question. Chances are, you will find one or more patches that are completely optional, to a point of not being detected as applicable/needed even natively by Windows Update service running on the server.

If something like this happens, evaluate each offending patch individually and decline it/them on the master WSUS server (or install locally on the servers where it is indeed needed). Don’t forget to sync your WSUS replicas with master after declining the patch – you should see the exclamation marks disappear from the WSUS console right after declining the offending patches.

Another thing to try here is to double-check that all applicable patches have been approved for installation in WSUS. If there is a patch that does apply to a system but hasn’t been approved yet, WSUS will flag affected computers as having missing patches, but those computers won’t detect them.

WSUS Cleanup Wizard Affects Computer Status

I noticed that in a rare case, running Cleanup Wizard (which you need to do regularly as part of WSUS maintenance) may result in a new revision of a previously approved patch to appear in WSUS console, or change status of a previously approved patch to unapproved. This in turn causes WSUS to flag computer objects as needing updates. If you run into this, re-approve the patch, synchronize your WSUS topology, and deploy the patch to the affected servers.

Re-install Some Patches Manually

In the case of KB 2656368, “Security Update for Microsoft .NET Framework 4”, this patch would install fine through WSUS, but after running WSUS Server Cleanup wizard my server was flagged by WSUS as needing 2656368 again. Running Windows Update check manually on the server in question would not detect any missing patches, either from WSUS or directly from Microsoft. If you run into this type of problem you may just need to reinstall the patch in question manually (or through some other automation outside of WSUS), otherwise WSUS report will continue to list the server with an exclamation mark.

No Responses to "Common WSUS 2012 Troubleshooting Tasks"

[…] noticing occasional sync failures (timeouts). You start troubleshooting them and run through the WSUS Cleanup Wizard and database index defragmentation tasks outlined here, and initially that seems to […]