0x80244007 scan failures traced to WSUS maxCachedUpdates

ConfigMgr clients stopped installing updates during their maintenance windows. The investigation ran through client and server logs, a retry loop that kept the WSUS server at high CPU, and several plausible dead ends before landing on a little-known WSUS limit: maxCachedUpdates.

TL;DR — If the WSUS/SUP catalog grows past the client web service’s cached-update cap, SyncUpdates calls fail. Clients log 0x80244007; the server logs InvalidParameters, Message=parameters.OtherCachedUpdateIDs. Fix: raise maxCachedUpdates (and maxInstalledPrerequisites) in %ProgramFiles%\Update Services\WebServices\ClientWebService\web.config, recycle WsusPool, then reduce the catalog size.

Symptom
“Updates aren’t deploying during the maintenance window.” The windows themselves were fine — UpdatesDeployment.log showed them opening on schedule, followed each night by:

A user-defined service window(non-business hours) is available. We will attempt to install any scheduled updates.
Attempting to install 0 updates

Zero actionable updates because the scan never succeeded. WUAHandler.log showed repeated 0x80244007 failures (WSUS returned a SOAP fault), with occasional 0x80244010 and 0x80240439.
Server side
SoftwareDistribution.log on the SUP showed a high volume of exceptions from many clients, in three patterns:

ErrorCode=InvalidParameters, Message=parameters.OtherCachedUpdateIDs, Client=...
ErrorCode=InvalidCookie, Message=, Client=?   (cookie blob won't deserialize)
ClientImplementation.RegisterComputer  SqlException: ...semaphore timeout period has expired

Clients were stuck in a loop: sync fails → client tries to re-register → RegisterComputer fails on a SQL transport timeout → retry. Enough clients retrying kept CPU high, which starved the server’s own SQL connections and caused the timeouts blocking recovery.
Dead ends checked along the way
Each fit part of the evidence and was tested before being ruled out: app-pool limits (already tuned), packet loss to SQL (clean), the SQL server itself (idle and healthy), web garden (maxProcesses = 1), TLS inspection (cert thumbprints matched end-to-end), WAS recycling the worker (nothing significant), restore-orphaned metadata (13 rows only).
The isolating test
Block TCP 8531 at the firewall for everyone except one test machine, reboot the SUP to clear accumulated load, wipe the test client’s SoftwareDistribution datastore, and watch one clean full sync with the IIS log alongside:

06:17:17  POST /ClientWebService/client.asmx  200
   ... eleven more successful trips ...
06:17:34  POST /ClientWebService/client.asmx  500   <- and 500s from then on

On the now-quiet server, the fault clearly referenced the test client’s own ID:

ErrorCode=InvalidParameters, Message=parameters.OtherCachedUpdateIDs, Client=<test client>

With a brand-new datastore, every ID in OtherCachedUpdateIDs had been issued by this server minutes earlier. The server wasn’t rejecting the IDs themselves — it was rejecting the size of the list.
Root cause
During a multi-trip sync, the client echoes back the update IDs it has already received so the server only sends what’s new. WSUS validates that list against maxCachedUpdates in ClientWebService\web.config; past the limit, the call is rejected — surfaced to the client as 0x80244007.
The SUSDB carried 100,306 updates (most already declined, but still present) and 771,775 IDs in the dependency cache. A routine catalog sync pushed the working set past the cap, and clients began failing around the same time. Established clients failed immediately; freshly imaged ones synced for a dozen trips, crossed the cap, then failed consistently — which made it resemble server-side corruption. The cookie churn, CPU load, and SQL timeouts were all downstream effects.
Fix
The file is ACL-protected, and a non-elevated Notepad will “save” into the UAC VirtualStore without changing the real file — edit from an elevated session:

$p = "$env:ProgramFiles\Update Services\WebServices\ClientWebService\web.config"

takeown /f $p
icacls  $p /grant "Administrators:F"
New-Item -ItemType Directory -Force C:\Backup | Out-Null
Copy-Item $p C:\Backup\ClientWebService-web.config.bak

notepad $p

In Notepad (launched from the elevated session, or the save silently goes to the VirtualStore), find and change the two values — set maxCachedUpdates comfortably above your total update count:

<add key="maxCachedUpdates" value="150000" />
<add key="maxInstalledPrerequisites" value="800" />

Save, then verify the change actually landed and recycle the pool:

Select-String -Path $p -Pattern 'maxCachedUpdates|maxInstalledPrerequisites'
Restart-WebAppPool WsusPool

After reopening client access, expect elevated load for a while as clients re-register and complete full syncs — that’s recovery. The signal for an actual relapse is SqlException entries returning to the server log.
Keeping it fixed
Raising the cap is a workaround; the durable fix is a smaller catalog: decline superseded and expired updates on a schedule, remove unused products and classifications, delete obsolete updates (spGetObsoleteUpdatesToCleanup / spDeleteUpdate), reindex SUSDB, and monitor the update count against the configured cap.
Error-code reference
Where Code / message Meaning in this incident
Client 0x80244007 Server SOAP fault — the OtherCachedUpdateIDs rejection
Client 0x80244010 Out of round-trips mid-sync; benign, next scan resumes
Client 0x80240439 The same fault surfacing through a different code path
Server InvalidParameters: parameters.OtherCachedUpdateIDs Root cause — list over maxCachedUpdates
Server InvalidCookie / “invalid header” Downstream noise while recovery was blocked

Server SqlException semaphore timeout in RegisterComputer Downstream effect of sustained retry load

Names, domains, and addresses anonymised. Environment: ConfigMgr current branch, Server 2022 SUP, SUSDB on remote SQL, largely UWF-protected lab clients.