WSUS (Server 2022, WID) clients stop reporting status — detection/download work fine, but Last Status Report frozen for 130+ machines

Question

WSUS (Server 2022, WID) clients stop reporting status — detection/download work fine, but Last Status Report frozen for 130+ machines

Vijay Gupta 0

Environment: WSUS on Windows Server 2022, WID database, ~600 clients (mostly Win11, few Win10).

Issue: Since ~24 July 2026, 130+ clients stopped reporting status. Console shows "Last Status Reported" frozen at old dates, some show "Not yet reported" — despite endpoints being active and current.

What I've confirmed is working (ruled out):

All WSUS/IIS/WID services running normally; ReportingWebService responds locally
Client-to-server TCP connectivity (port 8530) confirmed fine
SelfUpdate content (wuident.cab) downloads successfully on affected clients
GPO settings correct (WUServer, WUStatusServer, UseWUServer=1)
Affected clients show detection (Event 26) and downloads (Event 41) succeeding repeatedly with zero errors in WindowsUpdateClient/Operational log
Side-by-side: 2 affected machines behave identically to 1 working machine client-side — only the working one's report actually gets recorded
tbEventInstance table checked: only ~4,194 rows (ruled out known bloat issue)
One-off error 0x80244010 seen once, hasn't recurred — likely unrelated

Already tried without success: WSUS Cleanup Wizard, subscription category trim + resync, SUSDB backup, IIS/WID service restarts, full client-side WU reset (SusClientId, SoftwareDistribution, catroot2), deleting and letting a computer object re-register.

Question: Since detection/download work but report submission specifically fails to persist for a subset of machines under identical client config, what server-side diagnostics (SQL Profiler on ReportingWebService inserts, IIS Failed Request Tracing, WSUS-specific logging) would help isolate why? Any known bugs/hotfixes for this exact symptom?

0 comments

2 answers

Your answer

Answer 1

Adam J. Marshall 11,031 MVP

Some users have reported that the September 2026 CU that was just released fixed their issue. Can you install it on a client that is having trouble and try getting it to report back?

https://www.ajtek.ca/wsus/client-machines-not-reporting-to-wsus-properly/#ForceReport

0 comments

Answer 2

Hi Vijay,

Since detection/download works and the affected clients can reach WSUS, I agree that this should be investigated specifically in the WSUS reporting pipeline, rather than continuing with full client resets.

There are also recent reports of a similar Windows Server 2022 WSUS/WID symptom where clients successfully scan and POST to ReportingWebService.asmx, but LastReportedStatusTime is not updated. However, I could not find a Microsoft-published known issue or hotfix confirming that all of these cases have the same root cause.

For one affected and one working client, reproduce the issue and compare:

IIS logs for POST /ReportingWebService/ReportingWebService.asmx, including HTTP status/substatus.
C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log at the same timestamp. Look specifically for ValidateEventBatch, parsing/SOAP exceptions, ArgumentNullException, DBNull, or SQL timeout messages.
In SUSDB, compare LastSyncTime and LastReportedStatusTime for both computer targets.
Check the size of dbo.tbEventInstance; Microsoft has documented cases where excessive reporting events can block clients from reporting, although that older documented condition may not be the cause here.

An HTTP 200 from ReportingWebService only confirms that IIS accepted the request; it does not prove that WSUS successfully validated and persisted the report into SUSDB. This distinction is important given your symptoms.

If the affected POST requests return 200 but SoftwareDistribution.log shows server-side validation/parsing failures and SUSDB is not updated, I would collect those logs plus a SQL Profiler/Extended Events trace if possible and open a Microsoft Unified Support case. I would avoid manually modifying SUSDB until the exact failure has been identified.