Azure Local: 10 mistakes that can derail your deployment before it starts

Over the past few years, starting back when it was still called Azure Stack HCI, I've spent most of my time on Azure Local: scoping calls, design reviews, workshops, assessments and more escalations than I'd like to count. When I look back at the projects that went sideways, very few started with a product defect. They started with a decision made too early, too late, or without the right people in the room. 

This post is for the people who design, deploy and run Azure Local: architects, partners and platform teams. For each mistake I cover what we see in the field, what's going on under the hood, and what to check instead, with the commands and settings I look at during reviews. 

Three ground rules. The customer stories are real but anonymized. Prices are list prices at the time of writing. And Azure Local changes every month, so treat the Microsoft Learn pages listed at the end as the source of truth. Where a behavior changed in a specific release, I say which one. One more note on vocabulary: the documentation now says "machines", while most of us in the field still say "nodes". I use both.

The ten mistakes at a glance 

The mistakes follow the order a project meets them: Plan, before the purchase order; Design, where some choices can't be undone; and Operate, life after Day 1. 

 

Figure 1. The ten mistakes across the project lifecycle. The later one is found, the more it costs to fix.

 Why early mistakes get expensive fast 

Licensing is an equation, not a default 

Azure Local is billed per physical core, per month, through your Azure subscription. The storage design decides which meter you pay: 

If your hardware ships with an OEM Azure Local license, read the footnotes on the pricing page: it lists a separate rate of $10 per core per month for OEM-licensed instances with external storage attached. 

So L1 looks like the obvious winner, until you price the disks. Here's a simplified example I use with customers. A team starts on Storage Spaces Direct, then realizes two months in that a SAN fits their estate better. 

I've seen customers move from L1 to L2 and pay less overall, with better storage efficiency, and I've seen the opposite. It's an equation each customer has to solve before the purchase order, especially when a VMware renewal has already made cost the headline. And because the fee is per physical core, the CPU choice is a licensing decision too: cores the workloads don't need are a monthly cost, not a one-time one. 

Two billing details catch people out. New registrations get a 60-day free trial, so the meter starts later than the deployment. And retiring an instance is a billing event too: if you stop using it without deleting its Azure resource, billing continues until it has been disconnected for more than 31 days. Delete what you decommission. 

People are part of the cost 

Many teams rush to Azure Local because the VMware renewal date is coming, planning to migrate first and figure it out afterwards. That bill arrives later, as training under pressure, avoidable mistakes and outages. Engineers with 25 or 40 years of VMware experience are an asset, but Azure Local is a different beast, and the mindset shift is a lot like the move from on-premises to the cloud. 

Upskill before Day 1, not after the first incident. Arc Jumpstart LocalBox is a good place to start: it deploys a complete Azure Local sandbox, nested inside a single Azure VM, so the team can practice deployment, VM provisioning, updates and break-fix without touching production (Which is also a common pattern - no Dev/test clusters planned as part of the PO)

Mistake 1: Selling a hypervisor, not a hybrid platform 

The most common expectation I hear is some version of "a vSphere look-alike we deploy once and run however we like." Azure Local isn't that, and pretending otherwise sets the project up for disappointment. 

The way I explain it: Hyper-V on Windows Server 2025 is a set of building blocks. It's Lego, and you can design it however you want as long as you respect the foundational patterns. Azure Local runs on the same Hyper-V engine, but it was designed from day one as a complete solution and a true extension of Azure. That brings a cloud-like experience on-premises, with obligations attached. 

Under the hood 

The VM management model deserves its own decision record, because it shapes recovery and migration later. Azure Local VMs enabled by Azure Arc are created and managed through Azure: the portal, Azure CLI or any IaC tool that can interact with ARM APIs. Their lifecycle operations (create, start and stop, delete, NIC and disk changes, vCPU and memory changes, extensions) belong there. Hyper-V Manager, Failover Cluster Manager, Windows Admin Center and PowerShell are supported only for the operations on Microsoft's supported list. A few things aren't supported with any tool: changing a NIC's VLAN ID, live-migrating a VM to another cluster, storage live migration, changing the disk type, and cloning. Live migration between machines of the same instance is fine. 

Hyper-V VMs created locally run on the same hypervisor but don't show up as Azure Local VMs. You can Arc-enable their guest OS to bring Azure management services to them, but their lifecycle stays local. Neither model is wrong. Mixing them without rules is how you end up with VMs nobody can recover the same way twice. 

N.B : The Hyper - VM living in Azure Local today can become hydrated to Azure Local native VMs once the hydration feature is out.

What to do instead 

• Run a fit workshop before the hardware conversation, covering workloads, the VM management model, connectivity and the update lifecycle. 

• Record the VM management model for each workload class, with the reasons. 

• Be explicit about the 30-day sync. If a site genuinely can't connect, that's a different design conversation, and you want it now, not after delivery. 

• If the customer is weighing Azure Local against Hyper-V on Windows Server 2025, score both honestly. Sometimes the Lego set is the right answer.

Back to the ten mistakes

Mistake 2: Buying hardware before the design 

Too often, the quote arrives before the architecture. A bill of materials gets approved, and the NICs, drives and storage protocol are locked in by procurement instead of design. 

I've watched a seven-figure order of servers and SAN storage go through for Azure Local before anyone validated the design. Then the network adapters turned out not to be supported for the chosen storage protocol, and the fallback plan became the very platform the team was trying to leave. Nobody was careless. They trusted an earlier assurance and skipped validation. 

Under the hood 

Azure Local hardware is a validated solution, not a parts list. These are the checks I make before any order: 

One more thing to ask the OEM: which Solution Builder Extension (SBE) support the configuration gets, and how quickly feature releases reach it. Feature releases arrive on hardware that uses the extension only after the OEM has validated them. 

What to do instead 

• Design first, then the bill of materials. 

• Validate every NIC, drive and storage path for the role it will play, not just the server model. 

• Run the licensing equation from the previous section before choosing the storage path. 

• When something is borderline, ask for a validation deployment before the full order. 

Back to the ten mistakes

Mistake 3: Skipping the Azure landing zone discussion 

This is the one I push hardest, because of Arc. Every Azure Local instance projects its resources into Azure, into an environment that's either well structured or not. If you're plugging into an existing Azure estate, the plumbing has to be right. 

Azure Local has historically been driven by OEMs and partners, and many only ask the customer for a subscription ID and enough permissions to deploy. The instances land somewhere in Azure and nobody assesses the risks. I've also seen a VM recovery stall because its image lived in a different resource group. 

 

Figure 2. An Azure Local instance lands inside your Azure governance: management groups, policy, RBAC and resource group layout all apply from day one.

 

Under the hood 

Placement is permanent. The Azure Local FAQ is explicit: moving resources between subscriptions or resource groups isn't supported for any Azure Local resource. To change location, you redeploy the instance into the new subscription and resource group. Decide the layout once, deliberately. 

Prerequisites belong in the landing zone, not the deployment call. The subscription needs these resource providers registered: 

$providers = "Microsoft.HybridCompute", "Microsoft.GuestConfiguration", "Microsoft.HybridConnectivity", "Microsoft.AzureStackHCI", "Microsoft.Kubernetes", "Microsoft.KubernetesConfiguration", "Microsoft.ExtendedLocation", "Microsoft.ResourceConnector", "Microsoft.HybridContainerService", "Microsoft.Attestation", "Microsoft.Storage", "Microsoft.Insights", "Microsoft.KeyVault" foreach ($p in $providers) { az provider register --namespace $p }

Deployment roles are assigned on the resource group. Registering the machines with Azure Arc needs Azure Connected Machine Onboarding and Azure Connected Machine Resource Administrator. Deploying the instance needs Azure Stack HCI Administrator, Reader, Key Vault Data Access Administrator (an owner on a Sub does not give you Data plan permissions) , Key Vault Secrets Officer, Key Vault Contributor and Storage Account Contributor. Those are deployment rights. Operations teams need a different, smaller set, and the two shouldn't be the same standing assignments. 

Policy reaches the nodes. Each machine is an Arc-enabled server, so any policy assignment that targets Arc machines, at management group or subscription scope, applies to your cluster nodes as well. Azure Local isn't a standard Arc-enabled server, though. Updates are a good example: Microsoft's guidance is not to update Azure Local through Azure Update Manager's Machines pane or the Arc machine's Updates pane (nor through SConfig, Windows Admin Center or manual Cluster-Aware Updating runs), because that can install unsupported out-of-band updates and add billing for periodic assessment and patching. A patching policy inherited from the cloud side can do exactly that. List what actually lands on the resource group, inherited assignments included: 

az policy assignment list --scope "/subscriptions/<sub-id>/resourceGroups/<rg>" --disable-scope-strict-search -o table

 

Extensions are admin access. On the nodes and on Arc-enabled VMs, the Connected Machine agent's extension manager runs as Local System on Windows (root on Linux). Deploying an extension requires Microsoft.HybridCompute/machines/extensions/write, which the Azure Connected Machine Resource Administrator role includes, along with broad roles like Contributor. Whoever holds that permission at a scope covering your machines can run code with full rights on them. Treat it like local administrator access to the cluster. 

What to do instead 

• Start the conversation in Azure, before the OEM deploys anything: are landing zones in place? is the Cloud Adoption Framework followed? does the Sovereign Landing Zone apply? 

• Settle the subscription and resource group layout knowing you can't move it later. 

• Separate deployment roles from operations roles, and make elevated access time-bound using PIM and a structured SG layout.

• Review every inherited policy assignment that targets Arc machines, and add exemptions where a policy assumes a regular server. 

• Decide who may deploy extensions to nodes and VMs, and audit it. 

• Bring the landing-zone owner to the first design workshop, not the deployment call. 

Back to the ten mistakes

Mistake 4: Skipping connectivity planning

Connectivity is where Azure Local meets the rest of your network, and it's where I see the most avoidable surprises. Three decisions sit here: the DNS servers the infrastructure depends on, the path outbound traffic takes to Azure, and whether that traffic goes through Arc gateway. Some can be revisited after deployment, with care and a maintenance window. Others can't. All of them are cheaper to get right on paper. 

DNS: plan it as if it's permanent 

DNS is the one most people working with Azure Local have heard about, and it still keeps happening. Treat the DNS servers you give the infrastructure at deployment as permanent: at the time of writing, changing them afterwards isn't supported. If they must change, you're looking at a rebuild.

To be fair, Azure Local isn't the only platform with this kind of constraint, and a DNS design that outlives its servers is good practice whatever the platform allows. 

Three versions of the same story. One customer was advised not to change host DNS after deployment, did it anyway, and some VMs lost external connectivity. Another retired a domain controller without realizing it was one of the cluster's infrastructure DNS servers, and DNS went unhealthy. A third, moving to new DNS servers, tried to edit the infrastructure logical network and the change was rejected, as designed. 

 

Figure 3. Point the infrastructure at addresses designed to outlive any single DNS server.

Under the hood: 

 

Since release 2601, the infrastructure logical network also shows up in the Azure portal, named after the instance with an "-InfraLNET" suffix. It's there as a safeguard against provisioning workloads on the network reserved for infrastructure, and it's a useful reminder of what it holds. 

Outbound path: public or private, with or without Arc gateway 

Figure 4. Arc gateway shrinks the allow-list, but some endpoints are always reached directly.

Every instance needs outbound HTTPS to Azure, and the first design choice is how it gets there. On the public path, traffic leaves through your proxy or firewall to the internet. On the private path, it travels over ExpressRoute or a site-to-site VPN to an Azure Firewall explicit proxy, so it never crosses the public internet. Arc gateway sits on top of either: an Arc proxy on each machine sends most traffic to a single gateway FQDN, which shrinks the allow-list but doesn't empty it. Some endpoints still go through your proxy or firewall directly: 

• Bootstrap: aka.ms and azurestackreleases.download.prss.microsoft.com 

• Arc registration: login.microsoftonline.com, the regional login endpoint, management.azure.com, gbl.his.arc.azure.com and the regional his.arc.azure.com endpoint 

• The gateway URL itself, your Key Vault and your cloud witness storage account 

• HTTP certificate revocation endpoints, because the gateway doesn't carry HTTP traffic 

• For AKS extensions, the regional obo.arc.azure.com endpoint on port 8084 

The gateway doesn't work with TLS-terminating proxies, so plan for no TLS inspection on that path. Arc endpoints must resolve to public IPs through whatever proxy you run. And Azure Local doesn't support Azure Arc private link scopes for its own traffic: with the private path, the virtual network that hosts Azure Firewall must have them disabled, so put workloads that need one on a separate virtual network. 

Changing course after deployment 

This is where the picture has improved. Starting from release 2610, you can enable Arc gateway on an existing instance, update the proxy and bypass list across the machines and the Arc resource bridge with Update-AzureLocalProxy, and move an existing instance from the public path to the private path. Each comes with conditions worth knowing before you count on it: 

• Arc gateway can't be disabled after you enable it, so rehearse the change first. 

• The move to the private path depends on Arc gateway: enable and validate the gateway first, then point the proxy at the Azure Firewall private IP and explicit proxy port. Changing the proxy address before the gateway is enabled doesn't create private path connectivity and can interrupt outbound traffic. 

• A proxy change reaches the machines and the Arc resource bridge, but existing AKS clusters don't automatically pick up the new settings. The recommended option is to delete and re-create existing AKS clusters after you update the proxy. New clusters inherit the complete updated configuration.

Being able to change course is welcome, but each of these changes touches every machine and needs a maintenance window. Choosing the path during design is still the cheaper option. 

What to do instead 

• Plan DNS as if it has to outlive every server it points to, because it does. 

• If your organization rotates DNS servers every few years, put a virtual IP, an anycast address or stable forwarders in front of them, so the real servers can change without touching what the cluster was given. 

• If a DNS server the cluster uses has to be retired anyway, keep its IP alive: move the address to the replacement server or a forwarder before the old one goes. 

• Make sure those servers resolve both your Active Directory domain and the public Azure endpoints. Arc endpoints must resolve to public IPs. 

• Add the cluster's DNS addresses to your domain controller decommissioning checklist. 

• Decide the outbound path during design: public or private, with or without Arc gateway, and size the firewall and proxy rules for it. 

• If the proxy changes later, refresh and validate existing AKS clusters separately.

Back to the ten mistakes

Mistake 5: Overlapping IPs and no room to grow 

IP conflicts used to hide. Now they tend to surface, usually at the worst possible moment. A workload logical network created without an explicit IP pool can claim the whole subnet, collide with the infrastructure range and get rejected. Designs that put VMs on the same subnet as the hosts hit the same wall, and a VLAN change after deployment once left a resource bridge in a failed state. Once Azure Local and Azure are connected privately, over ExpressRoute or a site-to-site VPN, overlaps stop being a local issue and become an estate-wide one. 

 

Figure 5. Every range Azure Local touches, on one page. Illustrative addressing.

Under the hood 

 

What to do instead 

• Keep one IP worksheet covering node IPs, the infrastructure pool, every logical network and its pools, the resource bridge, AKS and the storage VLANs. 

• Check it against everything already routed on-premises and in Azure, and again whenever the site gets a new private connection to Azure. 

• Give every static logical network an explicit IP pool. 

• Leave room in the management subnet for the machines you'll add later. 

Back to the ten mistakes

Mistake 6: Leaving AD, firewall and proxy to Day 1 

These integrations are where deployments stall on the day of deployment, and some of the mistakes can't be undone afterwards. 

Active Directory 

Preparation is well documented, and the tooling does the heavy lifting: Prepare Active Directory for Azure Local deployment - Azure Local | Microsoft Learn

Install-Module AsHciADArtifactsPreCreationTool -Repository PSGallery -Force New-HciAdObjectsPreCreation -AzureStackLCMUserCredential (Get-Credential) -AsHciOUName "<OU name or distinguished name including the domain components>"

It creates a dedicated OU that blocks inherited GPOs and holds the deployment user. Keep one instance per OU. Believe it or not, the pattern keeps repeating anyway. Six months after a clean deployment, someone links a new GPO at the domain root, the Azure Local OU inherits it, and the next call is "my resource bridge VM is offline." 

The detail people miss: blocking inheritance doesn't stop a GPO whose link is set to Enforced. Check what actually reaches the OU, not what you think reaches it: 

(Get-GPInheritance -Target "OU=AzL-Prod01,DC=contoso,DC=com").InheritedGpoLinks | Format-Table DisplayName, Enforced, Target

Replication is the other trap. Adding a node once failed validation until OU permission changes had replicated to every domain controller. Run repadmin /replsummary before you blame the product. And if Active Directory itself is the blocker, deployment with local identity, without AD, has been generally available since release 2604. 

Firewall and proxy 

Static IP allow-lists quietly go stale (Most modern firewalls support dynamic lists), because the addresses behind Microsoft's endpoints change over time. The firewall requirements page links per-region endpoint lists, so build rules on FQDNs, keep them under change control, and review them with each release. 

The proxy bypass list is set during Arc registration, and its format trips people up. It must include the IP address and NetBIOS name of every machine and of the cluster, plus the infrastructure IPs or the whole infrastructure subnet. Entries are comma-separated and wildcards work, but CIDR notation and "" don't: 

Invoke-AzStackHciArcInitialization <...> -Proxy "http://proxy.contoso.com:8080" ` -ProxyBypass "localhost,127.0.0.1,*.contoso.com,node01,node02,azlclus01,10.20.10.*"

If the proxy or bypass list has to change later, there's now a supported way to do it (see mistake 4), but it's still far easier to get right the first time.

 

Two smaller items cause outsized pain. The first is a reachable, verified time source: check it with w32tm /query /status on every machine. The second is the OEM's in-band path from the operating system to the iDRAC or iLO, which the Solution Builder Extension (SBE) relies on during updates. 

Validate in week one 

Deployment runs its own validation, but that's the worst possible day to discover a blocked endpoint or a missing OU permission. Run the Environment Checker yourself in week one, when there's still time to fix what it finds, and again before every update: 

Install-Module -Name AzStackHci.EnvironmentChecker -Repository PSGallery -Force Invoke-AzStackHciConnectivityValidation Invoke-AzStackHciHardwareValidation Invoke-AzStackHciSoftwareValidation Invoke-AzStackHciNetworkValidation Invoke-AzStackHciArcIntegrationValidation Invoke-AzStackHciExternalActiveDirectoryValidation # takes your OU, domain and naming parameters

Back to the ten mistakes

Mistake 7: No headroom in storage or network 

Sizing usually happens once, right before the hardware order. Then the migration starts and the cluster fills up with workloads nobody accounted for. 

Two things are usually missing. The first is repair: nodes go down for maintenance, disks fail, and Storage Spaces Direct needs free capacity to rebuild into. The second is growth. Azure Local keeps adding reasons to run more on it, from Azure Virtual Desktop and AKS to Foundry Local, and a cluster sized only for today's migration has nowhere to put them. On one cluster we reviewed, the pool was close to 80% full with every drive bay populated, so the only way to grow was a whole new node, with the budget and lead time that come with it. 

 

Figure 6. With a three-way mirror, usable capacity is a fraction of raw. Illustrative only; size real designs with the Azure Local sizer.

Storage, under the hood 

With three or more machines, the usual resiliency is a three-way mirror: three copies of every write, 33.3% storage efficiency. On top of that, Microsoft's guidance is to leave unallocated reserve in the pool equal to one capacity drive per server, up to four drives, so repairs have somewhere to go. 

Run the numbers in Figure 6 and two things stand out. The reserve is capped at four drives, so it weighs less as the cluster grows: going from four to five nodes adds 20.5 TB of usable capacity while the reserve stays at 30.7 TB. And doubling the drives per node more than doubles usable capacity. Efficiency belongs in the same equation as cost, and empty drive bays are the cheapest growth path you'll ever have. 

To see where a pool stands today: 

Get-StoragePool -IsPrimordial $false | Select-Object FriendlyName, @{n='SizeTB'; e={[math]::Round($_.Size/1TB,1)}}, @{n='AllocatedTB'; e={[math]::Round($_.AllocatedSize/1TB,1)}}, @{n='FreeTB'; e={[math]::Round(($_.Size-$_.AllocatedSize)/1TB,1)}}

If the free space is smaller than one capacity drive per node (up to four), you're already eating into repair capacity. 

Network, under the hood:

I regularly find 25 GbE ports left idle, storage on 10 GbE while management and compute got the 25 GbE links, or a storage MTU left at the default. Network ATC makes the intent explicit, so start there: 

Get-NetIntent # which adapters carry management, compute and storage Get-NetIntentStatus # did the intent apply cleanly on every machine? Get-NetAdapterRdma # is RDMA enabled where storage expects it? Get-NetAdapterAdvancedProperty -RegistryKeyword "*JumboPacket"

Match storage bandwidth to drive density, put the fastest ports on storage, and keep jumbo frames consistent from adapter to switch. The deployment offers 1514, 4088 or 9014 bytes on the adapters, and Microsoft's guidance uses a 9216-byte MTU on the switch side for RDMA storage traffic. 

Network intents: design for what you'll enable later 

Network ATC intents feel like plumbing, but they decide which features you can turn on later. In a recent case, a cluster went live with four intents: management, compute, storage, and a fourth for an isolated backup network used by a third-party backup appliance. Months later, SDN enabled by Arc stopped during enablement because it found more than three intents, and the project was blocked. 

Before SDN is enabled, the way out is manageable: remove the extra intent and its virtual switch, enable SDN, then add the backup intent back. After SDN is enabled, the options narrow. Enablement can't be rolled back or disabled, and the virtual switches carry the policies the Network Controller pushes, so removing or recreating one isn't a change to make casually. Remember too that SDN resources live on a single virtual switch, and NSGs apply to Azure Local VMs on it, so a VM that only sits on a separate backup switch won't get them. 

If SDN is anywhere on the roadmap, check the intent design against its supported networking patterns before deployment. Microsoft Learn lists these intent configurations as unsupported for SDN enabled by Arc: 

What to do instead 

• Size for repair, growth and efficiency, with the Azure Local sizer rather than a spreadsheet. 

• Keep the reserve unallocated, and set an expansion trigger at about 70% of usable capacity. 

• Leave drive bays free where the budget allows. 

• Validate the storage network the way you validate the servers: bandwidth, RDMA and MTU, end to end. If SDN is on the roadmap, check the intent design against its supported patterns before deployment, not on enablement day. 

Back to the ten mistakes

Mistake 8: Testing in production 

"We test in production." One customer team told us exactly that, and they're far from alone. Many estates have no Dev/test cluster at all, so every update and configuration change lands in production first. 

Self-assessments can hide the problem. I've seen a team tick "tested in a production-like environment" when they meant test VMs running on the production cluster. That tests the VM, not the platform change you're about to make. 

Under the hood:

The changes worth rehearsing are the ones you can't take back, or that touch every node: solution updates including the OEM extension, adding or repairing a node, secret and certificate rotation, enabling Arc gateway on an existing instance, and restore and failover tests. 

What to do instead 

A Dev/test environment doesn't need to match production in scale. Few customers validate fixes on a smaller UAT clusters after updating them, ran several rounds of testing, and only then planned the rollout to the rest of the estate. That's the pattern to copy. 

• Build something representative, not big: same hardware generation, same solution version, comparable network. 

• Update it first, every time. 

• Where a test cluster genuinely can't be justified, a recurring review of planned changes is a partial mitigation, not a substitute.

Back to the ten mistakes

Mistake 9: Updating without a readiness routine 

Azure Local updates are a lifecycle, not Patch Tuesday. Instances outside the supported update window may need to be brought to a supported version before Microsoft can fully investigate issues unrelated to the update process. Consult the current Azure Local lifecycle and support documentation for the applicable support position.
Check out more details here: Azure Local release information - Azure Local | Microsoft Learn

That said, nobody has to patch every month. You need to stay inside the six-month window, with a maintenance routine that fits your own change calendar. What hurts is having neither: no defined window, no readiness check, and a team constantly chasing the latest release. 

The worst case I've seen was an estate where most clusters were failing updates on mixed versions, security updates were more than a month late, and a go-live was slipping. Looking back at the update escalations I've been part of, very few came down to a single product defect. Most traced back to readiness, drift or coordination: a VLAN change that broke the resource bridge, a certificate lost during rotation, a capacity alert disabled instead of addressed, or hosts reimaged from the same OEM image ending up on different hotfix levels. 

 

Figure 7. Stay inside the six-month window, and run the same routine before every maintenance window.

Under the hood 

A solution update isn't just an OS patch. It covers the operating system, the core agents and services (including the Connected Machine agent and the Arc resource bridge) and, where the OEM integrates, the Solution Builder Extension with drivers and firmware. Out-of-band updates to individual components aren't supported. The typical cadence is a cumulative update every month and a feature update twice a year. Within a feature release train you can skip ahead to a later release, but you must install the last cumulative update before moving to the next feature update. 

Use the Azure Local view in Azure Update Manager to update at scale, or PowerShell on a node: 

# Where are we, and what's available? Get-SolutionUpdateEnvironment Get-SolutionUpdate | Format-Table DisplayName, State # Download and run the readiness checks without installing Get-SolutionUpdate -Id <update-id> | Start-SolutionUpdate -PrepareOnly # Install, then follow progress Get-SolutionUpdate -Id <update-id> | Start-SolutionUpdate Get-SolutionUpdate -Id <update-id> | Format-Table DisplayName, State

When a run stops, Get-SolutionUpdateRun gives you the details of where it stopped. Start-SolutionUpdate also has an -IgnoreWarnings switch. Use it only when you understand every warning it would skip. 

Before the window, I also check the storage layer directly, because an update that starts on a degraded pool is an escalation waiting to happen: 

Get-StorageJob | Where-Object JobState -ne 'Completed' # no repairs still running Get-VirtualDisk | Where-Object HealthStatus -ne 'Healthy' # every volume healthy Get-HealthFault # open faults on the cluster

What to do instead 

• Check: run the Environment Checker, the health checks and the OEM prerequisites, and clear open faults. 

• Fix drift first: versions, VLANs, certificates and disabled alerts. 

• Rehearse on the test cluster, on the same version as production. 

• Update production inside the window, and keep every cluster on the same version. 

• Validate afterwards: live migration, the resource bridge and your workloads. 

• Check the Azure Local Supportability repository on GitHub before and after each window, for known issues and troubleshooting guides. 

Back to the ten mistakes

Mistake 10: No Day-2 plan for alerts, backup and DR 

Azure Local is an extension of Azure, yet many customers run it without the Azure capabilities that come with it: monitoring and alerting, Microsoft Defender for Cloud and Microsoft Sentinel, backup and disaster recovery. That's a missed opportunity, and it ties straight back to the landing zone in mistake 3. 

On one cluster, a volume's write latency spiked past half a second, against a customer-impact threshold of 10 milliseconds. The spike was right there in the portal. No alert fired, because no alert rules existed, and nobody noticed until we opened the workbook together. The data was being collected. Nobody was being told. 

 

Figure 8. Day 2 starts on Day 1: the Azure services that close the gaps we see most often.

 Under the hood: monitoring 

A small but useful detail if you're planning the move to 2610: update the AzureEdgeAlerts extension to 12.2607.5.0 or later first. 

Under the hood: backup and recovery 

Backup scope drifts. VMs moved or re-created on another cluster can silently fall out of the backup job meant to protect them, so check scope after every migration wave. Microsoft Azure Backup Server (MABS) V4 can protect Azure Local VMs and Hyper-V VMs at host or guest level, and many customers use partner products. Know your restore path before you need it: restoring an Azure Local VM to an alternate location with MABS or ASR gives you a VM that's no longer managed from Azure. 

For disaster recovery, Azure Site Recovery for Azure Local became generally available in October 2026. It replicates Windows and Linux VMs (Generation 1 and 2) to Azure, fails over there, and fails back to the same or an alternate host. 

BitLocker recovery keys often stay inside the cluster they protect. If the cluster is down and the domain controllers run on it, the keys may be out of reach exactly when you need them. Export them from a local console, an RDP session or a CredSSP remote session, and store them outside the cluster, for example in Azure Key Vault: 

Get-AsRecoveryKeyInfo | Format-Table ComputerName, PasswordID, RecoveryKey

Starting with release 2609, automatic backup of the keys to a backup key vault is also available.

What to do instead 

• Treat Day 2 as part of Day 1. Turn on Insights and the health alerts, add the recommended alert rules, and route them to an action group somebody reads - I would just get notified through a teams chat or through an SMS sent to my Phone. (Use the Azure Native power)

• Agree RTO and RPO per workload, then choose backup and DR to match. 

• Test a restore after the migration, not during the first incident. 

• Export the recovery keys to a vault outside the cluster. 

• Onboard the nodes and VMs to Defender for Cloud, and connect them to Microsoft Sentinel. 

Most of this costs little or nothing, and it's usually missing.

Back to the ten mistakes

The lesson behind all ten 

If I had to reduce this post to one sentence: design before you deploy, because some choices can't be undone. A handful of decisions are made once, at deployment: DNS, IP ranges, the landing zone and resource placement, the VM management model, the storage design and, increasingly, Arc gateway and SDN. Get those right and almost everything else gets easier. 

Where to get help 

You don't have to learn all of this the hard way. If your organization has Microsoft Unified (or even without Unified),  ask your account team/Microsoft Representative about the Azure Local Foundations Workshop and the Azure Local Architecture and Operations Assessment. Some customers book the workshop every year, even with years of Azure Local behind them, and the assessment is built to surface quick wins and flag what must be fixed before the next outage. Bringing Microsoft's delivery teams in before the first design workshop costs far less than bringing them in after the first incident. 

 

Thank you for reading my article till the end! Now, I'm interested to learn about your journey so far on Azure Local and which of these ten have you run into, and what would you add to the list? Tell me in the comments. 

#AzureLocal #AzureArc #HybridCloud #VMwareExit #CloudArchitecture #SovereignPrivateCloud