Azure Local VMs Just… Vanished — And Here’s the Whole Messy Story

 

Azure Local VMs Just… Vanished — And Here’s the Whole Messy Story

Picture this: you’re minding your own business on a random weekday, maybe halfway through your second coffee, when someone pings you saying a handful of Azure Local VMs are gone. Not powered off. Not migrated. Gone. No warning. No change ticket. Nothing in the activity log that makes immediate sense. That was the reality for a number of Azure Local customers earlier this year, and it’s a story worth unpacking — because the fix, the rollout pause, and the update path that followed are all tangled together in ways that’ll affect your patching strategy for the rest of 2026.

Let me walk through what happened, what the remediation looked like, and what your update path should actually be right now.

—

The Scenario: Unintended VM Deletion

To keep your Azure Local solution in a supported state, you have up to six months to install updates — but before installing a feature update, you must install the last released cumulative update first. Most of us know this drill. What we didn’t expect was that the update machinery itself could be the thing deleting our VMs.

Microsoft confirmed an issue that could cause unintended Azure Local VM deletion. This isn’t a user error story. This is a platform-side bug that hit clusters during or around solution updates, and it’s about as bad as it sounds. If you’ve been in the HCI/Azure Local space long enough, you know that the Azure Arc resource bridge and its appliance virtual machine are treated as core, tightly integrated components of the Azure Local platform. When something goes sideways with that layer, the blast radius is significant.

What made it worse: Azure Arc resource bridge is a critical, tightly integrated component and must not be deleted or redeployed without direct guidance from Microsoft. The documented self-service recovery and redeployment procedures in the public docs apply to Arc-enabled VMware and Arc-enabled SCVMM, not to Azure Local. So if you were frantically Googling “how to recover Arc resource bridge” and following the vSphere disaster recovery docs, you were in the wrong place entirely. I’ve seen that exact confusion play out in the field.

—

What Microsoft Did About It

Microsoft’s response came in layers, which is actually the right call for something this serious. According to the Azure Local release information page, the remediation went like this:

1. Manual remediation guidance was shared with affected clusters first — the “here’s how to dig yourself out” step.
2. A newly released Telemetry & Diagnostics Arc extension was pushed as a managed update and automatically remediated the majority of remaining affected clusters.
3. Hotfixes for versions 2603 and 2604 were released, adding a second layer of automated remediation baked directly into the update path.

That third point is the one I’d pay the most attention to. It means the fix isn’t just a one-time patch you apply and forget — it’s embedded in the update stream going forward, so clusters that update into 2603 or 2604 get the remediation automatically.

The Telemetry and Diagnostics Arc extension, shown as AzureEdgeTelemetryAndDiagnostics in the Azure portal, enables the collection of telemetry and diagnostics information from your Azure Local instance. In this case, it did double duty as the delivery vehicle for automated cluster remediation. That’s a creative use of the extension framework, even if the circumstances that required it were not great.

—

The Update Pause and What Got Unblocked

While all this was being sorted out, Microsoft put a hold on Solution and SBE (Solution Builder Extension) updates. That’s the right call — you don’t keep shipping updates when you know there’s a deletion bug in the stack. Once the hotfixes landed and the Telemetry extension had done its remediation sweep, the block was lifted.

Here’s the current state of play on update targets:

• Versions 2601 and 2602 are no longer available as update targets. If you’re already on one of them, you’re fine and fully supported — you just can’t use them as a stepping stone for new deployments or fresh update paths.
• If you’re on 2510–2512, 2601, or 2602: discover and apply solution version 12.2603.1002.502 or later.
• If you’re on 2603: discover and apply 12.2604.1003.1006 or later.
• If you’re on 2604: apply 12.2605.1003.210.

The latest build as of this writing is 12.2605.1003.210, availability date 2026-05-28, running OS build 26100.32860 with the May OS security update baked in.

—

Understanding the Two-Track Update Model

This is where I see the most confusion in the field, so let me spell it out clearly. Starting with release 2504, Microsoft releases two Azure Local solution versions each month, each aligned to a specific OS build. All future updates for a solution version continue to use its associated OS build.

In plain English, that means:

| Solution version prefix | OS build | When to use | |—|—|—| | 10.2xxx / 11.25xx | 25398.xxxx (23H2) | Legacy path — update through each feature/cumulative build | | 12.25xx / 12.26xx | 26100.xxxx (24H2) | Current path — install subsequent releases directly |

If you’re still on the 11.x train, you’re on 23H2. And that’s a problem you need to solve now.

—

23H2 Is Done. Seriously.

I’ll be blunt here: Azure Stack HCI, version 23H2 OS (OS version 25398.xxxx) reached end of support in April 2026. Each Azure Local release is supported for six months, whether you’re on 23H2 (11.x.x.x) or 24H2 (12.x.x.x).

October 2025 (version 11.2510) is the final 23H2 release. Support for the 23H2 OS without the Azure Local solution is available until April 2026. After April 2026, you won’t receive monthly security and quality updates for 23H2. Support requests are only available for patching to a supported release.

So if you’re still sitting on a 23H2 cluster and haven’t moved, you’re now in unsupported territory. Versions not updated within six months are no longer supported. Running an unsupported version may expose your environment to security vulnerabilities, compliance issues, or regulatory requirements associated with using an unsupported version. Microsoft doesn’t guarantee or provide remediation for risks resulting from the continued use of unsupported versions.

Starting with 2602, the Azure portal displays an “End of Support at the end of April” banner for devices running OS version 25398.xxxx (23H2). If you’re seeing that banner and you haven’t acted on it yet — that’s your sign.

The upgrade path from 23H2 to 24H2 involves going through the 11.2510 release first. Before you can update to the 2511 release, you must first apply the 12.2510 update. The 12.2510 (24H2) update becomes automatically available once you apply 11.2510.

Here’s a quick PowerShell snippet for checking your current solution version before you plan anything:

# Run on any node in the cluster
# This gets the current solution version from the LCM (Lifecycle Manager)
Get-SolutionUpdate | Select-Object DisplayName, Version, State

# Also worth checking the OS build to confirm which track you're on
Get-ComputerInfo | Select-Object OsName, OsBuildNumber, WindowsVersion

If OsBuildNumber starts with 25398, you’re on 23H2. If it starts with 26100, you’re on 24H2. Simple as that.

—

The Arc Resource Bridge Certificate Clock Is Ticking

One thing that gets buried in the release notes but absolutely cannot be ignored: Azure Arc resource bridge requires solution updates to be applied within one year. This requirement is critical to keep certificates valid and the Azure Local VM functionality working.

This is separate from the six-month support window. You can be on a “supported” version and still have your Arc resource bridge certificates expire if you haven’t applied a solution update in over a year. When that happens, the ability to manage VMs from Azure is lost, but workloads continue to run locally. The documented path is to redeploy the Arc resource bridge with assistance from Microsoft Support.

That’s a support ticket you really don’t want to open. Keep your solution updates current.

—

Feature Release Timing: Don’t Blame Microsoft

One thing worth knowing if you’re waiting on a feature release and it hasn’t shown up: feature release availability dates depend on the model and stock-keeping unit (SKU) of the servers in your cluster. If your hardware uses Solution Builder Extension (SBE) updates, your OEM has to validate the release before it shows up in your update feed. That validation process takes a few weeks after the Microsoft release date and varies by vendor.

So if 2605 dropped on May 28 and you’re not seeing it yet — check with your OEM before filing a support ticket. It’s probably just sitting in their validation queue.

—

What to Watch Next

• Get off 23H2 immediately if you haven’t. There’s no more runway.
• Apply 12.2605.1003.210 if you’re on 2604 — it’s the current target and includes the second-layer VM deletion remediation.
• Check your Arc resource bridge certificate age. If you’ve been coasting on an older solution version, that one-year clock may be closer than you think.
• Watch for SBE updates from your OEM — with Solution updates unblocked, the hardware vendors should be pushing their validated builds through shortly.
• The release information page is your source of truth here. Bookmark it. Check it monthly.