I’ve installed WSUS on my Central Site and configured SUP to sync with Microsoft Update. All of the updates are coming down fine. Next I’ve installed WSUS on a Child Primary Site and configured the SUP.

However, no updates seems to be coming down from the Central Site (the “wsyncmgr.log” just sits there saying “Waiting xx minutes for requests…” and was last updated days ago).

You need a subscription to access the answer.

This content is restricted to subscribers

ANSWER:

Opening the “WCM.log” on the Child Primary showed the following lines indicating there was an issue with the SUP and WSUS communicating:

This <server_name> system is the Top Site where WSUS Server is configured to Sync from Microsoft Update (WU/MU) OR do not Sync.
Waiting for changes for 1 minutes
Wait timed out after 0 minutes while waiting for at least one trigger event.
Timed out…
Active Software Update Point is not selected. WCM will not change any configuration.

Removing and re-installing the SUP didn’t work. Checking in WSUS the updates were being synchronised between the Central and Primary Site (open “Synchronizations” in the WSUS Console to view the synchronisation history).

Removing the SUP/WSUS and re-installing them didn’t make any difference.

I noticed that although the last entries from the WSUS-related log files were from 6 days ago the date/time stamps were updating on a regular basis. In the end I ended up renaming the existing files to “*.OLD“. ConfigMgr re-created them and opening them the sync was actually running:

WCM.log:

This  <server_name> system will Sync from the parent site's WSUS Server as it is not the Top Site.

Followed by:

Verify Upstream Server settings on the Active WSUS Server
WSUS Server settings are correctly configured and Upstream Server is to to <fqdn_of_central_site>
Subscription should only be done at the Top Site
Configuration successful. Will wait 1 minute for any subscription changes
Received site attachment <site_code>.SHA
Deleted site attachment <drive>:\<path>\inboxes\WSUSMgr.box\<site_code>.SHA

 

Then looking in the “wsyncmgr.log” at around the time the SUP was configured it showed:

Requesting local sync due to a change in main WSUS server location
Performing sync on local request
….
Synchronizing WSUS server <this_server's_name>
Synchronizing WSUS server <this_srver's_fqdn>
sync: Starting WSUS synchronization
sync: WSUS synchronising categories, processed 0 out of 1000 items (0%)
sync: WSUS synchronising categories, processed 1000 out of 1000 items (100%)
sync: WSUS synchronising updates, processed x out of y items (0%)
….
sync: WSUS synchronising updates, processed y out of y items (100%)
Successfully synced site with parent <parent_site_code>, version <number>

I can only surmise that somehow the WSUS-related ConfigMgr log files became corrupt and forcing ConfigMgr to create new one’s resolved the issue.

As a FYI, the following Status Messages for the “SMS_WSUS_SYNC_MANAGER” Component will also be generated if the sync is working:

  • 6701 SMS WSUS Synchronization started
  • 6704 SMS WSUS Synchronization in progress. Current phase: Synchronizing WSUS Server
  • 6702 SMS WSUS Synchronization done.

If you see a 6703 then there is a sync issue and the Status Message will give you clues as to what the issue is.

Login to leave your feedback!

Leave a Reply