Home / Azure Local

News | Azure Local Urgent Heads-Up

News | Azure Local Urgent Heads-Up


Reading Time: 3 minutes

Azure Local moves fast, and most of the time that is a good thing. Every few weeks there is a new release, a new feature, a new way to make life on-prem feel a bit more like Azure. But once in a while the news isn’t a shiny new capability, it’s a “stop what you are doing and check your clusters” moment.

TL;DR

  1. On Azure Local2601 to 2604, a platform component can misclassify VMs during routine operations anddelete them unintentionally. Update the MOC component via the Remediation Support Tool.
  2. IMDS-based attestationis failing in the field. Windows VMs activated through IMDS are flipping to“not activated”. No official statement yet, AVMA isnota reliable workaround, and the fix is realistically expected in theJuly 2026guest OS update.

Issue 1: Potential unintended VM deletion on 2601 and later

If your Azure Local instance is running 2601, 2602, 2603, or 2604, this one is for you.

A platform component can misclassify virtual machines during routine operations and end up deleting them unintentionally. That is exactly the kind of sentence you don’t want to read on a Friday afternoon. Microsoft has confirmed the issue and blocked further updates on the affected versions while the fix rolls out as a managed component update.

What you should do

  • Don’t wait for the next solution update.The fix ships as a managed component update, so you need to push it manually.
  • Run the Remediation Support Toolto update theMOCcomponent. This is the standard tool you already use for known-issue mitigations on Azure Local.
  • Verifythe MOC component version after the run, and confirm your instance is no longer on the affected build profile.
  • Pause non-essential VM lifecycle operationsuntil the MOC component is patched. The misclassification happens during routine operations, so the less churn you create in the meantime, the better.

The official write-up, the affected builds, and the remediation steps live in the Microsoft Learn release notes:

Release notes with fixed and known issues in Azure Local, Microsoft Learn(opens in new window)

If you manage multiple Azure Local instances (customers, sites, regions), this is worth turning into a quick inventory exercise: which clusters are on 2601 and above, which already have the MOC update applied, and which still need attention. The Azure Local Documenter comes in place here; https://www.gettothe.cloud/tool-azure-local-documenter/


Issue 2: IMDS attestation failures, VMs reporting as “not activated”

The second issue is more subtle, and there is no official statement on it yet, but it is showing up in the field often enough that it deserves a heads-up.

IMDS-based attestation can fail, and when it does, the Windows VMs that rely on it for activation flip to “not activated”. For anyone running Windows workloads on Azure Local with IMDS activation, that is a noisy and customer-visible problem.

A few things worth knowing:

  • AVMA is not a reliable workaround.It canappearto fix the activation status, but it doesn’t hold. Don’t bake AVMA into your runbook as a permanent answer, you’ll be back to “not activated” before you know it.
  • Open a support caseif you’re seeing it. Until Microsoft publishes a KB, support cases are how this gets prioritised and tracked.
  • The fix is expected in a future guest OS update.Realistically,July 2026 Patch Tuesdayis the earliest plausible ship date.

What you should do

  • Check your fleet for VMs in a“not activated”state on Azure Local, especially anything that recently went through a host update or a live migration cycle.
  • If you find affected VMs,open a support caseand reference IMDS attestation failure. The more data points Microsoft has, the better.
  • Don’t switch your activation strategy to AVMA in a panic.It is not a fix.
  • Plan your guest OS update cadence so you can absorb the July 2026 cumulative update quickly once it lands.

Why this matters

Azure Local sits at a very specific intersection: it’s an Azure service, but the failure modes are on your hardware, in your datacenter, and the blast radius is your VMs. A “platform component misclassifies VMs” headline in pure Azure is a Service Health blip. The same headline on Azure Local is a potentially lost workload.

The official channels will catch up (Microsoft Learn release notes already have Issue 1 documented, and Issue 2 will surface in a KB eventually), but in the meantime the LinkedIn and community grapevine is doing real work.

If you’re running Azure Local in production, this is the time to:

  1. Patch MOCvia the Remediation Support Tool on every 2601 and later cluster.
  2. Audit activation statusof your IMDS-activated Windows VMs.

Stay safe out there.

Share and Enjoy !

Shares

Designer (23)

Stay close to the action—follow GetToThe.Cloud across social!
Deep dives and hands‑on how‑tos on Azure Local, hybrid cloud, automation, PowerShell/Bicep, AVD + FSLogix, image pipelines, monitoring, networking, and resilient design when the internet/Azure is down.

🔗 Our channels
▶️ YouTube: https://www.youtube.com/channel/UCa33PgGdXt-Dr4w3Ub9hrdQ
💼 LinkedIn Group: https://www.linkedin.com/groups/9181126/
✖️ X (Twitter): https://x.com/Gettothecloud
🎵 TikTok: https://www.tiktok.com/@gettothecloud
🐙 GitHub: https://github.com/GetToThe-Cloud/Website
💬 Slack: DM us for an invite
📲 WhatsApp: DM for the community link

We use cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners. View more
Cookies settings
Accept
Privacy & Cookie policy
Privacy & Cookies policy
Cookie name Active

Who we are

Our website address is: https://www.gettothe.cloud

Comments

When visitors leave comments on the site we collect the data shown in the comments form, and also the visitor’s IP address and browser user agent string to help spam detection.An anonymized string created from your email address (also called a hash) may be provided to the Gravatar service to see if you are using it. The Gravatar service privacy policy is available here: https://automattic.com/privacy/. After approval of your comment, your profile picture is visible to the public in the context of your comment.

Media

If you upload images to the website, you should avoid uploading images with embedded location data (EXIF GPS) included. Visitors to the website can download and extract any location data from images on the website.

Cookies

If you leave a comment on our site you may opt-in to saving your name, email address and website in cookies. These are for your convenience so that you do not have to fill in your details again when you leave another comment. These cookies will last for one year.If you visit our login page, we will set a temporary cookie to determine if your browser accepts cookies. This cookie contains no personal data and is discarded when you close your browser.When you log in, we will also set up several cookies to save your login information and your screen display choices. Login cookies last for two days, and screen options cookies last for a year. If you select "Remember Me", your login will persist for two weeks. If you log out of your account, the login cookies will be removed.If you edit or publish an article, an additional cookie will be saved in your browser. This cookie includes no personal data and simply indicates the post ID of the article you just edited. It expires after 1 day.

Embedded content from other websites

Articles on this site may include embedded content (e.g. videos, images, articles, etc.). Embedded content from other websites behaves in the exact same way as if the visitor has visited the other website.These websites may collect data about you, use cookies, embed additional third-party tracking, and monitor your interaction with that embedded content, including tracking your interaction with the embedded content if you have an account and are logged in to that website.

Who we share your data with

If you request a password reset, your IP address will be included in the reset email.

How long we retain your data

If you leave a comment, the comment and its metadata are retained indefinitely. This is so we can recognize and approve any follow-up comments automatically instead of holding them in a moderation queue.For users that register on our website (if any), we also store the personal information they provide in their user profile. All users can see, edit, or delete their personal information at any time (except they cannot change their username). Website administrators can also see and edit that information.

What rights you have over your data

If you have an account on this site, or have left comments, you can request to receive an exported file of the personal data we hold about you, including any data you have provided to us. You can also request that we erase any personal data we hold about you. This does not include any data we are obliged to keep for administrative, legal, or security purposes.

Where we send your data

Visitor comments may be checked through an automated spam detection service.
Save settings
Cookies settings