Azure Arc Blog articles

Your first model deployment on Foundry Local on Azure Local: from catalog to inference in 10 minutes

JonathanSchtechel — Wed, 03 Jun 2026 16:25:52 GMT

Foundry Local on Azure Local lets you run open-source models directly on your own Azure Local cluster, behind an OpenAI-compatible AP. It's the same experience you've gotten used to in the cloud, but the inference runs on hardware you own.

Foundry Local on Azure Local is in public preview at the time of this writing.

You've installed Foundry Local on your Azure Local cluster. The operator's pods are running, the CRDs are registered, you've checked it twice with kubectl get pods. Now what?

This blog covers the part that comes right before all of that - the lifecycle pattern you'll use to deploy any model on Foundry Local on Azure Local. Our recent announcement covers the bigger picture: multi-node inference, vLLM as a first-class runtime alongside ONNX-GenAI, and an expanded catalog. We'll keep this walkthrough single-node for clarity, but the same ModelDeployment pattern scales without changes to your client code or workflow.

By the end of this walkthrough, you'll have gone from an empty kubectl prompt to a working, OpenAI-compatible inference endpoint serving Phi-4. All in about ten minutes, using nothing but kubectl, Python, and a small sample script. We'll also show you how to switch that same flow to the new vLLM runtime by changing roughly five lines of YAML.

All the code lives in Azure-Samples/foundry-local-model-catalog. Clone it and follow along.

What you'll build

The sample walks through five steps, each driven by the same Python script with different flags:

Query the model catalog - read the ConfigMap the operator syncs from the Microsoft Foundry catalog API.
Deploy a model - create a ModelDeployment custom resource pointing at one catalog entry.
Wait for ready - the operator pulls the model image, schedules pods, and reports state.
Run inference - call the OpenAI-compatible /v1/chat/completions endpoint with an API key the operator generates for you.
Clean up - delete the deployment.

The same five steps apply whether you're serving an ONNX model on a CPU node or a vLLM model on a GPU node. We'll start with the simpler path: Phi-4 on CPU on the ONNX runtime, then show you the vLLM variant at the end.

Before you start

You'll need:

An Azure Local cluster (or any Arc-enabled Kubernetes cluster) with the Foundry Local extension installed. If you haven't set this up yet, the Foundry Local on Azure Local install guide walks through the cluster, extension, and resource requirements.
kubectl configured against that cluster, with permissions to read ConfigMaps and Secrets and to create ModelDeployment resources in the foundry-local-operator namespace.
Python 3.9 or later.

Verify the operator is alive before you go further:

kubectl get pods -n foundry-local-operator kubectl get crd | grep foundry

You should see operator pods in Running state and at least one CRD named modeldeployments.foundrylocal.azure.com. If you don't, the install docs are the right place to back up to.

Then clone and install:

git clone https://github.com/Azure-Samples/foundry-local-model-catalog.git && cd foundry-local-model-catalog && python3 -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt

Step 1 - See what's in your catalog

Start with the lowest-risk command in the sample, it talks to the cluster but changes nothing:

python catalog_sample.py --catalog-only

A few things to notice in that table:

Most models appear more than once. The same model gets packaged for different runtime/hardware combinations, and the operator picks the right container image based on which entry you reference.
There's a RUNTIME column. We'll come back to vLLM at the end of this post; for now, the default Phi-4-generic-cpu ONNX entry is what we'll deploy.
The catalog itself is just a ConfigMap. No magic, no hidden registry. The operator syncs it from the Microsoft Foundry catalog API on a CronJob, and the sample reads it the same way you would:

kubectl get configmap foundry-local-catalog -n foundry-local-operator -o yaml

If you ever wonder what's actually available on your cluster, that's the source of truth.

Step 2 - Deploy a model

Now the side-effecting part. We're going to ask the operator to deploy Phi-4 on CPU:

python catalog_sample.py --deploy-only

Under the hood, the sample builds and applies a ModelDeployment manifest that looks like this:

apiVersion: foundrylocal.azure.com/v1 kind: ModelDeployment metadata: name: phi-4-generic-cpu namespace: foundry-local-operator spec: model: catalog: name: Phi-4-generic-cpu workloadType: generative compute: cpu replicas: 1 port: 5000

The operator takes it from there. It pulls the model container image, schedules a pod, generates an API-key Secret named phi-4-generic-cpu-api-keys, and walks the deployment through Pending → Creating → Running states. The sample polls until both status.state == Running and status.deploymentReady == true.

the first deployment of a given model pulls the model image, which can take a few minutes depending on model size and network speed. The image is cached on a PersistentVolume, so the second deploy of the same model is much faster.

Step 3 - Run inference

The endpoint is up. Time to actually use it.

If you're running this script from inside the cluster (say, from a debug pod), the endpoint lives at the in-cluster service DNS and the sample picks that up automatically. Most readers will be running from a laptop, though, so we'll cover that path explicitly.

In one terminal, port-forward the deployment's service:

kubectl port-forward svc/phi-4-generic-cpu 5000:5000 -n foundry-local-operator

In another, run the sample's inference-only mode against the forwarded endpoint:

python catalog_sample.py --infer-only --endpoint https://localhost:5000 --insecure

The sample reads the API key from the auto-generated Secret and sends it as Authorization: Bearer <key>. same pattern as cloud OpenAI.

The --insecure flag bypasses self-signed TLS. Together with kubectl port-forward, this is a smoke-test setup. for real traffic, expose the deployment via Ingress or LoadBalancer.

The request body is the standard OpenAI chat-completions shape:

{ "model": "Phi-4-generic-cpu:1.0.0", "messages": [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "What is the capital of France? Reply in one sentence."} ], "max_tokens": 256 }

That response just traveled from your terminal, through kubectl port-forward, into a model serving inside your Azure Local cluster, and back.

Step 4 - Clean up

The sample's default flow deletes the deployment on its way out, so if you ran the full python catalog_sample.py (no flags) you're already clean. If you used --deploy-only or --skip-cleanup, drop it explicitly:

kubectl delete modeldeployment phi-4-generic-cpu -n foundry-local-operator

The operator garbage-collects the pod, service, and API-key Secret. The cached model image stays on its PersistentVolume, so your next deploy of the same model skips the image pull.

Going beyond CPU: vLLM in 5 lines

Now for the variant we've been pointing at. The same ModelDeployment CR, the same OpenAI-compatible endpoint, switched to a runtime built for concurrent users, demonstrated on a popular open-source model.

The diff against the manifest from Step 2:

spec: - compute: cpu + compute: gpu + runtime: vllm model: catalog: - name: Phi-4-generic-cpu + name: Mistral-7B-v0.2

The same sample script handles it:

python catalog_sample.py \ --model Mistral-7B-v0.2 \ --compute gpu \ --runtime vllm

What you get back is the same OpenAI-compatible endpoint your client code already knows, but now backed by vLLM's PagedAttention, continuous batching, and automatic planner-tuned configuration. Your application code doesn't need to know any of that; it's still POST /v1/chat/completions with a Bearer token.

That's the point of the lifecycle pattern: ONNX or vLLM, CPU or GPU, the platform engineer's deployment loop looks the same. For the architectural "why" behind multi-node, vLLM, and the expanded catalog, read the announcement.

What you've built

Ten minutes ago you had an installed-but-empty Foundry Local cluster. You now have:

A working OpenAI-compatible chat endpoint serving Phi-4.
A clear sense of what the operator manages for you (ModelDeployment CR, model image cache, API-key Secret) and what stays in your hands (which model, which runtime, which compute target).
A small, modular script you can wire into three things:
- A smoke test for every new cluster you stand up (--catalog-only → --deploy-only → --infer-only is a one-line CI step).
- An internal demo when you need to show a team that Foundry Local on Azure Local is real and reachable.
- The foundation for your team's own deployment automation - copy the manifest builder, drop the CLI, and wire it into your existing GitOps or platform tooling.

From endpoint to chat surface

The model deployment above exposes a standard OpenAI-compatible API - enough for any existing chat client to point at. If you'd like to see exactly that, Azure-Samples/local-chat-with-foundry-local picks up where this walkthrough ends: it wires the running endpoint into the Sovereign Chat Experience starter UI. About ten more minutes from working endpoint to working chat in the browser.

Where to go from here

Try the rest of the sample: --catalog-only, --deploy-only, --infer-only, and --skip-cleanup compose into whichever workflow you're testing.
Read the announcement for the architectural why behind multi-node, vLLM, and the expanded catalog.
Read the docs for the full operator and CRD reference.
Feel free to share your feedback with us at FoundryLocalOnAzure@microsoft.com. The product is in public preview, so your feedback shapes what ships next.

Build, deploy, and govern sovereign AI with Foundry Local on Azure Local

insagiv — Wed, 03 Jun 2026 07:19:19 GMT

Not every AI workload can run in the cloud. For many of our customers, data needs to stay within defined boundaries, connectivity may be limited or absent, and latency, governance, and auditability are non-negotiable.

With Foundry Local on Azure Local, you can use the same model catalog, developer workflows, and governance capabilities you know from Azure, while running AI entirely within your own environment where your data resides.

Foundry Local provides the model catalog and developer experience.
Azure Local provides the customer-managed infrastructure.
Azure Arc provides unified policy, governance, and lifecycle management across cloud and local environments.

This gives developers a consistent way to build, deploy, and operate AI. The same az commands, the same model catalog, the same Arc policies, all running on hardware you control.

Expansion of Foundry Local on Azure Local

We're expanding the Foundry Local model offering on Azure Local, with support for multi-node deployments and new agents and tools that run locally, in preview.

Deploy and run AI models locally. Run models with Foundry Local in customer-managed environments on Azure Local, across sovereign, private, and edge scenarios, including fully disconnected operation.

Choose from a flexible, high-performance model catalog. Access proprietary and community models through Foundry Local, now expanded with vLLM-optimized models alongside ONNX-based offerings. You explore and deploy through the same catalog API experience, then operate locally on Azure Local.

Build for production realities. Bring governance, identity, and auditability into your applications while keeping execution inside your controlled boundary.

See what’s new in Foundry Local on Azure Local in the Tech Community blog.

From intelligence to action: agents and tools inside the enterprise boundary

Most production AI use cases need two things: grounded answers and the ability to act on them, without sending data outside the environment. Here's how we're enabling that locally.

Preview: Agentic retrieval with Foundry Local: Ground agents in enterprise data using retrieval-augmented generation across local Microsoft 365 services, including Exchange and SharePoint. Read the Tech Community blog to learn more.

Preview: Agents and tools with Foundry Local: Build AI systems that reason, retrieve information, and take action within customer-controlled environments. Learn more.

Preview: Developer acceleration templates: Jump-start local AI application development with new Foundry solution templates, including local chat experiences and video agents, powered by Azure AI Video Indexer. Read the Tech Community to learn more.

GitHub Enterprise Local: Now available in public preview

Sovereign AI is also about how systems are built and secured, not just where they run. With GitHub Enterprise Local on Azure Local, you can bring your full software development lifecycle on-premises:

Source control and repositories
CI/CD pipelines
Security and DevSecOps workflows

GitHub Enterprise Local deploys entirely within customer-owned infrastructure, so teams get the developer tools they expect without compromising on data residency or operational control. This extends modern DevSecOps practice into sovereign environments and pairs naturally with the AI development workflows above: build, secure, and ship your AI applications within the same boundary where they run.

Read the tech community blog to learn more about GitHub Enterprise Local and how to join the preview.

Accelerating High-performance AI at the Edge with NVIDIA 

We are expanding our collaboration with NVIDIA to deliver high-performance AI capabilities directly at the edge.

At Build, we are bringing:

Azure Local and Foundry Local on NVIDIA-powered GPUs, including NVIDIA RTX PRO 6000 Blackwell Server Edition, with expanded GPU support coming soon
Integration with Nemotron models, optimized for enterprise performance
A scalable foundation for data-intensive, low-latency workloads

This partnership ensures that organizations can run advanced AI workloads where data is generated - without dependency on centralized cloud infrastructure.

Hardware options: AI factory configurations are available now in the catalog

Alongside our hardware partners, we’re bringing integrated solutions to customers building AI within sovereign environments. The Azure Local hardware catalog now includes AI factory configurations from our OEM partners, including NVIDIA-certified 8xH100 systems, with options from DataON, Dell, HPE, and Lenovo. These configurations are sized for the performance that model serving and agentic workloads require on customer-managed infrastructure.

Together with Microsoft, we are advancing sovereign AI by bringing the open NVIDIA Nemotron model family to Microsoft Foundry Local on Azure Local. This collaboration gives organizations a production-ready AI platform that enables them to deploy AI where their data resides while maintaining the governance, control, and performance needed to scale AI across the enterprise.”
Kari Briski, VP Generative AI Software Products, NVIDIA

”Sovereign AI is becoming increasingly important for governments, regulated industries, and enterprises that want to use AI while maintaining control of their data, location, and operations. Lenovo’s ThinkAgile MX Series delivers trusted, enterprise-grade infrastructure with global deployment expertise to help customers run AI wherever their data resides. Co-engineered with Foundry Local and Azure Local, this solution provides an optimized platform to deploy, run, and scale AI locally with greater simplicity, consistency, and control, while helping meet strict data residency, security, and compliance requirements."

Scott Patti - VP Infrastructure Solutions Group (ISG), Lenovo

From AI models to trusted, mission-critical systems: what this unlocks for developers and operators

AI is evolving from systems that answer questions to systems that plan, reason, and take action across workloads. These capabilities move AI from a cloud-only assumption to something you can deploy where sensitive work actually happens, with governance and operational controls intact. For our customers, this means you can now:

Keep data, identities, and audit trails inside your sovereign boundary.
Run AI inference and agentic workloads in connected, intermittently connected, or fully disconnected modes.
Apply consistent policy and governance across cloud and local environments through Azure Arc.
Use the same Foundry catalog and developer experience you already know, on infrastructure you own.
Build, secure, and ship your AI applications with GitHub Enterprise Local, keeping source control, CI/CD, and DevSecOps workflows inside the same sovereign boundary.

Resources

Join us at Build
- OD837 Shipping physical AI to the edge with Azure Local and Foundry Local https://github.com/microsoft/build26-OD837
- OD839 Foundry Local: AI solutions for industrial and sovereign needs https://github.com/microsoft/build26-OD839
- LTG425 Expanding horizons: Foundry Local for devices and on-prem
  https://build.microsoft.com/en-US/sessions/LTG425
Request to join the Foundry Local on Azure Local preview
Hands-on walkthrough: Your first model deployment on Foundry Local on Azure Local: from catalog to inference in 10 minutes | Microsoft Community Hub
Read our Tech Community blogs:
- Foundry Local announcing multi-node and vLLM support
- Agentic Retrival with Foundry Local blog: https://aka.ms/AgentsAndToolsBuildBlog2026
- Code sample / model catalog blog: https://aka.ms/foundry-local-model-catalog-blog
For more details on the expanded capabilities of Foundry Local for highly secure environments, contact your Microsoft account team
Discover Microsoft Sovereign Cloud
Explore product documentation at:
- Foundry Local models on Azure Local: https://aka.ms/FoundryLocalonAzureLocal_documentation
- Local Agentic retrieval with Foundry Local: https://aka.ms/edge-agentic-retrieval-docs

Unlock On-Prem Productivity with Agentic Retrieval in Foundry Local

moran_assaf — Tue, 02 Jun 2026 19:20:52 GMT

In today’s connected world, customers expect instant, context-rich interactions, even in environments where cloud connectivity isn’t guaranteed. That’s where Retrieval-Augmented Generation at the edge comes in. Since we launched into public preview, we’ve watched teams across regulated, disconnected, and mission-critical environments push this technology into places cloud GenAI simply couldn’t reach.

What we heard back shaped everything in this release: customers don’t just want retrieval. They want reasoning, they want agency, and they want an end-user experience that feels as natural as the one they already use in the cloud.

Today at Build 2026, we're excited to introduce Agentic Retrieval, the next evolution of our on-prem RAG platform, enabled by Azure Arc and powered by Foundry language models. Agentic Retrieval is part of Microsoft's Adaptive Cloud approach, which extends Azure capabilities to wherever customer data and workloads actually live, with Edge AI focused on bringing reasoning and grounding to on-prem, distributed, and disconnected environments. Together with Foundry Local, Agentic Retrieval continues to shape Microsoft's Foundry Anywhere commitment: flexibility, resilience, and intelligence wherever customers operate.

What’s new at Build 2026

This release introduces three major pillars that work independently or together:

Agentic Retrieval engine: a first-party orchestration runtime for planning, reasoning, conversation state, and tool calls over your local data

Knowledge: a dedicated layer for organizing, curating, and governing your grounding data, exposed via MCP and connectable to any agentic retrieval layer

Chat UI: a production-ready, polished conversational experience that ships as the default UX for Agentic Retrieval and can also be deployed standalone

Alongside, we’re delivering the platform upgrades customers asked for: flexible deployment modes (Agentic-only, Knowledge-only, or Combined), BYOM with pluggable backends, Foundry Local model catalog integration, Entra ID support, disconnected-ready, and hybrid search combined with agentic retrieval.

Agentic Retrieval: From Answering to Reasoning

Classic RAG retrieves, then generates. Agentic Retrieval plans, reasons, and acts, running multi-step retrieval and tool invocation under a first-party orchestration runtime, entirely on your infrastructure. Under the hood it manages query planning, iterative multi-hop retrieval, tool calls via MCP, conversation state, and mandatory grounding with citations and audit logging built in.

Image 1: Agentic reasoning trace: query decomposition, retrievals, tool calls, grounded answer

What customers can achieve:

Compliance, policy, and permit workflows for public sector, regulators, and defense operations, with data never leaving sovereign infrastructure
Multi-document synthesis across standards, technical manuals, contracts, and field procedures for industrial operators
An agentic chat experience for regulated and operational teams (engineers, inspectors, analysts) that reasons like a subject-matter expert
Auditable AI for sovereign and mission-critical environments, with every answer traceable to its source

Knowledge: A First-Class, Governed Data Layer

Great answers start with great knowledge. Knowledge is now a standalone component customers can deploy on its own or alongside Agentic Retrieval, exposed through an MCP wrapper so it can connect to any agentic retrieval layer, ours or yours.

This release brings Collections (segmented groups of indexed knowledge with granular access permissions), multi-source ingestion across documents, tables, images, and SharePoint (indexed source moving to public preview), high-fidelity parsing for complex enterprise content, Bring Your Own MCP to connect customer-owned data sources directly into Agentic Retrieval and the chat experience, and governance enforced at the data layer itself.

Image 2: Knowledge management view - collections, sources, and permission scopes

What customers can achieve:

Scope knowledge access to different slices of the same corpus, by plant, site, classification, or jurisdiction
Enforce data sovereignty, residency, and regulatory compliance at the knowledge layer itself
Ground both first-party Agentic Retrieval and BYO orchestration through a single governed source of truth across distributed sites
Keep classified, proprietary, and operational data fully on-prem while delivering premium chat experiences

Chat UI: Production-Ready Conversational Experience

Agentic Retrieval now ships with a polished, production-ready Chat UI as its default experience, and the same component can be deployed standalone for customers building their own stack on Foundry Local.

Highlights include Entra ID authentication (MSAL login, Bearer tokens, user identity display), pluggable backends across AI Foundry, BYOM, or mock mode with zero code changes, Chain-of-Thought visibility and inline citations that make grounding transparent to end users, standalone frontend deployment via Helm chart and container image, and disconnected-ready operation for air-gapped environments.

Image 3: Chat UI answer with Chain-of-Thought panel expanded and inline citations

What customers can achieve:

Deliver a polished end-user experience to operators, inspectors, and analysts without building UI from scratch
Build trust in regulated and industrial workflows through transparent, inspectable reasoning and grounding
Run the same UI across air-gapped facilities, sovereign clouds, and connected industrial sites
Accelerate rollout across public sector, defense, manufacturing, and other mission-critical environments

Why This Release Matters

Every update to our on-prem RAG platform has moved us toward a simple conviction: GenAI should be useful wherever customers operate, whether regulated or open, connected or disconnected, centralized or distributed.

With Agentic Retrieval, Knowledge, and Chat UI coming together, backed by Foundry on Arc, BYOM, and fully disconnected support, this is no longer “cloud RAG, but local.” It’s an agentic knowledge platform purpose-built for the realities of enterprise data: on-prem, governed, and increasingly autonomous.

Learn More

Explore Agentic retrieval documentation
Read Foundry Local on Azure Local model inferencing blog post
For more information reach out to the team at FoundryLocalOnAzure@microsoft.com

Scale On-Prem AI with Foundry Local on Azure Local: Multi-Node Inference and vLLM Support

liranlyabock_microsoft — Tue, 02 Jun 2026 19:18:28 GMT

Since announcing the public preview of Foundry Local on Azure Local for single-node, we’ve seen strong adoption in regulated industries and consistent customer demand to expand the platform for scalable deployments.

Today, we’re expanding Foundry Local model offering on Azure Local (preview) with three additions that broaden where and how you can use it:

Multi-node scheduling - distribute inference workloads across the GPU capacity in your Azure Local cluster, not just a single node
vLLM runtime support - a high-throughput serving engine purpose-built for large language models and concurrent workloads
An expanded model catalog - new models available in vLLM optimized format alongside the existing ONNX offerings

Together, these additions let you scale to higher concurrency, serve more users from a single endpoint, and run larger models on-premises. They round out Foundry Local on Azure Local into a more complete, production-grade on-premises inference platform - covering a wider range of model sizes, concurrency profiles, and hardware footprints, while preserving the same Kubernetes-native, OpenAI-compatible patterns you're already using.

Runs disconnected - no cloud round-trip required

Foundry Local on Azure Local is designed to run fully on-premises, including in disconnected and intermittently-connected environments. Model weights, prompts, and inference traffic stay entirely inside your Arc-enabled cluster - there is no per-request call to Azure, no data exfiltration to the cloud, and no dependency on a live WAN to serve inference.

Models are cached locally on Persistent Volumes after the first pull. Once cached, the inference endpoint keeps serving even when the WAN is down - across reboots, network outages, and extended disconnected operation.

API-key authentication continues working uninterrupted during disconnected periods. Microsoft Entra ID auth resumes seamlessly when connectivity returns.

The control plane is local to the cluster. The Foundry Local operator, the model catalog, and the inference runtimes all live inside Azure Local - Arc is used for fleet management and updates, not for the inference data path.

For factory floors, offshore platforms, sovereign data centers, classified sites, and remote branch offices where cloud connectivity is unreliable, restricted, or prohibited, this is what makes on-premises AI inference actually viable in production.

Multi-node scheduling: more scenarios, more capacity

Foundry Local on Azure Local now expands to support multiple nodes in your cluster. The inference operator schedules and manages deployments across the GPU capacity available cluster-wide, so you can:

GPU capacity from any node in the cluster, not just a single node’s resources

Place inference workloads where the hardware lives, with the operator managing deployments across nodes

The same Model Deployment custom resource you already use defines the workload, and it is served through the standard OpenAI-compatible endpoint (POST /v1/chat/completions). The API used to interact with conversational AI models by sending structured messages and receiving model-generated responses. Existing applications work against multi-node deployments with zero code changes.

vLLM runtime: high-throughput serving for production workloads

Alongside ONNX-GenAI, Foundry Local now offers vLLM as a first-class inference runtime. vLLM is an open-source, high-throughput serving engine that has become the standard for production LLM inference in the cloud. Bringing it to Foundry Local on Azure Local means the same performance characteristics are available on your factory floor, in your sovereign data center, or at your remote site.

Why vLLM matters for edge and on-premises inference

Capability	ONNX-GenAI	vLLM
Hardware	CPU and GPU	GPU only
Throughput	Optimized for single-user, low-latency	Optimized for high-throughput, multi-user concurrency
Memory management	Standard allocation	PagedAttention - efficient KV-cache management reduces VRAM waste
Continuous batching	Not supported	Supported - incoming requests are batched dynamically for higher GPU utilization
FP8 KV cache	Not supported	Supported on compatible models and GPUs - roughly doubles token capacity
Best for	Compact models, CPU-only nodes, single-client scenarios	Larger models, multi-user workloads, GPU-equipped clusters

Automatic GPU inference tuning with the vLLM planner

One of the operational challenges with vLLM is configuration tuning - setting GPU memory utilization, context length, batch sizes, and other parameters for a given model on a given hardware profile. Get it wrong and the pod either OOMs (runs out of memory) on startup or wastes GPU capacity.

Foundry Local addresses this with the vLLM planner, an automatic tuning component that inspects the available GPU resources, analyzes the target model's footprint, and generates a memory-safe, high-performance configuration before the model server starts. You declare what model you want to run; the planner figures out how to run it optimally on your hardware.

Full configuration reference is in the vLLM planner docs.

Identity-based access for multi-user workloads

Serving more concurrent users isn't only a throughput problem - it's also an access-control problem. Foundry Local supports two authentication modes side by side on the same endpoint:

API keys - primary and secondary keys per deployment, with zero-downtime rotation. Ideal for service-to-service traffic and automated pipelines.

Microsoft Entra ID with Azure RBAC - per-identity access using the Cognitive Services OpenAI User role (or any role granting the equivalent data-plane action). JWT validation runs inside the inference pod; authorization is enforced through the cluster's Arc-managed identity.

Enable both, and clients can present either credential type in the same Authorization: Bearer header - the platform detects which one was sent and routes to the right validation path. API-key callers also keep working uninterrupted if external connectivity is briefly lost, giving you a natural degradation story for edge and disconnected sites.

For a multi-user AI assistant on the factory floor or in a sovereign data center, this is the difference between a shared service account and a per-user audit trail.

Expanded model catalog: ONNX and vLLM side by side

The Foundry Local model catalog now includes models in both ONNX and vLLM formats. The same model can appear multiple times in the catalog - once per runtime/compute target - so you can pick the build that matches your hardware without leaving the platform. The operator selects the right container image automatically based on the entry you reference.

Broader open-model support

Beyond the Phi and GPTOSS families, the catalog now includes additional models across multiple open-source lineups that customers have requested for on-prem and sovereign deployments, including Mistral and NVIDIA Nemotron. Both are available as catalog entries, served by the vLLM runtime on GPU, and accessible through the same OpenAI-compatible endpoint you already use.

In collaboration with NVIDIA, Foundry Local now supports the latest Nemotron models, optimized for enterprise performance on NVIDIA powered Azure Local hardware including NVIDIA RTX Pro 6000. Nemotron models are tuned for reasoning, instruction-following, and agentic workflows, and run on the vLLM runtime with PagedAttention, continuous batching, and FP8 KV cache on compatible GPUs. The vLLM planner handles GPU memory utilization and context-length sizing automatically. you declare the catalog entry, the platform sizes the deployment to your hardware.

Models available in vLLM format

(see the model catalog docs for the full, regularly updated list)

Model	ONNX	vLLM	Notes
Phi-4	✓	✓	Microsoft's flagship SLM
Phi-4-mini	✓	✓	Compact, fast inference
Phi-4-mini-reasoning	✓	✓	Chain-of-thought reasoning
Phi-4-reasoning	—	✓	vLLM-only, reasoning-focused
gpt-oss-20b	✓	✓	Mid-range generative
gpt-oss-120b	—	✓	Large generative, vLLM-only
Mistral-7B-v0.2	✓	✓	Popular open-source LLM
DeepSeek-R1 (7b/14b)	✓	—	Reasoning-focused
Qwen2.5 (0.5b–14b)	✓	—	Multilingual, coder variants
Qwen3 (0.6b–14b)	✓	—	Latest generation
Whisper (multiple sizes)	✓	—	Speech-to-text
Nemotron	✓ (CPU)	✓

The catalog now includes a growing list of models across both runtimes. Models in vLLM format are served using the vLLM engine with all its performance benefits - PagedAttention, continuous batching, FP8 KV cache - while ONNX models continue to serve on CPU or GPU through the ONNX-GenAI runtime.

Bring-your-own model (BYOM)

When you need a model that isn’t in the catalog, bring-your-own model still works the same way: package your model as an OCI artifact in any ORAS-compatible registry (Azure Container Registry, GitHub Container Registry, Docker Hub) and reference it from your ModelDeployment. The operator caches it locally and reuses the cached copy on subsequent deployments.

Choosing the right runtime

ONNX-GenAI when you're running on CPU-only hardware, serving a single application with a compact model, or need the broadest model compatibility including speech and predictive workloads.

vLLM when you have GPU hardware, need to serve concurrent users, want to run larger models, or need production-grade throughput from your inference endpoint.

Both runtimes expose the same OpenAI-compatible REST API - the choice is transparent to application code.

vLLM ModelDeployment is as simple as this:

Everything else - memory utilization, context length, batch sizing - is handled by the vLLM planner. See the model catalog docs for the BYO pattern and full configuration options.

What hasn't changed

Everything from the public preview remains fully supported:

Two installation paths - Azure Arc extension (recommended for fleet management) and Helm chart (for platform engineers who need full control)

OpenAI-compatible REST endpoints - POST /v1/chat/completions and standard patterns

API key and Microsoft Entra ID authentication - secured with bearer tokens, with the per-identity RBAC model described above

TLS-enabled ingress - encrypted traffic in transit

Disconnected operation - models cached on local PersistentVolumes continue serving when WAN connectivity drops

Bring-your-own predictive models - deploy custom ONNX models from OCI registries

Multi-model orchestration - agent-style patterns coordinating multiple local models

Your existing ModelDeployment manifests continue to work. Applications targeting the ONNX-GenAI runtime don't need any changes. The new capabilities are additive.

Real-world scenarios, now at scale

Over the past few months, we’ve partnered with customers in early preview to build and validate real-world scenarios. A consistent theme across these engagements is the need to run AI where data resides—on-premises—while maintaining the governance and consistency enabled by Azure Arc.

"In energy operations, AI needs to run where the work happens – at remote facilities, offshore platforms, and field locations where connectivity is often limited, and safety is paramount. Foundry Local gives us a path to bring AI-driven decision-making closer to our operational data, with the governance our industry demands. The ability to deploy and run AI workloads consistently across edge and field environments, even when disconnected, is critical as we advance Chevron's vision for autonomous and intelligent operations." (Chevron) Ed Moore - OT Strategist and Distinguished Engineer

With multi-node and vLLM, the scenarios from our initial preview scale to meet production demands:

Manufacturing: multi-user quality inspection

A quality-control system on a production line previously ran Phi-4-mini for single-station anomaly explanation. With vLLM's continuous batching, the same Foundry Local endpoint now serves 10+ inspection stations concurrently - each sending defect images and sensor telemetry for real-time root-cause analysis - without response-time degradation.

Sovereign: identity-scoped document processing

A government agency processing sensitive casework needs production-grade throughput and a strict audit trail. Foundry Local serves the workload on-premises across multiple GPU nodes, with per-analyst access enforced through Entra ID and Azure RBAC, so every inference call is tied to a real identity - and no data leaves the cluster.

Energy: disconnected multi-user operations

An offshore platform runs Foundry Local on a multi-node Azure Local cluster. When WAN connectivity drops, the vLLM-powered endpoint continues serving safety procedure lookups, maintenance guidance, and operational queries to multiple crew members simultaneously - each accessing the inference endpoint from their local application. API-key auth keeps working through the outage; Entra ID resumes seamlessly when the WAN comes back.

Getting started

If you're already running Foundry Local on Azure Local in the public preview:

Once installed the Foundry Local extension is automatically kept up to date, with multi-node and vLLM support included.
Browse the updated catalog to discover models available in vLLM format
Deploy a vLLM model by setting runtime: vllm in your ModelDeployment manifest
Let the vLLM planner optimize - override only the preferences you care about and let the planner handle the rest

If you're new to Foundry Local on Azure Local:

Follow the get-started code-sample blog to see the end-to-end flow
Request preview deployment access to get started
Read the documentation for architecture overview and deployment guide

What's next

Multi-node and vLLM are just the beginning. We're continuing to invest in:

Distributed LLM serving with LLM-D - KV-cache-aware routing and disaggregated serving for large models that span multiple nodes

Autoscaling for inference workloads - dynamic capacity that follows demand

Broader model catalog expansion - more model families, more sizes, more task types

Enhanced monitoring and observability for inference workloads

Performance optimization for specific Azure Local hardware profiles

Expanded GPU hardware validation across the Azure Local catalog

We're building Foundry Local to be the production AI inference platform for edge and sovereign environments. Your feedback is shaping every release - keep it coming.

Learn more:

Foundry Local Model and inferencing on multi node demo

Foundry Local for devices (GA)

For more information reach out to the team at FoundryLocalOnAzure@microsoft.com

Introducing GitHub Enterprise Local (Preview): DevOps for Sovereign and Private Cloud Environments

sushil_jarwal — Tue, 02 Jun 2026 19:15:00 GMT

Across the world, many organizations, particularly in government, defense, financial services, and critical infrastructure, must operate within strict sovereign boundaries, often due to regulatory, security, or disconnected environment requirements. Microsoft’s Sovereign Private Cloud is a customer operated cloud model designed for scenarios where sovereignty, operational control, and resiliency are non negotiable. It enables organizations to operate securely and at scale, even in restricted or disconnected environments, while maintaining governance aligned with regulatory and national obligations.

Azure Local is the foundation that makes this possible. With Azure Local, organizations can run critical workloads—including virtual machines, Kubernetes, virtual desktop infrastructure, and AI workloads—on infrastructure they own and control, while still benefiting from Azure consistent management, governance, and lifecycle operations. We’re continuing to expand the set of workloads and capabilities supported on Azure Local to meet the needs of organizations operating in sovereign and highly regulated environments. With Microsoft 365 Local, Azure Local now extends beyond infrastructure to support communication and collaboration workloads, enabling productivity and resiliency even in disconnected or restricted conditions. And with Foundry Local, we are supporting modern AI workloads on Azure Local, bringing advanced AI capabilities to infrastructure customers own and operate.

We are excited to announce the public preview of GitHub Enterprise Local, which brings GitHub’s enterprise developer platform into sovereign and private cloud environments. GitHub Enterprise Local is fully hosted on customer owned infrastructure, enabling organizations to modernize application development while keeping source code, build pipelines, and development artifacts entirely within their own operational boundaries.

What Is GitHub Enterprise Local?

GitHub Enterprise Local enables organizations to deploy GitHub Enterprise Server (GHES) entirely within customer‑owned infrastructure using Azure Local as the underlying private cloud platform. The solution is delivered as a prebuilt virtual machine image that runs on Azure Local and operates fully within the customer’s security and network perimeter.

All repositories, metadata, CI/CD workflows, and artifacts remain on‑premises. GitHub Enterprise Local is designed to run without internet connectivity by default, making it suitable for both connected and fully disconnected or air‑gapped environments. At the same time, it preserves a GitHub‑consistent experience for developers, allowing teams to continue using familiar workflows for source control, collaboration, and automation.

Developer and Platform Capabilities

GitHub Enterprise Local provides a comprehensive set of enterprise developer platform capabilities. Teams can host private repositories, manage organizations, and collaborate through pull requests, branch protection rules, and structured code reviews. Issues, wikis, and project collaboration features are also available, enabling end‑to‑end development workflows within the same platform.

GitHub Enterprise Local can run on either a single-node or multi-node Azure Local instance depending on customer needs. Single‑node Azure Local runs GHES as a standalone VM, ideal for preview, PoC, and low‑risk scenarios focused on simplicity and cost efficiency. For production-oriented deployments, the same single GHES VM can run on a multi‑node Azure Local cluster, where Azure Local provides VM‑level high availability and failover.

For automation and delivery, GitHub Enterprise Local supports GitHub Actions using self‑hosted runners. This allows organizations to build and run CI/CD pipelines entirely within their own environments, with full control over execution context, dependencies, and network access. GitHub Packages can be used for artifact management, supporting common ecosystems such as npm, NuGet, Maven, and container images.

GitHub Enterprise Local extends modern development workflows with AI assisted experiences while keeping sensitive data within customer-controlled environments. Developers can use GitHub Copilot in several ways, including as a standalone experience, through Copilot CLI, and in VS Code. They can choose GitHub-managed models by connecting to GitHub.com, or connecting directly to model providers from Copilot CLI, allowing source code to avoid passing through GitHub Cloud. Foundry Local provides an on-premises inference layer that keeps prompts, code context, and model execution inside organizational boundaries. Together, these capabilities create a clear integration path across code automation and AI application development, enabling organizations to modernize the developer experience while preserving operational control, compliance, and auditability.

Developer AI Workflow Architecture

This architecture demonstrates how GitHub Enterprise Local serves as the secure, customer-managed foundation for source control, collaboration, and workflow orchestration, enabling developers to layer AI-assisted capabilities through GitHub Copilot, GitHub CLI, and Foundry Local—while ensuring that code, data, and AI execution remain fully within organizational boundaries.

Reference Architecture

Architecture Overview

GitHub Enterprise Local follows a layered architecture model.

Infrastructure Layer

Azure Local forms the foundation, deployed on Azure Local–certified hardware. It provides:

The virtualization platform for running GitHub Enterprise Local
Infrastructure availability and update management
Customer‑controlled networking, identity, and security policies
Azure Arc‑enabled management for infrastructure lifecycle operations

GitHub Enterprise Local Appliance Layer

GitHub Enterprise Server (GHES) is deployed as a prebuilt virtual machine image on Azure Local. This VM includes:

The GHES application stack
Persistent data disks for repositories and metadata
Support for replica‑based failover configurations, depending on customer requirements

All application data remains within customer infrastructure boundaries.

Operations Layer

Operational responsibilities are clearly separated:

Azure Local administrators manage the Azure Local infrastructure through Azure
GitHub administrators manage GHES configuration, upgrades, user access, and ongoing maintenance through the GitHub Management control and site admin dashboard

This separation aligns with common enterprise operational models.

Connectivity Modes and Deployment Scenarios

GHES is designed to operate fully offline, making it suitable for air‑gapped and restricted environments. Azure Local complements this capability by supporting both connected and fully disconnected operational modes. In connected environments, customers can take advantage of centralized management and monitoring of GHES appliance. In disconnected environments, the entire solution can operate in complete isolation, ensuring compliance with strict sovereignty or security mandates.

This flexibility allows organizations to adopt a deployment model that aligns with their regulatory, operational, and security requirements.

Hardware and Capacity Planning

GitHub Enterprise Local virtual machine sizing depends on customer use cases, including:

Number of developers
Repository size and growth
CI/CD pipeline frequency
Artifact storage requirements

Azure Local supports running GitHub Enterprise Local on both Integrated and Premier hardware solutions, provided sufficient capacity is available. Customers should plan compute, memory, storage, and network resources accordingly.

Minimum recommended requirements

Billing Overview

GitHub Enterprise Local combines user-based application licensing, Azure Local infrastructure-based billing, and separate pricing for AI services such as Copilot and Foundry.

GitHub Enterprise Local is billed per user seat. (GitHub Enterprise license)
Azure Local is billed per physical CPU core. (Azure Local Billing)
Copilot and Foundry have separate service-based pricing. (GitHub Copilot Plans & pricing)

Public Preview Access

GitHub Enterprise Local on Azure Local is available today in public preview. Customers can request access by completing the public preview registration form. Submissions are reviewed as part of the preview onboarding process.

Participate in public preview:
GitHub Enterprise Local Preview Sign-Up

Learn More

GitHub Enterprise Local documentation

Embed intelligence into physical systems with smaller form factor infrastructure (preview)

Cosmos_Darwin — Wed, 03 Jun 2026 15:57:44 GMT

Written by Cosmos Darwin, Azure Edge PM, and Michael MacKenzie, VP of Digital Operations

AI is transforming how we work, but so far it's mostly lived on your screen: agents and models assisting with information work. How can that intelligence take on physical work, too? Jobs that happen out in the world, like transporting goods, inspecting equipment, manufacturing products, and serving retail customers. This is already possible today, but developing autonomous robots remains highly complex and specialized. The real breakthrough will come when using AI in physical work is as simple and ubiquitous as it is on a screen. To get there, we need to go beyond software agents and embed intelligence directly into physical systems.

Today at Microsoft Build 2026, we're announcing several new capabilities to help organizations everywhere get started. We're extending AI-ready Azure-managed infrastructure to smaller form factor hardware, bringing Foundry Local to it for running local AI agents and models, and adding support for Azure Kubernetes Service and Azure IoT Operations.

Demo: a simple robot that thinks for itself

Applied in combination, these capabilities can be surprisingly powerful. For Microsoft Build this week, we wanted to show you just how easy this can be. We put together a basic agentic robot using nothing but open-source AI models, commercial off-the-shelf sensors and robot hardware, and the new Azure previews we're announcing today. It's a playful example, but it illustrates what’s possible – check it out:

Lightweight deployments on smaller form factor hardware (preview)

First, we're extending Azure-based provisioning and management to smaller hardware form factors, using a lightweight, performance-oriented architecture built for AI workloads. Unlike hyperconverged and disaggregated deployments, this doesn’t rely on virtualization, and instead runs Linux (initially Azure Linux) directly on bare metal to host containers. You can choose whichever runtime tools you prefer, like Docker, open source k3s, or fully managed Azure Kubernetes Service.

Each deployment is provisioned and managed from the cloud using a new type of resource called Provisioned Machine that looks and behaves a lot like an Azure VM – for example, you can see it in the Azure portal and govern access with Microsoft Entra ID. Over the coming months, we’ll be rolling out more features like update management, metrics, security configuration, and natively configurable child resources for network interfaces and disks.

Screenshot of the new Provisioned Machine resource type in Azure portal.

Provisioned Machines support lifecycle operations centrally from the Azure portal and APIs. Effectively, you can treat physical machines like cloud resources, removing the need for separate on-site IT tools. This makes it much more practical to scale across many distributed locations. For an organization like Chevron, whose operations span field sites around the world, that’s significant:

"Chevron has a growing fleet of industrial edge devices that collect data in the field and increasingly perform local AI processing. Technologies like Azure Local on smaller form factors can help us manage these systems centrally and in a more automated way – reducing complexity compared to the customized OS environments and tools we use today."

— Ed Moore, OT Strategist and Distinguished Engineer, Chevron

Run agents and models locally with Foundry Local (preview)

To embed intelligence into physical systems, Foundry Local is now available as a lightweight container image for Linux infrastructure.

Foundry Local provides a consistent way to deploy and run agents and models, including an inference server that runs alongside your app container and exposes an OpenAI-compatible REST endpoint. It also offers a trusted source for the latest open-source models with an extensive online catalog. Although it integrates closely with Microsoft Foundry, at run time everything stays local: there's no round-trip to the cloud. Data stays on the machine, responses start instantly with zero network latency, and inferences continue even without connectivity. There are no per-token costs, either.

Optimized for edge and industrial form factors, the new Foundry Local preview automatically detects and uses available accelerators like GPUs (and soon NPUs), lining up the full stack for you, from kernel drivers to user-mode libraries. For example, in our demo above, Foundry Local taps an Nvidia RTX 2000E GPU to deliver snappy inferences in real time.

Diagram of the lightweight Linux architecture with container-based Azure services.

More popular Azure services

In addition to Foundry Local, these popular Azure services are validated too:

Azure Kubernetes Service (AKS), the fully-managed enterprise-grade Kubernetes service, now runs directly on bare metal with small form factor deployments – no virtualization layer required. It's the same AKS already available in the cloud and on servers. Once deployed, the cluster looks and works exactly like AKS anywhere else – with Azure-based RBAC, networking, upgrades, monitoring, and even integrations like AKS Fleet Manager – so the controls and tooling you rely on in the cloud extend all the way to the industrial edge. Learn more and join the AKS preview

Azure IoT Operations provides a unified data and control plane for physical assets at the edge. It includes a variety of connectors and an industrial-grade MQTT broker where local agents and logic can run – even with intermittent connectivity – to shape operational data into AI-ready forms, act on it autonomously, and connect into broader cloud analytics and AI systems. It provides a no-code graphical interface to configure data flows and contextualize data before sending it to destinations like Microsoft Fabric for Real-Time Intelligence, and allows you to send messages back to the physical machines it’s connected to. It's already generally available, and as seen in our demo above, it now works on small form factor deployments too. Learn more about Azure IoT Operations

Choose the hardware that fits your requirements

We're delighted to partner with leading makers of edge and industrial computers so you can deploy Azure-managed infrastructure on smaller form factor hardware that’s available to buy today – straight from your preferred vendor or distributor, with no special customization required.

We’re partnering with leading makers of AI-ready edge and industrial computers.

The most compact and affordable options are the ASUS NUC 14 Pro and 15 Pro. At barely 4 inches square and under 2 pounds, they pack the latest Intel® Core™ Ultra processors into a remarkably trim package, well suited to space-constrained scenarios like retail. Learn more about NUC 15 Pro

“With ASUS NUC 14 Pro and 15 Pro, organizations have a powerful yet compact platform for innovation at the edge. When paired with Azure Local, these devices make it easy to deploy, manage, and scale AI workloads at the edge – unlocking real-time intelligence for retail stores and manufacturing environments while maintaining seamless integration with the cloud.”

– (ASUS) KuoWei Chao, General Manager of ASUS NUC Business Unit

For more flexibility, the industrial-grade Lenovo ThinkEdge SE100 offers expandable storage and networking, plus an optional Nvidia RTX A1000 (8GB) or 2000E (16GB) GPU to accelerate demanding edge AI inferencing. Learn more about ThinkEdge SE100

For the toughest operational and regulatory constraints, the OnLogic Helix 521 offers a fan-less design with no moving parts. Designed, assembled, and supported entirely in the USA, it takes the uncertainty out of meeting stringent supply-chain requirements. Learn more about the Hx521

Get started today

We're excited to bring AI-ready infrastructure to where physical work happens, and we genuinely had a lot of fun making the agentic robot demo above. Now it's your turn. Small form factor deployments are available in public preview today, starting in the East US region. There is no charge during the preview. Once your hardware is ready, the Azure-based provisioning experience gets most previewers up and running in about an hour. Instructions to get started are on Microsoft Learn, and if you’d like to engage directly with our team, get in touch here. (If you need to evaluate before committing to hardware, you can spin it up on a virtual machine, though it’s not quite the same as real hardware.)

Whether you're bringing intelligence to a fleet of machines, standing up inference next to your data, or building something we haven't even imagined yet, we can't wait to see what you create!

- Cosmos & Mike

on behalf of our global team in Redmond, Mountain View, Pittsburgh, and Bengaluru

Ansible + Azure Arc: Manage Azure Arc Extensions with New Ansible Modules

alinetran — Thu, 28 May 2026 17:24:53 GMT

We’re excited to announce new modules in Ansible Galaxy that make it easier to manage Azure Arc machine extensions at scale. With the latest updates to the azure.azcollection on Ansible Galaxy, you can now deploy and manage Azure Arc extensions using familiar, declarative Ansible workflows.

These new modules include:

Together, they enable infrastructure and platform teams to automate extension lifecycle management across their hybrid estate—bringing consistency, security, and efficiency to Azure Arc-enabled servers.

Why this matters

Azure Arc machine extensions power critical scenarios such as security, monitoring, update management, configuration and compliance. Until now, managing these Azure Arc extensions across hybrid estates often required Azure CLI scripts, ARM templates, or manual operations. With these new Ansible modules, you can:

Integrate Azure Arc extension management into existing Ansible playbooks
Enforce consistent configuration across hybrid servers
Reduce operational overhead through declarative automation
Align extension deployment with broader configuration management workflows

What’s included

azure_rm_arcmachineextensions

This module allows you to manage the full lifecycle of Azure Arc machine extensions, including:

Creating and deploying extensions
Updating extension settings
Removing extensions when no longer needed

You can define extension state declaratively, ensuring consistent enforcement across your Azure Arc-enabled servers.

azure_rm_arcmachineextensions_info

This module provides visibility into extension state by retrieving:

Installed extensions on Azure Arc-enabled machines
Provisioning status and configuration details
Extension metadata for reporting and validation

This is useful for compliance validation, auditing, and conditional automation in playbooks.

Scenario: Enforcing identity-based SSH access across a hybrid fleet

Consider a regulated enterprise that must ensure all Linux servers—whether on-premises or in a multicloud environment—use Microsoft Entra ID for SSH access. The organization wants to:

Eliminate local SSH credentials
Enforce centralized identity and access controls
Audit access consistently across all environments

By combining Azure Arc with Ansible, the organization can deploy the Microsoft Entra SSH for Linux extension across all Azure Arc-enabled servers as part of a standardized playbook, ensuring compliance and reducing operational overhead.

Example: Deploy Microsoft Entra SSH for Linux extension

Below is an example of using Ansible to deploy the Microsoft Entra SSH extension to an Azure Arc-enabled server:

- name: Deploy Entra SSH extension to Arc server hosts: localhost connection: local tasks: - name: Install Entra SSH extension for Linux azure_rm_arcmachineextensions: resource_group: myResourceGroup machine_name: myArcServer name: AADSSHLoginForLinux publisher: Microsoft.Azure.ActiveDirectory type: AADSSHLoginForLinux type_handler_version: "1.0" settings: {} state: present

Example: Retrieve extension information

Below is an example of using Ansible to retrieve details about your Azure Arc extensions:

- name: Get Arc machine extension details hosts: localhost connection: local tasks: - name: Fetch extensions azure_rm_arcmachineextensions_info: resource_group: myResourceGroup machine_name: myArcServer

Integrating with existing Ansible workflows

If you’re already using Ansible for:

OS configuration
Patch and update management
Application deployment

You can now extend those workflows to include Azure Arc extension management—without introducing new tools or processes. This allows you to manage on-premises servers, Edge infrastructure and multicloud environments through a unified automation approach powered by Azure Arc and Ansible.

What’s next

These modules are part of our continued investment in making Azure Arc a first-class platform for managing Windows and Linux machines in hybrid and multicloud infrastructure.

By bringing extension lifecycle management into Ansible, we’re enabling teams to enforce security, compliance, and operational consistency at scale—using the tools they already trust.

Stay connected

Join the Azure Arc Monthly Forum here: aka.ms/ArcServerForumSignup

Let us know what you’d like to see next in the comments!

Azure Arc Server April 2026 Forum

Aurnov_Chattopadhyay — Tue, 19 May 2026 18:58:36 GMT

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

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

Public Preview of Essential Machine Management, learn more at aka.ms/EMM-blog and sign up at aka.ms/EMM-feedback
Engage with product group on exploration of AI on bring your own Kubernetes by signing up at aka.ms/arc-ai-survey
Product group is investing in extending the Multi-cloud Connector provide customers the ability to connect their MECM environments to Azure for inventory, monitoring, and management

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 May 2026 forum will be held on Thursday, May 21 at 9:30 AM PST / 12:30 PM EST. We look forward to you joining us, thank you!

Simplified access to Hotpatching enabled by Azure Arc for Windows Server 2025

sharmajyoti — Tue, 19 May 2026 21:18:34 GMT

With Windows Server 2025, we introduced hotpatch enabled by Azure Arc, delivering security updates to Windows Server across hybrid and multicloud environments – minimizing downtime (no reboot), accelerating protection, and unifying patch management.

We know that keeping your servers updated with the latest patches is one of the critical tasks that IT teams perform day-to-day. We want to make it simpler to install the latest operating system (OS) updates without rebooting machines after every installation.

The resounding feedback we have received from you underscored the criticality of this feature in the lifecycle management and security of your infrastructure. We are now taking it one step further to reduce the friction to deploying these critical updates: hotpatch enabled by Azure Arc is now available at no additional cost for Windows Server 2025.

Which machines are eligible for this offer?

To use hotpatch for Windows Servers running on-premises or in multicloud environments, you must be using Windows Server 2025 Standard or Datacenter, and your server must be connected to Azure Arc. With this announcement, enabling and usage of the hotpatching service is available at no additional charge.

Please take note that there are no charges for customers running on Azure IaaS, or Azure Local, wherein hotpatching is available as part of the functionality of Windows Server Datacenter: Azure Edition. This feature is already included both with Windows Server 2022 Datacenter: Azure Edition and Windows Server 2025 Datacenter: Azure Edition.

How do I manage hotpatches enabled by Azure Arc for Windows Server 2025?

If your Windows Server 2025 machines aren't already connected to Azure Arc, install the Azure Connected Machine agent — it takes just a few minutes per server and supports at-scale rollout via Group Policy, service principal, or Terraform. Once connected, enable Hotpatch from the Azure portal, Azure PowerShell, Azure CLI, or the REST API — just confirm Virtualization-based security (VBS is enabled) first. From there, use Azure Update Manager to schedule and monitor rollouts at scale.

For instructions on how to enable hotpatch for Azure Arc-enabled machines using group policy or scripts, learn more here: https://aka.ms/ws-hotpatch

For patch orchestration at scale, you can use Azure Update Manager to deliver hotpatches enabled by Azure Arc for Windows server 2025 machines. This enables greater uptime with fewer reboots and faster deployment of updates with easy patch orchestration. Alternatively, you can use APIs or other management tools to manage hotpatches.

Centralized management of hotpatch updates across hybrid and multicloud environments enabled by Azure Arc

Once your machines are connected to Azure Arc, you can also use the cloud-native services from Azure to manage your windows machines running on-prem. Azure Arc enables you to standardize security and governance across a wide range of resources so you can easily organize, govern and secure Windows, Linux, SQL servers, and Kubernetes clusters running across data centers, edge, and multi-cloud environments – using Azure services such as Azure Policy, Azure Monitor, Microsoft Defender and more.

At no additional cost for machines attached to Azure Arc
Basic inventory across on-prem and multi-cloud	Tag your resources, organize them into resource groups, subscriptions, and management groups, and query at scale with Azure Resource Graph to unify your environments.
Infra as Code (Bicep, Terraform)	Infra as code for provisioning and management of resources.
VM Self Service	Perform lifecycle management such as (create, resize, update and delete) and power cycle operations such as (start, stop, and restart on VMware vCenter and System Center Virtual Machine Manager Virtual Machines.
Hotpatch for Windows Server 2025 *^NEW*	Windows Server hot patching enables you to apply security updates without rebooting, keeping systems secure while maintaining continuous uptime.
VM Management	Administrate your servers anywhere using SSH for Azure Arc, Run Command, and Custom Script Extension.
Mgmt. Services included for no additional costs with Windows Server Software Assurance or Extended Security Updates
Azure Update Manager	Provides a unified, centralized service to monitor, orchestrate, and automate patching across Azure, on‑prem, and multi‑cloud environments ensuring security, compliance, and minimal downtime at scale.
Azure Machine Configuration (Policy)	Policy‑driven auditing and enforcement of OS and application settings as code across Azure and hybrid machines—ensuring consistent, compliant state at scale. Including compliance policies like CIS Benchmark and WinRE
Change Tracking & Inventory	Real‑time visibility into configuration changes and system state across your fleet enabling faster troubleshooting, improved security, and continuous compliance at scale.
VM insights from Azure Monitor	Delivers a unified, pre‑built observability experience that provides real‑time performance, health, and dependency visibility across VMs—enabling faster troubleshooting, optimization, and capacity planning at scale.
Windows Admin Center	Unified, browser‑based management plane to securely manage Windows servers, VMs, and hybrid infrastructure from anywhere—simplifying operations and improving efficiency at scale.
Best Practices Assessment	Continuously evaluation your server configurations against Microsoft-recommended standards to proactively identify risks and provide actionable remediation guidance—improving security, performance, and operational health at scale.

Frequently Asked Questions

What are hotpatch updates?

Hotpatch updates are monthly security updates that take effect without requiring you to restart the device. They contain a full set of security updates equivalent to the standard updates released the same day.

What is the hotpatch update cycle?

All eligible Windows Server 2025 machines enrolled in hotpatch are offered up to 8 monthly hotpatch updates in a calendar year in a quarterly cycle:

Baseline month: In January, April, July, and October, devices install the monthly cumulative security update and must restart for the update to take effect. This update includes the latest security fixes, cumulative new features, and enhancements since the last baseline.
Subsequent two months: Devices receive hotpatch updates, which only include security updates and don't require a restart for the update to take effect. These devices will catch up on features and enhancements with the next cumulative baseline month (quarterly).

Will billing be stopped for existing enrolled machines?

Yes, as of 15^th May 2026 all billing for hotpatch has been stopped for all existing machines enrolled in hotpatch.

What action do we need to take if we have machines enrolled in hotpatch already?

There is no additional action needed for machines that are currently enrolled in hotpatch. These machines will remain enrolled in hotpatch and receive hotpatch updates when available.

I want all my Windows Server 2025 machines to get hotpatches. How do I do it?

If you have Windows Server 2025 machines on-premises or on cloud (other than Azure) then you can enable hotpatch on them. To do so, ensure these machines have Virtualization Based Security enabled and are connected to Azure Arc and then you can use Azure Arc portal, Azure Update manager or APIs to enable hotpatch. Learn more: https://aka.ms/ws-hotpatch

Is anything changing for Hotpatching on Azure?

Hotpatch continues to be available on Azure for your Windows Server 2022 and Windows Server 2025 VMs when using Azure Edition. There is no fee associated with Hotpatching on Azure. Learn more here.

Is there a community forum for Arc?

Yes, you can join the Azure Arc Monthly Forum here: aka.ms/ArcServerForumSignup

Introducing cert-manager for Azure Arc-enabled Kubernetes: now in Public Preview

NicolasMondada — Wed, 13 May 2026 03:37:38 GMT

Today we’re releasing a public preview of cert-manager for Azure Arc-enabled Kubernetes. It’s an Arc extension that automates TLS certificate and trust bundle management for edge Kubernetes clusters.

If you’re running Kubernetes at the edge: in factories, retail stores, remote sites, you’ve probably hit the certificate problem already. Certificates expire. Each cluster has its own tooling. Nobody owns the renewal process until something breaks. We routinely hear from customers that certificate issues are a common source of unplanned outages and last-minute firefighting, especially as workload counts grow.

This extension packages the open-source cert-manager and trust-manager into a managed Arc extension with Microsoft support. You get automated lifecycle management and trust distribution without having to run and maintain these tools yourself.

What it does

The extension bundles two CNCF-graduated projects: cert-manager and trust-manager, into a single Arc-K8s extension that you install once per cluster. From there:

1. You can issue, renew, and rotate certificates automatically. You do not need to manage them manually.

2. You can distribute trusted CA certificates consistently across namespaces. No more per-workload trust configuration.

3. You choose the CA issuer: built-in self-signed for dev/test, or your enterprise PKI for production.

4. The extension ships with enterprise support, regular security patches, and proactive maintenance from Microsoft team.

Why we built it

We built Microsoft cert-manager for Azure Arc-enabled Kubernetes to address three recurring problems we saw in real hybrid and edge environments.

Problem 1: Manual certificate issuance.

Many organisations still issue, install, and renew certificates through manual steps across clusters and namespaces. That creates operational overhead, slows teams down, and increases the risk of outages when certificates expire or are configured incorrectly.

The answer is automation. With cert-manager running as an Arc-enabled extension, teams can automate certificate issuance, renewal, and rotation through Kubernetes-native workflows instead of relying on tickets, scripts, and manual intervention.

Problem 2: Fragmented approaches to automation.

Even when teams try to automate, they often end up with a mix of scripts, custom controllers, product-specific setups, and one-off operational patterns. That fragmentation makes certificate management harder to scale, harder to standardise, and harder to operate consistently across environments.

The answer is to standardise on cert-manager. It provides a common, Kubernetes-native approach to certificate lifecycle management, helping teams reduce tool sprawl, align on a consistent operating model, and simplify how certificates are managed across clusters.

Problem 3: Maintenance and upgrade burden for open-source cert-manager.

cert-manager is a powerful open-source project, but many organisations do not want the ongoing burden of packaging, validating, patching, upgrading, and supporting it themselves as a production dependency. That can create operational risk, delay updates, and make long-term ownership unclear.

The answer is a Microsoft-supported Arc-enabled extension. Microsoft cert-manager for Azure Arc-enabled Kubernetes gives customers a supported way to use cert-manager, with Microsoft handling packaging, delivery, and ongoing maintenance so teams can adopt the capability without taking on the full operational burden of managing the OSS component themselves.

What’s in the public preview

Here’s what you get:

Certificate lifecycle automation with cert-manager: issuance, renewal, rotation, all handled for you.
Trust bundle distribution with trust-manager: push trusted CA certs to every namespace that needs them.
Self-signed or external CA. Start with the built-in CA, swap in your enterprise PKI when you’re ready.
Secure by default. We turned on the security settings you’d want enabled anyway: TLS enforcement, least-privilege RBAC, restricted pod security.
Tested at the edge. Validated on AKS Edge Essentials, AKS on Azure Local, and several third-party Kubernetes distros. Works offline.

Fits into your Arc stack

If you’re already running Azure IoT Operations or Azure Monitor on Arc-enabled clusters, the extension handles TLS between those services with minimal setup. No custom certificate plumbing required: install the extension and the other Arc components pick it up.

Get started

The extension is available now in public preview.

👉 Documentation and quickstart

Azure Local expands to sovereign-scale infrastructure with disaggregated deployments

troettinger — Mon, 27 Apr 2026 15:45:00 GMT

As organizations accelerate digital transformation across datacenters, sovereign environments, and edge locations, infrastructure architectures must evolve to meet new operational and regulatory demands.

The first feature update of Azure Local in CY 2026 (version 2604) marks a significant step forward—expanding Azure Local as a platform for sovereign private cloud infrastructure, introducing larger scale, disaggregated deployment architectures, expanded storage ecosystem partnerships, and simplified identity capabilities that unlock entirely new infrastructure scenarios from edge locations to enterprise-scale environments.

This release is focused on enabling:

Sovereign private cloud deployments at scale from single node up to multi-rack infrastructure
Infrastructure modernization through SAN reuse and disaggregated architectures
Simplified edge deployment without Microsoft Active Directory dependencies
Faster lifecycle operations across deployment and update workflows

Introducing disaggregated larger scale deployments using SAN storage

Azure Local now supports a disaggregated infrastructure architecture, allowing customers to deploy compute and storage resources independently—while continuing to benefit from an Azure-consistent management and operational experience. This enables organizations to scale infrastructure more flexibly separating compute and storage to align with workload demands and long-term growth.

This architecture enables:

Independent scaling of compute nodes and storage infrastructure
SAN‑only and hybrid storage architectures for Azure Local infrastructure and workloads
Fibre Channel (FC) connectivity support beginning with 2604 (iSCSI coming soon)

With disaggregated deployments and SAN storage, Azure Local clusters can now scale from a single node at the edge to multi-rack environments spanning beyond 16 nodes and up to thousands of nodes, addressing growing demand for large-scale deployments across sovereign, government, defense, and regulated environments. This unlocks new class of Azure -consistent infrastructure deployments at sovereign scale.

This unlocks a new class of Azure-consistent infrastructure deployments at sovereign scale. This new capability is generally available with the release of Azure Local 2604.

General Availability of SAN Support for Azure Local

Support for attaching SAN storage to Azure Local was introduced as public preview back in November 2025. Today this brownfield expansion capability is generally available and allows external SAN devices to be introduced into already deployed Azure Local instances via Fibre Channel (FC)—supporting virtual machines, Kubernetes environments, and Azure Virtual Desktop workloads without requiring disruptive infrastructure changes or full system refresh.

Azure Local instances now support the coexistence of Storage Spaces Direct volumes and external SAN volumes.

Support for SAN-attached deployments allows organizations to:

Reuse existing enterprise SAN investments
Modernize infrastructure without replacing existing storage estates
Manage rising disk costs associated with hyperconverged architectures
Enable workload scenarios that depend on massive storage requirements

These innovative capabilities supporting disaggregated deployments and SAN storage are supported by a strong ecosystem of hardware partners.

DataON, Dell Technologies, Everpure, HPE, Hitachi Vantara, Lenovo and NetApp are working with Microsoft to deliver configurations, giving customers more flexibility in how they design and scale their infrastructure.

General Availability of Local Identity with Azure Key Vault

While disaggregated architectures primarily target sovereign and centralized datacenter deployments, Azure Local 2604 also introduces a major advancement for distributed and edge scenarios.

With the General Availability of Local Identity with Key Vault, Azure Local can now be provisioned without infrastructure dependencies on Microsoft Active Directory, enabling simplified deployment in disconnected, air-gapped, and regulated environments.

This simplifies deployment and adoption, by removing the need for extra hardware running domain controllers and removing the complexity of firewall configurations when installing in isolated network environments.

Azure Local 2604 adds support for deploying rack-aware clusters using Local Identity with Azure Key Vault. This combines reduced requirements with the high availability that customers demand across manufacturing, energy, and other industries. This capability removes one of the key barriers to deploying Azure-consistent infrastructure in sovereign and edge environments.

Pricing Changes

Pricing for multi-rack and sovereign-scale deployments is being introduced as part of this release. Customers should connect with their Microsoft account team to learn more about pricing, configuration options, and early access programs as these offerings continue to actively evolve.

Getting started

Release 2604 is available for both existing and new Azure Local instances.

Review the release note for Azure Local 2604 release here
Learn more about disaggregated deployments here
Learn more about SAN attach here
Learn more about Local Identity with Azure Key Vault here.
Learn more about hardware configurations that support disaggregated deployments using the solutions catalog or learn directly from our partners:

o DataON: “DataON Premier Solutions for Azure Local provide a premium Azure Local experience that includes deployment, integration, training, and white glove service & support. Our goal is to not only get you up and running quickly but also to help your team to be confident in managing Azure Local.”

o Dell Technologies: “Coming Soon, Dell Private Cloud–Microsoft enables a modern disaggregated architecture, simplifying operations across Dell PowerEdge compute, Dell PowerStore storage, and Azure Local.”

“Available now, Dell PowerStore delivers high-performance, scalable, and resilient storage for Azure Local, with support for Dell Private Cloud coming soon to make it easier to streamline operations for storage, compute, and your Azure Local license.”

o Everpure: “Azure Local now supports external storage with Everpure FlashArray, offering Azure Local customers unprecedented levels of scale, performance and efficiency with the added benefit of seamless hybrid cloud integration with Everpure Cloud in Azure.”

o Hitachi Vantara: “Hitachi Vantara VSP and VSP One Block, fully validated to meet Microsoft's Azure Local storage requirements, deliver enterprise SAN reliability for Azure Local.”

o HPE: “HPE ProLiant Compute Premier Solutions for Azure Local enable customers to gain full control over data residency, and accelerate innovation with industry-leading performance, security, and management automation.”

“HPE Alletra Storage MP B10000 integrated with Azure Local delivers a unified, Azure managed experience with the simplicity of Azure Local plus the advanced data services of a modern enterprise storage platform.”

o Lenovo: “Lenovo is expanding its Azure Local portfolio to support disaggregated infrastructure designs that deliver greater choice across compute and storage. The ThinkAgile Disaggregated Solution for Microsoft Azure Local with new compute-only configurations on ThinkAgile MX Series enables customers to integrate ThinkSystem DM, DS, and DG Series storage arrays or bring their own Azure Local validated third party SAN arrays into new or existing Azure Local environments, allowing fully disaggregated, independent scaling using enterprise class Lenovo solutions for sovereign private cloud deployments and emerging AI workloads.”

o NetApp: “With Azure Local, NetApp delivers support across NetApp® AFF, ASA, and FAS systems.”

Thank you!

This first feature release of 2026 is packed with innovation for Azure Local, and we can’t wait for you to try it and share feedback. We are committed to listening to your feedback and delivering the next wave of capabilities in a continuously evolving world. Thank you to all our customers who trust Azure Local to run their business—and to our engineering partners for the incredible collaboration in building solutions together.

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 Blog articles

Your first model deployment on Foundry Local on Azure Local: from catalog to inference in 10 minutes

What you'll build

Before you start

Step 1 - See what's in your catalog

Step 2 - Deploy a model

Step 3 - Run inference

Step 4 - Clean up

Going beyond CPU: vLLM in 5 lines

What you've built

From endpoint to chat surface

Where to go from here

Build, deploy, and govern sovereign AI with Foundry Local on Azure Local

Expansion of Foundry Local on Azure Local

From intelligence to action: agents and tools inside the enterprise boundary

GitHub Enterprise Local: Now available in public preview

Accelerating High-performance AI at the Edge with NVIDIA

Hardware options: AI factory configurations are available now in the catalog

From AI models to trusted, mission-critical systems: what this unlocks for developers and operators

Resources

Unlock On-Prem Productivity with Agentic Retrieval in Foundry Local

What’s new at Build 2026

Agentic Retrieval: From Answering to Reasoning

What customers can achieve:

Knowledge: A First-Class, Governed Data Layer

What customers can achieve:

Chat UI: Production-Ready Conversational Experience

What customers can achieve:

Why This Release Matters

Learn More

Scale On-Prem AI with Foundry Local on Azure Local: Multi-Node Inference and vLLM Support

Runs disconnected - no cloud round-trip required

Multi-node scheduling: more scenarios, more capacity

vLLM runtime: high-throughput serving for production workloads

Why vLLM matters for edge and on-premises inference

Automatic GPU inference tuning with the vLLM planner

Identity-based access for multi-user workloads

Expanded model catalog: ONNX and vLLM side by side

Broader open-model support

Models available in vLLM format

Bring-your-own model (BYOM)

Choosing the right runtime

What hasn't changed

Real-world scenarios, now at scale

With multi-node and vLLM, the scenarios from our initial preview scale to meet production demands:

Manufacturing: multi-user quality inspection

Sovereign: identity-scoped document processing

Energy: disconnected multi-user operations

Getting started

What's next

Introducing GitHub Enterprise Local (Preview): DevOps for Sovereign and Private Cloud Environments

What Is GitHub Enterprise Local?

Developer and Platform Capabilities

Developer AI Workflow Architecture

Architecture Overview

Infrastructure Layer

GitHub Enterprise Local Appliance Layer

Operations Layer

Connectivity Modes and Deployment Scenarios

Hardware and Capacity Planning

Billing Overview

Public Preview Access

Learn More

Embed intelligence into physical systems with smaller form factor infrastructure (preview)

Demo: a simple robot that thinks for itself

Lightweight deployments on smaller form factor hardware (preview)

Run agents and models locally with Foundry Local (preview)

More popular Azure services

Choose the hardware that fits your requirements

Get started today

Ansible + Azure Arc: Manage Azure Arc Extensions with New Ansible Modules

Azure Arc Server April 2026 Forum

Simplified access to Hotpatching enabled by Azure Arc for Windows Server 2025

Which machines are eligible for this offer?

How do I manage hotpatches enabled by Azure Arc for Windows Server 2025?

Frequently Asked Questions

Introducing cert-manager for Azure Arc-enabled Kubernetes: now in Public Preview

What it does

Why we built it

Problem 1: Manual certificate issuance.

Accelerating High-performance AI at the Edge with NVIDIA 