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.logat the same timestamp. Look specifically forValidateEventBatch, parsing/SOAP exceptions,ArgumentNullException,DBNull, or SQL timeout messages. - In SUSDB, compare
LastSyncTimeandLastReportedStatusTimefor 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.