WSUS Server 2022 rejects Event 156 reporting when MiscData g= contains pipe-separated GUIDs

Question

I am troubleshooting a WSUS reporting issue where clients can successfully scan for and install updates, but WSUS does not update their reported installation status.

The issue has now been traced to the WSUS Reporting Web Service rejecting Event 156 (AGENT_STATUS_30) events when the lowercase g= field in MiscData contains multiple GUIDs separated by pipe (|) characters.

Environment

WSUS running on Windows Server 2022 Standard
WSUS server OS build: 20348.5622
Clients include Windows Server 2016, Windows Server 2022, and other Windows versions
WSUS is using HTTP/8530
The originally investigated client is Windows Server 2016

Symptoms

The affected client successfully contacts WSUS and performs an online Windows Update COM scan explicitly against the managed WSUS server.

The scan correctly reports recently installed cumulative updates as:

IsInstalled=True
RebootRequired=False

However:

WSUS continues to show those updates as Not Installed.
LastSyncTime advances.
LastReportedStatusTime does not advance.
IIS records successful HTTP POST requests to:

/ReportingWebService/ReportingWebService.asmx

Packet capture result

I captured an affected reporting transaction from the client.

The POST reaches the WSUS server successfully. The HTTP response is:

HTTP/1.1 200 OK

but the SOAP response contains:

false

Therefore, HTTP 200 only confirms that the web request itself completed. The WSUS ReportEventBatch operation is reporting failure.

The client request contains an Event 156 with a MiscData field resembling:

g=AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA|BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB

Some affected clients send three GUIDs:

g=AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA|BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB|CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC

Corresponding WSUS server failure

At the same time as the captured failed reporting request, SoftwareDistribution.log on the WSUS server records:

ReportingEvent.ValidateMiscData
Exception occurred while parsing MiscData for event
 
System.ArgumentException:
Error occurred while parsing MiscData for event.
 
MiscData element
g=AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA|BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB
 
System.FormatException:
Guid should contain 32 digits with 4 dashes
(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

The relevant stack is:

System.Guid..ctor(String g)
 
Microsoft.UpdateServices.Internal.Reporting.MiscDataParser.ParseGuidArrayString(String guidArrayString)
 
Microsoft.UpdateServices.Internal.Reporting.MiscDataParser.ParseEventMiscData(ReportingEvent e)
 
Microsoft.UpdateServices.Internal.Reporting.ReportingEvent.ValidateMiscData()
 
Microsoft.UpdateServices.Internal.Reporting.ReportingEvent.Validate()
 
Microsoft.UpdateServices.Internal.Reporting.WebService.ValidateEventBatch(ReportingEvent[] eventBatch)
 
Microsoft.UpdateServices.Internal.Reporting.WebService.ReportEventBatch(...)

It is then followed by:

WebService.ValidateEventBatch
Event in batch failed to validate.

The failed events are:

EventId=[156]
SourceId=[101]

This affects multiple clients

This is not isolated to the original Windows Server 2016 client.

After examining the WSUS server log, I found the same ParseGuidArrayString / System.Guid failure associated with multiple systems and different pipe-separated GUID values.

Examples include clients reporting OS versions corresponding to:

10.0.14393.x
10.0.20348.x
10.0.26200.x

and multiple hardware/VM platforms.

At the same time, many other reporting events are logged as:

ReportingEvent.ValidateMiscData
Successfully parsed MiscData

This appears to specifically affect events where lowercase g= contains multiple pipe-separated GUIDs.

Server reboot/servicing ruled out

The WSUS server initially had pending Windows servicing and had not recently rebooted.

Before continuing troubleshooting, I rebooted the server and allowed pending servicing to complete.

The problem reproduced immediately after reboot.

A new packet capture again showed:

false

and the WSUS server generated fresh ValidateMiscData exceptions for pipe-separated g= values.

Therefore, a pending reboot was not sufficient to explain or correct the issue.

Troubleshooting already performed

The following have been verified:

Client is configured for the correct WSUS server.
Client and WSUS computer IDs match.
Managed-server scans succeed.
Installed updates are correctly detected locally.
No reboot is required on the originally investigated client.
Full-state Windows Update scans have been performed.
/reportnow does not cause LastReportedStatusTime to advance.
Reporting POSTs reach IIS.
Reporting POSTs receive HTTP 200.
SOAP ReportEventBatchResult is false.
Client datastore / WSUS identity resets were previously tested without resolving the issue.
WSUS server has been rebooted after pending servicing.
The parsing failure continues after the reboot.
The same server-side exception affects multiple clients.

Question

Is this a known WSUS/Windows Update Agent compatibility issue?

Specifically:

What is the expected delimiter for multiple GUIDs in the lowercase Event 156 MiscData g= value?
Is g=GUID|GUID a valid Windows Update Agent reporting format?
If so, why does Microsoft.UpdateServices.Internal.Reporting.MiscDataParser.ParseGuidArrayString() appear to pass the pipe-separated value to the .NET single-GUID parser?
Is there a supported Windows Server 2022/WSUS servicing update that addresses this behavior?
Is there a Microsoft-supported diagnostic or remediation path that does not involve modifying WSUS binaries, SUSDB, or client reporting payloads?

I am specifically looking for a supported fix or confirmation of a known compatibility issue. I would prefer not to perform speculative security-update rollbacks, WSUS database modifications, DLL replacement, payload modification, or additional client identity/datastore resets.

Answer

Dear Caleb,

Thank you for posting your question to the Microsoft community and for providing the detailed troubleshooting results, including the SOAP response, server-side exception, and reproduction across multiple clients.

Based on the evidence you provided, this appears to be a server-side WSUS reporting validation failure, rather than a client scanning, update installation, or connectivity issue.

The most significant findings are:

The Reporting Web Service receives the request and returns HTTP 200, but ReportEventBatchResult is false.

ReportingEvent.ValidateMiscData() fails while processing Event 156 (AGENT_STATUS_30).

The exception occurs in MiscDataParser.ParseGuidArrayString(), followed by System.Guid..ctor(String g).

The failure occurs across multiple Windows versions and persists after the WSUS server reboot.

These results strongly suggest that the reporting service cannot parse the supplied g= value. However, they do not establish whether the client is generating an unsupported format or the WSUS server is incorrectly handling a valid format.

Regarding your specific questions:

Is g=GUID|GUID a supported reporting format?

I could not verify a publicly documented Microsoft specification defining the expected delimiter or serialization format for the lowercase g= field in Event 156 MiscData.

The internal method name ParseGuidArrayString() suggests that the field may represent multiple GUIDs, but it does not establish which delimiter is supported.

The exception indicates that a value containing pipe-separated GUIDs reaches GUID parsing without being successfully converted into individual GUID values. This is consistent with a parsing incompatibility, but confirming whether the client format or server implementation is responsible would require Microsoft to review the internal reporting contract.

Is this a known WSUS compatibility issue?

I could not verify a published Microsoft known issue specifically matching Event 156, pipe-separated GUIDs, and ParseGuidArrayString() failures.

Microsoft has documented a separate WSUS issue affecting the display of synchronization error details after KB5070884 and later updates. However, that issue does not establish a connection to the Event 156 reporting failure you described.

You can review the official information here:

Windows Server 2022 release health

October 13, 2026 — KB5126655 (OS Build 20348.5761)

Is there a supported servicing update or workaround?

Your reported build, 20348.5622, corresponds to the September 8, 2026 cumulative update, KB5122882.

Microsoft released KB5126655 on October 13, 2026, bringing Windows Server 2022 to build 20348.5761.

Although updating to the latest applicable cumulative update is a reasonable servicing step, I could not verify that KB5126655 specifically fixes this reporting parser behavior. Therefore, I would not describe it as a confirmed remediation.

Before applying it, review the update prerequisites and known issues, and follow your organization's normal change-management process.

Recommended next steps

Given the troubleshooting you have already completed, I would not recommend additional WSUS identity resets, client datastore resets, or repeated /reportnow commands. Those actions are unlikely to provide new diagnostic information about the server-side parsing exception.

Instead, I recommend the following:

Preserve the original request and SOAP response demonstrating ReportEventBatchResult=false, including the Event 156 payload.

Preserve the corresponding timestamped SoftwareDistribution.log entries showing ValidateMiscData() and ParseGuidArrayString() failures.

Record the WSUS server build, installed cumulative updates, and affected client OS builds.

If possible, identify whether the same reporting batch succeeds when Event 156 does not contain multiple GUIDs. This would help isolate the formatting-dependent failure without modifying any reporting payloads.

Open a Microsoft Support case through your organization's applicable support agreement and request investigation of the WSUS Reporting Web Service's Event 156 MiscData validation.

The support request should specifically ask Microsoft to confirm:

The expected serialization format for multiple GUIDs in the Event 156 lowercase g= field.

Whether pipe-separated GUIDs are valid Windows Update Agent output.

Whether the observed behavior represents a WSUS parser defect or a client reporting incompatibility.

Whether a supported cumulative update, hotfix, or other remediation is available.

Microsoft Support can review the relevant internal component behavior and determine whether further product investigation is required. Please provide packet captures and detailed logs privately rather than posting unredacted diagnostic data in the public forum.

For reference, Microsoft confirms that WSUS is deprecated but remains supported for production deployments, including security and quality updates within the applicable product lifecycle:

Windows Server Update Services overview

Based on the evidence presented, the strongest working hypothesis is a compatibility or validation problem between the Windows Update Agent reporting payload and the WSUS server parser. The available information does not yet establish which component is responsible.

Since you have reproduced the issue across multiple clients and correlated the failed SOAP response with the server-side exception, I believe the next productive step is Microsoft product-level investigation rather than additional generic WSUS troubleshooting.

If this helped, I'd appreciate a Like so others can find the answer more easily. If it resolved the issue, please mark it as an Accepted Answer.

Best regards.