Azure Arc for servers: the complete setup guide, and why it changes how you run everything outside Azure

Most estates don't live in one place. There's a datacentre, a couple of branch offices, some workloads in another cloud, and usually one server under a desk that nobody quite owns. Each one tends to come with its own patching, its own monitoring and its own blind spots.

Azure Arc-enabled servers fixes that without moving anything. You install one agent and the server becomes an Azure resource. It gets a resource ID, sits in a resource group, takes tags, and can be managed by the same Azure tools you already use for your Azure VMs.

This guide goes end to end: how Arc works under the hood, how to plan a rollout, the network options, every onboarding method, what to switch on afterwards, how to lock it down, how to run it day to day, and how to fix it when it breaks. Everything comes from Microsoft's own documentation, linked at the end.

What Arc is, and what it isn't

Microsoft's definition: Arc-enabled servers lets you manage Windows and Linux physical servers and virtual machines hosted outside of Azure, on your corporate network or with another cloud provider.

• It doesn't migrate anything. The server stays where it is and keeps running its workload. Arc adds a management connection.
• It's not for Azure VMs. The agent won't install on an Azure VM, and the installer rolls back if it detects one.
• An Arc outage doesn't stop your servers. Microsoft is explicit that an outage only affects management through Arc, not the workload itself.
• There's no limit on the number of Arc-enabled servers or extensions in a resource group or subscription.
• Your data stays in region. By default, customer data stays in the region you register the server in. The metadata Arc collects is things like the OS name and version, computer name, FQDN and agent version.

How it works

The agent

The Azure Connected Machine agent is a handful of services working side by side:

On Windows it installs to %ProgramFiles%\AzureConnectedMachineAgent, with configuration, logs and identity files in %ProgramData%\AzureConnectedMachineAgent. On Linux it lives under /opt/azcmagent/ and /var/opt/azcmagent/.

The connection

Every connection the agent makes is outbound HTTPS on TCP 443. There are no inbound ports to open and no VPN to build. The agent keeps a persistent connection open for notifications and sends a heartbeat every five minutes.

The server's identity credential is valid for up to 90 days and renews every 45, which is why a long disconnection matters. If a server is disconnected, its machine configuration assignments are kept locally for 14 days and then deleted.

The control model

The only way to make the agent do anything, such as install an extension or run a command, is through the server's resource in Azure. So Azure RBAC on that resource is your access control, and Azure activity logs are your audit trail. On top of that, local settings on the server take precedence over anything set in the cloud, which we'll use later to lock it down.

Plan before you onboard

Organise your resources

An Arc server is a normal Azure resource, so the structure you choose now drives RBAC, Azure Policy and cost reporting later. A few patterns that work well:

• Resource groups per site or environment, such as rg-arc-london-prod. That's your natural boundary for who can manage what.
• Tags at connect time, such as Datacenter, Environment and Owner. azcmagent connect takes a --tags flag, so every server arrives labelled.
• The nearest region when you generate the script. Microsoft recommends the Azure region closest to the server, and it's also where that server's data is kept.

Who needs which role

Choose a network pattern

The network in detail

Endpoints and service tags

The planner below builds the exact list for your options. The short version:

• Always: login.microsoftonline.com, *.login.microsoft.com, pas.windows.net, *.his.arc.azure.com, *.guestconfiguration.azure.com, the guest notification service and *.servicebus.windows.net.
• When installing: download.microsoft.com for Windows and packages.microsoft.com for Linux.
• When connecting or disconnecting: management.azure.com.
• Service tags, if your firewall supports them: AzureActiveDirectory, AzureTrafficManager, AzureResourceManager, AzureArcInfrastructure, Storage and AzureFrontDoor.Frontend. Allow the whole AzureArcInfrastructure tag, not a regional slice.

One that catches people out: the agent normally gets tokens from a regional Entra endpoint, such as uksouth.login.microsoft.com, and only falls back to the global one. Allowing login.microsoftonline.com on its own isn't enough. Servers need TLS 1.2 or 1.3, which is on by default from Windows Server 2012 R2.

Using a proxy

Set the proxy on the agent itself rather than through environment variables. No service restart is needed:

1
2
3azcmagent config set proxy.url "http://proxy.contoso.com:8080"
azcmagent config get proxy.url
azcmagent config clear proxy.url

If some traffic should skip the proxy, for example because Entra ID is reachable directly, use proxy.bypass with one or more of AAD, ARM, AMA, Arc and ArcData:

azcmagent config set proxy.bypass "AAD,ARM"

Some extensions don't inherit the agent's proxy settings, so check each extension's documentation.

Azure Arc gateway

The gateway is an Azure resource that acts as a single front door for Arc traffic. With it, servers only need seven endpoints: your gateway URL (<prefix>.gw.arc.azure.com), management.azure.com, login.microsoftonline.com plus your regional login endpoint, gbl.his.arc.azure.com, <region>.his.arc.azure.com, and the package download site for your OS.

• Up to five gateways per subscription. For servers only, one gateway handles around 2,000 servers per region.
• The onboarding script gains a --gateway-id parameter. From agent 1.51, existing servers switch to the gateway automatically when you associate them.
• Some extensions still need their own endpoints. The Azure Monitor Agent, for example, needs your Log Analytics workspace's ingestion endpoint.

Private Link

Create an Azure Arc Private Link Scope and a private endpoint, then connect servers with --private-link-scope "<scope resource ID>". Only *.his.arc.azure.com and *.guestconfiguration.azure.com go through the private endpoint. Entra ID and the notification service stay public, and management.azure.com stays public unless you also set up a Resource Manager private link.

Plan your rollout with the planner

Pick your options below. You'll get the exact firewall allow-list, an onboarding script with your values filled in, and a readiness checklist. Nothing you type leaves your browser.

Before you start: prerequisites

Supported operating systems

• Windows Server 2012, 2012 R2, 2016, 2019, 2022 and 2025, Desktop or Server Core, x64 only.
• Windows 10 and 11, but only when used like a server: always on, always connected.
• Linux, including Ubuntu 18.04 to 24.04, RHEL 7 to 10, Debian 11 to 13, SLES 12 SP5 and 15, Rocky, Alma, Oracle Linux, Azure Linux and Amazon Linux. 64-bit only.

If a version isn't on Microsoft's list, it isn't supported. Linux needs systemd, wget and openssl, plus gnupg on Debian-based systems. On Windows, if Group Policy controls the "Log on as a service" right, add NT SERVICE\himds to it.

Resource providers

1
2
3
4
5
6az account set --subscription "<subscription>"
az provider register --namespace Microsoft.HybridCompute
az provider register --namespace Microsoft.GuestConfiguration
az provider register --namespace Microsoft.HybridConnectivity
az provider register --namespace Microsoft.AzureArcData   # only for Arc-enabled SQL Server
az provider register --namespace Microsoft.Compute        # for Update Manager

Step by step: your first server

1. Register the resource providers above, once per subscription.
2. Create the resource group, following the structure you planned.
3. Open the network using the planner's list, a proxy, Arc gateway or Private Link.
4. Generate the script. In the portal, go to Azure Arc > Machines > Onboard/Create > Onboard existing machines. Pick the subscription, resource group and nearest region, add tags, and download the script.
5. Check the network from the server before connecting:
   text1 linecopy

   azcmagent check --location uksouth

6. Run the script as an administrator. On Windows it must be a 64-bit PowerShell session. Without a service principal it signs you in through a browser or device code.
7. Confirm it worked. The server should show as Connected under Azure Arc > Machines within a few minutes, and azcmagent show on the server should say the same.

Onboarding at scale

The service principal

For anything beyond a handful of servers, use a service principal. In the portal, go to Azure Arc > Service principals > Add, scope it to the resource group or subscription, choose a secret lifetime, and give it the Azure Connected Machine Onboarding role. Microsoft describes it as a limited identity with only the permission needed to connect machines, and it's used only during onboarding.

When you generate the script, choose Authenticate machines automatically and pick the service principal. The connect command then looks like this:

1
2
3
4
5
6
7
8azcmagent connect `
  --subscription-id "<subscription-id>" `
  --resource-group "rg-arc-london-prod" `
  --location "uksouth" `
  --tenant-id "<tenant-id>" `
  --service-principal-id "<app-id>" `
  --service-principal-secret "<secret>" `
  --tags "Datacenter=London,Environment=Prod"

Microsoft recommends passing the secret through a configuration file rather than on the command line, so it doesn't end up in console logs. Keep the secret's lifetime short and remove it when the rollout's done.

Every way to roll it out

Group Policy, step by step

1. Create a share that domain controllers and servers can reach. Give domain computers Change permission and domain admins Full Control.
2. Download Microsoft's ArcEnabledServersGroupPolicy release from GitHub and the agent MSI from aka.ms/AzureConnectedMachineAgent, and put both on the share.
3. On a domain controller, run DeployGPO.ps1:
   text4 linescopy

   1
   2
   3
   4.\DeployGPO.ps1 -DomainFQDN contoso.com -ReportServerFQDN Server.contoso.com `
     -ArcRemoteShare AzureArcOnBoard -ServicePrincipalSecret $ServicePrincipalSecret `
     -ServicePrincipalClientId $ServicePrincipalClientId -SubscriptionId $SubscriptionId `
     -ResourceGroup $ResourceGroup -Location $Location -TenantId $TenantId

4. Link the new GPO, [MSFT] Azure Arc Servers (datetime), to the OU of servers you want to onboard. It runs a scheduled task on each one. Scope it carefully, because everything in scope gets onboarded.
5. Once the servers show as Connected, disable the GPO, so the task doesn't run again at every reboot or policy refresh.

Things to decide during rollout

• SQL Server: servers running SQL Server have their SQL instances connected to Arc automatically. To opt out, add the tag ArcSQLServerExtensionDeployment = Disabled when you connect.
• Automatic agent upgrades (preview, agent 1.57+, public cloud only): add --enable-automatic-upgrade to the connect command, or assign the built-in policy Configure Azure Arc-enabled Servers to enable automatic upgrades.

After onboarding: switch things on

This is where Arc pays off. Use Azure Policy at the resource group or management group so every new server picks everything up the moment it connects.

Update Manager

Assign the built-in policy Configure periodic checking for missing system updates on Azure Arc-enabled servers, once for Windows and once for Linux, with a remediation task. Update Manager then checks each server for missing updates every 24 hours. Add a maintenance configuration to patch on a schedule alongside your Azure VMs.

Azure Monitor

Create a data collection rule for the logs and counters you want, then assign Microsoft's built-in initiative to configure Windows or Linux Arc machines with the Azure Monitor Agent, passing the DCR's resource ID. The policy installs the agent and associates the rule on every server it covers.

Defender for Cloud

Turn on Defender for Servers for the subscription. Arc servers in it get Microsoft Defender for Endpoint, vulnerability management and threat detection, just like Azure VMs. Plan 2 also covers Update Manager and machine configuration costs for those servers.

Machine configuration

Assign machine configuration policies, such as Microsoft's security baselines, to audit settings inside every server, wherever it runs.

Windows Server Management enabled by Azure Arc

If your Windows Server licences have active Software Assurance or are subscription licences, you can unlock a set of services at no extra cost beyond networking, storage and log ingestion:

• Update Manager, Change Tracking and Inventory, and machine configuration (Windows Server 2012 and later).
• Windows Admin Center in Azure, Remote Support, Best Practices Assessment, Azure Site Recovery configuration, and discounted Azure File Sync (Windows Server 2016 and later).
• Network HUD (Windows Server 2025).

It isn't automatic. You have to attest: go to Azure Arc > Licenses > Azure Benefits - Windows Server, select the servers, choose Activate benefits, accept the terms and select Activate. The status changes to Activated within about ten minutes. Servers need agent 1.47 or later and must be Connected.

Managed identity: no more secrets in config files

Every Arc server gets a system-assigned managed identity. Grant it access to, say, a Key Vault, and apps on the server can get a token from a local endpoint at http://localhost:40342. Only members of the local Administrators or Hybrid Agent Extension Applications group on Windows, or the himds group on Linux, can request tokens. The request is a two-step challenge that proves the caller can read a protected local file:

1
2
3
4
5
6
7
8$apiVersion = "2020-06-01"
$resource   = "https://vault.azure.net"
$endpoint   = "{0}?resource={1}&api-version={2}" -f $env:IDENTITY_ENDPOINT, $resource, $apiVersion
try { Invoke-WebRequest -Method GET -Uri $endpoint -Headers @{ Metadata = 'True' } -UseBasicParsing }
catch { $secretFile = ($_.Exception.Response.Headers["WWW-Authenticate"] -split "Basic realm=")[1] }
$secret   = Get-Content -Raw $secretFile
$response = Invoke-WebRequest -Method GET -Uri $endpoint -Headers @{ Metadata = 'True'; Authorization = "Basic $secret" } -UseBasicParsing
$token    = (ConvertFrom-Json $response.Content).access_token

Lock the agent down

For sensitive servers, use the agent's local controls. They take precedence over anything set in the cloud:

1
2
3
4
5
6
7
8# only allow the extensions you actually use
azcmagent config set extensions.allowlist "Microsoft.Azure.Monitor/AzureMonitorWindowsAgent,Microsoft.Azure.AzureDefenderForServers/MDE.Windows"

# turn off remote access features
azcmagent config set incomingconnections.enabled false

# only if you don't use machine configuration on this server
azcmagent config set guestconfiguration.enabled false

Beyond that, keep RBAC tight. Anyone who can write to an Arc server resource can install extensions and run commands on the machine, so treat Azure Connected Machine Resource Administrator on your Tier 0 servers like any other privileged role, ideally through PIM.

Day-two operations

Keeping the agent up to date

• Windows: Microsoft recommends Microsoft Update. On domain-joined servers, enable "Install updates for other Microsoft products" in the Configure Automatic Updates policy. Or upgrade silently with msiexec.exe /i AzureConnectedMachineAgent.msi /qn.
• Linux: upgrade through your package manager (apt, yum or zypper) from packages.microsoft.com.
• Either: Update Manager can upgrade the agent, or turn on automatic agent upgrade.

Watching the estate with Resource Graph

Arc servers are queryable in Azure Resource Graph like everything else. A quick health view:

1
2
3Resources
| where type == 'microsoft.hybridcompute/machines'
| summarize Servers = count() by Status = tostring(properties.status)

And Microsoft's sample for servers running an outdated agent:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16AdvisorResources
| where type == 'microsoft.advisor/recommendations'
| where properties.category == 'HighAvailability'
| where properties.shortDescription.solution == 'Upgrade to the latest version of the Azure Connected Machine agent'
| project id, JoinId = toupper(properties.resourceMetadata.resourceId),
    machineName = tostring(properties.impactedValue),
    agentVersion = tostring(properties.extendedProperties.installedVersion),
    expectedVersion = tostring(properties.extendedProperties.latestVersion)
| join kind=leftouter (
    Resources
    | where type == 'microsoft.hybridcompute/machines'
    | project machineId = toupper(id), status = tostring(properties.status)
  ) on $left.JoinId == $right.machineId
| where status != 'Expired'
| summarize by id, machineName, agentVersion, expectedVersion
| order by tolower(machineName) asc

Turn the first query into an alert and you'll know about disconnected servers before anyone asks.

Decommissioning a server

Do it in this order, because uninstalling the agent doesn't remove extensions or the Azure resource:

1. Remove all extensions from the server in Azure.
2. Disconnect: run azcmagent disconnect as an administrator. This deletes the Azure resource and clears the agent's local state.
3. Uninstall the agent: through Programs and Features or msiexec /x on Windows, or your package manager on Linux.

If the Azure resource has already been deleted, use azcmagent disconnect --force-local-only to clean up the server.

What it costs

Two ways to bring the bill down:

• Windows Server Software Assurance or subscription licences, through the attestation above.
• Defender for Servers Plan 2, which includes Update Manager and machine configuration for the servers it covers.

Update Manager on Arc is charged per server, prorated daily, and only for days the server is Connected and actually managed by Update Manager.

Troubleshooting

Start here

• azcmagent check --location <region> tests every endpoint the agent needs. Run it first, always.
• azcmagent show shows the agent's status and connection details, including the proxy settings it's using.
• Add --verbose to any command, then read the log: %ProgramData%\AzureConnectedMachineAgent\Log\azcmagent.log on Windows or /var/opt/azcmagent/log/azcmagent.log on Linux.
• azcmagent logs collects everything into a zip for a support case.

Common error codes

Usual suspects

• Only the global login endpoint is allowed. Add the regional one, such as uksouth.login.microsoft.com.
• TLS inspection on the proxy. Exclude the Arc endpoints.
• A Log Analytics gateway used as the proxy. It isn't supported for the Connected Machine agent.

FAQ