Azure Arc-enabled servers

Azure Arc-enabled servers bring Windows and Linux machines that live outside Azure (in your data centre, a branch office or another cloud) into Azure Resource Manager. Each one becomes an Azure resource you can tag, put under Azure Policy, monitor with the Azure Monitor Agent and patch with Update Manager, just like a VM.

For most companies this is the bridge to hybrid operations: one inventory, one set of policies, one monitoring workspace for every server, wherever it runs.

There’s no on-premises lab here, so you’ll use Microsoft’s supported evaluation method: a throwaway Azure VM made to look like an outside server. You’ll connect it, send its logs to law-saat, and fix the two connection problems every Arc admin meets.

TimeYou needCostBy the end you can
About 75 minutesvnet-saat, the Developer Bastion, law-saat and dcr-saat-basic, the CLIAbout 15 US cents: a small test VM and a NAT Gateway for about an hour; the Arc connection itself has no chargeOnboard a server to Azure Arc, manage it like an Azure VM, and fix disconnected agents

What it is, in one line

Azure Arc-enabled servers are machines outside Azure that run the Connected Machine agent and appear as resources in Azure.

In Simple Words

Visiting pupils on the school register

A school runs a summer camp, and children from other schools join. They aren’t the school’s pupils, but the camp puts them on its register so it can take attendance, share notices and call parents, just like its own pupils.

Each visiting child wears a camp badge. That badge is the Connected Machine agent, and the register entry is the Arc resource in Azure.

If a child stops answering roll call for a while, the register marks them “not seen”. That’s a Disconnected server, and it’s this lesson’s first break.

Engineer's View

How Arc-enabled servers work

  • Connected Machine agent (azcmagent): installed on the server, it creates a Microsoft.HybridCompute/machines resource and a managed identity for it.
  • Heartbeat: the agent checks in every 5 minutes. After 15 minutes without a heartbeat the status becomes Disconnected; after 45 days it becomes Expired and must be reconnected.
  • Network: outbound HTTPS 443 only, to Arc, Entra ID and Resource Manager endpoints, directly, through a proxy, or through Azure Arc private link scope.
  • What you get: tags, RBAC, Azure Policy and machine configuration, extensions (Azure Monitor Agent, Defender, Custom Script), Update Manager, inventory in Resource Graph and run commands.
  • Cost: connecting the server and core management have no charge; add-ons such as Update Manager, Defender for Servers and some machine configuration features are billed per server.
  • Evaluation on Azure VMs: the agent refuses to run where it can reach the Azure Instance Metadata Service (169.254.169.254). Microsoft’s test method removes the Azure VM agent and blocks that address. Never do this to a VM you need.

How it works, step by step

What happens when you run azcmagent connect on a server:

Azure Arc-enabled servers onboarding flow with azcmagent connect
  1. You sign in (device code here; a service principal for bulk onboarding).
  2. The agent creates the Arc resource in the chosen resource group and region.
  3. Azure issues a managed identity certificate to the server.
  4. The agent starts sending heartbeats and polls for extensions and policies.
  5. The server shows as Connected; you manage it from Azure from now on.

From step 4 on, everything depends on outbound HTTPS. Most Arc tickets are network tickets.

Azure Arc-enabled servers status: Connected, Disconnected and Expired

Arc doesn’t move workloads to Azure. The server stays where it is; only its management moves.

Hands-on lab: Azure Arc-enabled servers with arc01

Load the network IDs and add outbound access for this lab:

$v = Get-Content C:\azure-lab\vnet-saat.json | ConvertFrom-Json
$sub = az account show --query id -o tsv
$tenant = az account show --query tenantId -o tsv
az network public-ip create --resource-group rg-saat-core --name pip-saat-natgw --sku Standard --location centralindia --tags course=saatvedha-azure lesson=40 -o none
az network nat gateway create --resource-group rg-saat-core --name natgw-saat --public-ip-addresses pip-saat-natgw --idle-timeout 4 --location centralindia --tags course=saatvedha-azure lesson=40 -o none
az network vnet subnet update --ids $v.'snet-web' --nat-gateway natgw-saat -o none

1Create a throwaway “outside” server

A small Ubuntu VM in its own group, and a separate group for the Arc resource:

az group create --name rg-saat-l40 --location centralindia --tags course=saatvedha-azure lesson=40 -o none
az group create --name rg-saat-arc --location centralindia --tags course=saatvedha-azure lesson=40 -o none
az vm create --resource-group rg-saat-l40 --name arc01 --image Canonical:ubuntu-24_04-lts:server:latest --size Standard_B2ats_v2 --subnet $v.'snet-web' --public-ip-address '""' --nsg '""' --admin-username azureuser --generate-ssh-keys --tags course=saatvedha-azure lesson=40 -o none
"subscription: $sub"
"tenant: $tenant"

2Make it look like a non-Azure server

Open arc01 in the portal, Connect, Bastion, and sign in as azureuser with your SSH key. In the browser terminal, run Microsoft’s evaluation steps: stop and remove the Azure VM agent, and block the metadata service.

current_hostname=$(hostname)
sudo systemctl stop walinuxagent
sudo waagent -deprovision -force
sudo rm -rf /var/lib/waagent
sudo hostnamectl set-hostname $current_hostname
sudo ufw --force enable
sudo ufw deny out from any to 169.254.169.254
sudo ufw default allow incoming
curl -s -m 5 -H Metadata:true "http://169.254.169.254/metadata/instance?api-version=2021-02-01" || echo "IMDS blocked"

The last line should print this:

IMDS blocked

From now on, Run Command and VM extensions no longer work on arc01; it behaves like a server outside Azure. Keep the Bastion tab open.

3Install the agent and connect

Still in the Bastion terminal (use the subscription and tenant IDs printed in step 1):

wget -q https://aka.ms/azcmagent -O ~/install_linux_azcmagent.sh
sudo bash ~/install_linux_azcmagent.sh
sudo azcmagent connect --resource-group rg-saat-arc --location centralindia --subscription-id <subscription-id> --tenant-id <tenant-id> --use-device-code

The agent prints a device code. Open the link on your laptop, enter the code and sign in. After a minute it reports that the machine is connected.

Check from your laptop:

az connectedmachine show --resource-group rg-saat-arc --name arc01 --query "{name:name, status:status, os:osName, agent:agentVersion, lastSeen:lastStatusChange}" -o table

You should see something like this:

Name    Status     Os     Agent         LastSeen
------  ---------  -----  ------------  --------------------------------
arc01   Connected  linux  1.58.03104.2  2026-10-22T09:41:20.117000+00:00

4Manage it like an Azure VM

Tag it, add the Azure Monitor Agent as an Arc extension, and point it at the DCR from Lesson 32:

$arcId = az connectedmachine show --resource-group rg-saat-arc --name arc01 --query id -o tsv
az tag update --resource-id $arcId --operation Merge --tags env=lab owner=saatvedha -o none
az connectedmachine extension create --resource-group rg-saat-arc --machine-name arc01 --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor --type AzureMonitorLinuxAgent --location centralindia -o none
$dcrId = "/subscriptions/$sub/resourceGroups/rg-saat-core/providers/Microsoft.Insights/dataCollectionRules/dcr-saat-basic"
Set-Content -Path C:\azure-lab\dcr-assoc.json -Value ('{"properties": {"dataCollectionRuleId": "' + $dcrId + '"}}')
az rest --method put --url "https://management.azure.com${arcId}/providers/Microsoft.Insights/dataCollectionRuleAssociations/dcra-saat-basic?api-version=2022-06-01" --body '@C:\azure-lab\dcr-assoc.json' -o none

After about 10 minutes, query law-saat in the portal:

Heartbeat
| where Computer == 'arc01'
| summarize LastSeen = max(TimeGenerated) by Computer, ComputerEnvironment, ResourceProvider

You should see something like this:

Computer  ComputerEnvironment  ResourceProvider        LastSeen
arc01     Non-Azure            Microsoft.HybridCompute 2026-10-22 09:55:10

Same workspace, same DCR, same KQL as your Azure VMs, but this machine counts as non-Azure. That’s the whole idea of Arc.

Azure Arc-enabled servers list with a connected machine
arc01 in Azure Arc, Connected.
Azure Arc-enabled servers lab: arc01 connected and sending heartbeats
IMDS blocked, the agent connected, and arc01 reporting as Non-Azure.

✅ Checkpoint: arc01 shows as a Connected Arc machine with tags, the Azure Monitor Agent, and heartbeats in law-saat as Non-Azure.

Break It, Then Fix It

Keep the Bastion session to arc01 open for both.

1Break it: the server goes Disconnected

Remove the NAT Gateway, as a firewall change might, and wait 20 minutes:

az network vnet subnet update --ids $v.'snet-web' --remove natGateway -o none
Start-Sleep -Seconds 1200
az connectedmachine show --resource-group rg-saat-arc --name arc01 --query "{name:name, status:status, os:osName, agent:agentVersion, lastSeen:lastStatusChange}" -o table

You should see something like this:

Name    Status        Os     Agent         LastSeen
------  ------------  -----  ------------  --------------------------------
arc01   Disconnected  linux  1.58.03104.2  2026-10-22T10:16:20.117000+00:00

The agent missed three heartbeats, so Azure marks it Disconnected after 15 minutes. Policies, extensions and monitoring stop updating for it. In the Bastion terminal, the agent’s own checker shows why:

sudo azcmagent check --location centralindia

You should see some endpoints fail their reachability test.

Fix it: restore outbound HTTPS (NAT, firewall rules, a proxy with azcmagent config set proxy.url, or Arc private link), then wait for the next heartbeat:

az network vnet subnet update --ids $v.'snet-web' --nat-gateway natgw-saat -o none
Start-Sleep -Seconds 600
az connectedmachine show --resource-group rg-saat-arc --name arc01 --query "{name:name, status:status, os:osName, agent:agentVersion, lastSeen:lastStatusChange}" -o table

Status should be Connected again. If a server stays disconnected for 45 days, it becomes Expired and must be onboarded again.

2Break it: deleted in Azure, still connected on the server

A tidy-up script deletes the Arc resource from Azure, but nobody tells the server:

az connectedmachine delete --resource-group rg-saat-arc --name arc01 --yes

In the Bastion terminal, check the agent and try to connect again:

sudo azcmagent show | grep -i -E 'status|resource name'
sudo azcmagent connect --resource-group rg-saat-arc --location centralindia --subscription-id <subscription-id> --tenant-id <tenant-id> --use-device-code

The agent still believes it’s connected to a resource that no longer exists, and the new connect is refused because the machine is already set up with a connection. The server is in limbo: unmanaged in Azure, and stuck locally.

Fix it: clear the local connection, then connect again:

sudo azcmagent disconnect --force-local-only
sudo azcmagent connect --resource-group rg-saat-arc --location centralindia --subscription-id <subscription-id> --tenant-id <tenant-id> --use-device-code

The right way to retire an Arc server is the other way round: run sudo azcmagent disconnect on the server first, which removes both the local configuration and the Azure resource.

Clean up: first disconnect properly in the Bastion terminal:

sudo azcmagent disconnect --use-device-code

Then remove everything this lesson created, from your laptop:

az group delete --name rg-saat-arc --yes
az group delete --name rg-saat-l40 --yes
az network vnet subnet update --ids $v.'snet-web' --remove natGateway -o none
az network nat gateway delete --resource-group rg-saat-core --name natgw-saat
az network public-ip delete --resource-group rg-saat-core --name pip-saat-natgw
C:\azure-lab\Find-LabResources.ps1 -Lesson 40

The last command should print this:

Nothing tagged course=saatvedha-azure is left.
Azure Arc-enabled servers problems: Disconnected agent and deleted resource
No outbound path means Disconnected; a deleted resource needs a local disconnect.

✅ Checkpoint: You brought a Disconnected server back and fixed a server stuck after its Arc resource was deleted. All lesson resources are gone.

This happened at work

400 servers, 70 of them silent

A retailer onboarded 400 store servers to Azure Arc and moved all patching to Update Manager. Three months later, the security team found 70 store servers missing two months of patches.

Every one of them showed Disconnected or Expired in Azure. A new web proxy had been rolled out to stores, and the Arc agent wasn’t configured to use it. The servers were fine; Azure simply couldn’t reach them, so no schedule ran.

What they changed: the store build now sets the proxy with azcmagent config, and the agent’s connectivity check runs after every network change. An Azure Monitor alert fires when any Arc machine stays Disconnected for more than an hour, and a weekly Resource Graph report lists all non-Connected machines by store.

Common mistakes and troubleshooting

MistakeWhat you seeWhat to do
No outbound path or proxy not setStatus Disconnected, then ExpiredOpen 443 to Arc endpoints or set proxy.url.
Deleting the Arc resource before the agentServer stuck; connect refusedRun azcmagent disconnect on the server first.
Onboarding a normal Azure VMAgent refuses (IMDS reachable)Use Azure VM features; Arc is for outside machines.
Using a personal account for bulk onboardingOnboarding breaks when the person leavesUse a service principal with the Arc onboarding role.
Expecting Arc to be a migrationServer still on-premisesArc moves management, not workloads.
Ignoring Expired machinesStale inventory and missed patchesAlert on Disconnected; reonboard Expired.

Interview questions

Click a question to open it. Each one is written the way an interviewer would ask it. Under it you will see why they ask it and one way you could answer, in your own words.

Fresher level

1. What is Azure Arc-enabled servers?

Why they ask this: The basic concept.

How you might answer: A service that connects Windows and Linux servers outside Azure to Azure Resource Manager through the Connected Machine agent, so you can manage them with Azure tools like Policy, Monitor and Update Manager.

2. What network access does the Arc agent need?

Why they ask this: A practical requirement.

How you might answer: Outbound HTTPS on 443 to Azure Arc, Entra ID and Resource Manager endpoints, directly, through a proxy, or through Azure Arc private link scope. No inbound ports are needed.

3. What do the statuses Connected, Disconnected and Expired mean?

Why they ask this: They want the lifecycle.

How you might answer: Connected means heartbeats are arriving. Disconnected means none for 15 minutes. Expired means disconnected for 45 days; the identity certificate has expired and the server must be onboarded again.

2–5 years experience

4. An Arc server shows Disconnected. How do you troubleshoot?

Why they ask this: A real ticket.

How you might answer: Run azcmagent check and azcmagent show on the server, check DNS, proxy and firewall for the Arc endpoints, check the himds service is running, and look at agent logs. Most cases are network or proxy changes.

5. How do you onboard hundreds of servers?

Why they ask this: They want scale.

How you might answer: A service principal with the Azure Connected Machine Onboarding role, a script generated from the portal, deployed with existing tools like Configuration Manager, Group Policy or Ansible, with tags and resource groups set at connect time.

6. How do you monitor Arc servers?

Why they ask this: They want the link to earlier lessons.

How you might answer: Install the Azure Monitor Agent as an Arc extension, often by policy, and associate DCRs, the same way as Azure VMs. Data lands in the same workspace with ComputerEnvironment set to Non-Azure.

Senior level

7. How would you design hybrid management for 2,000 servers with Arc?

Why they ask this: They want governance.

How you might answer: Resource groups by location or business unit, tags at onboarding, policy initiatives for AMA, DCRs, Defender and machine configuration, Update Manager schedules by dynamic scope, Arc private link where needed, and alerts on disconnected machines.

8. What are the security considerations for Arc?

Why they ask this: They want risk awareness.

How you might answer: Arc extends Azure RBAC to on-premises servers, so Azure roles can now run commands there. I’d limit extension and run command permissions, use PIM, restrict allowed extensions on the agent, and monitor the Activity log for Arc operations.

9. When would you not use Arc?

Why they ask this: They want judgement.

How you might answer: For servers about to be retired or migrated soon, isolated networks that can’t reach Azure even through a proxy or private link, or where an existing tool already does the job well and Arc adds cost through paid add-ons.

Quick quiz

Q1. What does Azure Arc move into Azure?

  1. The workload
  2. The management of the server
  3. The disks
  4. The network
Show answer

B — The server stays where it is.

Q2. After how long without heartbeats is a machine Disconnected?

  1. 5 minutes
  2. 15 minutes
  3. 1 hour
  4. 45 days
Show answer

B — Expired comes after 45 days.

Q3. What port does the agent need?

  1. Inbound 3389
  2. Outbound 443
  3. Inbound 22
  4. Outbound 25
Show answer

B — Only outbound HTTPS.

Q4. Why does the evaluation method block 169.254.169.254?

  1. To save cost
  2. So the agent doesn’t detect an Azure VM
  3. To stop SSH
  4. For DNS
Show answer

B — The agent refuses to run where IMDS is reachable.

Q5. How should you retire an Arc server?

  1. Delete it in the portal first
  2. Run azcmagent disconnect on the server
  3. Unplug it
  4. Rotate keys
Show answer

B — Disconnect removes local config and the Azure resource.

Quick recap

You can now bring outside servers into Azure management and keep them connected.

  • The Connected Machine agent turns a server into an Azure resource.
  • Only outbound 443 is needed; proxy and firewall changes cause most issues.
  • Disconnected after 15 minutes, Expired after 45 days.
  • Manage Arc servers with the same AMA, DCRs and policies as VMs.
  • Disconnect on the server before deleting in Azure.

Next lesson

Lesson 41: From ARM templates to Bicep → You turn a portal-exported ARM template into clean Bicep and deploy it.

Further reading: Azure Arc-enabled servers

Want to go deeper into Azure Arc-enabled servers? See Microsoft’s Azure Arc-enabled servers overview and Evaluate Azure Arc-enabled servers on an Azure VM. You can also see the full plan for this course on the Azure Cloud Administration course page.

Scroll to Top