Azure Local solution updates blocked by malformed EnvironmentReadiness Timestamp

Hi Juhani Harju & thx for join me at Q&A platform,

an EnvironmentReadiness / Update Service serialization issue, rather than an actual cluster health or time synchronization problem.

The important clue is the timestamp format: 2026-10-15T09.58.03.629Z. The date and UTC suffix are valid, but the time portion uses periods instead of colons. Newtonsoft.Json then fails to deserialize the result, which prevents Get-SolutionUpdateEnvironment from displaying the actual readiness checks.

There's an interesting .NET detail here. When formatting a DateTime, the : character in a custom format string can act as a culture-dependent time separator. Depending on the effective culture, something like HH:mm:ss can produce 09.58.03 instead of 09:58:03. That matches the malformed value you're seeing.

It doesn't prove that's the bug, tho. You've already changed the SYSTEM culture to en-US and reproduced the issue after restarting all nodes. But the component generating the JSON might be using a different execution context, an explicitly selected culture, or its own formatting logic.

The fact that the HPE SBE and Microsoft EnvironmentReadiness objects contain valid UTC System.DateTime values is particularly useful. It suggests the issue occurs during serialization or at another processing boundary, rather than when the original health checks generate their timestamps.

At this point, I wouldn't spend more time changing regional settings or restarting nodes. You've already done enough testing to rule out the usual configuration issues.

What Microsoft engineering needs to identify is which component first converts the valid DateTime into the malformed string. I'd ask them to inspect the raw readiness payload at the EnvironmentReadiness-to-Update Service boundary, confirm the runtime culture used by the serializer, and check whether the affected component uses a culture-sensitive timestamp format instead of an invariant ISO 8601 format.

A proper fix should serialize these values consistently, for example using the invariant round-trip O format, rather than relying on machine or process culture.

I agree this needs escalation to the Azure Local Update Service / EnvironmentReadiness engineering team. The changing result indexes, fresh reproductions, and successful validation of the original HPE timestamps make a strong case for a product-side defect.

I wouldn't recommend manually modifying readiness JSON, bypassing the health checks, or forcing a solution update on a production cluster. Those aren't supported fixes and could hide genuine readiness failures.

One thing worth including in the existing support case is the exact component responsible for producing the malformed JSON, if Microsoft can identify it from the diagnostic logs, along with the EnvironmentChecker and LcmUpdateService versions you've provided. That should help engineering determine whether this is a known serialization regression in the 2609 update stack.

Given how thoroughly you've isolated the issue, the next useful response really needs to come from Microsoft engineering a confirmed root cause, supported workaround, or hotfix.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

Hello Juhani Harju

Kindly please change the timestamp assignment in MemoryResourceSummaryHelper.psm1 to $resultObject.TimeStamp = Get-Now, replacing the current Get-Date -Format expression. The file is in the active Microsoft.EnvironmentReadiness.Validator module under %ProgramFiles%\WindowsPowerShell\Modules\Microsoft.EnvironmentReadiness.Validator. This keeps the memory check enabled while using the shared timestamp helper instead of the culture-sensitive formatter.

Then rerun Invoke-SolutionUpdatePrecheck -SystemHealth and share the full output so we can confirm whether the timestamp parsing error has cleared.

Will this change be included in a future Microsoft.EnvironmentReadiness.Validator release, and should we keep the workaround in place until then?

Yes, this will come in future environment readiness release. You need to keep the existing workaround in place as per our previous instructions