WSUS sync fix only for new installs, old servers still stuck

Since roughly July 13, Windows Server Update Services on Windows Server 2012 and later has been unable to complete upstream syncs on the normal schedule — some runs finishing in many multiples of the usual window, others timing out outright — with the effect that any admin pushing this month’s Windows cumulative to Windows 10 1607+ clients through WSUS or Configuration Manager has been unable to close the loop. Microsoft confirmed the issue on the Windows Health Dashboard and BleepingComputer reported the current fix state on July 20. Microsoft’s own phrasing on the dashboard is that sync “has been restored and is operating normally for new WSUS installations and rebuilds” — and, for previously-affected servers, that the company is “working on mitigation steps to help customers safely remove the affected metadata from their environments.”

That is a floor, not a lift. The mitigation Microsoft shipped Saturday, July 18, addresses the ingest path: a fresh WSUS server pulling from Microsoft Update today syncs in normal time. A server that already pulled the metadata Microsoft is now trying to unwind stays broken until the cleanup step ships. That framing also rules out a pure upstream fault — if the problem were only on Microsoft’s side, restarting the affected syncs would restore everyone at once. There is a persistent local artifact on affected downstream servers, and until Microsoft publishes the tooling to remove it safely, those servers do not recover on their own.

What this means if you run WSUS

If your syncs have been slow or timing out since around the middle of last week. You are the audience Microsoft is still working on. There is no supported cleanup path in place yet — Windows Release Health is where the follow-up will land, keyed to the WSUS sync-delay entry. Do not delete SUSDB, do not uninstall and reinstall the WSUS role, and do not blow the content directory away as a shortcut. The fix Microsoft is preparing is expected to reach into the specific metadata that broke the pipeline; a full rebuild loses the entire approval history on that server and every replica downstream of it.

If you’re running Configuration Manager on top of WSUS. The software-update point rides the same pipeline. A downstream WSUS that can’t sync is a Configuration Manager site that can’t offer this month’s cumulative to any client that depends on it. The “we can’t patch anything this week” tickets landing in enterprise environments right now mostly trace back through this one incident, not through a separate ConfigMgr fault.

If your last successful sync was before July 13 and you haven’t tried since. Test in isolation before pushing. A server that ingests the affected metadata now will land in the same broken state as one that ingested it a week ago. Microsoft’s phrasing about “new installations and rebuilds” implies the mitigation prevents the reingest, but until a cleanup path exists for the servers already stuck, treat that as narrow.

Why WSUS keeps landing in this position

WSUS has been Microsoft’s on-premises patch-distribution service since Windows Server 2003, and the metadata-sync codepath is essentially the same one that shipped with it. Microsoft’s announced direction — the WSUS deprecation notice went out in September 2024 — is to move customers off WSUS entirely and onto cloud-managed patching. The migration story is real for organizations whose clients always have a path to the internet — Autopatch, Intune, Windows Update for Business. It is not real, or at least not finished, for organizations with clients that don’t: branch offices behind slow links, air-gapped enterprises, OT environments running Windows update targets, and every environment where a bandwidth-shared WSUS is the reason the branch site can even patch monthly. That is why an incident in a “legacy” service takes down current-month patch cadence, and why the fixes ship in the sequence they do — new installs first, then previously-affected servers on a lag — instead of both at once.

One specific thing to do this week

If a WSUS server has been failing to sync since around July 13, leave it in place and watch the Windows Health Dashboard entry for the mitigation Microsoft is preparing. Do not attempt a SUSDB rebuild or a WSUS-role reinstall as a workaround — the supported cleanup is expected to preserve approval state, and a manual rebuild throws that away. If patch deployment for a specific set of clients cannot wait for that cleanup, temporarily point those clients at Windows Update directly or roll them onto Intune / Autopatch for the July cumulative — including this month’s AD FS, SharePoint, and BitLocker zero-days — then move them back to WSUS once your server is on the far side of the mitigation.