Azure Arc Blog articles

Bringing AI to the Factory Floor with Foundry Local - Now in Public Preview on Azure Local

liranlyabock_microsoft — Fri, 17 Apr 2026 15:23:10 GMT

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.

Example of a model deployment YAML file

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.

Foundry Local on Arc high level Service Diagram

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

SQL Server enabled by Azure Arc Overview

NaufalPrawironegoro — Thu, 16 Apr 2026 15:00:00 GMT

Table of Contents

What is Azure Arc-enabled SQL Server?
Connecting SQL Server to Azure Arc (4-step onboarding)
Your SQL Server is Now in Azure (unified management)
SQL Best Practices Assessment
Monitoring and Governance
Troubleshooting Guide
Azure Arc Demo

What You Can Learn from This Article

This article walks you through the end-to-end journey of bringing external SQL Servers (on-prem, AWS, GCP, edge) under Azure management using Azure Arc. Specifically, you'll learn how to onboard SQL Server instances via the Arc agent and PowerShell script, navigate the unified Azure Portal experience for hybrid SQL estates, enable and interpret SQL Best Practices Assessments with Log Analytics, apply Azure Policy and performance monitoring across all environments, leverage Azure Hybrid Benefit for cost savings, and troubleshoot common issues like assessment upload failures, Wire Server 403 errors, and IMDS connectivity problem, with a real case study distinguishing Azure VM vs. Arc-enabled server scenarios.

1. What is Azure Arc-enabled SQL Server?

Azure Arc helps you connect your SQL Server to Azure wherever it runs.

Whether your SQL Server is running on-premises in your datacenter, on AWS EC2, Google Cloud, or at an edge location Azure Arc brings it under Azure management. This means you get the same governance, security, and monitoring capabilities as native Azure resources and streamline migration journey to Azure, effectively manage SQL estate at scale and strengthen security and governance posture

Cloud innovation. Anywhere.

SQL Server migration in Azure Arc includes an end-to-end migration journey with the following capabilities:

Continuous database migration assessments with Azure SQL target recommendations and cost estimates.
Seamless provisioning of Azure SQL Managed Instance as destination target, also with an option of free instance evaluation.
Option to choose between two built-in migration methods: real-time database replication using Distributed Availability Groups (powered by the Managed Instance link feature), or log shipping via backup and restore (powered by Log Replay Service feature).
Unified interface that eliminates the need to use multiple tools or to jump between various places in Azure portal.
Microsoft Copilot is integrated to assist you at select points during the migration journey.

learn more in SQL Server migration in Azure Arc – Generally Available | Microsoft Community Hub

1.1 The Problem Azure Arc Solves

Organizations typically have SQL Servers scattered across multiple environments:

Location	Challenge Without Azure Arc
On-premises datacenter	Separate management tools, no unified view
AWS EC2 instances	Multi-cloud complexity, different monitoring
Google Cloud VMs	Inconsistent governance and policies
Edge / Branch offices	Limited visibility, manual compliance
VMware / Hyper-V	No cloud-native management features

Azure Arc solves this by extending a single Azure control plane to ALL your SQL Servers regardless of where they physically run

Azure Arc Overview Microsoft Learn: https://learn.microsoft.com/en-us/azure/azure-arc/overview
Architecture Reference — Administer SQL Server with Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/azure/architecture/hybrid/azure-arc-sql-server
Documentation Index — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/?view=sql-server-ver17
SQL Server migration in Azure Arc (Community Hub): https://techcommunity.microsoft.com/blog/azuresqlblog/sql-server-migration-in-azure-arc-generally-av...

2. Connecting SQL Server to Azure Arc

Connecting SQL Server to Azure Arc

This section shows how to onboard your SQL Server to Azure Arc. Once connected, your SQL Server appears in Azure Portal alongside your other Azure resources.

2.1 Step 1: Access Azure Arc Portal

Navigation: Azure Portal → Azure Arc → Machines

Figure 1: Azure Arc | Machines, Starting Point for Onboarding

Description: The Azure Arc Machines blade is your entry point for connecting servers outside Azure. Click 'Onboard/Create' dropdown and select 'Onboard existing machines' to begin. The left menu shows Azure Arc capabilities: Machines, Kubernetes clusters, Data services, Licenses, etc. This is where ALL your Azure Arc-enabled servers will appear after onboarding.

2.2 Step 2: Configure Onboarding Options

Select your operating system, enable SQL Server auto-discovery, and choose connectivity method:

Figure 2: Onboarding Configuration, Enable SQL Server Auto-Discovery

Description: Key settings: (1) Operating System select Windows or Linux, (2) SQL Server checkbox, 'Automatically connect any SQL Server instances to Azure Arc' enables auto-discovery of SQL instances on the server, (3) Connectivity method, 'Public endpoint' for direct internet access or 'Private endpoint' for VPN/ExpressRoute. The SQL Server checkbox is crucial, it installs the SQL Server extension automatically.

💡 Important: Check the 'Connect SQL Server' option! This ensures SQL Server instances are automatically discovered and connected to Azure Arc.

2.3 Step 3: Download the Onboarding Script

Azure generates a customized PowerShell script containing your subscription details and configuration:

Figure 3: Generated Onboarding Script, Ready to Download

Description: The portal generates a PowerShell script customized for your environment. Key components: (1) Agent download from Azure CDN, (2) Installation commands, (3) Pre-configured connection parameters (subscription, resource group, location). Click 'Download' to save the script. Requirements note: Server needs HTTPS (port 443) access to Azure endpoints.

2.4 Step 4: Run the Script on Your Server

Copy the script to your SQL Server and execute it in PowerShell as Administrator:

Figure 4: Executing OnboardingScript.ps1 on the SQL Server

Description: PowerShell console showing script execution from D:\Azure Arch directory. The script (OnboardingScript.ps1, 3214 bytes) installs the Azure Connected Machine Agent and registers the server with Azure Arc. During execution, a browser window opens for Azure authentication. After completion, the server appears in Azure Arc within minutes.

What happens during onboarding:

Azure Connected Machine Agent is downloaded and installed
Agent establishes secure connection to Azure
Server is registered as an Azure Arc resource
SQL Server extension is installed (if checkbox was enabled)
SQL Server instance appears in Azure Arc → SQL Server

Connect Your SQL Server to Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/connect?view=sql-server-ver17
Prerequisites — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/prerequisites?view=sql-server-ver17
Manage Automatic Connection — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/manage-autodeploy?view=sql-server-ver17

3. Your SQL Server is Now Visible in the Azure Control Plane

Once connected via Azure Arc, your SQL Server is projected as a resource in the Azure Portal,right alongside your native Azure SQL resources. This is the power of Azure Arc: your SQL Server remains where it runs (on-premises, in AWS, or anywhere else), but Azure's management plane now extends to it. You can govern, monitor, and secure it with the same tools you use for Azure-native resources, without migrating the workload.

3.1 Unified View in Azure Portal

After onboarding, you can see your Azure Arc-enabled SQL Server through two paths:

Navigation Path	What You See
Azure Arc → SQL Server	All Azure Arc-enabled SQL instances
Azure Arc → Machines	The host server with extensions

3.2 Management Experience Similar to SQL Server on Azure VM

The management capabilities for Azure Arc-enabled SQL Server are very similar to SQL Server on Azure VM. The screenshots below show the SQL Server on Azure VM experience Azure Arc-enabled SQL Server provides nearly identical functionality.

Whether your SQL Server runs natively on an Azure VM or is connected from outside Azure via Azure Arc, you get access to a consistent management experience including:

Figure 5: SQL Server Management Overview — Consistent Experience

Description: This shows the management experience for SQL Server in Azure. Whether connected via Azure Arc or running on Azure VM, you see: SQL Server version and edition, VM details, License type configuration, Storage configuration, and feature status. Azure Arc-enabled SQL Server provides a nearly identical dashboard experience, extending this unified view to your on-premises and multi-cloud servers.

3.3 Azure Hybrid Benefit - Use Your Existing Licenses

One of the key cost-saving advantages which is you can apply Azure Hybrid Benefit (AHB) to Azure SQL Database and Azure SQL Managed Instance, saving up to 30% or more on licensing costs by leveraging your existing Software Assurance-enabled SQL Server licenses.

Note: Azure Hybrid Benefit applies to Azure SQL Database and SQL Managed Instance. For SQL Server running on-premises or in other clouds managed via Azure Arc, AHB does not apply directly. However, Arc-enabled SQL Server provides other benefits such as centralized management, Azure-integrated security, and access to Extended Security Updates (ESUs).

Figure 6: Azure Hybrid Benefit Configuration

Description: License configuration for SQL Server on Azure VM, showing three options: Pay As You Go, Azure Hybrid Benefit (selected), and HA/DR. With Azure Hybrid Benefit, organizations with existing SQL Server licenses and active Software Assurance can save up to 30% or more on SQL Server licensing costs running on Azure VMs (as reflected in the Azure portal configuration blade). Free SQL Server licenses for High Availability and Disaster Recovery are also available for Standard and Enterprise editions.

Configure SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/manage-configuration?view=sql-server-ver1...
Manage Licensing and Billing — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/manage-license-billing?view=sql-server-ve...

4. SQL Best Practices Assessment

One of the most valuable features available to Azure Arc-enabled SQL Server is the Best Practices Assessment — automatically evaluating your SQL Server configuration against Microsoft's recommendations.

4.1 Prerequisites: Log Analytics Workspace

Before enabling assessment, you need a Log Analytics Workspace to store the results:

Figure 7: Create Log Analytics Workspace

Description: Log Analytics workspace creation form. Fill in: Subscription, Resource Group, Name (green checkmark indicates valid name), and Region (choose same region as your resources). This workspace stores assessment results, performance metrics, and logs from ALL your SQL Servers both Azure Arc-enabled and Azure VMs.

Figure 8: Log Analytics Workspace Ready for Use

Description: Workspace overview showing: Status (Active), Pricing tier (Pay-as-you-go), and Operational issues (OK). The 'Get Started' section guides you through: (1) Connect a data source, (2) Configure monitoring solutions, (3) Monitor workspace health. This workspace becomes the central repository for all your SQL Server insights.

4.2 Enable SQL Best Practices Assessment

Navigate to your SQL Server (Azure Arc-enabled or Azure VM) and enable the assessment:

Figure 9: SQL Best Practices Assessment Enable Feature

Description: Assessment landing page explaining the feature: evaluates indexes, deprecated features, trace flags, statistics, etc. Results are uploaded via Azure Monitor Agent (AMA). Click 'Enable SQL best practices assessments' to begin configuration. This feature is available for BOTH Azure Arc-enabled SQL Server and Azure SQL VMs.

Figure 10: Assessment Configuration Select Log Analytics Workspace

Description: Configuration panel requiring: (1) Enable checkbox, (2) Log Analytics workspace selection, (3) Resource group for AMA. The warning 'No Log Analytics workspace is found' appears if you haven't created one yet, see Section 4.1. Once configured, assessments run on schedule and upload results to your workspace.

4.3 Run and Review Assessment

Figure 11: Run Assessment Button

Description: After configuration, click 'Run assessment' to start evaluation. Assessment duration varies: 5-10 minutes for small environments, 30-60 minutes for large ones. The 'View latest successful assessment' button (disabled until first run completes) opens the results workbook.

Figure 12: Assessment Results History

Description: Assessment history showing multiple runs with different statuses: 'Scheduled' (pending), 'Completed' (results available), 'Failed - result expired' (data retention exceeded). Regular assessments help catch configuration drift over time. If you see 'Failed - upload failed', see the Troubleshooting section.

Figure 13: Assessment Recommendations Actionable Insights

Description: Best practices workbook showing three panels: (1) Recommendation Summary with severity (High, Medium) and categories (DBConfiguration, Performance, Index, Backup), (2) Recommendation Details with target and name, (3) Details panel showing selected item — example: 'Enable instant file initialization' for performance improvement. High severity items should be addressed immediately.

Severity Levels:

Severity	Description	Action Timeline
🔴 High	Critical issues affecting performance or security	Address immediately
🟡 Medium	Important optimizations recommended	Within 30 days
🟢 Low	Nice-to-have improvements	As time permits
ℹ️ Info	Informational findings	Review and acknowledge

Configure Best Practices Assessment — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/assess?view=sql-server-ver17
Troubleshoot Best Practices Assessment — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/troubleshoot-assessment?view=sql-server-v...
Assess Migration Readiness — SQL Server enabled by Azure Arc Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/migration-assessment?view=sql-server-ver1...
Log Analytics Workspace creation: https://learn.microsoft.com/en-us/azure/azure-monitor/logs/quick-create-workspace

5. Monitoring and Governance

With your SQL Servers connected to Azure (via Azure Arc or native), you gain access to Azure's full monitoring and governance capabilities.

5.1 Azure Policy Compliance

Apply consistent governance policies across ALL your SQL Servers — regardless of where they run:

Figure 14: Azure Policy Compliance Dashboard

Description: Compliance dashboard showing: 28% overall compliance (5 of 18 resources), pie chart with Compliant (green), Exempt, and Non-compliant (red). The table lists non-compliant resources (microsoft.hybridcompute type = Azure Arc-enabled servers). Use this to ensure ALL SQL Servers, on-premises, cloud, edge meet your organization's standards.

5.2 Performance Monitoring

Figure 15: Performance Monitoring Unified Dashboard

Description: Performance dashboard showing: Logical Disk Performance (C: drive 30% used), CPU Utilization (1.75% average, 5.73% 95th percentile), Available Memory (3.1GB average). This same dashboard works for Azure Arc-enabled servers, giving you consistent visibility across your entire SQL Server estate.

5.3 Service Dependency Mapping

Figure 16: Service Map Visualize Dependencies

Description: Map view showing server FNPSVR01 with 17 processes connecting to Port 443 (7 servers) and Port 53 (1 server). Machine Summary shows FQDN, OS (Windows Server 2016), IP address. Use this to understand application dependencies before maintenance or migration available for both Azure Arc-enabled and Azure-native servers.

6. Troubleshooting Guide

This section covers common issues encountered when working with Azure Arc-enabled SQL Server and Azure SQL VMs.

6.1 Common Issues Overview

Issue	Symptoms	Azure Arc-enabled	Azure VM
Assessment Upload Failed	Status: 'Failed - upload failed'	✅ Applies	✅ Applies
Wire Server 403	Agent cannot connect	❌ N/A	✅ Applies
IMDS Disabled	Cannot obtain token	❌ N/A	✅ Applies
Azure Arc Agent Connectivity	Server not appearing	✅ Applies	❌ N/A
SQL Login Failed	Machine account denied	✅ Applies	✅ Applies

6.2 Real Case Study: Assessment Upload Failed on Azure VM

Note: This case study is from an Azure VM (not Azure Arc-enabled). The Wire Server and IMDS issues are specific to Azure VMs. Azure Arc-enabled servers use different connectivity mechanisms.

Symptoms observed:

Assessment status: 'Failed - upload failed'
Local data collected successfully (415 issues)
Data not appearing in Log Analytics workspace

Root causes identified from logs:

Error 1 (ExtensionLog ):

[ERROR] Customer disable the IMDS service, cannot obtain IMDS token.

Error 2 (WaAppAgent.log):

[WARN] GetMachineGoalState() failed: 403 (Forbidden) to 168.63.129.16 Resolution for Azure VMs

Fix Wire Server (168.63.129.16) connectivity:

# Test connectivity Test-NetConnection -ComputerName 168.63.129.16 -Port 80 # Add route if missing route add 168.63.129.16 mask 255.255.255.255 <gateway> -p # Add firewall rule if needed New-NetFirewallRule -DisplayName "Allow Azure Wire Server" -Direction Outbound -RemoteAddress 168.63.129.16 -Action Allow

Fix IMDS (169.254.169.254) connectivity:

# Test IMDS Invoke-RestMethod -Uri "http://169.254.169.254/metadata/instance?api-version=2021-02-01" -Headers @{Metadata="true"} # Add firewall rule if blocked New-NetFirewallRule -DisplayName "Allow Azure IMDS" -Direction Outbound -RemoteAddress 169.254.169.254 -Action Allow

Test Azure Arc agent connectivity:

# Check Arc agent status & "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" show # Test connectivity to Azure endpoints & "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" check

6.3 Azure Arc-enabled SQL Server Connectivity Issues

For Azure Arc-enabled servers (not Azure VMs), connectivity issues are different:

Required Azure endpoints for Azure Arc agent:

Endpoint	Port	Purpose
management.azure.com	443	Azure Resource Manager
login.microsoftonline.com	443	Azure AD authentication
*.his.arc.azure.com	443	Azure Arc Hybrid Identity
*.guestconfiguration.azure.com	443	Guest configuration

Troubleshoot Best Practices Assessment Microsoft Learn: https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/troubleshoot-assessment?view=sql-server-v...
What is IP Address 168.63.129.16 (Wire Server) Microsoft Learn: https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16
Azure Instance Metadata Service (IMDS) Microsoft Learn: https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service
Troubleshoot IMDS Connection Issues on Windows VMs Microsoft Learn: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/windows-vm-imds-connec...
Troubleshoot Azure Windows VM Agent Issues Microsoft Learn: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/windows-azure-guest-ag...

7. Troubleshooting Guide

Demo Deck: Azure Arc for Windows Server and SQL Server

More Additional Resources :

Learn more about the new migration capability in Azure Arc on Microsoft Learn.
Onboard your SQL Server to Azure Arc today.
Learn more about continuous migration assessment from SQL Server enabled by Azure Arc.
Download resources on github.com/microsoft /sql -server-samples

From fragmented sites to consistent governance: Azure Arc patterns for adaptive cloud strategy.

sakshimalhotra — Wed, 15 Apr 2026 17:11:28 GMT

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.

Figure 1: 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.

Figure 2 - AzureArc integrates external resources into Azure landing zones via ARM, enabling a unified control plane and consistent governance across cloud, on‑premises, and edge environments.

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.

Figure 3: Azure local integration with select azure services

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.

Figure 4: Azure Local disconnected architecture

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.

Azure Arc Server Mar 2026 Forum Recap

Aurnov_Chattopadhyay — Tue, 14 Apr 2026 17:54:18 GMT

Please find the recording for the monthly Azure Arc Server Forum on YouTube!

During the March 2026 Azure Arc Server Forum, we discussed:

Deploying Ansible Playbooks through Machine Configuration as Azure Policy (Learn more: Announcing Private Preview: Deploy Ansible Playbooks using Azure Policy via Machine Configuration) and sign up at https://aka.ms/ansible-arc-signup
New MECM (SCCM) connector supporting Cloud Native Server Management, sign up for Private Preview at aka.ms/arc-mecm /preview
Automatic Agent Upgrade at Scale Enablement (Learn more: Run the latest Azure Arc agent with Automatic Agent Upgrade (Public Preview))
TPM-backed Identity for Secure Onboarding, sign up for Private Preview at
https://aka.ms/arc-tpm-backed-identity/preview/

To sign up for the Azure Arc Server Forum and newsletter, please register with contact details at https://aka.ms/arcserverforumsignup/.

For the latest agent release notes, check out What's new with Azure Connected Machine agent - Azure Arc | Microsoft Learn.

Our April 2026 forum will be held on Thursday, April 16 at 9:30 AM PST / 12:30 PM EST. We look forward to you joining us, thank you!

Automating Arc-enabled SQL Server license type configuration with Azure Policy

TomClaes — Mon, 13 Apr 2026 07:06:25 GMT

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

Thank you!

Simplify Azure Arc Server Onboarding with Ansible and the New Onboarding Role

alinetran — Wed, 08 Apr 2026 06:40:42 GMT

If you’re already using Ansible to manage your infrastructure, there’s now a simpler—and more secure—way to bring machines under Azure Arc management. We’ve introduced a new Azure Arc onboarding role designed specifically for automated scenarios like Ansible playbooks. This role follows the principle of least privilege, giving your automation exactly what it needs to onboard servers—nothing more.

A better way to onboard at scale

Many customers want to standardize Azure Arc onboarding across hybrid and multicloud environments, but run into common challenges:

Over‑privileged service principals
Manual steps that don’t scale
Inconsistent onboarding across environments

By combining Ansible with the Azure Arc onboarding role, you can:

Automate server onboarding end‑to‑end
Reduce permissions risk with a purpose‑built role
Scale confidently across thousands of machines
Integrate Arc onboarding into existing Ansible workflows

Built for automation, designed for security

The new onboarding role removes the need to assign broader Azure roles just to connect servers to Azure Arc. Instead, your Ansible automation can authenticate using a tightly scoped identity that’s purpose‑built for Arc onboarding—making security teams happier without slowing down operations.

Whether you’re modernizing existing datacenters or managing servers across multiple clouds, this new approach makes Azure Arc onboarding simpler, safer, and repeatable.

Get started in minutes

Our Microsoft Learn documentation provides guidance to help you get started quickly:
Connect machines to Azure Arc at scale with Ansible

Check out the Arc onboarding role, part of the Azure collection in Ansible Galaxy:

Ansible Galaxy - azure.azcollection - Arc onboarding role

Anything else you’d like to see with Azure Arc + Linux? Drop us a comment!

Run the latest Azure Arc agent with Automatic Agent Upgrade (Public Preview)

yunishussein — Fri, 03 Apr 2026 19:30:06 GMT

Customers managing large fleets of Azure Arc servers need a scalable way to ensure the Azure Arc agent stays up to date without manual intervention. Per server configuration does not scale, and gaps in upgrade coverage can lead to operational drift, missed features, and delayed security updates.

To address this, we’re introducing two new options to help customers enable Automatic Agent Upgrade at scale: applied as a built-in Azure Policy and a new onboarding CLI flag.

The built-in policy makes it easy to check whether Automatic Agent Upgrade is enabled across a given scope and automatically remediates servers that are not compliant.

For servers being newly onboarded, customers can enable the feature at onboarding by adding the --enable-automatic-upgrade flag to the azcmagent connect command, ensuring the agent is configured correctly from the start.

What is Automatic Agent Upgrade?

Automatic Agent Upgrade is a feature, in public preview, that automatically keeps the Azure Connected Machine agent (Arc agent) up to date. Updates are managed by Microsoft, so once enabled, customers no longer need to manually manage agent upgrades.

By always running the latest agent version, customers receive all the newest capabilities, security updates, and bug fixes as soon as they’re released. Learn more: What's new with Azure Connected Machine agent - Azure Arc | Microsoft Learn.

Getting Started

Apply automatic agent upgrade policy

Navigate to the ‘Policy’ blade in the Azure Portal

Navigate to the ‘Compliance’ section and click ‘Assign Policy’

Fill out the required sections
- Scope: Subscription and resource group (optional) that policy will apply to
- Policy definition: Configure Azure Arc-enabled Servers to enable automatic upgrades

Navigate to the ‘Remediation’ tab and check the box next to ‘Create a remediation task’

Navigate to the ‘Review + create’ tab and press ‘Create’. The Policy has been successfully applied to the scope.

For more information on this process, please visit this article Quickstart: Create policy assignment using Azure portal - Azure Policy | Microsoft Learn.

Apply automatic agent upgrade CLI Flag

Adding the following flag enables automatic agent upgrade during onboarding

--enable-automatic-upgrade

While this flag can be used on a single server, it can also be applied at scale using one of the existing Azure Arc at scale onboarding methods and adding the flag Connect hybrid machines to Azure at scale - Azure Arc | Microsoft Learn.

Here is an at scale onboarding sample using a basic script.

azcmagent connect --resource-group {rg} --location {location} --subscription-id {subid} --service-principal-id {service principal id} --service-principal-secret {service principal secret} --tenant-id {tenant id} --enable-automatic-upgrade

To get started with this feature or learn more, please refer to this article Manage and maintain the Azure Connected Machine agent - Azure Arc | Microsoft Learn.

Announcing Private Preview: Deploy Ansible Playbooks using Azure Policy via Machine Configuration

alinetran — Thu, 09 Apr 2026 16:25:52 GMT

Azure Arc is on a mission to unify security, compliance, and management for Windows and Linux machines—anywhere. By extending Azure’s control plane beyond the cloud, Azure Arc enables organizations to unify governance, compliance, security and management of servers across on‑premises, edge, and multicloud environments using a consistent set of Azure tools and policies.

Building on this mission, we’re excited to announce the private preview of deploying Ansible playbooks through Azure Policy using Machine Configuration, bringing Ansible‑driven automation into Azure Arc’s policy‑based governance model for Azure and Arc‑enabled Linux machines.

This new capability enables you to orchestrate Ansible playbook execution directly from Azure Policy (via Machine Configuration) without requiring an Ansible control node, while benefiting from built‑in compliance reporting and remediation.

Why this matters

As organizations manage increasingly diverse server estates, they often rely on different tools for Windows and Linux, cloud, on-premises, or at the edge—creating fragmented security, compliance, and operational workflows. Many organizations rely on Ansible for OS configuration and application setup, but struggle with:

Enforcing consistent configuration across distributed environments
Detecting and correcting drift over time
Integrating Ansible automation with centralized governance and compliance workflows

With this private preview, Azure Policy becomes the single control plane for applying and monitoring Ansible‑based configuration, bringing Linux automation into the same governance model already used for Windows. Configuration is treated as policy—declarative, auditable, and continuously enforced—with compliance results surfaced in familiar Azure dashboards.

What’s included in the private preview

In this preview, you can:

Use Azure Policy to trigger Ansible playbook execution on Azure and Azure Arc–enabled Linux machines
Execute playbooks locally on each target machine, triggered by policy.
Enable drift detection and automatic remediation by default
View playbook execution status and compliance results directly in the Azure Policy compliance dashboard, alongside your other policies

This provides a unified security, compliance and management experience across Windows and Linux machines—whether they’re running in Azure or connected through Azure Arc—while using your existing Ansible investments.

Join the private preview

If you’re interested in helping shape the future of Ansible‑based configuration management in Azure Arc, we’d love to partner with you. We’re especially interested in hearing your stories around usability, compliance reporting, and real‑world operational workflows.

👉 Sign up for the private preview and we'll reach out to you.

We’ll continue investing in deeper Linux parity, broader scenarios, and tighter integration across Azure Arc’s security, governance and compliance experiences.

We look forward to enhancing your unified Azure Arc experience for deploying, governing, and remediating configuration with Ansible—bringing consistent security, compliance, and management to Windows and Linux machines not only in Azure, but also across on‑premises and other public clouds.

Announcing Public Preview of Argo CD extension on AKS and Azure Arc enabled Kubernetes clusters

Poornima99 — Tue, 24 Mar 2026 08:00:00 GMT

We are excited to announce public preview of the Argo CD extension for Azure Kubernetes Service (AKS) and Azure Arc-enabled Kubernetes clusters.

As GitOps becomes the standard for deploying and operating applications at scale, enterprises need a way to implement GitOps while staying compliant with best practices for security and identity management. Argo CD extension delivers on this need across 3 pillars -

Trusted Identity and Secure Access

The Argo CD extension integrates with Microsoft Entra ID to provide a secure, enterprise-ready experience for:

Secure authentication using Workload Identity federation to Azure Container Registry (ACR) and Azure DevOps. This removes the need for long-lived credentials or hard-coded secrets in Git Repos, moving your CD pipelines closer to a true zero-trust architecture.
Single Sign-On (SSO) using existing Azure identities.

Enterprise-Grade Hardening and Security

This preview introduces several enhancements to improve your security posture:

To minimize the attack surface, the extension’s images are built on Azure Linux, specifically engineered for reduced CVEs and improved baseline security.
Opt-in to automatic patch releases to stay current on security fixes while maintaining full control over your change management processes.

Parity with upstream Argo CD

Argo CD extension is designed to remain fully aligned with the upstream Argo CD open‑source project, so teams can use Argo CD as they do today with support for

Configuring Argo CD extension with High availability (HA) for production‑grade deployments of critical workloads.
Using hub‑and‑spoke architecture for multi‑cluster GitOps scenarios.
Application and ApplicationSet, enabling automated and scalable application delivery across large fleets of clusters.

Getting Started

We invite you to explore the Argo CD extension and provide feedback as we continue to evolve GitOps capabilities for Kubernetes.

To get started today, you can enable the extension on your clusters using the Azure CLI. Argo CD extension management via the Azure Portal will be available in a few weeks.

Building Microsoft’s Sovereign AI on Azure Local with NVIDIA RTX PRO and Next Gen NVIDIA Rubin

meenagowdar — Mon, 16 Mar 2026 20:08:55 GMT

Across governments, regulated industries, and critical infrastructure, organizations are moving quickly to adopt advanced AI but with a clear requirement: AI systems should be built and operated within Sovereign boundaries. The question is no longer whether to use advanced models, but where those models should run, who controls them, and how they can evolve over time without compromising sovereignty, resilience, or trust.

Many of these customers are building Sovereign Private Clouds: environments designed to run their most sensitive and mission-critical workloads entirely within their own operational boundaries. These environments often span on-premises datacenters, edge locations, and, in some cases, fully disconnected deployments. Customers want the power of modern AI, but available on infrastructure they control.

This is where Azure Local comes in. Azure Local helps bring Azure-consistent infrastructure, lifecycle management, and governance into customer-controlled environments. As AI workloads evolve rapidly, customers are planning for the next generation of AI acceleration and need confidence that their local infrastructure can be ready – without re-architecting their environment.

NVIDIA Rubin: Powering the Next Generation of Sovereign AI on Azure Local

Sovereign AI requirements span a wide range of deployments models – from enterprise inference and development today to large-scale, sustained AI systems in the near future. Azure Local is designed to help support this evolution by providing a consistent deployment, management, and governance model across current NVIDIA Blackwell-based systems and future NVIDIA Rubin platforms.

The NVIDIA Rubin platform represents the next wave of accelerated computing, targeting large-scale workloads that go beyond basic inference. These include frontier model inference, agentic and reasoning‑based systems, and high‑throughput AI pipelines where performance, efficiency, and interconnect matter at scale.

These are the workloads Sovereign Private Cloud customers are planning for:

National and sector specific AI models trained and operated‑ within sovereign boundaries
Advanced reasoning and agentic systems used to help customers with defense, intelligence, and critical decision-making‑
High-performance inference pipelines that operate‑ close to sensitive data, with low latency and strict compliance requirements

Foundry Local is built to help host these workloads directly inside customer environments, providing a modern AI platform for deploying, operating, and scaling advanced models under full customer control while remaining aligned with Azure API, tooling, and governance on Azure Local.

That’s why Azure Local will be adding support for NVIDIA Rubin platform, working closely with NVIDIA to enable customers to adopt this next generation of accelerated computing as part of their Sovereign Private Cloud strategy.

Enterprise AI Acceleration Available Today on Azure Local

While Rubin represents the next wave of large-scale AI acceleration, Azure Local also supports enterprise-grade GPUs available today to help customers begin building sovereign AI systems now.

Built on the NVIDIA Blackwell architecture, NVIDIA RTX PRO™ 6000 Blackwell Server Edition delivers powerful AI and visual computing performance for on-premises and sovereign environments. Azure Local harnesses the power of the RTX PRO 6000 for scenarios such as AI inferencing, code development, and data adjacent workloads, whether environments are connected to Azure or fully disconnected.

Support for the NVIDIA RTX PRO 6000 Blackwell Server Edition is generally available starting with Azure Local 2603 release. And coming soon, Azure Local will be adding support for the upcoming models of the Blackwell series, including the NVIDIA RTX PRO™ 4500 Blackwell Server Edition. This allows customers to start building and operating sovereign AI workloads today, while preparing for next generation platforms such as NVIDIA Rubin as they become available.

From Infrastructure to Models: Bringing AI Closer to the Data

With Foundry Local services on Azure Local, customers can deploy and operate advanced AI models directly inside their sovereign environments. This includes access to modern models and APIs from the Foundry catalog, alongside NVIDIA-optimized models and frameworks, enabling high-performance AI execution close to sensitive data.

Using Azure Kubernetes Services (AKS) on Azure Local, customers can containerize and deploy AI workloads consistently across public and sovereign environments. This supports scenarios where models are built in the cloud and operated locally, or built and run entirely within customer-controlled boundaries, while maintaining a consistent application and operations model.

Together, this enables customers to continuously evolve AI solutions over time without sacrificing control, compliance, or operational consistency.

A Platform That Evolves With Customers

Azure Local is more than infrastructure. Through Azure Arc, it helps deliver consistent management, policy enforcement, and lifecycle operations across sovereign environments, with integrated security and monitoring capabilities.

This platform approach allows Sovereign Private Cloud customers to adopt new GPU architectures, AI frameworks, and models over time, without re-architecting their environments, while maintaining a strong security posture and compliance with regulatory requirements.

Azure Local and NVIDIA will work closely with OEMs including Dell, HPE, and Lenovo to enable validated hardware platforms and GPU support over time. This helps ensure customers can adopt new AI infrastructure with confidence as part of their Sovereign Private Cloud strategy.

As AI workloads continue to advance, Azure Local remains focused on one simple goal: enabling customers to run demanding AI workloads securely, compliantly, and under their control, today and into the future.

To learn more: https://aka.ms/azurelocal

Azure Arc Server Feb 2026 Forum Recap

Aurnov_Chattopadhyay — Thu, 12 Mar 2026 23:24:03 GMT

Please find the recording for the monthly Azure Arc Server Forum at YouTube!

During the February 2026 Azure Arc Server Forum, we discussed:

Arc Server Reporting & Dashboard (Jeff Pigot, Sr. Solution Engineer): Check out this awesome visual reporting bringing together different management services and experiences across Azure Arc-enabled servers on GitHub at Arc Software Assurance Benefits Dashboard.
VM Applications (Yunis Hussein, Product Manager): Shared private preview experience and capabilities for 3P Application Deployment and Patching on Azure Arc-enabled servers. Please fill out this form to participate in Private Preview.
Windows Server 2016 ESUs enabled by Azure Arc: Portal Experience Feedback (George Enninful): Please sign up on the feedback form.

To sign up for the Azure Arc Server Forum and newsletter, please register with contact details at https://aka.ms/arcserverforumsignup/.

For the latest agent release notes, check out What's new with Azure Connected Machine agent - Azure Arc | Microsoft Learn.

Our March 2026 forum will be held on Thursday, March 26 at 9:30 AM PST / 12:30 PM EST. We look forward to you joining us, thank you!

Announcing the General Availability of the Azure Arc Gateway for Arc-enabled Kubernetes!

jalenmcg — Tue, 03 Mar 2026 23:12:14 GMT

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:

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

PragyaDwivedi — Thu, 26 Feb 2026 18:02:37 GMT

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.

Azure Arc Server Jan 2026 Forum Recap

Aurnov_Chattopadhyay — Tue, 20 Jan 2026 18:51:56 GMT

During the January 2026 Azure Arc Server Forum, the Azure Arc product group showcased:

Essential Machine Management capabilities in Azure Compute Hub
Windows Server Hot Patch: Roadmap and Update on billing commencement
Preview of new TPM based Onboarding to Azure Arc
Recap of SQL Server Major Announcements from 2025

What can you do to stay in touch?

Connect with the Azure Arc product group provide feedback on the expired and stale Arc Server Experience
Stay on the latest Azure Arc agent version to get the latest security and quality fixes
Register for SQL Con 2026 at sqlcon.us for insight into the future of SQL

Check out the YouTube recording for the session at Arc Server Forum January 2026.

To sign up for the Azure Arc Server Forum and newsletter, please register with contact details at https://aka.ms/arcserverforumsignup/.

Our next session will be on Thursday, February 19 at 9:30 AM PST. We look forward to you joining us, thank you!

Azure Arc Monthly Forum Recap – November 2025

yunishussein — Wed, 17 Dec 2025 17:55:17 GMT

Key Highlights

Auto Agent Upgrade

Status: Public Preview
Capability: Automatically updates AZCM Agent
Support: Email arcautoupgradefeedback@microsoft.com for feedback or issues.

Essential Machine Management (EMM)

Status: Private Preview
Capability: Enables simple and unified machine management experience.
Link: https://aka.ms/operationsCenterLab
Support: Email machineEnrollmentSupport@microsoft.com for feedback and issues.

Machine Configuration – CIS Baseline Compliance

Status: Public Preview
Capability: Filter, search, exclude and modify baseline settings in Azure Policy.
Link: aka.ms/machine-config-insiders
Support: Email machineconfig@microsoft.com for feedback and issues.

November 2025 FAQs

Essential Machine Management (EMM)

Does EMM cover Azure Local? Yes, Azure Local is supported.
Optimizations vs. Recommendations? Recommendations come from Azure Advisor (security, observability, configs). Optimizations focus on cost and emissions for now.
Is Arc being rebranded as Operations Center? No. Operations Center is a new unified management experience.
Training material for Operations Center? We have published official documentation (link) which provides an overview of Operations Center.
Setup costs for Log Analytics & Monitor? The Azure Monitor Workspace is free with the metrics that are configured through EMM. The Log Analytics Workspace logs are still charged separately and the only service that is configured to send logs is Change Tracking and Inventory

Machine Configuration – CIS Baseline Compliance

Will other baselines be added? Yes.
DeployIfNotExists Policy for Security Baseline? Audit policies available; remediation is on the roadmap.
What about Windows Security Baseline? Planned for WS2025.
Override local GPO policies? Audit-only for now; no overrides yet.

Machine Configuration – OS Settings Inventory Platform

Are there any plans to give us custom classes we can build and ingest the data we want? Not at the moment.
Is it just Windows, or do you have Linux support in Guest Configuration resources? Linux support will be available soon.

Azure Arc Server Forum: 2026 Updates

Aurnov_Chattopadhyay — Mon, 08 Dec 2025 22:58:42 GMT

We are excited to announce the fourth calendar year of the Azure Arc Server Forum. We are incredibly thankful to all the customers and community members, who have joined our forum and newsletter from our start back in the Fall of 2023.

From January 2026, the monthly Azure Arc Server Forum will be hosted on the third Thursday of each month from 9:30 – 10:15 AM PST. Each Arc Server Forum includes live demos of new capabilities, question and answer sessions with the product group, and feedback opportunities covering Windows, Linux, and SQL Server management, licensing, and connectivity across hybrid, multicloud, and edge environments. Sessions are skipped in July and December for summer and winter holidays respectively.

Forum participants also receive a monthly newsletter summarizing updates including:

Announcements of General Availability, Public Preview, and Private Previews capabilities including key details and documentation
Updates on agent improvements and updates on experience changes
Opportunities to provide feedback to and influence the product group’s roadmap or engage in ongoing customer research studies
Updates on the invitation and timing of the Arc Server Forum

Recordings from the Arc Server Forum are periodically uploaded to the Azure Arc Server Forum YouTube channel: Azure Arc Server Forum - YouTube typically within 2-3 weeks of the Forum.

To sign up for the Azure Arc Server Forum and newsletter, please register with contact details at https://aka.ms/arcserverforumsignup/. Thank you!

Azure Local 22H2 Clusters: End of Service and Feature Degradation

Arpita Duppala — Tue, 25 Nov 2025 15:17:52 GMT

Azure Local (formerly Azure Stack HCI) version 22H2 reached End of Service (EOS) on May 31, 2025. As communicated earlier, this means:

No further security updates or bug fixes will be provided.
CSS support is limited to upgrade assistance of the existing environment only.

What’s Changing?

Around February 23, 2026, Microsoft will begin degrading features on 22H2 clusters. These changes align with Microsoft’s Modern Lifecycle Policy, which requires customers to stay current with servicing and system requirements to maintain support. Under this policy, failure to upgrade can lead to significant degradation of product functionality, starting with:

Disabling ESU: Extended Security Updates will no longer be available.
Disabling WSS: Windows Server Subscription benefits will be removed.

Once these changes take effect:

Customers will not be able to purchase or renew ESU or WSS for 22H2 clusters, meaning:

ESU updates will no longer be offered, leaving guest operating systems exposed to security vulnerabilities.
Guest operating systems will no longer be licensed, which can lead to compliance violations and potential service disruptions.

Any degraded feature will not be restored under best-effort support.

Customer Responsibility

If the customer chooses to remain on 22H2:

They assume full responsibility for any security vulnerabilities, compliance issues, or government regulatory requirements associated with running an unsupported version.
Microsoft does not provide guarantees or remediation for risks arising from continued use of 22H2.

Next Steps

To maintain a secure and supported environment:

Upgrade to 24H2 as soon as possible.
Learn how to upgrade → We strongly recommend planning your upgrade now to avoid service disruptions and compliance risks.

AKS enabled by Azure Arc: Powering AI Applications from Cloud to Edge [Ignite 2025]

SchumannGE — Tue, 02 Dec 2025 21:02:54 GMT

A New Era for Hybrid Kubernetes and AI

Microsoft Ignite 2025 continues to accelerate Azure’s hybrid vision, extending cloud-native innovation into datacenters, factories, retail sites, and remote, fully disconnected environments. This year’s announcements expand the capabilities of AKS enabled by Azure Arc, making it the most versatile and secure platform for deploying modern applications and AI workloads across any environment.

AKS Arc now underpins Azure’s hybrid and edge strategy — and increasingly its hybrid AI strategy by delivering consistent operations, strong security, and flexible deployment models for distributed applications.

TL;DR: New AKS Arc offering and features in 2025

Azure Kubernetes Fleet Manager for Arc-enabled clusters Public Preview
AKS on Azure Local Disconnected Operations Public Preview
Improvements to AKS on Azure Local, including lifecycle, portability, additional GPU support and hardware support expansion.
Improvements to AKS on Windows Server, improved platform reliability, security, and consistency through fixes to image packaging, dependency handling, node/agent synchronization, certificate and key management, error detection, telemetry and cleanup of stale resources
2-Node High Availability for AKS Arc at the edge Private Preview
AI Foundry Local integration for offline/hybrid AI development
KAITO on AKS Arc Public Preview for hybrid/edge model deployment
Edge RAG on Azure Local
Arc Gateway for AKS Arc Public Preview
KMS v2 for secrets encryption on AKS on Azure Local
Expanded GPU support for AKS Arc on Azure Local (RTX 6000 Ada GA, NVIDIA L-series Preview)
AKS Container Apps on Azure Local Public Preview
AKS Edge Essentials release for improved stability and offline operations
Arc-enabled Azure Monitor Pipeline, Workload Identity Federation, and Azure Container Storage enhancements
Azure Linux 3.0 support, Key Vault Secret Store extension

Azure Kubernetes Fleet Manager for Arc-enabled clusters

As customers scale Kubernetes across datacenters, edge sites, and multiple clouds, fleet operations become increasingly complex. To address this, Azure Kubernetes Fleet Manager now supports Azure Arc-enabled clusters in Public Preview, extending centralized fleet management to any CNCF-compliant Kubernetes distribution, regardless of where it runs.

With Arc-enabled clusters onboarded as Fleet Manager members, teams gain a single place to monitor fleet health, enforce governance, and deploy apps and configurations consistently across environments. Intelligent workload placement further simplifies running the right workloads in the right places, helping customers reduce operational overhead while improving agility and reliability for distributed Kubernetes at scale.

Fleet Manager now supports Arc-enabled Kubernetes clusters for unified multi-cluster management.
Enables centralized health visibility, consistent configuration rollout, and smarter workload placement across hybrid and multi-cloud fleets.

Learn more.

AKS on Azure Local: Evolving the Hybrid Managed Kubernetes Platform

This year, AKS on Azure Local introduces several major enhancements that broaden where and how customers can deploy AKS as their managed Kubernetes platform at the edge.

Disconnected Operations Public Preview

AKS on Azure Local can now operate entirely offline, supporting customers in sovereign, regulated, or isolated environments. Clusters can be deployed, managed, and updated without continuous Azure connectivity, syncing only when connectivity is temporarily restored.

Small Form Factor Bare-Metal Preview

The new SFF edition brings AKS to compact industrial PCs and constrained retail or factory environments. It delivers bare-metal performance in a much smaller footprint, including optional GPU support for edge inferencing.

Improvements to Azure Local

Azure Local continues to mature with expanded hardware compatibility, improved lifecycle reliability, and better workload portability across cloud and local deployments — enabling enterprises to standardize on AKS across all tiers of infrastructure.

2-Node High Availability for the Edge

For space- and cost-constrained environments, AKS Arc can support HA clusters with only two nodes, enabling robust production workloads in places where traditional 3-node clusters are not feasible.

Operational Excellence with AKS Arc

Enterprises operating distributed Kubernetes fleets will benefit from new governance and connectivity capabilities.

AKS Arc Gateway Public Preview

Arc Gateway simplifies hybrid connectivity by streamlining cluster onboarding and reducing required firewall rules. This creates a more secure and operationally efficient pattern for managing large fleets of Arc-enabled clusters.

KMS v2 for Kubernetes secrets encryption at rest in etcd

KMS v2 enhances Kubernetes secret encryption for hybrid and on-prem clusters, delivering improved reliability, stronger security boundaries, and consistency with Azure’s cloud-native cryptography approach.

AKS as the Hybrid AI Application Platform

AI is the defining theme of Ignite 2025 and AKS enabled by Azure Arc is now the foundation for deploying AI where the data resides. Organizations increasingly need to run AI models in datacenters, factories, field environments, and sovereign locations, and this year’s updates establish AKS Arc as Azure’s platform for distributed and offline AI workloads.

AI Foundry Local: Build and Fine-Tune AI Models Anywhere

AI Foundry Local brings Azure AI Foundry’s core capabilities: the curated model catalog, development tools, templates, and fine-tuning support into customer environments. It allows developers to run foundation models locally using optimized execution paths for GPUs, NPUs, and CPUs; fine-tune models with LoRA/QLoRA in regulated or offline scenarios; and package model artifacts for deployment on AKS clusters.
This enables a complete hybrid AI development loop that works both online and fully disconnected.

KAITO Public Preview on AKS Arc

KAITO automates model serving across cloud, datacenter, and edge. Now available on AKS Arc, it provides one-click packaging, optimization, and deployment of models built in AI Foundry Local. Customers can run ONNX, Hugging Face, or custom models with edge-aware performance optimization across diverse hardware, including CPU-only and GPU-accelerated nodes.

Expanded GPU Capabilities

Hybrid AI workloads benefit from expanded GPU options, including general availability of the NVIDIA RTX 6000 Ada, preview support for NVIDIA L-series GPUs, and new GPU Partitioning (GPU-PV) support for efficient resource utilization. These capabilities make it possible to run high-performance inferencing and training workloads across a wide range of hybrid deployment scenarios.

RAG on Azure Local: Bring Generative AI to On-Premises Data

RAG (Retrieval-Augmented Generation) on Azure Local enables organizations to ground AI in their own on-premises data without moving information to the cloud. Delivered as a first-party Azure Arc extension, it provides an integrated retrieval pipeline for ingesting, indexing, and querying enterprise content stored in datacenters or edge locations. With support for hybrid search, multi-modal data, evaluation tooling, and responsible AI controls, organizations can build RAG applications that remain fully compliant with data sovereignty requirements while reducing latency and improving accuracy.
By running the full RAG workflow locally — from retrieval to generation — customers can create intelligent applications that leverage proprietary documents, images, and other unstructured data directly within their secure environments.

Expanding Application Capabilities at the Edge

AKS Container Apps on the Edge

A major milestone this year is the public preview of ACA on the edge, enabling teams to bring the simplicity of Azure Container Apps to Azure Local. Developers can deploy AI-powered microservices, inference endpoints, and event-driven applications at the edge using the same ACA programming model used in Azure.

AKS Edge Essentials

The latest release improves cluster stability, enhances offline lifecycle operations, and strengthens both Linux and Windows support, making it easier to operate AKS at scale in constrained or intermittently connected environments.

Enhanced Storage, Telemetry, and Security for Hybrid AI

Distributed AI workloads require robust identity, storage, and observability patterns, and Ignite brings major updates in all three areas.

The Arc-enabled Azure Monitor Pipeline improves telemetry ingestion across disconnected or segmented networks, caching data locally and syncing to Azure when connectivity is available.
Workload Identity Federation for Arc enables secure, secret-less identity for workloads running at the edge.
And Azure Container Storage enabled by Arc, now expanded for AKS Arc clusters, provides a high-performance persistent storage layer suited for vector stores, embedding caches, cloud ingest and mirror.

Conclusion

Ignite 2025 represents a major step forward for AKS enabled by Azure Arc as both a hybrid Kubernetes platform and a hybrid AI application platform. With disconnected operations, edge-native Container Apps, improved GPU acceleration, KAITO for unified model serving, AI Foundry Local for offline model development, and a fully consistent operational model across cloud, datacenter, and edge, AKS Arc now enables organizations to run their most critical cloud-native and AI workloads anywhere they operate.

We look forward to continuing to support customers as they build the next generation of hybrid and edge AI applications.

Announcing the preview of Azure Local rack aware cluster

mindydiep — Tue, 27 Jan 2026 17:24:34 GMT

As of 1/22/2026, Azure Local rack aware cluster is now generally available!

To learn more: Overview of Azure Local rack aware clustering - Azure Local | Microsoft Learn

We are excited to announce the public preview of Azure Local rack aware cluster! We previously published a blog post with a sneak peek of Azure Local rack aware cluster and now, we're excited to share more details about its architecture, features, and benefits.

Overview of Azure Local rack aware cluster

Azure Local rack aware cluster is an advanced architecture designed to enhance fault tolerance and data distribution within an Azure Local instance. This solution enables you to cluster machines that are strategically placed across two physical racks in different rooms or buildings, connected by high bandwidth and low latency within the same location. Each rack functions as a local availability zone, spanning layers from the operating system to Azure Local management, including Azure Local VMs.

The architecture leverages top-of-rack (ToR) switches to connect machines between rooms. This direct connection supports a single storage pool, with rack aware clusters distributing data copies evenly between the two racks. Even if an entire rack encounters an issue, the other rack maintains the integrity and accessibility of the data. This design is valuable for environments needing high availability, particularly where it is essential to avoid rack-level data loss or downtime from failures like fires or power outages.

Network architecture diagram of an Azure Local rack aware cluster instance

Key features

Starting in Azure Local version 2510, this release includes the following key features for rack aware clusters:

Rack-Level Fault Tolerance & High Availability

Clusters span two physical racks in separate rooms, connected by high bandwidth and low latency. Each rack acts as a local availability zone. If one rack fails, the other maintains data integrity and accessibility.

Support for Multiple Configurations

Architecture supports 2 machines up to 8 machines, enabling scalable deployments for a wide range of workloads.

Scale-Out by Adding Machines

Easily expand cluster capacity by adding machines, supporting growth and dynamic workload requirements without redeployment.

Unified Storage Pool with Even Data Distribution

Rack aware clusters offer a unified storage pool with Storage Spaces Direct (S2D) volume replication, automatically distributing data copies evenly across both racks. This ensures smooth failover and reduces the risk of data loss.

Azure Arc Integration and Management Experience

Enjoy native integration with Azure Arc, enabling consistent management and monitoring across hybrid environments—including Azure Local VMs and AKS—while maintaining the familiar Azure deployment and operational experience.

Deployment Options

Deploy via Azure portal or ARM templates, with new inputs and properties in the Azure portal for rack aware clusters.

Screenshot of deployment wizard in Azure portal for Azure Local rack aware cluster

Provision VMs in Local Availability Zones via the Azure Portal

Provision Azure Local virtual machines directly into specific local availability zones using the Azure portal, allowing for granular workload placement and enhanced resilience.

Screenshot of Azure Arc virtual machine creation wizard in Azure portal

Upgrade Path from Preview to GA

Deploy rack aware clusters with the 2510 public preview build and update to General Availability (GA) without redeployment—protecting your investment and ensuring operational continuity.

Get started

The preview of rack aware cluster is now available to all interested customers. We encourage you to try it out and share your valuable feedback. To get started, visit our documentation: Overview of Azure Local rack aware clustering (Preview) - Azure Local | Microsoft Learn

Stay tuned for more updates as we work towards general availability in 2026. We look forward to seeing how you leverage Azure Local rack aware cluster to power your edge workloads!

Expanding Azure Arc for Hybrid and Multicloud Management

SatyaVel — Tue, 18 Nov 2025 16:26:46 GMT

Hybrid and multi-cloud environments are no longer optional—they’re essential for modern enterprises. At Ignite 2025, we are announcing key enhancements to Azure Arc based on your feedback, designed to simplify governance, improve security, and deliver operational consistency across diverse infrastructures. Here’s what’s new:

1. Multicloud Connector for GCP – Public Preview

Azure Arc now extends its multicloud reach with Google Cloud Platform (GCP) support in public preview. Customers can now inventory and manage resource and gain a single pane of glass across AWS, GCP, and Azure resources. Learn more https://aka.ms/multicloud-connector-gcp-blog

Agentless inventory discovery: Automatically detects GCP resources and projects them into Azure Resource Graph for unified visibility.
Arc onboarding for GCP VMs: Bring GCP virtual machines under Azure management to apply monitoring, policy, and security controls.
Secure authentication via OIDC federation: Eliminates the need for storing credentials, reducing security risk.

2. Azure virtual desktop for hybrid environments

As part of this wave of new releases, Azure Virtual Desktop for hybrid environments is now available in preview through Azure Arc server.

Building on the current offering of Azure Virtual Desktop for Azure Local, this capability enables organizations to deliver a rich virtual desktop experience on-premises—without requiring new hardware investments or hypervisor changes. In this release, Azure Virtual Desktop is enabled on Arc connected servers to address scenarios with high-latency, data residency, or application constraints that demand local VDI, while leveraging the Azure management plane for streamlined operations. This expansion provides greater deployment flexibility and supports customers who need both local and cloud-based solutions. To learn more: https://aka.ms/AVDHybridIgnite2025Blog

3. Azure Arc Auto-Agent Upgrades

Managing Connected Machine Agents just got easier. With auto agent upgrades we reduce the operational overhead and minimizes downtime risk. Ensures machines stay secure and compliant with the latest features and patches automatically. Learn more Public Preview: Auto agent upgrade for Azure Arc-enabled servers | Microsoft Community Hub

Automatic agent upgrade: Keeps agents current without manual intervention.
Flexible control: Enable or disable auto-upgrade via Azure Portal, CLI, or PowerShell.
Resilience built-in: Includes rollback and retry mechanisms for failed upgrades.

4. Azure Machine Configuration: OS Configuration Editor and Policy

The new OS Configuration Editor simplifies compliance at scale. Accelerates compliance initiatives and reduces configuration drift. Non-technical teams can manage OS settings visually, improving agility and reducing errors. Learn more https://aka.ms/MCBaselinesPreviewBlog

Visual authoring interface: Create and apply guest configuration policies without writing code.
Fleet-wide auditing: Enforce OS settings across Azure and Arc-enabled servers.
Integration with Azure Policy: Centralized governance for hybrid environments.

5. Windows Server Recovery Configuration Audit via Arc

Part of the Windows Resiliency initiative, Azure Arc now supports recovery audits. Improves disaster recovery preparedness and compliance reporting. Enterprises can proactively identify gaps and reduce downtime during critical incidents. Learn more

Audit WinRE policies: Validate Windows Recovery Environment readiness across Arc-enabled servers.
Compliance visibility: View recovery status in Azure portal dashboards.
Future roadmap: Configure your servers to receive boot critical updates and remote remediation for disaster recovery scenarios.

6. Workload Identity for Arc-enabled Kubernetes – General Availability

Secure identity management for Kubernetes workloads is now GA. Strengthens security posture by eliminating secret sprawl. Simplifies identity management for hybrid and edge-native applications, reducing operational risk. Learn more https://aka.ms/workload-identity-arc-for-kubernetes-ga

Federated identity integration: Connect workloads to Microsoft Entra without static secrets.
Token-based authentication: Pods securely access Azure resources without manual credential rotation.
Broad compatibility: Works across multiple Kubernetes distros connected via Azure Arc.

7. Azure Arc Site Manager – Public Preview Refresh

Site Manager is a powerful solution designed to streamline site configuration and edge infrastructure observability and management at scale, making it easier to manage distributed environments, apply consistent policies, and streamline workflows across hybrid and edge deployments. Learn more

Hierarchical Site Organization: Site creation that mirror an organization’s hierarchical structure
Aggregated Monitoring and Insights: Single pane of glass for monitoring distributed environments for Connectivity, Updates, Alerts and Security baseline status
Site Configurations: Define configurations at the site level and reuse them across partner solutions

8. Simplified migration journey for Arc customers - Preview

Azure Migrate now natively integrates with Azure Arc to simplify the migration journey for Arc customers. Customers can leverage Azure Arc data to generate a comprehensive business case for migration as well as full estate migration readiness assessments with no additional on-premises deployments. Learn more

Simple set up: Create a project and scope Arc resources by subscription. Azure Migrate generates business cases and assessments automatically. Optionally deploy the Azure Migrate Collector VM extension to collect additional information to improve the accuracy of business cases and assessments.
Comprehensive business case: Compare the Total Cost of Ownership of your current Arc-enabled on-premises estate with that in Azure as well as insights into sustainability improvements of migrating to Azure.
Full-estate readiness assessment: Assess the readiness of your workloads to various Azure targets such as Azure VMs, Azure SQL Databases, Azure SQL Managed Instance etc. Get right-sized recommended SKUs as well as potential monthly costs for your workloads in Azure.

9. Azure Key Vault Secret Store Extension – General Availability

Azure Key Vault Secret Store Extension (SSE) is now generally available for Arc-enabled on-premises Kubernetes, including clusters that you connect yourself and AKS Arc managed clusters. SSE automatically fetches secrets from an Azure Key Vault to the on-premises cluster for offline access. Learn more

Offline Access: With SSE, workloads can access Azure Key Vault secrets from the local Kubernetes secrets store regardless of internet connectivity interruptions.
Scalability: SSE helps very large distributed deployments with hundreds or thousands of clusters to work with Azure Key Vault by spreading demand over time.

These innovations reinforce Azure Arc’s position as the most comprehensive platform for hybrid and multicloud management. From easy connecting to AWS/GCP to Azure through multicloud connector to enabling secure workload identities and resilient OS configurations, Azure Arc is helping enterprises stay agile, secure, and compliant.