Windows Server 2022 WSUS with WID - Windows 11 25H2 clients sync successfully but never report status

Question

Windows Server 2022 WSUS with WID - Windows 11 25H2 clients sync successfully but never report status

Rajendra Chandrikapure 50

Has anyone seen this behavior with Windows 11 25H2 clients and WSUS on Windows Server 2022 (WID) where:

Successfully scans against WSUS.

Finds approved updates.

Downloads updates.

Installs updates.

Windows Update Operational log shows Event ID 26 ("Windows Update successfully found updates") and Event ID 41 ("An update was downloaded").

Therefore, client-to-WSUS communication appears to be working.

synchronization succeeds,

IIS returns HTTP 200,

clients download/install updates,

but status reporting never reaches SUSDB (LastReportedStatusTime, LastInventoryTime, and tbEventInstance remain empty)?

Is there a known compatibility issue, required WSUS update, or server-side fix for Windows 11 25H2 reporting?

0 comments

Answer accepted by question author

Adam J. Marshall 10,871 MVP

If you have a licence for WAM, we added a tool to fix this. Download 2026.07.1 and install it and then you can run from the WAM Shell

Invoke-DetectoidCleanup

This will follow Microsoft's instructions and easily clean up your database from the test detectoids.

If you want to let WAM tell you if you have it or not, just wait for the next run tomorrow or execute from the WAM Shell:

.\Clean-WSUS.ps1 -ScheduledRun

And then check the report to see if the detectoids have been found in your database.

Alternatively follow https://support.microsoft.com/en-us/servicing/os/windows/docs/2026/07/kb5121986-windows-server-update-service-sync-operations-issues-and-timeouts

Rajendra Chandrikapure 50 Reputation points

2026-07-23T11:22:07.19+00:00

Thank you for sharing KB5121986. I have reviewed the article.

My WSUS server does not appear to exhibit the synchronisation issues described in the KB. Synchronisation completes successfully; clients can scan, download, and install updates; and IIS logs show successful HTTP 200 responses from ReportingWebService.asmx.

The only issue is that Windows 11 25H2 clients do not update LastReportedStatusTime and remain "Not yet reported"

Could you please confirm whether this behaviour is expected to be covered by KB5121986, or should be investigated as a separate Windows 11 25H2 reporting issue?
Adam J. Marshall 10,871 Reputation points MVP

2026-07-23T13:29:05.36+00:00

The only way to know if this applies to you or not is to modify the SQL code to select the appropriate rows and see if you have more than 0. If you have more than 0, this applies to you. If you don't, then this isn't the answer.

This is a widespread issue Microsoft created causing anyone who was syncing with MS before July 18th (when they fixed it) to be affected. This was such a problem that we chose to create an emergency detection path in WAM and create an easy tool for our customers to fix this issue causing us to re-release WAM with this updated check in our off-schedule. If this ever happens again, WAM would then detect and alert you to remove the detectoids.
William Fourqurean 0 Reputation points

2026-07-24T11:01:57.71+00:00

What is WAM?
Adam J. Marshall 10,871 Reputation points MVP

2026-07-24T13:35:37.5766667+00:00

WAM stands for WSUS Automated Maintenance (Full disclosure: our product). You will need to search for it, as my intent is not advertising.)

Answer accepted by question author

Chen Tran 12,750 Independent Advisor

Hello Rajendra,

Thank you for posting question on Microsoft Windows Forum!

Based on the issue description. Well! The plausible explanation to this behavior is that Windows 11 25H2 introduces changes to the Windows Update Agent that affect how reporting data is packaged and sent to WSUS. While the scan, download, and install workflows (which use the newer Unified Update Platform protocols) function correctly, the reporting event payload appears incompatible with the WSUS server-side processing on Windows Server 2022. The server accepts the connection (HTTP 200), but fails to parse the reporting data into the SUSDB, so tbEventInstance, LastReportedStatusTime, and LastInventoryTime are never updated.

The suggestion is to ensure your WSUS server is fully patched with the latest cumulative update from Windows Update/Microsoft Update Catalog. If you are already on a patch level later than February 2025 and the issue persists, a specific out-of-band fix may still be pending for 25H2. Checking for any latest servicing stack updates.

On the other hand, try to check the Server-Side by looking at what WSUS is doing with the data it receives. You can open the WSUS application log on your Server 2022 box. Navigate to this path C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log and search the log for references to ReportingWebService.asmx or DBNull / ArgumentNullException. If you see SOAP or Parsing Exceptions which indicates that Windows 11 25H2 introduced minor changes to the Windows Update Agent (WUA) payload string. If WSUS does not know how to map a new hardware property or OS feature metric sent by 25H2, the web service throws an unhandled exception and silently discards the report. Ensure your Server 2022 host has the absolute latest Cumulative Updates installed to get the updated microsoft.updateservices binaries. In case, you see SQL Timeout Exceptions which indicates the reporting pipeline is choking on the WID back-end.

Hope the above information is helpful!

Rajendra Chandrikapure 50 Reputation points

2026-07-18T05:49:20.34+00:00

I reviewed SoftwareDistribution.log and did not find any SOAP exceptions, SQL timeout errors, or parsing/ArgumentNullException errors related to ReportingWebService.

The WSUS server is fully patched (WSUS version 10.0.20348.5386). IIS logs confirm that ReportingWebService.asmx returns HTTP 200 for Windows 11 25H2 clients, and Windows 10/earlier Windows 11 versions report successfully. Only Windows 11 25H2 clients fail to update LastReportedStatusTime and LastInventoryTime.

Could you please confirm whether this is a known compatibility issue between Windows 11 25H2 and WSUS on Windows Server 2022, and whether a hotfix or workaround is available?

4 additional answers

Your answer

Rajendra Chandrikapure 50 Reputation points

2026-07-23T11:22:07.19+00:00

Thank you for sharing KB5121986. I have reviewed the article.

My WSUS server does not appear to exhibit the synchronisation issues described in the KB. Synchronisation completes successfully; clients can scan, download, and install updates; and IIS logs show successful HTTP 200 responses from ReportingWebService.asmx.

The only issue is that Windows 11 25H2 clients do not update LastReportedStatusTime and remain "Not yet reported"

Could you please confirm whether this behaviour is expected to be covered by KB5121986, or should be investigated as a separate Windows 11 25H2 reporting issue?
Adam J. Marshall 10,871 Reputation points MVP

2026-07-23T13:29:05.36+00:00

The only way to know if this applies to you or not is to modify the SQL code to select the appropriate rows and see if you have more than 0. If you have more than 0, this applies to you. If you don't, then this isn't the answer.

This is a widespread issue Microsoft created causing anyone who was syncing with MS before July 18th (when they fixed it) to be affected. This was such a problem that we chose to create an emergency detection path in WAM and create an easy tool for our customers to fix this issue causing us to re-release WAM with this updated check in our off-schedule. If this ever happens again, WAM would then detect and alert you to remove the detectoids.
William Fourqurean 0 Reputation points

2026-07-24T11:01:57.71+00:00

What is WAM?
Adam J. Marshall 10,871 Reputation points MVP

2026-07-24T13:35:37.5766667+00:00

WAM stands for WSUS Automated Maintenance (Full disclosure: our product). You will need to search for it, as my intent is not advertising.)
Rajendra Chandrikapure 50 Reputation points

2026-07-18T05:49:20.34+00:00

I reviewed SoftwareDistribution.log and did not find any SOAP exceptions, SQL timeout errors, or parsing/ArgumentNullException errors related to ReportingWebService.

The WSUS server is fully patched (WSUS version 10.0.20348.5386). IIS logs confirm that ReportingWebService.asmx returns HTTP 200 for Windows 11 25H2 clients, and Windows 10/earlier Windows 11 versions report successfully. Only Windows 11 25H2 clients fail to update LastReportedStatusTime and LastInventoryTime.

Could you please confirm whether this is a known compatibility issue between Windows 11 25H2 and WSUS on Windows Server 2022, and whether a hotfix or workaround is available?

Answer 1

William Fourqurean 0

I have almost this exact same problem, except for the OS versions affected. All of my Windows Server 2016 clients and some of my Windows Server 2019 clients have not updated their status in WSUS since July 15, 2026. All Windows 11, Windows Server 2022, Windows Server 2025, and some Windows Server 2019 clients are reporting normally. I followed the remediation instructions in the KB for cleaning SUSDB metadata, and I have reset client WU data. Nothing has fixed this.

0 comments

Answer 2

Willy 0

My situation is very similar. The Last Reported Status field in WID is always NULL, and most client machines have stopped reporting after July 2. Only a small number of machines—mostly Windows Server systems—are still reporting normally.

I've tried various performance optimizations as well as the latest mitigation measures, but none of them worked.

On July 22, I completely reinstalled Windows Server 2025 and WSUS using the latest available versions. Unfortunately, the issue remains exactly the same. I can see clients checking in, but they never send back their status reports.

Could someone from Microsoft please help investigate this issue or advise if there is a known fix? Any assistance would be greatly appreciated.

Marco 41 Reputation points

2026-07-24T06:37:40.54+00:00

Hi, I had this issue too. Upon investigating, the problem was only with Asus clients. I uninstalled the latest July update and they started working again. I had also tried setting up a new server, but the issue persisted. Check this log and search miscData=[

t=

Server log: C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log

ReportingEvent.ValidateMiscData

ValidateMiscData: Rejecting MiscData entry with empty or whitespace-only value: t=

WebService.ValidateEventBatch

Event in batch failed to validate.

Exception: MiscData entry has empty or whitespace-only value: t=

ComputerBrand=[ASUSTeK COMPUTER INC.]

ComputerModel=[ASUS EXPERTBOOK B1502CVA_B1502CV]

OSVersion=[10.0.26200.65792.0.0.0.0.0]

miscData=[

t=

...

]
William Fourqurean 0 Reputation points

2026-07-24T10:52:57.72+00:00

I think you are onto something regarding the vendor info. All my systems that had problems are third party systems (they are actually Dell servers but rebranded from another OEM vendor, and they are years old). How can we get this fixed?
Marco 41 Reputation points

2026-07-24T11:02:49.0133333+00:00

I remove the July Cumulative Update
William Fourqurean 0 Reputation points

2026-07-24T11:06:06.7566667+00:00

Did you remove the July update from the WSUS server or from the clients? This issue came up immediately after I installed the July LCU on the WSUS server, but before I installed updates on clients.
Marco 41 Reputation points

2026-07-24T11:14:18.8466667+00:00

Remove from wsus server.
Adam J. Marshall 10,871 Reputation points MVP

2026-07-24T13:33:52.0466667+00:00
Have you seen the OOB update? You must import OOB updates into WSUS - they do not sync otherwise.

Import-WsusUpdate -KB KB5121767

I wonder if this OOB fixes this for you instead of uninstalling the CU? Likely the old Dell systems are using the Intel Driver mentioned.
William Fourqurean 0 Reputation points

2026-07-24T16:44:59.7966667+00:00

That OOB update applies to Windows 11. I don't see an OOB update for Windows Server. All my affected client systems are servers, but they probably are not identifying themselves using a known manufacturer or model. I will need to try to query the log data next week when I am back in the office. These systems were StreamVault or Seneca systems, but they often show up in management reports as unknown model. They are actually manufactured by Dell, and I can install Dell updates on them, but they don't identify as Dell through normal reporting.
William Fourqurean 0 Reputation points

2026-07-26T11:39:04.3033333+00:00

I uninstalled the July LCU for Windows Server 2022 from my WSUS server, and it resolved this issue. All clients are reporting normally now. I looked in the SoftwareDistribution.log and I found the same warning that you mentioned.

Event in batch failed to validate. Exception: Miscdata entry has empty or whitespace-only value: T=

I don’t have the other messages that you had about the computer model or brand.

I hope someone at Microsoft is aware of this and working on it. I have found no other reference to this issue outside of this thread.
William Fourqurean 0 Reputation points

2026-07-26T11:42:50.0966667+00:00

Actually I found the references to ComputerBrand and ComputerModel. They Are blank.

Answer 3

Adam J. Marshall 10,871 MVP

Are you performing the proper WSUS maintenance including but not limited to running the Server Cleanup Wizard (SCW), declining superseded updates, running the SQL Indexing script, etc.?

https://www.ajtek.ca/wsus/how-to-setup-manage-and-maintain-wsus-part-8-wsus-server-maintenance/

Client reporting is the job of each client. Have you tried running the client side script after deleting the client from the WSUS MMC Console?

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

If that doesn't fix it, move down the page from top to bottom to confirm everything is setup correctly.

Rajendra Chandrikapure 50 Reputation points

2026-07-20T05:54:39.4133333+00:00

Thanks, Adam.

Yes, I've already completed the recommended WSUS maintenance, including the Server Cleanup Wizard, SQL reindexing/DB maintenance, and declining superseded/expired updates. The WSUS database appears healthy, and IIS logs show Windows 11 25H2 clients successfully POST to ReportingWebService.asmx with HTTP 200 responses.

I also tested deleting the affected client from the WSUS console and running the client-side reset/reporting script. The client scans, downloads, and installs updates successfully, but LastReportedStatusTime is still not updated and shows as "Not Yet Reported"
Marco 41 Reputation points

2026-07-20T08:58:59.1933333+00:00

Hi. I have the same issue.

All windows server client reporting correctly

Some client reporting correctly. Other client contact the wsus server (w2022) but not reporting.
William Fourqurean 0 Reputation points

2026-07-24T11:12:17.1533333+00:00

I think that you are hammering the WSUS maintenance a bit too hard. Yes, we all need to do the maintenance, but that does not mean that is the cause of all problems. I've finally found evidence that others are experiencing the same issue as I have been dealing with for a week, and it appears to be related to some type of change that was included in the July LCU. My issues started immediately after installing the July LCU on the WSUS server, but before installing any updates (except update catalog) on the WU clients.
Adam J. Marshall 10,871 Reputation points MVP

2026-07-24T13:28:56.27+00:00
99% of all problems is due to the lack of the right maintenance and optimizations. This falls into the 1% group. With Microsoft's detectoid issue from just before the July CU release, and the fact that July 2026's CU initially had issues with specific Intel drivers, later fixed with Out of Band (OOB) update KB5121767 which must be manually imported into WSUS -

Import-WsusUpdate -KB KB5121767

I would say this is almost a perfect storm as to what to blame.
William Fourqurean 0 Reputation points

2026-07-24T15:36:48.56+00:00

Thanks for the feedback. I am a proponent of preventive maintenance, and I took almost all of the recommended actions to try to fix my issue. My issue is mostly with all the steps required to fully reset the WUA client configuration. This can be a very time consuming and disruptive procedure, especially if you are talking about a sizable number of affected clients, not just a one-off situation. Some of those folders, like the catroot2 folder, can't be easily deleted without taking extraordinary steps to shut other things down, including multiple restarts. Often following all of those steps results in no change. When a change happens immediately after a CU rollout, someone should suspect a change in the CU as a possible cause. I hope that Microsoft finds the source of this issue. I was preparing to rebuild my WSUS server next week, but since I found this thread, now I know that probably would not have fixed anything and would have been another waste of time.