The client is fine and your WSUS server is broken: the server-side diagnostic order to run before you touch another endpoint

A ticket says a laptop is missing the August cumulative update. You check the client. The Windows Update service is running, the component store is clean, there is no pending reboot, the policy looks right, and Get-WindowsUpdateLog shows a scan that completed without an error. So you reset SoftwareDistribution, run SFC, and wait. Nothing changes.

Three days later you have re-imaged two devices, opened a case with your OEM, and the update is still missing. Then somebody looks at the WSUS server and finds that the update was declined during a cleanup pass eleven weeks ago.

Every client in that fleet was working correctly the whole time. They asked the server what they needed, the server answered honestly, and the answer was nothing. There is no client-side error for "the server told me I am fine", which is exactly why this failure mode eats days.

This post is the server-side diagnostic order. It is deliberately narrow: no client remediation, no DISM, no service resets. The rule is simple. Never re-image a client until you have proven the server is serving.

The problem: the client is telling you the truth

The reason this failure is expensive is that it produces no error. A client that scans successfully and is offered nothing looks identical to a client that is fully patched.

Here is that identity on a real device. The block below is from a live Windows 11 Enterprise 25H2 machine, build 26200.9168, read out of the Microsoft-Windows-WindowsUpdateClient/Operational channel.

That is the whole trap. Event 26 is a success record, so every client-side triage script treats it as green. Event 41 ("An update was downloaded") never arrives because there was nothing to download, and the absence of an event is not something a monitoring rule fires on.

The table below is the translation layer you need when the ticket lands. The left column is what you are told; the right column is the server-side reading that most teams never make.

Look at the last row for a moment, because it is the single highest-value inference in this post. Microsoft's WSUS server-settings reference lists the IIS virtual directories created at setup: ClientWebService, ServerSyncWebService, ReportingWebService, SimpleAuthWebService, DssAuthWebService and WSUSAdmin. All six are documented as running in the WsusPool application pool.

So "the console cannot connect" and "no client can scan" are not two tickets. They are one fault reported by two different observers, and the console is the observer that happens to be sitting on your desk.

One honest caveat before we go server-side, because this post is not an argument that the server is always at fault. Microsoft's own WSUS troubleshooting guidance is explicit that the console message "Computer hasn't reported status" is typically caused by the client, not the server: the machine is off, asleep, or off the network. That message is a reporting gap, not a serving failure, and it belongs in a different investigation. The failures in this post are the ones where the client demonstrably completed a scan.

Why it happens: five server-side faults that present as client faults

1. The update is declined — and declined updates are hidden by default

WSUS has three approval states that matter here, and the difference between two of them is the entire post.

Not approved is not the same as absent. Microsoft's update-operations documentation is clear that when an update is left unapproved, the server still lets clients evaluate whether they need it. The update shows up in compliance reporting as needed and not installed. That is the state you want for something you have not deployed yet, because it keeps the update visible in your reports.

Declined is different in kind. Declining removes the update from the default list and the server stops offering it to clients — not just for installation, but for evaluation. The client will never see it, will never report it as needed, and will never generate a compliance gap. Your dashboard goes green because the question was withdrawn, not because it was answered.

Now the part that turns a five-minute check into a three-day outage: declined updates only appear in the WSUS console's update list if you explicitly select Declined in the Approval filter under View. The default view hides them. So an admin who opens the console, searches for the KB, and finds nothing concludes the update never synchronised — when in fact it is sitting right there, declined.

2. The update expired, and a revision auto-declined it

The second cause is the same end state reached without anyone deciding anything.

WSUS updates are revised. Microsoft defines a revision as a version of an update that has changed — and gives expiry and changed applicability rules as the two examples. On the Advanced tab of Automatic Approvals there are two options that are on by default: automatically approve new revisions of approved updates, and automatically decline updates when a new revision causes them to expire.

Both defaults are correct. Microsoft recommends keeping them, because they are what stops the database filling with dead metadata. But the consequence is that Microsoft expiring an update upstream can silently transition it to Declined on your server, at a time of Microsoft's choosing, with no admin action and no notification. Weeks later, a device that legitimately needed that specific update gets offered nothing.

The documentation is equally blunt about the alternative: if you turn off automatic declining of expired updates, you have taken on the job of declining them manually on a periodic basis. There is no third option where the metadata just stays tidy on its own.

3. Supersedence chains that were never pruned

This is the slow one. It does not break a single update; it degrades every scan, for years, until scans start timing out.

Start with a fact that surprises people: WSUS does not automatically decline superseded updates when you approve the update that supersedes them. Microsoft states plainly that no such feature exists, and further advises against assuming a superseded update should be declined — a superseding update may support only newer OS versions, or have narrower applicability, so the older one can still be the correct answer for part of your fleet.

The result is that on a server nobody maintains, superseded metadata accumulates monotonically. Microsoft's WSUS best-practices guidance calls keeping superseded updates around longer than needed the leading cause of WSUS performance problems, and the maintenance guide gives a hard number you can measure yourself:

Why does server-side metadata volume hurt a client? Because of how a scan works. WSUS keeps a database-backed cache of update metadata and returns the delta since the client last checked in. Microsoft describes building that cache as expensive and very memory intensive. When a client has no usable prior state it must do a full scan instead of a delta, and the maintenance guidance notes transfers greater than 1 GB per client in that scenario, particularly on a poorly maintained server.

Multiply one gigabyte by a few thousand devices arriving after a Patch Tuesday and you have what Microsoft calls a scan storm. Which leads directly to the next fault, because a scan storm is how the application pool dies.

4. WsusPool recycles under load and answers HTTP 503

If you only remember one server-side check from this post, make it this one. It is the most common cause of a whole fleet appearing to break its Windows Update client simultaneously, and it is a single number in IIS.

The mechanism is documented end to end. WSUS builds that expensive metadata cache inside the IIS worker process. The WsusPool application pool has a default private-memory limit. Cache building crosses it. IIS recycles the pool to enforce the limit. The recycle discards the cache. The next client request starts rebuilding it. Under sustained load that loop never converges, and clients get HTTP 503 back instead of update metadata.

The scale of the mismatch is the interesting part. Microsoft's best-practices article notes that an environment with around 17,000 cached updates may need more than 24 GB of memory while the cache is being built, settling at around 14 GB. The default private-memory limit is 1,843,200 KB — about 1.76 GB. The default is roughly an order of magnitude below the documented working set of a large server.

Here is the documented recommended configuration, with the defaults it replaces:

All five live in the same place: IIS Manager, Application Pools, select WsusPool, then Advanced Settings. Read them before you change them — the current values are diagnostic data.

The other reason to know this cold is that the client-side error codes point straight at it, if you can read them. Microsoft's Windows Update error reference maps HTTP status codes into WU_E_PT_* values:

5. The content directory and the SUSDB

The last two are the ones that show up as "detection works, download fails" and "everything is just slow".

Storage first. When you store update files locally, Microsoft's documented figures are a minimum of 20 GB with at least 40 GB recommended, plus roughly 10 GB more per Windows version and processor architecture for on-premises Unified Update Platform content. Two architectures of one Windows release is therefore about 20 GB on top of your existing footprint. Content directories that were sized before UUP fill up, quietly, and BITS transfers start failing while metadata scans keep succeeding — which is precisely why detection and download can disagree.

Permissions are the other half of that. The WSUS server-settings reference is specific: the root of the drive holding WsusContent needs Read for the appropriate account, and the content directory itself needs Full Control for NT AUTHORITY\NETWORK SERVICE. Setup configures the latter; it does not configure the drive-root permission, and security software has been known to reset both. Get either wrong and BITS downloads fail.

Then the database. Microsoft's reindex article opens with the sentence that should be pinned above every WSUS server: the performance of large WSUS deployments degrades over time if the database is not maintained properly. Not "may degrade" — will. Index fragmentation and stale statistics on SUSDB are a client-visible problem because every client scan is a query against it.

How to verify: the server-side order, step by step

Everything below is read-only. Nothing here declines, approves, deletes or restarts anything. Work the steps in order and stop at the first one that fails, because a failure upstream makes everything downstream unreadable.

Step 1 — Scope the blast radius before you look at anything

This costs thirty seconds and eliminates most of the search space.

• One device, one update. Genuinely client-side is plausible. Even so, do step 3 first: it is faster than any client investigation.
• Many devices, one update. Approval, targeting, or supersedence. Never the client. Go to step 3.
• Many devices, all updates. The server plumbing. Skip to step 2, then step 5.
• All devices stopped reporting at roughly the same time. Almost certainly WsusPool. Steps 2 and 5, in that order.

Step 2 — Prove the web services are answering

The client web service is the endpoint every scan hits. Ask it the same question a client would.

Note what a 200 here does and does not prove. It proves the pool is running and the endpoint is bound. It does not prove the server can answer a real scan, because a real scan makes the pool build the metadata cache. That is why step 5 still matters even when step 2 is green.

Step 3 — Read the approval state, with Declined explicitly included

This is the step people skip, and it is the one that closes most of these tickets.

In the console the equivalent move is to set the Approval filter under View to Declined and refresh. If the KB appears there, you are done diagnosing: this was never a client fault, and no amount of client remediation would ever have fixed it.

While you are here, check the other approval trap. Approving an update for a parent computer group does not automatically change child groups — multi-select approvals default to keeping existing approvals, and children stay as they were unless you explicitly apply to children. A "missing on one whole ring" symptom is very often exactly this.

Step 4 — Measure supersedence and obsolescence

Run the census query from earlier. You are looking for two things: a "Superseded but not declined" figure above 1,500, and an obsolete-update count in the thousands. Either one means the server has never been maintained, and that alone explains slow or failing scans across the fleet.

Do not fix it yet. Record the numbers. They are your before-picture, and without them you cannot prove the fix worked.

Step 5 — Read the WsusPool configuration

Compare the live values against the recommended table above. Any pool still sitting at the 1,843,200 KB default on a server with more than a few hundred clients is a finding, not a configuration.

Also check whether Xpress metadata compression is enabled, because it materially affects scan bandwidth. It is configured in two places: a <scheme name="xpress"> entry under <httpCompression> in ApplicationHost.config pointing at C:\Program Files\Update Services\WebServices\suscomp.dll, and the registry value IIsDynamicCompression under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup. If both are absent, Microsoft documents DynamicCompression.vbs in the WSUS setup folder as the way to enable it. Trade-off is explicit: Xpress saves bandwidth and costs CPU.

Step 6 — Content directory and database

Two reads. First, resolve ContentDir from the registry and check free space on that volume against the 20 GB minimum / 40 GB recommended figures plus your UUP overhead. Second, resolve SQLServerName to find out whether you are on WID or SQL Server.

The registry key is shared, so it is stated once here:

Step 7 — Read the server-side logs, in this order

Three log sources, three different questions. Most people never open any of them.

This is why the IIS log beats every client-side tool for this class of fault. It is the only place where you can see the server's answer, the status code, and the latency together, for every device, with timestamps you can correlate against a client's Event 26.

Step 8 — Only now, go back to the client

If steps 2 through 7 are all clean — the pool is stable, the update is approved and not declined, supersedence counts are sane, content and SUSDB are healthy, and the IIS log shows fast 200s for that specific client's IP — then and only then have you earned the right to investigate the endpoint. And the ticket is now a genuinely different investigation, with the server eliminated on evidence rather than assumption.

The fix: repair the server in the documented order

Reinstating a declined update

If step 3 found a declined update, the repair is small and reversible. In the console, set the Approval filter to Declined, refresh, select the update, right-click, choose Approve and accept the dialog. That returns it to Not approved — visible again, evaluated by clients again, reported on again. Then approve it for the right computer group as a separate, deliberate action.

One caveat with teeth: if a cleanup pass has already deleted the declined update from the database, it is gone from the All Updates view and reinstating is not an option. You then re-import it from the Microsoft Update Catalog, assuming it has not been expired or removed there. And note that in a Configuration Manager environment the extra step after reinstating is a resynchronisation of the software update point — otherwise the site database still does not know about it.

Fixing WsusPool

Apply the values from the table in whichever of the two documented directions you chose, then recycle the pool once, deliberately, and watch the IIS log time-taken column as clients come back. Expect the first requests after the recycle to be slow — that is the cache rebuilding, and it is normal. What you are looking for is whether latency settles or whether the pool crosses its limit and recycles again.

Running the maintenance, in the documented order

Microsoft's maintenance sequence has five steps and the order is not decorative — reindexing before declining is what stops the decline pass timing out.

1. Back up SUSDB. Non-negotiable. Every later step deletes data.
2. Create the custom indexes. Optional but recommended, and a one-time job per database. Two non-clustered indexes: nclLocalizedPropertyID on tbLocalizedPropertyForRevision, and nclSupercededUpdateID on tbRevisionSupersedesUpdate. Microsoft's note is that they greatly improve performance of subsequent cleanup operations. Re-running the script on a database that already has them raises a duplicate-index error, which is harmless.
3. Reindex SUSDB. Microsoft's published T-SQL identifies fragmented indexes, rebuilds or reorganises them based on page density and fragmentation, and then updates statistics via sp_updatestats.
4. Decline superseded updates. Either the WSUS console, or the published Decline-SupersededUpdatesWithExclusionPeriod.ps1 script, or the SQL alternative built on spDeclineUpdate. Run the script with -SkipDecline first, every time, to get a count of what it would do.
5. Run the Server Cleanup Wizard (or Invoke-WsusServerCleanup). Then reindex again, because the decline and cleanup passes will have churned the indexes.

The Cleanup Wizard's six documented behaviours are worth knowing precisely, because several of them have thresholds that explain why an update you expected to be cleaned up was not:

• Remove unused updates and update revisions.
• Remove older updates and revisions that have not been approved.
• Delete client computers that have not contacted the server in 30 days or longer.
• Delete update files not needed by any update or downstream server.
• Decline updates that Microsoft has expired.
• Decline superseded updates — but only when all of five conditions hold: the superseded update is not mandatory; it has been on the server 30 days or more; no client currently reports it as needed; it has not been explicitly deployed to a computer group for 90 days or longer; and the superseding update is approved for install to a computer group.

That five-condition test is the answer to "why is this superseded update still here". Most often the last condition is unmet: the replacement was never approved for a group, so WSUS correctly refuses to decline the thing it would replace. There is a related trap with automatic approvals — updates approved by an auto-approval rule stay in an Approved state and the wizard will not remove them, so an admin has to set them to Not approved first to make them eligible.

The elephant: WSUS is on a deprecation path

Two concrete consequences that are already biting, both worth checking on your own estate.

First, driver synchronisation. Microsoft published a Windows IT Pro Blog post announcing the deprecation of WSUS driver synchronisation, and then published a second post titled "Continuing WSUS support for driver synchronization". Read both before you plan around either — the pair is a useful reminder that a deprecation date you memorised eighteen months ago may not be the current position, and that the only trustworthy answer is the live post.

Second, hardening. Microsoft published a servicing note that WSUS on Windows Server 2025 is removing dependencies on unsupported code, including binaries WSUS used to update the Windows Update SelfUpdate service on devices — starting with the September 2025 security update. The documented impact is narrow, affecting the updating of Windows Server 2012 and 2012 R2 endpoints on extended security updates, and Microsoft documents a temporary workaround involving copying the SelfUpdate folder from an older supported WSUS version and adding it as a virtual directory. Narrow or not, it is the shape of what deprecation looks like in practice: server-side changes that surface as client-side update failures.

Which is the argument of this whole post, restated. As the platform stops evolving, the proportion of "client" failures that are actually server failures goes up, not down.

Proof it worked: what to capture before and after

The failure mode here is invisible, so the fix is invisible too unless you measure it. Capture these before you change anything, and again a full detection cycle later.

Two closing notes on interpreting the after-picture.

Event 26 with a non-zero count on one test device is proof the server is now serving. It is not proof the fleet is compliant — compliance follows the detection cycle, so give it a day before you read the dashboard as truth.

And keep the census query. Seven numbers, once a month, in a spreadsheet, is the entire early-warning system for a technology that Microsoft has stopped improving. The next person to be handed a "broken client" will thank you for the trend line.

References

• Windows Server Update Services (WSUS) best practices - the WsusPool recommended-values table, the 1,843,200 KB default, the 29-hour recycle, the scan-storm and memory-cache mechanism, the 17,000-update memory figure, and the Xpress compression settings.
• WSUS messages and troubleshooting tips - Message ID 6703, the HTTP 503 / stopped WsusPool diagnosis, the 4 GB and 8 GB Private Memory Limit guidance, the mimeMap duplicate-entry fix, and the "Computer hasn't reported status" caveat.
• WSUS maintenance guide for Configuration Manager - the five-step maintenance order, the 1,500 superseded-update threshold and its SQL query, the custom index script, the decline script and its exclusion period, and the timeout / spDeleteUpdate fallback.
• Manual and automatic WSUS database maintenance - the seven-column SUSDB census query, the "resolves many scanning and synchronisation issues" framing, the duration range, and the create-a-new-SUSDB exit criterion.
• Reindex the WSUS database - the degradation-over-time statement and the published T-SQL that defragments indexes and updates statistics.
• Updates Operations (WSUS) - what Not approved versus Declined actually mean, the Declined view filter, reinstating declined updates, expired-update auto-decline, and the statement that WSUS never auto-declines superseded updates.
• Server Cleanup wizard - the six cleanup behaviours, the 30-day and 90-day thresholds, the five-condition supersedence test, the bottom-up hierarchy warning, and the imported-catalog-files warning.
• Invoke-WsusServerCleanup (UpdateServices) - the six cleanup switches, the equivalence to the console wizard, and -WhatIf support.
• Get-WsusUpdate (UpdateServices) - the -Approval values including Declined and AnyExceptDeclined, the -Status enumeration, and the -Classification limitation.
• Get-WsusServer (UpdateServices) - the read-only entry point that returns the IUpdateServer object every other cmdlet needs.
• Windows Update error code list by component - the WU_E_PT_* protocol-talker codes, their HTTP mappings, and the 0x80244020 / 0x80244023 description quirks.
• Plan your WSUS deployment - the 20 GB minimum and 40 GB recommended content figures, the UUP 10 GB per version/architecture overhead, the WID instance and SUSDB.mdf path, the installed web services, and the 22-hour polling interval.
• Troubleshoot WSUS synchronization and import issues - the SoftwareDistribution.log path, the SCHANNEL startup lines, the ProcessWebServiceProxyException pattern, and the TLS 1.2 Monthly Rollup dependency.
• Verifying WSUS Server Settings - the Update Services\Server\Setup registry values, the statement that configuration lives in SUSDB rather than the registry, the IIS virtual directory / WsusPool mapping, and the NETWORK SERVICE content-directory permissions that BITS depends on.
• Configure Logging in IIS - the default log directory, the W3C field list including sc-status, sc-win32-status and time-taken, and the UTC timestamp behaviour.
• Features removed or no longer developed in Windows Server - the definition of deprecation, the WSUS entry, and the Windows Internal Database entry.
• Windows Server Update Services (WSUS) overview - the deprecation note in its current wording, and the UUP support and MIME-type requirement.
• Deploy updates using Windows Server Update Services - the supported Windows Server versions for the WSUS role, and the 8530 / 8531 / 80 / 443 port rule.
• Deprecation of WSUS driver synchronization and Continuing WSUS support for driver synchronization - read the pair, in that order, before planning around either.
• Hardening changes for Windows Server Update Services in Windows Server 2025 - the SelfUpdate dependency removal, the affected legacy endpoints, and the documented virtual-directory workaround.