Ansible + Azure Arc: Manage Arc Extensions with New Ansible Modules
We’re excited to announce new modules in Ansible Galaxy that make it easier to manage Azure Arc machine extensions at scale. With the latest updates to the azure.azcollection on Ansible Galaxy, you can now deploy and manage Azure Arc extensions using familiar, declarative Ansible workflows. These new modules include: Arc machine extensions module Arc extensions info module Together, they enable infrastructure and platform teams to automate extension lifecycle management across their hybrid estate—bringing consistency, security, and efficiency to Arc-enabled servers. Why this matters Azure Arc machine extensions power critical scenarios such as security, monitoring, update management, configuration and compliance. Until now, managing these Arc extensions across hybrid estates often required Azure CLI scripts, ARM templates, or manual operations. With these new Ansible modules, you can: Integrate Arc extension management into existing Ansible playbooks Enforce consistent configuration across hybrid servers Reduce operational overhead through declarative automation Align extension deployment with broader configuration management workflows What’s included azure_rm_arcmachineextensions This module allows you to manage the full lifecycle of Azure Arc machine extensions, including: Creating and deploying extensions Updating extension settings Removing extensions when no longer needed You can define extension state declaratively, ensuring consistent enforcement across your Arc-enabled servers. azure_rm_arcmachineextensions_info This module provides visibility into extension state by retrieving: Installed extensions on Arc-enabled machines Provisioning status and configuration details Extension metadata for reporting and validation This is useful for compliance validation, auditing, and conditional automation in playbooks. Scenario: Enforcing identity-based SSH access across a hybrid fleet Consider a regulated enterprise that must ensure all Linux servers—whether on-premises or in a multicloud environment—use Microsoft Entra ID for SSH access. The organization wants to: Eliminate local SSH credentials Enforce centralized identity and access controls Audit access consistently across all environments By combining Azure Arc with Ansible, the organization can deploy the Microsoft Entra SSH for Linux extension across all Arc-enabled servers as part of a standardized playbook, ensuring compliance and reducing operational overhead. Example: Deploy Microsoft Entra SSH for Linux extension Below is an example of using Ansible to deploy the Microsoft Entra SSH extension to an Azure Arc-enabled server: - name: Deploy Entra SSH extension to Arc server hosts: localhost connection: local tasks: - name: Install Entra SSH extension for Linux azure_rm_arcmachineextensions: resource_group: myResourceGroup machine_name: myArcServer name: AADSSHLoginForLinux publisher: Microsoft.Azure.ActiveDirectory type: AADSSHLoginForLinux type_handler_version: "1.0" settings: {} state: present Example: Retrieve extension information Below is an example of using Ansible to retrieve details about your Arc extensions: - name: Get Arc machine extension details hosts: localhost connection: local tasks: - name: Fetch extensions azure_rm_arcmachineextensions_info: resource_group: myResourceGroup machine_name: myArcServer Integrating with existing Ansible workflows If you’re already using Ansible for: OS configuration Patch and update management Application deployment You can now extend those workflows to include Azure Arc extension management—without introducing new tools or processes. This allows you to manage on-premises servers, Edge infrastructure and multicloud environments through a unified automation approach powered by Azure Arc and Ansible. Read more at Enable VM Extensions Using Red Hat Ansible - Azure Arc | Microsoft Learn What’s next These modules are part of our continued investment in making Azure Arc a first-class platform for managing Windows and Linux machines in hybrid and multicloud infrastructure. By bringing extension lifecycle management into Ansible, we’re enabling teams to enforce security, compliance, and operational consistency at scale—using the tools they already trust. Let us know what you’d like to see next in the comments!
Simplified access to Hotpatching enabled by Azure Arc for Windows Server 2025
With Windows Server 2025, we introduced hotpatch enabled by Azure Arc, delivering security updates to Windows Server across hybrid and multicloud environments – minimizing downtime (no reboot), accelerating protection, and unifying patch management. We know that keeping your servers updated with the latest patches is one of the critical tasks that IT teams perform day-to-day. We want to make it simpler to install the latest operating system (OS) updates without rebooting machines after every installation. The resounding feedback we have received from you underscored the criticality of this feature in the lifecycle management and security of your infrastructure. We are now taking it one step further to reduce the friction to deploying these critical updates: hotpatch enabled by Azure Arc is now available at no additional cost for Windows Server 2025. Which machines are eligible for this offer? To use hotpatch for Windows Servers running on-premises or in multicloud environments, you must be using Windows Server 2025 Standard or Datacenter, and your server must be connected to Azure Arc. With this announcement, enabling and usage of the hotpatching service is available at no additional charge. Please take note that there are no charges for customers running on Azure IaaS, or Azure Local, wherein hotpatching is available as part of the functionality of Windows Server Datacenter: Azure Edition. This feature is already included both with Windows Server 2022 Datacenter: Azure Edition and Windows Server 2025 Datacenter: Azure Edition. How do I manage hotpatches enabled by Azure Arc for Windows Server 2025? If your Windows Server 2025 machines aren't already connected to Azure Arc, install the Azure Connected Machine agent — it takes just a few minutes per server and supports at-scale rollout via Group Policy, service principal, or Terraform. Once connected, enable Hotpatch from the Azure portal, Azure PowerShell, Azure CLI, or the REST API — just confirm Virtualization-based security (VBS is enabled) first. From there, use Azure Update Manager to schedule and monitor rollouts at scale. For instructions on how to enable hotpatch for Azure Arc-enabled machines using group policy or scripts, learn more here: https://aka.ms/ws-hotpatch For patch orchestration at scale, you can use Azure Update Manager to deliver hotpatches enabled by Azure Arc for Windows server 2025 machines. This enables greater uptime with fewer reboots and faster deployment of updates with easy patch orchestration. Alternatively, you can use APIs or other management tools to manage hotpatches. Centralized management of hotpatch updates across hybrid and multicloud environments enabled by Azure Arc Once your machines are connected to Azure Arc, you can also use the cloud-native services from Azure to manage your windows machines running on-prem. Azure Arc enables you to standardize security and governance across a wide range of resources so you can easily organize, govern and secure Windows, Linux, SQL servers, and Kubernetes clusters running across data centers, edge, and multi-cloud environments – using Azure services such as Azure Policy, Azure Monitor, Microsoft Defender and more. At no additional cost for machines attached to Azure Arc Basic inventory across on-prem and multi-cloud Tag your resources, organize them into resource groups, subscriptions, and management groups, and query at scale with Azure Resource Graph to unify your environments. Infra as Code (Bicep, Terraform) Infra as code for provisioning and management of resources. VM Self Service Perform lifecycle management such as (create, resize, update and delete) and power cycle operations such as (start, stop, and restart on VMware vCenter and System Center Virtual Machine Manager Virtual Machines. Hotpatch for Windows Server 2025 NEW Windows Server hot patching enables you to apply security updates without rebooting, keeping systems secure while maintaining continuous uptime. VM Management Administrate your servers anywhere using SSH for Azure Arc, Run Command, and Custom Script Extension. Mgmt. Services included for no additional costs with Windows Server Software Assurance or Extended Security Updates Azure Update Manager Provides a unified, centralized service to monitor, orchestrate, and automate patching across Azure, on‑prem, and multi‑cloud environments ensuring security, compliance, and minimal downtime at scale. Azure Machine Configuration (Policy) Policy‑driven auditing and enforcement of OS and application settings as code across Azure and hybrid machines—ensuring consistent, compliant state at scale. Including compliance policies like CIS Benchmark and WinRE Change Tracking & Inventory Real‑time visibility into configuration changes and system state across your fleet enabling faster troubleshooting, improved security, and continuous compliance at scale. VM insights from Azure Monitor Delivers a unified, pre‑built observability experience that provides real‑time performance, health, and dependency visibility across VMs—enabling faster troubleshooting, optimization, and capacity planning at scale. Windows Admin Center Unified, browser‑based management plane to securely manage Windows servers, VMs, and hybrid infrastructure from anywhere—simplifying operations and improving efficiency at scale. Best Practices Assessment Continuously evaluation your server configurations against Microsoft-recommended standards to proactively identify risks and provide actionable remediation guidance—improving security, performance, and operational health at scale. Frequently Asked Questions What are hotpatch updates? Hotpatch updates are monthly security updates that take effect without requiring you to restart the device. They contain a full set of security updates equivalent to the standard updates released the same day. What is the hotpatch update cycle? All eligible Windows Server 2025 machines enrolled in hotpatch are offered up to 8 monthly hotpatch updates in a calendar year in a quarterly cycle: Baseline month: In January, April, July, and October, devices install the monthly cumulative security update and must restart for the update to take effect. This update includes the latest security fixes, cumulative new features, and enhancements since the last baseline. Subsequent two months: Devices receive hotpatch updates, which only include security updates and don't require a restart for the update to take effect. These devices will catch up on features and enhancements with the next cumulative baseline month (quarterly). Will billing be stopped for existing enrolled machines? Yes, as of 15 th May 2026 all billing for hotpatch has been stopped for all existing machines enrolled in hotpatch. What action do we need to take if we have machines enrolled in hotpatch already? There is no additional action needed for machines that are currently enrolled in hotpatch. These machines will remain enrolled in hotpatch and receive hotpatch updates when available. I want all my Windows Server 2025 machines to get hotpatches. How do I do it? If you have Windows Server 2025 machines on-premises or on cloud (other than Azure) then you can enable hotpatch on them. To do so, ensure these machines have Virtualization Based Security enabled and are connected to Azure Arc and then you can use Azure Arc portal, Azure Update manager or APIs to enable hotpatch. Learn more: https://aka.ms/ws-hotpatch Is anything changing for Hotpatching on Azure? Hotpatch continues to be available on Azure for your Windows Server 2022 and Windows Server 2025 VMs when using Azure Edition. There is no fee associated with Hotpatching on Azure. Learn more here. Is there a community forum for Arc? Yes, you can join the Azure Arc Monthly Forum here: aka.ms/ArcServerForumSignupAzure Local expands to sovereign-scale infrastructure with disaggregated deployments
As organizations accelerate digital transformation across datacenters, sovereign environments, and edge locations, infrastructure architectures must evolve to meet new operational and regulatory demands. The first feature update of Azure Local in CY 2026 (version 2604) marks a significant step forward—expanding Azure Local as a platform for sovereign private cloud infrastructure, introducing larger scale, disaggregated deployment architectures, expanded storage ecosystem partnerships, and simplified identity capabilities that unlock entirely new infrastructure scenarios from edge locations to enterprise-scale environments. This release is focused on enabling: Sovereign private cloud deployments at scale from single node up to multi-rack infrastructure Infrastructure modernization through SAN reuse and disaggregated architectures Simplified edge deployment without Microsoft Active Directory dependencies Faster lifecycle operations across deployment and update workflows Introducing disaggregated larger scale deployments using SAN storage Azure Local now supports a disaggregated infrastructure architecture, allowing customers to deploy compute and storage resources independently—while continuing to benefit from an Azure-consistent management and operational experience. This enables organizations to scale infrastructure more flexibly separating compute and storage to align with workload demands and long-term growth. This architecture enables: Independent scaling of compute nodes and storage infrastructure SAN‑only and hybrid storage architectures for Azure Local infrastructure and workloads Fibre Channel (FC) connectivity support beginning with 2604 (iSCSI coming soon) With disaggregated deployments and SAN storage, Azure Local clusters can now scale from a single node at the edge to multi-rack environments spanning beyond 16 nodes and up to thousands of nodes, addressing growing demand for large-scale deployments across sovereign, government, defense, and regulated environments. This unlocks new class of Azure -consistent infrastructure deployments at sovereign scale. This unlocks a new class of Azure-consistent infrastructure deployments at sovereign scale. This new capability is generally available with the release of Azure Local 2604. General Availability of SAN Support for Azure Local Support for attaching SAN storage to Azure Local was introduced as public preview back in November 2025. Today this brownfield expansion capability is generally available and allows external SAN devices to be introduced into already deployed Azure Local instances via Fibre Channel (FC)—supporting virtual machines, Kubernetes environments, and Azure Virtual Desktop workloads without requiring disruptive infrastructure changes or full system refresh. Azure Local instances now support the coexistence of Storage Spaces Direct volumes and external SAN volumes. Support for SAN-attached deployments allows organizations to: Reuse existing enterprise SAN investments Modernize infrastructure without replacing existing storage estates Manage rising disk costs associated with hyperconverged architectures Enable workload scenarios that depend on massive storage requirements These innovative capabilities supporting disaggregated deployments and SAN storage are supported by a strong ecosystem of hardware partners. DataON, Dell Technologies, Everpure, HPE, Hitachi Vantara, Lenovo and NetApp are working with Microsoft to deliver configurations, giving customers more flexibility in how they design and scale their infrastructure. General Availability of Local Identity with Azure Key Vault While disaggregated architectures primarily target sovereign and centralized datacenter deployments, Azure Local 2604 also introduces a major advancement for distributed and edge scenarios. With the General Availability of Local Identity with Key Vault, Azure Local can now be provisioned without infrastructure dependencies on Microsoft Active Directory, enabling simplified deployment in disconnected, air-gapped, and regulated environments. This simplifies deployment and adoption, by removing the need for extra hardware running domain controllers and removing the complexity of firewall configurations when installing in isolated network environments. Azure Local 2604 adds support for deploying rack-aware clusters using Local Identity with Azure Key Vault. This combines reduced requirements with the high availability that customers demand across manufacturing, energy, and other industries. This capability removes one of the key barriers to deploying Azure-consistent infrastructure in sovereign and edge environments. Pricing Changes Pricing for multi-rack and sovereign-scale deployments is being introduced as part of this release. Customers should connect with their Microsoft account team to learn more about pricing, configuration options, and early access programs as these offerings continue to actively evolve. Getting started Release 2604 is available for both existing and new Azure Local instances. Review the release note for Azure Local 2604 release here Learn more about disaggregated deployments here Learn more about SAN attach here Learn more about Local Identity with Azure Key Vault here. Learn more about hardware configurations that support disaggregated deployments using the solutions catalog or learn directly from our partners: o DataON: “DataON Premier Solutions for Azure Local provide a premium Azure Local experience that includes deployment, integration, training, and white glove service & support. Our goal is to not only get you up and running quickly but also to help your team to be confident in managing Azure Local.” o Dell Technologies: “Coming Soon, Dell Private Cloud–Microsoft enables a modern disaggregated architecture, simplifying operations across Dell PowerEdge compute, Dell PowerStore storage, and Azure Local.” “Available now, Dell PowerStore delivers high-performance, scalable, and resilient storage for Azure Local, with support for Dell Private Cloud coming soon to make it easier to streamline operations for storage, compute, and your Azure Local license.” o Everpure: “Azure Local now supports external storage with Everpure FlashArray, offering Azure Local customers unprecedented levels of scale, performance and efficiency with the added benefit of seamless hybrid cloud integration with Everpure Cloud in Azure.” o Hitachi Vantara: “Hitachi Vantara VSP and VSP One Block, fully validated to meet Microsoft's Azure Local storage requirements, deliver enterprise SAN reliability for Azure Local.” o HPE: “HPE ProLiant Compute Premier Solutions for Azure Local enable customers to gain full control over data residency, and accelerate innovation with industry-leading performance, security, and management automation.” “HPE Alletra Storage MP B10000 integrated with Azure Local delivers a unified, Azure managed experience with the simplicity of Azure Local plus the advanced data services of a modern enterprise storage platform.” o Lenovo: “Lenovo is expanding its Azure Local portfolio to support disaggregated infrastructure designs that deliver greater choice across compute and storage. The ThinkAgile Disaggregated Solution for Microsoft Azure Local with new compute-only configurations on ThinkAgile MX Series enables customers to integrate ThinkSystem DM, DS, and DG Series storage arrays or bring their own Azure Local validated third party SAN arrays into new or existing Azure Local environments, allowing fully disaggregated, independent scaling using enterprise class Lenovo solutions for sovereign private cloud deployments and emerging AI workloads.” o NetApp: “With Azure Local, NetApp delivers support across NetApp® AFF, ASA, and FAS systems.” Thank you! This first feature release of 2026 is packed with innovation for Azure Local, and we can’t wait for you to try it and share feedback. We are committed to listening to your feedback and delivering the next wave of capabilities in a continuously evolving world. Thank you to all our customers who trust Azure Local to run their business—and to our engineering partners for the incredible collaboration in building solutions together.
Bringing AI to the Factory Floor with Foundry Local - Now in Public Preview on Azure Local
Key capabilities in this preview Foundry Local exposes standard REST and OpenAI‑compatible APIs, enabling IT and AI teams to deploy and operate local AI workloads using familiar, cloud‑aligned patterns across edge and on‑prem environments. In this public preview, we deliver the following capabilities: Azure Arc extension for Foundry Local Deploy and manage Foundry Local via an Azure Arc extension, enabling consistent install, configure, update, and governance workflows across Arc‑enabled Kubernetes clusters, in addition to Helm‑based installation. Built‑in generative models from the Foundry Local catalog Deploy pre‑built generative models directly from the Foundry Local model catalog using a simple control‑plane API request. Bring‑your‑own predictive models (ONNX) from OCI registries Deploy custom predictive models (such as ONNX models) securely pulled from customer‑managed OCI registries and run locally. REST and OpenAI‑compatible inference endpoints Consume both generative and predictive models through standard HTTP endpoints. Multi‑model orchestration for agent‑style applications Enable applications that coordinate multiple local models—for example, generative models guiding calls to predictive models—within a single Kubernetes cluster. Running Foundry Local on Azure Local single-node gives you: A validated, supported hardware foundation for running AI inference at the edge, from compact 1U nodes on the factory floor to rugged form factors in remote sites, using hardware from the Azure Local catalog AKS on Azure Local as the deployment target, so Foundry Local runs as a containerized workload managed by Kubernetes - the same operational model you use for any other workload on the cluster GPU access through the NVIDIA device plugin on AKS, giving Foundry Local's ONNX Runtime direct access to the node's discrete GPU without requiring Windows or host-OS-level configuration Two installation Options for single node deployment: The preview includes the Foundry Local Azure Arc extension, providing a consistent installation, deployment, and lifecycle management experience through Azure Arc, while also supporting Helm‑based installation Choose one of two installation paths: Option 1 - Arc-enabled Kubernetes Extension Recommended when: your organization manages multiple Azure Local instances and wants Microsoft to handle the deployment lifecycle — version updates, configuration drift detection, health monitoring — through the Azure portal without the team needing to manage Helm releases manually. Arc-enabled Kubernetes extensions deploy and manage workloads on AKS clusters registered with Azure. The extension operator runs in the cluster and reconciles the desired state declared in Azure, which means you don't need direct kubectl or helm access to the node to push updates. This is the lower-operational-overhead path for OT teams who are not Kubernetes specialists. Once installed, the extension appears in the Azure portal under your AKS cluster's Extensions blade. Model updates and configuration changes are pushed by modifying the extension configuration in Azure — no shell access to the node required. For disconnected or intermittently connected deployments, the extension operator caches its desired state and continues operating; it reconciles with Azure when connectivity resumes. Option 2 - Helm Chart Recommended when: your team manages AKS workloads with Helm or GitOps (Flux), and you need precise control over GPU resource allocation, node affinity, model pre-loading, or persistent volume configuration. The Helm chart gives you full control over the deployment manifest. You decide exactly how much GPU memory is requested per pod, which node the inference pod is pinned to, and what StorageClass backs the model cache. This matters on a single-node Azure Local deployment where you're sharing one physical GPU between the inference workload and potentially other AKS workloads. With Helm you can also integrate with Flux for GitOps-managed deployment — useful when you manage multiple Azure Local single-node instances across plant sites and want to push model or configuration updates from a central Git repository. Note: Verify the chart repository URL, chart name, and exact values.yaml parameters from the official Foundry Local documentation before deploying to production. Choosing Between the Two Helm Chart Arc Extension authentication API key EntraID Version upgrades Manual helm upgrade or Flux Automatic, managed by Microsoft GitOps compatible Yes (Flux HelmRelease) Yes (via Azure Policy / desired state) Requires cluster access Yes No (after initial registration) Best for Platform engineers, custom configs OT-managed sites, multi-site fleet Disconnected operation Works after initial deploy Works; reconciles on reconnect Control plane K8S native management (kubectl) K8S native management + REST API control plane Early Customer Validation and Key Scenarios Early customer validation is shaping the preview -helping ensure Foundry Local meets real-world requirements for latency, data control, and operating in constrained or disconnected environments across industries such as energy, manufacturing, government, financial services, and retail. Based on this early feedback, customers are prioritizing scenarios such as: Sovereign and regulated o On-site inference with data, models, and processing under customer control o Decision support in disconnected or restricted-network environments o In-jurisdiction processing for sensitive records and casework o Real-time detection and situational awareness within secure facilities Industrial and critical infrastructure o Edge operations assistants combining sensor telemetry with conversational AI o Low-latency quality inspection and process verification on factory floors o Predictive maintenance for remote or intermittently connected equipment o Local safety monitoring and operational oversight close to systems This input is guiding improvements across deployment flows, model catalog experience, hardware coverage, telemetry visibility, and documentation -so teams can evaluate and adopt Foundry Local more quickly and confidently in the environments above. Examples: CNC Anomaly Explanation: A machine vision system on a CNC line classifies a surface defect and passes the classification JSON to the Foundry Local endpoint. Phi-4-mini generates a plain-language root-cause hypothesis for the operator, referencing the specific machining parameters. Disconnected Safety Procedure Lookup: An offshore platform or remote mine site loses WAN connectivity. The Foundry Local pods continue serving requests from the AKS cluster on the Azure Local node - Kubernetes keeps the pods running, the model is already on the local PersistentVolume, and no external dependency is required. Workers query safety procedures (LOTO sequences, chemical handling) from an intranet application backed by the same inference endpoint. Qwen2.5-7B fits within 8–12 GB VRAM and supports a 32K token context window, making it viable for inline procedure retrieval without a separate vector database - useful when plant-floor infrastructure is minimal. Foundry Local for Devices and Foundry Local on Azure Local: What's Different Foundry Local for devices reached general availability for developer devices -Windows 10/11, macOS (Apple Silicon), and Android. That release targets a specific scenario: a developer or end user running AI inference on their own machine, with the model executing locally on their CPU, GPU, or NPU. The install is a single command (winget or brew), the service runs directly on the host OS, and there is no Azure subscription or infrastructure required. It is a developer tool and an application-embedded runtime. General overview of Foundry Local is available here: What is Foundry Local? - Foundry Local | Microsoft Learn The public preview for Azure Local single node is a different deployment target built for a different operational context. The runtime is the same - ONNX Runtime, the same model catalog, the same OpenAI-compatible API - but where it runs, how it is deployed, and how it is managed are entirely different. Foundry Local for Devices (GA) Foundry Local on Azure Local Single Node (Preview) Target Developer machines, end-user devices Enterprise edge servers on the factory floor or remote site OS Windows 10/11, macOS, Android Linux container on AKS on Azure Local Hardware Laptops, workstations, NPU-equipped devices Validated server hardware from the Azure Local catalog GPU access Direct host GPU (CUDA, DirectML, Apple Neural Engine) NVIDIA device plugin on Kubernetes Installation winget install or brew install Arc-enabled Kubernetes extension or Helm chart Lifecycle management Manual update via winget upgrade Managed via Helm/Flux or Arc extension operator Intended consumers One developer or one application on one machine Multiple applications sharing one inference endpoint on the plant network Disconnected operation Supported after model download; primarily online Designed for persistent disconnected operation with NVMe-cached models Model persistence Local device cache Kubernetes PersistentVolume on local storage Operational model Developer installs and manages it Platform team deploys it; applications consume it as a service The short version: the GA device release is for building and running AI-enabled applications on a single machine. The Azure Local single-node preview is for deploying Foundry Local as a shared, production inference service that runs continuously on validated industrial hardware, survives WAN outages, and is consumed by multiple workloads running on the same edge cluster. If you are prototyping an application on your laptop using the GA release, the same application code - specifically the OpenAI-compatible API calls - runs unchanged against the Azure Local deployment. You change only the base_url from localhost to the Kubernetes Service Built for Secure Industrial and Sovereign Operations Foundry Local supports Microsoft’s sovereign cloud principles—allowing AI workloads to operate fully locally, with customer‑controlled data boundaries and governance. Integration with Azure Arc provides unified management, configuration, and monitoring across hybrid and disconnected landscapes, enabling organizations to meet stringent compliance and operational requirements while adopting advanced AI capabilities. Learn more about Foundry Local on Azure Local RECOMMENDED participate in Foundry Local on Azure Local preview form link Foundry Local on Azure Local Documentation link Reach out to the team for support requests, feedback or suggestions here: FoundryLocal_Support@microsoft.com Foundry Local on Azure Local: HELM deployment Demo - link Foundry Local is now Generally Available link
From fragmented sites to consistent governance: Azure Arc patterns for adaptive cloud strategy.
In Manufacturing companies, hybrid architectures aren’t transitional—they’re persistent. Most large manufacturers operate across remote plants, branch sites, private datacenters, and Azure. The main challenge manufacturers face isn’t adopting cloud services, it is preventing long‑term operational fragmentation: multiple teams, multiple tools, inconsistent security controls, and uneven governance as the estate grows. When manufacturing IT grows organically, systems end up scattered across factories, edge, and cloud—creating fragmentation instead of flow. Azure Arc addresses this as an architectural control‑plane pattern: it extends Azure management to infrastructure and Kubernetes outside Azure by projecting them into Azure Resource Manager (ARM) so they can be governed using Azure-native primitives such as policy, RBAC, and monitoring. This article describes three architecture patterns that consistently emerge in manufacturing and edge scenarios. Each pattern addresses a distinct set of constraints—ranging from centralized governance across hybrid estates, to plant‑adjacent platforms, to fully disconnected environments—and illustrates how Azure services can be composed to support these realities in a scalable, well‑governed way. Typical manufacturing environments must contend with some or many of the following components: Latency & determinism: plant-floor systems often require local execution Distributed footprint: dozens/hundreds of sites with varying maturity Connectivity variability: some sites are intermittently connected Regulatory & data constraints: some workloads must remain on premises Cloud: Native cloud applications including the AI based research applications, SAP systems, etc. As a result, the estate becomes a mix of Azure + non‑Azure infrastructure. The failure mode isn’t performance—it’s inconsistent operations: different patching methods, different monitoring stacks, and uneven security baselines. Azure Arc is positioned specifically to create unity across that operational model by bringing hybrid resources into the Azure control plane. A helpful way to think about Arc in manufacturing scenario is to separate the control plane and the data plane: Arc enables a centralized control plane by projecting resources, like the ones below, into ARM: Azure Resource Manager (resource inventory, tags, RBAC, Policy) Security posture & compliance (Defender for Cloud, policy initiatives) Observability and operations workflows (Azure Monitor, Update Manager, etc.) Whereas the data plane remains at distributed locations meaning: Workload execution remains at plants, private DCs, or edge sites Kubernetes API endpoints, runtime traffic, OT systems remain local This separation is an architectural lever allowing organizations to standardize governance without forcing workload relocation. A high-level design decision matrix Constraint Recommended starting pattern Why Many sites + inconsistent tooling Arc as distributed control plane Standardizes governance and inventory via ARM projection Plant workloads require local platform Azure Local + Arc Uses Azure Local baseline + Arc integration for operations Connectivity cannot be assumed Disconnected/intermittent design Forces control-plane boundary design + local autonomy Pattern 1 — Azure Arc as the distributed control plane (for VM, SQL severs+ Kubernetes) When this pattern fits Use this pattern when: You need consistent governance across plants, datacenters, and multicloud You can maintain at least periodic connectivity for control-plane sync You want Azure policy/security/monitoring to apply uniformly Architecture intent Azure Arc projects existing bare metal, VM, and Kubernetes infrastructure resources into Azure to handle operations with Azure management and security tools. Azure Arc simplifies governance and management by delivering a consistent multicloud and on-premises management platform experience for Azure services. Once projected, you can operate hybrid resources using Azure-native constructs (inventory, compliance reporting, policy scope) and apply standardized guardrails. From an architectural standpoint, Azure Arc establishes a centralized control plane in Azure (ARM, RBAC, Policy, Resource Graph) and decentralized data plane remaining at plants, datacenters, or edge sites. This separation enables organizations to apply management‑group–scoped policies, standardized tagging, and Defender for Cloud controls consistently across environments, while preserving local execution and latency characteristics required by manufacturing workloads. Why this pattern matters: It moves organizations from managing individual sites to governing the entire estate as one. It minimizes operational drift as environments expand across plants and edge locations. Centralized control simplifies enforcement of standards without slowing local operations. The pattern creates predictability at scale in highly distributed environments. It establishes a stable foundation for future modernization initiatives. Pattern 2 — Azure Local + Azure Arc (plant-adjacent platform pattern) When this pattern fits Use this pattern when: Workloads must run on premises for latency, sovereignty, or operational control You want cloud-consistent operations without creating a separate tooling island You need a standardized platform for virtualized + containerized workloads at sites You need the local AI inferencing where data needs to be processed at the source/plant site Architecture intent Azure Local Microsoft’s distributed infrastructure solution that extends Azure capabilities to customer-owned environments. It facilitates the local deployment of both modern and legacy applications across distributed or sovereign locations. Azure Local accelerates cloud and AI innovation by seamlessly delivering new applications, workloads, and services from cloud to edge, using Azure Arc as the unifying control plane. From an architectural perspective, Azure Local serves as the local data plane for applications—supporting general‑purpose virtual machines, managed Kubernetes (AKS), and selected Azure services—while Azure Arc extends the Azure control plane to that environment for inventory, policy, monitoring, and security integration. This separation allows workloads to run close to manufacturing systems without creating a parallel or disconnected operational model. Azure Local supports a broad spectrum of workload types on the same platform foundation, including: Traditional line‑of‑business applications on virtual machines Modern containerized workloads using AKS on Azure Local Azure‑consistent platform services that can be deployed locally, such as Azure Virtual Desktop and SQL Managed Instance GPU‑accelerated workloads for AI inferencing and computer vision scenarios Why this pattern matters: Without a platform like Azure Local integrated through Azure Arc, on‑premises manufacturing workloads tend to evolve into bespoke environments with inconsistent security, monitoring, and lifecycle management—making long‑term scale and governance increasingly difficult. Pattern 3 — Disconnected edge workloads (connectivity-constrained design) When this pattern fits Use this pattern when: Sites cannot assume continuous connectivity Local autonomy is required for safety or production continuity You still want centralized governance when connected Architecture intent In manufacturing and edge scenarios, some environments must operate without continuous internet connectivity due to regulatory constraints, physical isolation, or operational risk tolerance. In these cases, architectures must assume that cloud control‑plane access is intermittent or unavailable, while local execution must continue without disruption. Disconnected architectures shift the primary design concern from availability of services to autonomy of execution. This pattern applies to environments that are fully offline, intermittently connected, or explicitly restricted from sending data to public cloud endpoints. Azure supports this model through Disconnected-containers, where containerized services are deployed and operated fully offline. Once provisioned, these containers run entirely on local infrastructure with no runtime dependency on Azure endpoints, enabling uninterrupted execution even during extended disconnection periods. Disconnected containers are offered through commitment tier pricing, each offering a discounted rate compared to the Standard pricing model. Learn more about pricing here: Plan and Manage Costs - Microsoft Foundry | Microsoft Learn Before attempting to run a Docker container in an offline environment, make sure you know the steps to successfully download and use the container. For example: Host computer requirements and recommendations. The Docker pull command you use to download the container. How to validate that a container is running. How to send queries to the container's endpoint once it's running. Why this pattern matters: This pattern matters because not all environments can rely on continuous connectivity. It enables critical workloads to operate independently at the edge while remaining aligned to central governance when connectivity is available. The pattern prioritizes local autonomy without sacrificing architectural discipline. It reduces operational risk in constrained or disconnected sites. This approach ensures resilience and continuity in environments where connectivity cannot be assumed. Manufacturing IT will remain distributed by design. The risk is not hybrid complexity, but fragmented operations. By centralizing the control plane while keeping execution local, Arc enables consistent security, compliance, and operations across cloud, datacenter, and edge.Automating Arc-enabled SQL Server license type configuration with Azure Policy
Azure Arc enables customers to onboard SQL Server instances - hosted on Linux or Windows - into Azure, regardless of where they are hosted: on‑premises, in multicloud environments, or at the edge. Once onboarded, these resources can be managed through the Azure Portal using services like Azure Monitor, Azure Policy, and Microsoft Defender for Cloud. An important part of this onboarding is configuring the license type on each Arc-enabled resource to match your licensing agreement with Microsoft. For SQL Server, the LicenseType property on the Arc extension determines how the instance is licensed: Paid (you have a SQL Server license with Software Assurance or a SQL Server subscription), PAYG (you are paying for SQL Server software on a pay-as-you-go basis), or LicenseOnly (you have a perpetual SQL Server license). Setting this correctly matters for two reasons: Unlocking additional benefits: customers with Paid or PAYG license type gain access to some Azure services at no extra cost - such as Azure Update Manager and Machine Configuration - as well as exclusive capabilities like Best Practices Assessment and Remote Support Enabling pay-as-you-go billing: customers who do not have Software Assurance can pay for SQL Server software only when they use it via their Azure subscription by setting the license type to PAYG Configure the license types at scale using Azure Policy Configuring the license type on each Arc-enabled SQL Server instance can be done manually in the Azure Portal, but for large scale operations, automation is essential. One way to implement automation is via PowerShell, as explained here: Configure SQL Server - SQL Server enabled by Azure Arc | Microsoft Learn. But here we will focus on how this can be automated using Azure Policy. An existing article, written by Jeff Pigott, explains this process for Windows Server, which inspired extending the same approach to SQL Server. How to deploy the policy? Deployment has two steps: Create/update the Azure Policy definition and assignment Start a remediation task so existing Arc-enabled SQL Server extensions are brought into compliance You can deploy Azure Policy in multiple ways. In this article, we use PowerShell. See also: Tutorial: Build policies to enforce compliance - Azure Policy | Microsoft Learn. Source code: microsoft/sql-server-samples/.../arc-sql-license-type-compliance. Personal repository: claestom/sql-arc-policy-license-config. Definition and assignment creation Download the required files: # Optional: create and enter a local working directory mkdir sql-arc-lt-compliance cd sql-arc-lt-compliance $baseUrl = "https://raw.githubusercontent.com/microsoft/sql-server-samples/master/samples/manage/azure-arc-enabled-sql-server/compliance/arc-sql-license-type-compliance" New-Item -ItemType Directory -Path policy, scripts -Force | Out-Null curl -sLo policy/azurepolicy.json "$baseUrl/policy/azurepolicy.json" curl -sLo scripts/deployment.ps1 "$baseUrl/scripts/deployment.ps1" curl -sLo scripts/start-remediation.ps1 "$baseUrl/scripts/start-remediation.ps1" Note: On Windows PowerShell 5.1, curl is an alias for Invoke-WebRequest . Use curl.exe instead, or run the commands in PowerShell 7+. Authenticate to Azure: Connect-AzAccount Set your variables. Only TargetLicenseType is required - all others are optional: # Required $TargetLicenseType = "PAYG" # "Paid" or "PAYG" # Optional (uncomment to override defaults) # $ManagementGroupId = "<management-group-id>" # Default: tenant root management group # $SubscriptionId = "<subscription-id>" # Default: policy assigned at management group scope # $ExtensionType = "Both" # "Windows", "Linux", or "Both" (default) # $LicenseTypesToOverwrite = @("Unspecified","Paid","PAYG","LicenseOnly") # Default: all Run the deployment script: # Minimal: uses defaults for management group, platform, and overwrite targets .\scripts\deployment.ps1 -TargetLicenseType $TargetLicenseType # With subscription scope .\scripts\deployment.ps1 -TargetLicenseType $TargetLicenseType -SubscriptionId $SubscriptionId # With all options .\scripts\deployment.ps1 ` -ManagementGroupId $ManagementGroupId ` -SubscriptionId $SubscriptionId ` -ExtensionType $ExtensionType ` -TargetLicenseType $TargetLicenseType ` -LicenseTypesToOverwrite $LicenseTypesToOverwrite Parameter notes: ManagementGroupId (optional): management group where the policy definition is created. Defaults to the tenant root management group when not specified ExtensionType (optional, default Both ): Windows , Linux , or Both . When Both , a single policy definition and assignment covers both platforms SubscriptionId (optional): if provided, assignment scope is subscription (otherwise management group scope) TargetLicenseType (required): Paid or PAYG LicenseTypesToOverwrite (optional, default all): controls which current states are eligible for update Unspecified = no current LicenseType Paid , PAYG , LicenseOnly = explicit current values The script also creates a system-assigned managed identity on the policy assignment and assigns required roles automatically. Role assignments include retry logic (5 attempts, 10-second delay) to handle managed identity replication delays, which helps prevent common PolicyAuthorizationFailed errors. Remediation task creation After deployment, allow a few minutes for Azure Policy to run a compliance scan for the selected scope. You can monitor this in Azure Policy → Compliance. More info: Get policy compliance data - Azure Policy | Microsoft Learn. Set your variables. TargetLicenseType is required and must match the value used during deployment: # Required $TargetLicenseType = "PAYG" # Must match the deployment target # Optional (uncomment to override defaults) # $ManagementGroupId = "<management-group-id>" # Default: tenant root management group # $SubscriptionId = "<subscription-id>" # Default: remediation runs at management group scope # $ExtensionType = "Both" # Must match the platform used for deployment Then start remediation: # Minimal: uses defaults for management group and platform .\scripts\start-remediation.ps1 -TargetLicenseType $TargetLicenseType -GrantMissingPermissions # With subscription scope .\scripts\start-remediation.ps1 -TargetLicenseType $TargetLicenseType -SubscriptionId $SubscriptionId -GrantMissingPermissions # With all options .\scripts\start-remediation.ps1 ` -ManagementGroupId $ManagementGroupId ` -ExtensionType $ExtensionType ` -SubscriptionId $SubscriptionId ` -TargetLicenseType $TargetLicenseType ` -GrantMissingPermissions Parameter notes: ManagementGroupId (optional): defaults to tenant root management group ExtensionType (optional, default Both ): must match the platform used for the assignment SubscriptionId (optional): run remediation at subscription scope TargetLicenseType (required): must match the assignment target GrantMissingPermissions (optional switch): checks and assigns missing required roles before remediation starts You can track remediation progress in Azure Policy → Remediation → Remediation tasks. It can take a few minutes to complete, depending on scope and resource count. Recurring Billing Consent (PAYG) When TargetLicenseType is set to PAYG , the policy automatically includes ConsentToRecurringPAYG in the extension settings with Consented: true and a UTC timestamp. For details of this requirement see: Move SQL Server license agreement to pay-as-you-go subscription - SQL Server enabled by Azure Arc | Microsoft Learn. The policy also checks for ConsentToRecurringPAYG in its compliance evaluation - resources with LicenseType: PAYG but missing the consent property are flagged as non-compliant and remediated. This applies both when transitioning to PAYG and for existing PAYG extensions that predate the consent requirement (backward compatibility). Note: Once ConsentToRecurringPAYG is set on an extension, it cannot be removed - this is enforced by the Azure resource provider. When transitioning away from PAYG, the policy changes LicenseType but leaves the consent property in place. RBAC When .\scripts\deployment.ps1 creates the policy assignment, it uses -IdentityType SystemAssigned . Azure then creates a managed identity for that assignment. The assignment identity needs these roles at assignment scope (or inherited scope): Azure Extension for SQL Server Deployment: allows updating Arc SQL extension settings, including LicenseType Reader: allows reading resource and extension state for policy evaluation Resource Policy Contributor: allows policy-driven template deployments required by DeployIfNotExists This identity is used whenever DeployIfNotExists applies changes, both during regular compliance evaluation and during remediation runs. By default, the deployment script assigns these roles automatically with built-in retry logic to handle managed identity replication delays, which helps prevent common PolicyAuthorizationFailed errors. Brownfield and Greenfield Scenarios This policy is useful in both brownfield and greenfield Azure Arc environments. Brownfield: existing Arc SQL inventory In a brownfield environment, you already have Arc-enabled SQL Server resources in inventory and the current LicenseType values might be mixed, incorrect, or missing. This is where Azure Policy is especially useful, because it gives you a controlled way to remediate the current estate at scale. Depending on how you configure targetLicenseType and licenseTypesToOverwrite, you can use the policy to: standardize all in-scope resources on a single value set LicenseType only when it is missing migrate a specific subset, such as Paid to PAYG preserve selected states while correcting only the resources that need attention Examples: Standardize everything to Paid targetLicenseType: Paid licenseTypesToOverwrite: ['Unspecified','Paid','PAYG','LicenseOnly'] Result: every in-scope Arc SQL extension is converged to LicenseType == Paid. Backfill only missing values targetLicenseType: Paid licenseTypesToOverwrite: ['Unspecified'] Result: only resources without a configured LicenseType are updated; existing Paid, PAYG, and LicenseOnly values remain unchanged. Migrate only Paid to PAYG targetLicenseType: PAYG licenseTypesToOverwrite: ['Paid'] Result: only resources currently set to Paid are updated to PAYG; missing, PAYG, and LicenseOnly remain unchanged. When transitioning to PAYG, the policy also automatically sets ConsentToRecurringPAYG with Consented: true and a UTC timestamp, as required for recurring pay-as-you-go billing. Protect existing PAYG, fix only missing or LicenseOnly targetLicenseType: Paid licenseTypesToOverwrite: ['Unspecified','LicenseOnly'] Result: resources with no LicenseType or with LicenseOnly are updated to Paid, while existing PAYG stays untouched. Greenfield: newly onboarded SQL Servers In a greenfield scenario, the main value of Azure Policy is ongoing enforcement. Once new SQL Servers are onboarded to Azure Arc and fall within the assignment scope, the policy can act as a governance control to keep LicenseType aligned with your business model. This means Azure Policy is not only a remediation mechanism for existing inventory, but also a way to continuously enforce the intended license configuration for future Arc-enabled SQL Server resources. Azure Policy vs tagging By default, Microsoft manages automatic deployment of SQL Server extension for Azure. It include an option to enforce the LicenseType setting via tags. See Manage Automatic Connection - SQL Server enabled by Azure Arc | Microsoft Learn for details. This way all newly onboarded SQL Server instance are set to the desired LicenceType from day one. The deployment of the Azure Policy is still important to ensure that the changes of the extension properties or ad-hoc additions of the SQL Server instances stay compliant to our business model. A practical way to think about it: Tagging ensures the initial compliance of the newly connected Arc-enabled SQL servers Azure Policy enforces ongoing compliance of the existing Arc-enabled SQL servers Tools Interested in gaining better visibility into LicenseType configurations across your estate? Below you'll find an insightful KQL query and an accompanying workbook to help track compliance. KQL Query resources | where type == "microsoft.hybridcompute/machines" | where properties.detectedProperties.mssqldiscovered == "true" | extend machineIdHasSQLServerDiscovered = id | project name, machineIdHasSQLServerDiscovered, resourceGroup, subscriptionId | join kind= leftouter ( resources | where type == "microsoft.hybridcompute/machines/extensions" | where properties.type in ("WindowsAgent.SqlServer","LinuxAgent.SqlServer") | extend machineIdHasSQLServerExtensionInstalled = iff(id contains "/extensions/WindowsAgent.SqlServer" or id contains "/extensions/LinuxAgent.SqlServer", substring(id, 0, indexof(id, "/extensions/")), "") | project License_Type = properties.settings.LicenseType, machineIdHasSQLServerExtensionInstalled)on $left.machineIdHasSQLServerDiscovered == $right.machineIdHasSQLServerExtensionInstalled | where isnotempty(machineIdHasSQLServerExtensionInstalled) | project-away machineIdHasSQLServerDiscovered, machineIdHasSQLServerExtensionInstalled Source: Configure SQL Server - SQL Server enabled by Azure Arc | Microsoft Learn. Azure Workbook claestom/azure-arc-sa-workbook: Azure Workbook for monitoring Software Assurance compliance across Arc-enabled servers and SQL Server instances. Resources Configure SQL Server - SQL Server enabled by Azure Arc | Microsoft Learn Azure Policy documentation | Microsoft Learn Automating Windows Server Licensing Benefits with Azure Arc Policy | Microsoft Community Hub Recurring billing consent - SQL Server enabled by Azure Arc | Microsoft Learn claestom/azure-arc-sa-workbook: Azure Workbook for monitoring Software Assurance compliance across Arc-enabled servers and SQL Server instances microsoft/sql-server-samples/.../arc-sql-license-type-compliance claestom/sql-arc-policy-license-config Thank you!
Building Microsoft’s Sovereign AI on Azure Local with NVIDIA RTX PRO and Next Gen NVIDIA Rubin
This blog explores how Azure Local, in partnership with NVIDIA, enables governments and regulated industries to build and operate Sovereign AI within their own trusted boundaries. From enterprise AI acceleration available today with NVIDIA RTX PRO™ Blackwell GPUs to a forward‑looking preview of next‑generation NVIDIA Rubin support, Azure Local provides a consistent platform to run advanced AI workloads—connected or fully disconnected—without sacrificing control, compliance, or governance. Together with Foundry Local, AKS on Azure Local, and Azure Arc, customers can bring AI closer to sensitive data and evolve their Sovereign Private Cloud strategies over time with confidence.Announcing the General Availability of the Azure Arc Gateway for Arc-enabled Kubernetes!
We’re excited to announce the General Availability of Arc gateway for Arc‑enabled Kubernetes. Arc gateway dramatically simplifies the network configuration required to use Azure Arc by consolidating outbound connectivity through a small, predictable set of endpoints. For customers operating behind enterprise proxies or firewalls, this means faster onboarding, fewer change requests, and a smoother path to value with Azure Arc. What’s new: To Arc‑enable a Kubernetes Cluster, customers previously had to allow 18 distinct endpoints. With Arc gateway GA, you can do the same with just 9, a 50% reduction that removes friction for security and networking teams. Why This Matters Organizations with strict outbound controls often spend days, or weeks, coordinating approvals for multiple URLs before they can onboard resources to Azure Arc. By consolidating traffic to a smaller set of destinations, Arc gateway: Accelerates onboarding for Arc‑enabled Kubernetes by cutting down the proxy/firewall approvals needed to get started. Simplifies operations with a consistent, repeatable pattern for routing Arc agent and extension traffic to Azure. How Arc gateway works Arc gateway introduces two components that work together to streamline connectivity: Arc gateway (Azure resource): A single, unique endpoint in your Azure tenant that receives incoming traffic from on‑premises Arc workloads and forwards it to the right Azure services. You configure your enterprise environment to allow this endpoint. Azure Arc Proxy (on every Arc‑enabled Kubernetes Cluster): A component of the Arc K8s agent that routes agent and extension traffic to Azure via the Arc gateway endpoint. It’s part of the core Arc agent; no separate install is required. At a high level, traffic flows: Arc-enabled Kubernetes agent → Arc Proxy → Enterprise Proxy → Arc gateway → Target Azure service. Scenario Coverage As part of this GA release, Arc-enabled Kubernetes Onboarding and other common Arc‑enabled Kubernetes scenarios are supported through Arc gateway, including: Arc-enabled Kubernetes Cluster Connect Arc-enabled Kubernetes Resource View Custom Location Azure Policy's Extension for Azure Arc For other scenarios, including Microsoft Defender for Containers, Azure Key Vault, Container Insights in Azure Monitor, etc., some customer‑specific data plane destinations (e.g., your Log Analytics workspaces, Storage Accounts, or Key Vault URLs) still need to be allow‑listed per your environment. Please consult the Arc gateway documentation for the current scenario‑by‑scenario coverage and any remaining per‑service URLs. Get started Create an Arc gateway resource using the Azure portal, Azure CLI, or PowerShell. Allow the Arc gateway endpoint (and the small set of core endpoints) in your enterprise proxy/firewall. Onboard or update clusters to use your Arc gateway resource. For step‑by‑step guidance, see the Arc gateway documentation on Microsoft Learn. FAQs Does Arc gateway require new software on my clusters? No additional installation - Arc Proxy is part of the standard Arc-enabled Kubernetes Agent. Will every Arc scenario route through the gateway today? Arc-enablement, and other scenarios are covered at GA; some customer‑specific data plane endpoints (for example, Log Analytics workspace FQDNs) may still need to be allowed. Check the docs for the latest coverage details. What is the status of Arc gateway for other infrastructure types? Arc gateway is already GA for Arc-enabled Servers, and Azure Local. Tell us what you think We’d love your feedback on Arc gateway GA for Kubernetes - what worked well, what could be improved, and which scenarios you want next. Use the Arc gateway feedback form to share your input with the product team.Announcing Public Preview: Simplified Machine Provisioning for Azure Local
Deploying infrastructure at the edge has always been challenging. Whether it’s retail stores, factories, branch offices, or remote sites, getting servers racked, configured, and ready for workloads often require skilled IT staff on-site. That process is slow, expensive, and error-prone, especially when deployments need to happen at scale. To address this, we’re introducing Public Preview of Simplified Machine Provisioning for Azure Local - a new way to provision Azure Local hardware with minimal onsite interaction, while maintaining centralized control through Azure. This new approach enables customers to provision hardware by racking, powering on, and letting Azure do the rest. New Machine Provisioning Simplified machine provisioning shifts configuration to Azure, reducing the need for technical expertise on-site. Instead of manually configuring each server locally, IT teams can now: Define provisioning configuration centrally in Azure Securely complete provisioning remotely with minimal steps Automate provisioning workflows using ARM templates and ensure consistency across sites Built on Open Standards Simplified machine provisioning on Azure Local is based on the FIDO Device Onboarding (FDO) specification, an industry-standard approach for securely onboarding devices at scale. FDO enables: Secure device identity and ownership transfer protecting machines with zero trust supply chain security A consistent onboarding model across device classes, this foundation can extend beyond servers to broader edge scenarios. Centralized Site-Based Configuration in Azure Arc The new machine provisioning flow uses Azure Arc Site, allowing customers to define configuration once and apply it consistently across multiple machines. In Azure Arc, a site represents a physical business location (store/factory/campus) and the set of resources associated with it. It enables targeted operations and configuration at a per‑site level (or across many sites) for consistent management at scale. With site-based configuration, customers can: Create and manage machine provisioning settings centrally in the Azure portal Define networking and environment configuration at the site level Reuse the same configuration as new machines are added Minimal Onsite Interaction Simplified provisioning is designed to minimize onsite effort. The on-site staff only rack and power on the hardware and insert the prepared USB. No deep infrastructure or Azure expertise required. After exporting the ownership voucher and sharing it with IT, the remaining provisioning is completed remotely by IT teams through Azure. The prepared USB is created using a first‑party Microsoft USB Preparation Tool that comes with the maintenance environment* package available through the Azure portal, enabling consistent, repeatable creation of bootable installation media. *Maintenance environment - a lightweight bootstrap OS that connects the machine to Azure, installs required Azure Arc extensions, and then downloads and installs the Azure Local operating system. End-to-End visibility into Deployment Customers get visibility into deployment progress which helps in quickly identifying where a deployment is in the process and respond faster when issues arise. They can look into the status using Provisioning experience in Azure portal or using Configurator app. Seamless Transition to Cluster Creation and Workloads Once provisioning is complete, machines created through this flow are ready for Azure Local cluster creation. Customers can proceed with cluster setup and workload deployment. How it works? At a high level, this simpler way of machine provisioning looks like this: Minimal onsite setup Prepare a USB drive using machine provisioning software Insert the prepared USB drive & boot the machine Share the machine ownership voucher with IT team. Provision remotely Create an Azure Arc site Configure networking, subscription, and deployment settings Download provisioning artifacts from the Azure portal Deploy Azure Local cluster using existing flows in Azure Arc. Once provisioning is complete, the environment is ready for cluster creation and workload deployment on Azure Local. Status and progress are visible in both the Azure portal, and the Configurator app. IT teams can monitor, troubleshoot, and complete provisioning remotely. Available Now in Public Preview This new experience empowers organizations to deploy Azure Local infrastructure faster, more consistently, and at scale, while minimizing on-site complexity. We invite customers and partners to explore the preview and help us shape the future of edge infrastructure deployment. Try it at https://aka.ms/provision/tryit. Refer documentation for more details.Upgrade Azure Local operating system to new version
11/14/2025 Revision The recommended upgrade paths have changed with the Azure Local 2510 release, and the information in this blog is now outdated. Please refer to the following release notes for the latest information: Azure Local release information Today, we’re sharing more details about the end of support for Azure Local, with OS version 25398.xxxx (23H2) on October 31, 2025. After this date, monthly security and quality updates stop, and Microsoft Support remains available only for upgrade assistance. Your billing continues, and your systems keep working, including registration and repair. There are several options to upgrade to Azure Local, with OS version 26100.xxxx (24H2) depending on which scenario applies to you. Scenario #1: You are on Azure Local solution, with OS version 25398.xxxx If you're already running the Azure Local solution, with OS version 25398.xxxx, there is no action required. You will automatically receive the upgrade to OS version 26100.xxxx via a solution update to 2509. Azure Local, version 23H2 and 24H2 release information - Azure Local | Microsoft Learn for the latest version of the diagram. If you are interested in upgrading to OS version 26100.xxxx before the 2509 release, there will be an opt-in process available in the future with production support. Scenario #2: You are on Azure Stack HCI and haven’t performed the solution upgrade yet Scenario #2a: You are still on Azure Stack HCI, version 22H2 With the 2505 release, a direct upgrade path from version 22H2 OS (20349.xxxx) to 24H2 OS (26100.xxxx) has been made available. To ensure a validated, consistent experience, we have reduced the process to using the downloadable media and PowerShell to install the upgrade. If you’re running Azure Stack HCI, version 22H2 OS, we recommend taking this direct upgrade path to the version 24H2 OS. Skipping the upgrade to the version 23H2 OS will be one less upgrade hop and will help reduce reboots and maintenance planning prior to the solution upgrade. After then, perform post-OS upgrade tasks and validate the solution upgrade readiness. Consult with your hardware vendor to determine if version 24H2 OS is supported before performing the direct upgrade path. The solution upgrade for systems on the 24H2 OS is not yet supported but will be available soon. Scenario #2b: You are on Azure Stack HCI, version 23H2 OS If you performed the upgrade from Azure Stack HCI, version 22H2 OS to version 23H2 OS (25398.xxxx), but haven’t applied the solution upgrade, then we recommend that you perform post-OS upgrade tasks, validate the solution upgrade readiness, and apply the solution upgrade. Diagram of Upgrade Paths Conclusion We invite you to identify which scenarios apply to you and take action to upgrade your systems. On behalf of the Azure Local team, we thank you for your continuous trust and feedback! Learn more To learn more, refer to the upgrade documentation. For known issues and remediation guidance, see the Azure Local Supportability GitHub repository.
