Azure Local 2601–2604 Known Issues: The MOC Ghost-Deletion Problem and Everything Else You Need to Fix Right Now

Picture this: you’re on a Tuesday morning, coffee in hand, and you get a Slack ping that a handful of Azure Local VMs are just… gone. Not stopped. Not paused. Gone. No one deleted them. No runbook ran. They just vanished because a platform component decided they didn’t belong anymore. That’s not a hypothetical — that’s the headline bug across the 2601 through 2604 release cycle, and it’s a doooooozy.

Microsoft’s Azure Local known issues page has been getting a steady stream of updates across the 2602, 2603, and 2604 releases. Let me break down what actually matters, what’s been fixed, and — most importantly — what you need to do right now if you’re running 2601 or later.

—

The Big One: Unintended VM Deletion via MOC Misclassification

This is the issue that spawned a platform-wide update block, so let’s talk about it plainly.

The 2604 release ships as build 12.2604.1003.1005. But if you’re still on 2601, 2602, or 2603, you’re sitting on a live grenade. The Remediation Support Tool resolves a wide range of Azure Local VM issues automatically by updating infrastructure components such as Microsoft On-Premises Cloud (MOC) to the latest patch release.

The MOC component — the on-premises cloud management layer that handles VM lifecycle — can incorrectly classify running VMs during routine system operations and trigger deletion. This isn’t a fringe edge case. Microsoft took the unusual step of blocking all solution updates on 2601 and later until the fix was in place.

The Remediation Support Tool helps identify and remediate common issues with Azure Local infrastructure components, and also identifies and attempts to fix common problems that occur during the solution update. Running it before you do anything else is the right call.

—

Step-by-Step: Patching MOC Before You Do Anything Else

This is the order of operations I’d follow on any affected cluster. Don’t skip steps.

Step 1: Open a Remote PowerShell Session to a Node

Run PowerShell as an administrator on the client you use to connect to your system, open a remote PowerShell session to a machine on your Azure Local instance, and run the following command — providing credentials for your machine when prompted:

# Prompt for your deployment user credentials (the account used during AD prep)
$cred = Get-Credential

# Connect to one of your Azure Local nodes
Enter-PSSession -ComputerName "<Azure Local node IP>" -Credential $cred

Sign in using your deployment user account credentials — the account you created when preparing Active Directory and used to deploy Azure Local. (Also, you can login using your domain admin credentials). 

Step 2: Run the Remediation Support Tool

Before you open a support request, run the Support tool. It resolves a wide range of Azure Local VM issues automatically by updating infrastructure components such as MOC to the latest patch release, resulting in a faster resolution without having to file a support ticket.

The tool will run a battery of diagnostic checks. Here’s what a healthy output looks like (and what to watch for):

# What you WANT to see:
Validate MOC is on Latest Patch Version        Passed   MOC is on the latest patch version.
Validate MOC Cloud Agent Running               Passed   MOC Cloud Agent is running
Validate Missing MOC Node Agents               Passed   All MOC nodes have the Node Agent service installed and healthy.
Validate Missing MOC Host Agents               Passed   All nodes have MOC host agents installed and healthy.

# What you DON'T want to see:
Validate MOC is on Latest Patch Version        Failed   MOC is not on the latest patch version.

If problems persist after running the tool, raise a support ticket. Don’t try to hero your way through a stale MOC version manually.

Step 3: Verify wssdagent Is Running on All Nodes

While you’re in there, check the node agent. This one has bitten people independently of the MOC issue:

# Check wssdagent status across all cluster nodes
$ServerList = (Get-ClusterNode).name

foreach ($Server in $ServerList) {
    Write-Output "Cluster Node: $Server..."
    Invoke-Command -ComputerName $Server -ScriptBlock {
        Get-Service wssdagent
    }
}

If any node shows Stopped, restart it from that node:

# Run this ON the affected node, not remotely
Start-Service wssdagent

If VMs were deleted while the agent was down, that’s a support case — don’t try to recover those yourself.

—

What Got Fixed in 2604

The 2604 release has a solid list of fixes worth knowing about. Here are the ones I’d actually care about in production:

VM Connect cross-resource-group support — Previously, VM Connect couldn’t reach Azure Local VMs if they were deployed in a different resource group than the Azure Local instance itself. That’s now fixed. This was a real operational headache for shops that organize resources by workload rather than by infrastructure layer.

Gallery image timeouts — Large gallery images were timing out or taking forever during create/update operations. The logic has been optimized, so if you’ve been babysitting image uploads, that should be better now.

Storage path precheck logic — When you create a VM without specifying a storage path, the precheck was incorrectly targeting the infrastructure volume. That’s now fixed to correctly resolve a customer storage path. This one matters — accidentally writing workload data to the infrastructure volume is the kind of thing that quietly causes you pain weeks later.

CAU retry failures — The CAU run was failing with EvalCauRetryApplicability errors when a previous run had been canceled. Fixed.

SBE pre-deployment health checks — SBE health checks weren’t executing when SBE version was 5.0 or higher. Fixed.

Repair-Server / Add-Server Cluster Build ID mismatch — The Add-Server and Repair-Server cmdlets were failing with a “Cluster Build ID matches node to add’s Build ID” error. Fixed in 2604.

—

Still Open: Issues You Need to Work Around Manually

The az stack-hci-vm stop CLI Bug

If you’re running CLI version 1.14.x against clusters on versions prior to 2604, az stack-hci-vm stop will fail. Your options:

# Option 1: Force stop with the --skip-shutdown flag (use with care in prod)
az stack-hci-vm stop --name <vm-name> \
  --resource-group <rg-name> \
  --skip-shutdown

# Option 2: Downgrade CLI to 1.13.0 or earlier if graceful shutdown matters
az extension update --name stack-hci-vm --version 1.13.0

Portal Reporting Wrong Update Status

The Azure portal occasionally shows “Failed to update” or “In progress” even when the update completed successfully. Before you panic, verify via PowerShell:

# Replace the version string with your actual version, e.g. "10.2405.0.23"
$Update = Get-SolutionUpdate | Where-Object { $_.Version -eq "<version string>" }

# Check the state — if it says 'Installed', you're done
$Update.State

If the state is Installed, the portal will catch up within 24 hours. If you need it sooner, bounce the Cloud Management cluster group:

# Restart Cloud Management cluster group to force portal status refresh
Stop-ClusterGroup "Cloud Management"
Start-ClusterGroup "Cloud Management"

mochostagent Going Silent

The mochostagent service can appear to be running but stop updating its logs for over a month. Check the logs at C:\programdata\mochostagent\logs — if nothing recent is there, restart it:

# Quick fix for a zombie mochostagent
Restart-Service mochostagent

Windows Admin Center Volume Deletion Bug

If you’re running Cluster Manager below version 5.2.6 in WAC, do not delete volumes through the portal. You risk data loss. Update the Cluster Manager extension to 5.2.6 or use Windows Admin Center version 2511 build 2.6.6.18 or higher before touching volume operations.

Windows Defender ASR Rule Blocking Updates

If you have the “Block Process Creations originating from PSExec & WMI commands” ASR rule set to Block, solution updates will fail to run. You’ll need to set it to Audit or Disabled for the duration of the update, then re-enable it. Check the Azure Local update troubleshooting guide for the full remediation steps.

—

A Note on the Update Block

Starting with Azure Local 2604, quality updates are available prior to the cumulative update to stay compliant and remove partner dependencies. That’s a process change worth noting — the update cadence is shifting slightly.

To keep your Azure Local solution in a supported state, you have up to six months to install updates. Versions not updated within six months are no longer supported, and running an unsupported version may expose your environment to security vulnerabilities, compliance issues, or regulatory requirements. Six months sounds generous until it isn’t — I’ve seen shops get caught flat-footed on this.

Also worth flagging: Azure Stack HCI version 23H2 OS will reach end of support in April 2026, and each Azure Local release is supported for six months whether you’re on 23H2 or 24H2 — with October 2025 (version 11.2510) being the final 23H2 release. If you’re still on a 23H2 build and haven’t moved to 24H2, that clock is done ticking.

—

What to Watch Next

• Run the Remediation Support Tool on any cluster running 2601 or later — do it before your next update attempt, not after.
• Check your WAC Cluster Manager version before anyone touches volume management.
• Validate your Defender ASR rules if solution updates are mysteriously failing.
• For detailed per-issue remediation scripts beyond what’s here, the Azure Local Supportability GitHub repository is worth bookmarking — it’s Microsoft’s own resource for detailed remediation of common known issues.