When software update synchronization fails in Configuration Manager (the product many admins still call SCCM), new updates never reach the console, automatic deployment rules have nothing to deploy and child sites fall behind. The cause is nearly always written in two site server logs, wsyncmgr.log and WCM.log. In this post I'll show how to read them, fix each common failure and prove the fix.
Errors this guide fixes
Sync failed: WSUS server not configured. Please refer to WCM.log for configuration error details.. Source: CWSyncMgr::DoSyncwsyncmgr.logSync failed. Will retry in 60 minuteswsyncmgr.logSystem.Net.WebException: The request failed with HTTP status 502WCM.logSystem.Net.WebException: The request failed with HTTP status 407WCM.logSystem.Net.WebException: The request failed with HTTP status 503WCM.logNo connection could be made because the target machine actively refused itWCM.log0x80072EFE - The connection with the server was terminated abnormallyWSUS sync with Microsoft Update
Symptoms#
- Monitoring › Software Update Point Synchronization Status shows a failed or stale synchronization for one or more software update points (SUPs).
- Patch Tuesday updates don't appear under Software Library › Software Updates › All Software Updates.
wsyncmgr.login<ConfigMgr install path>\Logson the site server ends each attempt like this:
Sync failed: WSUS server not configured. Please refer to WCM.log for configuration error details.. Source: CWSyncMgr::DoSync
Sync failed. Will retry in 60 minutesWCM.logshows the underlying problem:
System.Net.WebException: The request failed with HTTP status 502
System.Net.WebException: The request failed with HTTP status 407
System.Net.WebException: The request failed with HTTP status 503
No connection could be made because the target machine actively refused it- At the top-level site, WSUS can't sync with Microsoft Update:
0x80072EFE - The connection with the server was terminated abnormallyor a connection timeout.
Why it happens#
Synchronization is a chain. The SUP at the top-level site (a central administration site or a standalone primary) pulls update metadata from Microsoft Update or an upstream WSUS server, the site imports it into the site database, then child sites get a synchronization request and their SUPs sync from their upstream SUP. Each link has its own component and log:
| Component | Runs on | Log | Job |
|---|---|---|---|
| WSUS Configuration Manager (WCM) | Site server | WCM.log | Applies the console settings (upstream source, proxy, products, classifications, languages) to WSUS once an hour |
| WSUS Synchronization Manager | Site server | wsyncmgr.log | Starts each sync and imports the metadata into the site database |
| WSUS Control Manager | SUP | WSUSCtrl.log | Checks that the WSUS components are healthy |
| WSUS | SUP | SoftwareDistribution.log | Downloads metadata and license terms from its upstream source |
If WCM can't configure WSUS, every sync stops with WSUS server not configured. Usual reasons: the site server can't reach the WSUS API on the SUP (name, port, SSL or firewall), a proxy is in the way, the connecting account lacks rights, or the WSUS service or its WsusPool application pool is down. At the top-level site, blocked access to Microsoft Update breaks the very first link.
How to fix it#
1. Find the first failing link#
Start in Monitoring › Software Update Point Synchronization Status. If only a child site fails, check its link to the parent SUP; if the top-level site fails, start there. Read the newest Sync failed line in that site server's wsyncmgr.log; when it points to WCM.log, search that for WebException. For history, use Monitoring › System Status › Component Status and show the messages for SMS_WSUS_SYNC_MANAGER and SMS_WSUS_CONFIGURATION_MANAGER.
2. Match the WCM.log error to a cause#
| Error in WCM.log | Usual cause | What to check |
|---|---|---|
| HTTP status 401 or 403 | The connecting account is refused | The WSUS Server Connection Account (if set) and ApiRemoting30 permissions |
| HTTP status 407 or 502 | A proxy is in the path or needs authentication | Proxy settings on the site system and SUP role; bypass the proxy for site server to SUP traffic |
| Target machine actively refused it | WSUS service or website stopped, or the wrong port | Step 3, then the port in the SUP properties |
| HTTP status 500 or 503 | The WSUS web service is failing, often WsusPool stopped or recycling | Step 3 |
| Remote party closed the transport stream | TLS handshake failure | Steps 4 and 5 (SSL setup, certificate, proxy) |
3. Make sure WSUS is up on the SUP#
Get-Service WsusService
Import-Module WebAdministration
Get-WebAppPoolState -Name WsusPool
Get-Website -Name 'WSUS Administration' | Select-Object Name, State # or 'Default Web Site'
& "$env:ProgramFiles\Update Services\Tools\wsusutil.exe" checkhealthcheckhealth reports to the Application event log; read it there, along with WSUSCtrl.log on the SUP. Start a stopped pool with Start-WebAppPool -Name WsusPool. If it keeps stopping or answering 503 under load, raise its queue length and memory limits as described in Software update point and WSUS maintenance.
4. Check the path from the site server to a remote SUP#
- The site server needs the WSUS administration console, which provides the APIs Configuration Manager uses. Test with it: Update Services › Connect to Server, using the SUP's FQDN and port.
- The ports in the SUP properties must match the WSUS website bindings (8530/8531 when WSUS has its own website, 80/443 on the Default Web Site).
- For HTTPS, the WSUS website certificate must match the SUP's FQDN and be in date, and WSUS must be configured for SSL.
- The computer and administrator accounts need access to the
ApiRemoting30virtual directory: IIS Manager › Sites › WSUS website › ApiRemoting30 › Edit Permissions.
Test-NetConnection sup01.contoso.com -Port 85305. Fix proxy and Microsoft Update access at the top-level site#
A 407, 502 or 0x80072EFE at the top-level SUP points at the internet path. Under Administration › Site Configuration › Servers and Site System Roles, check the proxy server defined on the site system and that the software update point role is set to use it for synchronization. Then confirm the firewall lets the SUP reach Microsoft Update. In the WSUS console (Options › Update Source and Proxy Server), the top-level SUP should sync from Microsoft Update or your upstream WSUS server, and neither it nor a primary site's first SUP may be a replica. Make changes in the Configuration Manager console: WCM reapplies its settings every hour.
6. Deal with license terms and timeouts#
Sync also fails when license terms (EULA files) can't download. Search SoftwareDistribution.log (in %ProgramFiles%\Update Services\LogFiles) for .txt, fix the firewall or proxy, then have WSUS fetch the missing files again:
"%ProgramFiles%\Update Services\Tools\wsusutil.exe" resetSyncs that run for hours or time out often mean a bloated, fragmented SUSDB. Decline superseded updates, remove obsolete ones and reindex SUSDB.
Verify the fix#
- Start a sync at the top-level site: Software Library › Software Updates › All Software Updates › Synchronize Software Updates.
- Watch
wsyncmgr.log: the run completes without a Sync failed line, andWCM.loglogs no newWebException. - In Monitoring › Software Update Point Synchronization Status, every SUP shows a completed sync with a current time, and child sites report the same catalog version as the top-level site.
- The latest updates appear in All Software Updates, and clients scan cleanly (see updates not installing: WUAHandler.log and UpdatesDeployment.log).
Prevent it next time#
- Change SUP settings only in the Configuration Manager console; WCM overwrites manual WSUS changes.
- Schedule WSUS maintenance, track WSUS certificate expiry and keep a proxy bypass for internal SUP traffic.
- Check the synchronization status node after each Patch Tuesday sync, before your automatic deployment rules run.
- Component status message IDs are listed in the site component status messages quick reference, and client scan codes in the software update error codes quick reference.

