Microsoft ships manual WSUS fix: SUSDB cleanup, IISReset

The cleanup step Loop said was pending on Sunday shipped today. Microsoft has published the manual procedure for unsticking Windows Server Update Services on the servers that were already broken — the ones a fresh install couldn’t fix because the bad publishing metadata was already sitting in their SUSDB. Windows Server 2012 and later on the server side, Windows 10 1607 and later on the client side that scans against them. If you deferred running a full sync last week hoping this would land before your next patch window, it did.

This is one of the pieces I flagged on Sunday. Microsoft has now confirmed the root cause on the Windows Release Health Dashboard: a buildup of publishing metadata in the WSUS database that inflates sync time until it either finishes in some absurd multiple of the normal window or times out outright. The manual procedure is a database intervention, not a hotfix. It ships as documentation, not a KB.

What you actually run

The published sequence, in order, against every SUSDB in your topology — that means the upstream server and every downstream replica, plus any DR/warm-standby WSUS box sharing the same database schema. Half-covering the fleet does not work; a replica pulling from a cleaned upstream will re-ingest the same broken metadata from a peer that wasn’t touched.

1. Back up every SUSDB. Full SQL backup, verified, before you touch anything. If you run WSUS on Windows Internal Database instead of full SQL, connect via the named-pipe path (\\.\pipe\Microsoft##WID\tsql\query) from sqlcmd or SSMS with the WSUS service account; a normal localhost connection won’t see WID. Every SUSDB. Every replica. This is the step that lets you undo the next three.
2. Run the Microsoft cleanup query from SSMS against each SUSDB. The query is the intervention — it removes the specific accumulated publishing metadata Microsoft has now identified as the cause. Do not improvise a cleanup of your own; the published query is what MSRC has tested against.
3. Reset the MaxXMLPerRequest registry value to its default. If a prior tuning guide or an admin under pressure last week bumped this up trying to force syncs to finish, put it back. The default is what the cleanup and the reindex expect.
4. Reindex SUSDB. Standard SQL reindex; the cleanup query leaves the tables fragmented and skipping this step is why some early adopters reported the first post-cleanup sync still ran long.
5. Run the WSUS Server Cleanup Wizard. From the WSUS console or via PowerShell (Invoke-WsusServerCleanup). All the usual options — obsolete updates, computers, expired updates, unused update files. This is the second half of the metadata cleanup and it also flushes the content directory of updates that no longer have a matching approval.
6. IISReset, or recycle just the WsusPool app pool. Clears cached catalog state so the next sync ingests fresh. IISReset is cleaner if you’re already inside a maintenance window; recycling WsusPool alone is enough if anything else is running on that IIS instance and you don’t want to bounce it.

Then kick off a sync. The first Windows Update scan against the cleaned server will be slow — Microsoft has said this explicitly, and the reason is that clients are rebuilding their local view of the freshly-cleaned catalog. Subsequent scans return to normal. Do not roll back at hour two thinking the fix didn’t take.

One more thing that will confuse people who aren’t expecting it: DataStore.edb on the WSUS server does not shrink after the cleanup. That is fine and documented — the file’s internal pages are freed and will be reused by future writes; the file itself only shrinks if you explicitly compact it. Do not schedule an unnecessary offline compact into the same maintenance window just because the file size didn’t drop. That’s a separate operation, and running it inside the same window is how you extend the outage into daylight hours.

Priority call

• You run WSUS or Configuration Manager and have been unable to sync since roughly July 13: this is your fix. Schedule the window this week. Backups first, in order, all SUSDBs, no shortcuts.
• You run WSUS but built a new box after Microsoft’s July 18 mitigation: the ingest side was already fixed on the 18th. You’re not stuck. Do not run the cleanup against a healthy DB; the query is for servers with the accumulated bad metadata and there is no reason to swing a scalpel at a server that doesn’t need it.
• You do not run WSUS: nothing to do here. If your patch delivery is Intune or a third-party product like ManageEngine or PDQ, this bug was never in your path — WSUS as a scan target is what triggered the failure mode.

What this closes and what it doesn’t

The eight-day scan-fail window on WSUS Server 2012+ closes for everyone who runs the procedure. What it does not close is the credibility hit for shops that were sitting on a full July cumulative rollout — including a couple of the KB5121767-driven fixes from over the weekend — and could not deliver it because their scan pipeline was down. The honest timeline on those deferred deployments starts today and stretches through this week’s change windows; it does not retroactively cover the days the cumulatives sat undelivered. Track that separately from “sync is back up.” Sync being back up is the ingest side. Getting the July payload actually installed on endpoints is a second job that starts as soon as the first successful scan completes.

The last piece worth naming plainly: this whole incident is a reminder that WSUS’s database health is a fleet asset, not a background job. The cleanup wizard and a reindex on a quarterly cadence would have made the buildup less punishing when it hit. If you don’t have that on the calendar, add it before the next Patch Tuesday.