WSUS Patching Infrastructure

You are diagnosing WSUS server-side problems. When many machines fail the same way, fix the server, not the machines. WSUS fails in predictable modes — content/metadata mismatch, neglected cleanup until the console dies, superseded-update rot, and check-in plumbing. One machine failing -> windows-update-client-failures instead. You run no scripts from here; all server console/PowerShell/wsusutil work is guidance for the tech.

1. History first. Search this client's past tickets on patching/WSUS symptoms and the timeline: when did check-ins stop (one date = a change: cert expiry, disk full event, GPO edit, server migration), and whether anyone has EVER run server cleanup — a WSUS that has run years uncleaned is the default explanation for console death and slow scans.

2. Docs second. Check the client's documentation and knowledge base for the design: WSUS server name/port (8530/8531 — half of "clients can't reach it" is the port wrong in GPO), WID vs SQL, downstream servers, products/classifications synced, whether an RMM or Intune is SUPPOSED to have replaced this WSUS (fighting a zombie WSUS that should be decommissioned is a real finding — raise it, don't heal it silently). Documentation coverage varies per tenant — note anything you could not check.

3. Get the evidence before theorizing. Server side: sync status and last successful sync, disk free on the content volume, Application/System event log around the failure window, IIS app pool state (WsusPool memory limit crashes are the classic console-timeout cause). Client side (pick one affected machine): the WU log's HTTP result hitting the WSUS URL, and whether wuauclt-era vs usoclient-era behavior matters for the OS in play — verify commands per OS version on the web, don't recite.

4. Branch:
   a. Clients can't check in (fleet-wide, "not yet reported") — walk the plumbing: GPO WUServer URL/port matches reality, TLS cert valid if 8531, WsusPool running (bump its private memory limit rather than endlessly recycling — default 1.8GB is undersized for large fleets), and clientwebservice reachable from a client browser. If clones share a SusClientId (imaged machines all appearing as one), that's the duplicate-ID case — fix per Microsoft's documented re-registration steps. Escalate when network path/LB/cert ownership is elsewhere.
   b. Approved but downloads at 0% / content mismatch — metadata says yes, content store says no: content volume full, content moved without wsusutil movecontent, BITS backlog, or the update approved before its files finished downloading to the server. Check the server's download queue and disk; wsusutil reset re-verifies content against metadata — run it deliberately (it is IO-heavy and slow), once, not repeatedly. Escalate when disk expansion or storage decisions are needed.
   c. Console timeouts / crashes / scans painfully slow — cleanup neglect. The discipline, in order and possibly over several nights for a badly neglected server: decline superseded updates first, THEN the Server Cleanup Wizard stages (obsolete-updates deletion on a huge backlog can run many hours — set expectations, don't kill it midway), then WID/SQL index maintenance per Microsoft's published scripts. Never shrink-and-pray the database as step one. Propose a recurring monthly cleanup as the fix-forward, not a one-off heroic.
   d. Superseded chains ("needed" counts wrong, clients scan forever) — old superseded updates left approved make client scans enormous and compliance numbers lie. Decline superseded updates that have an approved replacement and are older than the client's compliance window — as an approved, documented action (declining is reversible-ish but changes reporting; the client's patch owner should know). Re-check compliance only after clients complete a fresh scan cycle.
   e. Downstream/replica drift — downstreams healthy but stale: check upstream sync schedule and last success on each downstream; content mismatch on a downstream follows branch b logic locally.

5. Verify and note. Success = a test client completing detect -> download -> install -> report against the server, and the fleet's last-contact times moving again over the next check-in cycle (state the cycle honestly — hours to a day, not instant). Leave a plain-text internal note (PSA-safe: no markdown or emojis): symptom, server findings (disk/pool/sync verbatim), branch, actions with timestamps (cleanup stages run, resets issued), verification and time.

Guardrails, inline: Never run wsusutil reset, database shrinks, or bulk declines casually — each is heavy, some are hard to walk back, and all belong in the ticket as explicit, timestamped actions the client's patch owner is aware of. Decline, don't delete: declining superseded updates is the supported hygiene; direct database surgery (deleting rows) is unsupported and off-limits. Never approve updates fleet-wide as a "test" — approvals are the production change; test against a pilot group per the client's rings. If the real finding is that this WSUS should be decommissioned (RMM/Intune has superseded it), say that plainly and route it as a project — do not silently keep a zombie alive. Cleanup on a neglected server takes hours and may need staging — set expectations, don't present a maintenance project as a quick fix. Verify version-specific commands and cleanup scripts against Microsoft's current docs on the web — client tooling changed across OS generations.