Wsus and Windows 11 25H2 Asus clients sync successfully but never report status

If anyone installs the expected August LCU next week and finds that it either fixes this problem or reintroduces it, please post a comment to let us know. I will probably update my WSUS server last, after everything else has been updated. Thanks for the comments.

This issue affects Server 2025 as well, removing KB5099536 (the July Cumulative) is also the fix.

This issue affects 2019 server as well. I do not remove KB,

accept this issue, just only 6 Fujitsu clients in my enviroment.

I was wondering if anyone who commented on this thread previously who experienced this issue has installed the August cumulative update on their WSUS server? I am updating all my other systems first, and may not get to updating the WSUS server until next week. I was interested to see if the August update introduces the same issue as the July update, or if Microsoft fixed that. Thanks.

It's not fixed. Same problem persists after installing August update on Server 2025.

OK, thanks. I will see if there is a way that I can open a support incident with Microsoft. We don't have a paid support contract, so I'm not sure if that is something I can do. This doesn't seem to be a priority for them, they may not even be aware of this issue.

The t= field contains values such as:

7f4a7av for HP Elite Mini 600 G9

550b4av for HP Elite 800 G9

LENOVO_MT_12TY_BU_Think_FM_ThinkCentre M70t Gen 5 for Lenovo ThinkCentre M70t Gen 5

079C for Dell OptiPlex 7450

It appears to be a manufacturer-provided hardware identifier.

Another field that is not populated in the reports is:

ApplicableUpdateInfo=

For older clients, I also observed entries such as:

AppName=[AutomaticUpdates]
OSVersion=[6.1.7601]

where OSVersion=[6.1.7601] corresponds to Windows 7.

There is also a field in the form:

g=00CB4C21-B7D0-4F11-8694-8D80E881921C|
12710F51-6D71-4886-8D91-D211CC1DCF3A|
0B8CF281-9524-4874-A677-DA30E5F951DB|
AFBC8884-8812-49D8-B639-6C7326785B01

WSUS attempts to parse this field using ParseGuidArrayString(), which results in errors similar to:

Guid should contain 32 digits with 4 dashes

If we compare it to:

V=GUID;GUID;GUID;GUID;GUID...

the only noticeable difference is the delimiter. For V= the delimiter is a semicolon (;), whereas for g= it is a pipe character (|).

The data was extracted using:

PowerShell

1

Select-String -Path "C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log" `

2

-Pattern "miscData=" > miscdata.log

Show more lines

Additionally, I noticed that systems which do not update correctly often report:

BiosReleaseDate=[1/1/1900]

at least in my environment. This appears to be common among the affected systems.

I am wondering if there might be a registry value that we can update on the non-reporting clients to make WSUS happy with the reported data. It seems to not like the fact that the MiscData value is blank. I have searched through the registry for a MiscData value, but so far I have not found anything. This value may be based on some other values, but I don't know what those are.

Nothing to do, same problem on August 2026

Problem not fixed on august cumolative update

Same here. I installed the August update after patching all my other systems, and it brought this problem back. Hopeully, I can still uninstall the August update to get it back to working. I did do some research trying to find a registry value that might be related, but ultimately there was no fix. I found some registry values that are blank on the problem systems and I tried putting data into those blank values but it didn't fix anything, and after rebooting the server the values went back to blank. So, this info probably comes from the BIOS itself, which I don't think we can change. Here are the registry values I looked at and tried adding data to the blank values:

Key: HKLM\HARDWARE\DESCRIPTION\System\BIOS

These string values are blank on the problem systems:

BaseBoardManufacturer

BIOSVendor

SystemManufacturer

SystemProductName

My previous comment about disabling telemetry was incorrect and does not provide a solution for this WSUS issue.

I have several servers and workstations that are not reporting. Depending on the machine, my approach was to check for blank values returned by msinfo32 and populate them using a compatible DMI editor for each device.

One of the last machines where I resolved this issue was an old Intel NUC that had the System SKU field blank in msinfo32. I wrote a value (I used the same value as the model), confirmed that it appeared correctly in msinfo32.exe, and everything looked fine — but the reporting status in WSUS still did not change.

This is where the actual fix happens. 😉

First, you need to remove/delete the affected machine from the WSUS console. Then, on the client, stop the Windows Update service, delete the C:\Windows\SoftwareDistribution folder, and start Windows Update again or manually check for updates. This clears what appears to be persistent metadata both on the WSUS server and on the client.

It is expected that Windows Update will return errors after these steps. You need to retry the update scan three or four times until the machine finally updates and starts reporting successfully again. This behavior occurs with the August 2026 update installed.

Good luck!

The client side script method exposes this is client side yet again.

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

Can someone explain what the theory is about what is going on here/ What I see is that if you update the server with the LCU, a bunch of clients that are sending blank values that shouldn't be blank start getting rejected and we can't track their status anymore. Removing the LCU restores the functionality (no change on client required). What does resetting all of this stuff on the clients, while waiting up to 48 hours to see if anything changed, do? I get that occasionally client configuration information gets corrupt and needs to be cleared out and reset, but this situation seems different. The client info isn't "corrupt", it just has blank values that the server doesn't like.

@Adam J. Marshall I try this method on july and doesn't work. Even after reinstalling the operating system, the issue persists.

As soon as I uninstall the LCU from the Windows Server 2022 server, the affected client starts working normally again.

This is why I don't believe the problem is related to client corruption or a bad client configuration. A clean OS installation does not resolve it, while removing the LCU immediately restores functionality.

From my testing, the issue appears to be directly related to the LCU and its interaction with these specific clients.

@William Fourqurean You're correct. Some clients are affected by this issue, and they all seem to be from the same manufacturer. In my case, they're ASUS devices.

I've checked and there are no BIOS updates available for them. I also tried completely reinstalling one of the affected clients, but the problem remained.

At the moment, I have a Windows Server 2022 system that I cannot patch because of this issue. The problem appears to be related to the interaction between the updated server and these specific clients rather than to client corruption or configuration problems.

Hey Marco, I forgot that you had totally rebuilt one of your systems. In my case, I have 14 servers that are affected. They are Dell servers, but they are OEM models that were rebranded, by our security vendor, Genetec. They have blanks in the BIOS for System Model Name and for System Manufacturer. I'm attaching a picture of one server that I updated the BIOS on yesterday. I even reset all BIOS settings to default, but there is no way to edit those two blank fields. I have one server that is also an OEM model from the same vendor, but is the newest one (all are several year old). The newest server does not have blanks in those fields in the BIOS, and the reporting works normally. I see no way to solve this problem from the client side.

My situation:

Virtual Server: Vmware and Hyper-V no problem

Hp server: no problem

Lenovo server no problem

Client Asus: Problem on all client (different type: notebook and classic pc)

Client Hp: no problem

Client Dell: no probelm

Any chance that we can get this discussion set back to unanswered? I don't know if Microsoft monitors these discussions, but I have seen no acknowledgement of this issue. If it is marked as answered when it is still unresolved, that may reduce our ability to get attention to the issue. I asked internally at my organization, and presently I have no way to open a support incident with Microsoft, as we don't have a support agreement. I guess there is always a possibility that the issue may be fixed in an upcoming cumulative update, but without an acknowledgement of this as an issue, I don't feel hopeful.

@William Fourqurean i remove the accepted answer.

The BIOS on the PC appears to be fine..

Thanks Marco! Yes I see from the picture and the log data that you sent before that the manufacturer and model information is not blank like it is on my systems. However, it seems like there is some other value that is blank that the server doesn't like. Without a way to reverse engineer the reporting process or change the validation of the data that is uploaded by the client, I think we are dependent on Microsoft to either fix this issue or tell us what their stand on the issue is. Granted, having blank values is not preferred but since it has been accepted for years and now is being rejected with no proposed workaround, that means that a small portion of our managed systems cannot be updated via WSUS anymore. I feel that WSUS is no longer a priority for Microsoft, as they are encouraging the community to migrate to other solutions. Thanks again!

That's not true. Microsoft fully supports WSUS until at least 2035.

Have you created a ticket with Microsoft for this issue?

If not create a ticket and let me know the ticket number. I can use my contacts to push it forward.

@Adam J. Marshall I do not have any type of support plan or subscription. Where can I open a support ticket with Microsoft?

Thanks

I'm pretty sure you have to pay for a single incident option and when Microsoft confirms that it is their issue with Windows updates they will not charge your card or they will refund you if they already have.

@William Fourqurean i found this post on reddit https://www.reddit.com/r/sysadmin/comments/1v39xra/wsus_rejects_reporting_events_during/

Microsoft is aware of the issue, and it should be resolved with the September patch.

I also would like to know how to contact Microsoft support to open an issue. We don't have a service contract, and I looked for how to open a support incident, and I could not find anything. I asked if I could contact Microsoft through our parent organization, but I never heard back, so I haven't been able to move forward with getting any help, other than through this user discussion.

Thanks for sharing that info Marco! There is a lot of information in that Reddit thread. Hopefully it will be fixed soon. I would be nice if Microsoft posted an acknowledgement of this issue somewhere.

https://www.google.com/search?client=firefox-b-m&q=microsoft%20support%20pay%20per%20incident#lfId=ChxjMe

There were three issued clients in my environment.

I’m writing to let you know that two of them have been fixed.

All three are Fujitsu models.

Two are Lifebook FMVU09003, and one is an ESPRIMO FMVK09001.

Assuming the issue is on the client side, I updated the Lifebook’s BIOS to the latest version. However, there was no change. But after deleting all the files in the SoftwareDistribution\EventCache.v2 ,

I was able to confirm that reports were being sent to the WSUS server.

I fixed my second Lifebook today.

Before Bios updated, 10.68.0.128 is version 1.10, and Not yet reported.

10.68.0.141 was fixed one several days before that I wrote.

After updated Bios, but not yet changed. I needed to clean up SoftwareDistribution folder by using Marshall's client script https://www.ajtek.ca/wsus/client-machines-not-reporting-to-wsus-properly/

The target 10.68.0.128 was fixed, But ESPRIMO is still in problem, that was updated the latest bios and cleared before. Need to another BIOS. I think ASUS and Fujitsu also need to fix this issue.

Since the OS version has been updated(1509.~), I believe there are no issue with my WSUS server. Well, I have just one to fix, or close to watch.

We are experiencing the same WSUS issue after applying the August updates. Currently, the only workaround is to uninstall the update. Are there any alternative solutions or recommended mitigation steps that do not require removing the update?.

Have you created a ticket with Microsoft for this issue?

If not create a ticket and let me know the ticket number. I can use my contacts to push it forward.

@William Fourqurean today i have install kb5122882 2026-09 Cumulative Update on wsus server and now Asus Client reported correctly!!