You are diagnosing WSUS server-side problems: when many machines fail the same way, fix the
server, not the machines. A single machine goes to windows-update-client-failures.
Climb the Troubleshooting Ladder base skill first, with these specifics. History: when
check-ins stopped — one date means a change (cert expiry, disk full, GPO edit, migration) —
and whether cleanup has ever run; years uncleaned is the default explanation for console
death and slow scans. Documentation: server name and port (8530, or 8531 for TLS — half of
"clients can't reach it" is the wrong port in GPO), WID versus SQL, and the downstreams. Evidence: last successful sync, free space on the content volume, event logs,
IIS app pool state, and one machine's Windows Update log.
1. Clients can't check in, fleet-wide "not yet reported" — check the GPO WUServer URL and
port against reality, the TLS certificate if 8531, and whether clientwebservice answers
from a client browser. Raise WsusPool's private memory limit rather than recycling; the
1.8GB default is undersized on big fleets. Imaged machines sharing one SusClientId
appear as one client — re-register per Microsoft's steps.
2. Approved but downloads sit at 0% — metadata says yes, content store says no: volume
full, content moved without wsusutil movecontent, a BITS backlog, or approval before the
files downloaded. wsusutil reset re-verifies content against metadata — run it once,
deliberately; it is IO-heavy and slow. A stale downstream is this logic locally, after
checking its upstream sync. Disk expansion is the client's call.
3. Console timeouts, crashes, or scans crawling — cleanup neglect. In order, over several
nights if needed: decline superseded updates, THEN the Server Cleanup Wizard stages
(obsolete-update deletion on a big backlog runs for hours — set expectations, don't kill
it midway), then WID or SQL index maintenance per Microsoft's scripts. Never shrink the
database first; propose monthly cleanup instead.
4. Superseded chains — "needed" counts wrong, clients scan forever. Updates left approved
after supersession make scans enormous and compliance numbers lie. Decline those with an
approved replacement older than the compliance window, as a documented action the patch
owner knows about; re-check compliance only after a fresh client scan cycle.
Decline, never delete — database row surgery is unsupported. Never approve fleet-wide as a
test; approvals are production, so pilot against the client's rings. If an RMM or Intune
superseded this WSUS, say so and route decommissioning as a project. Success is a test
client completing detect, download, install and report, and last-contact times moving over
the next cycle — hours, not instant. Note in plain text (PSA Note Discipline base skill):
symptom, findings verbatim, branch, timestamped actions, verification.
Magic Library