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, install Command Line Tools and Native SQL Client from SQL Server 2008 R2 SP2 Feature Pack
- On the replica server, reindex WSUS database using T-SQL script posted in this Microsoft article
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.
One example is KB 972493, “Windows Server Update Services 3.0 SP2 Dynamic Installer for Server Manager”. The fact that you have a Windows Server 2008 box running Server Manager tricks WSUS into thinking that this update applies, however, the server running Windows Update check does not think so. Unless you plan to deploy an additional WSUS service on this particular server in the future, there is no need to worry about this update.
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.
Interestingly, in the case of KB 974470, “Microsoft .NET Framework 2.0 Service Pack 2 Security Update”, my servers would not detect this update as needed when Windows Update was run directly against Microsoft update service, but as soon as I re-approved this patch for installation through WSUS, my servers would pick it up from WSUS and offer to install it.
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.
WSUS installation folder, typically C:\Program Files\Update Services\Tools, has this tool called wsusutil.
Windows Server Update Services administration utility. Try: wsusutil.exe help checkhealth wsusutil.exe help configuressl wsusutil.exe help configuresslproxy wsusutil.exe help deletefrontendserver wsusutil.exe help listinactiveapprovals wsusutil.exe help removeinactiveapprovals wsusutil.exe help export wsusutil.exe help healthmonitoring wsusutil.exe help import wsusutil.exe help listfrontendservers wsusutil.exe help movecontent wsusutil.exe help reset wsusutil.exe help usecustomwebsite wsusutil.exe help listunreferencedpackagefolders
If you feel like running consistency checks against metadata stored in the WSUS database and cross reference updates stored on the file system, wsusutil.exe reset command does that.