Connected Machine agent prerequisites

This article outlines the technical prerequisites, supported environments, and specifications required for successfully onboarding physical and virtual servers to Azure Arc-enabled servers. Administrators and engineers planning to implement Azure Arc in their environments should review this information. Some onboarding methods may have more requirements.

Supported environments

Azure Arc-enabled servers support the installation of the Connected Machine agent on physical servers and virtual machines hosted outside of Azure, including on platforms like:

• VMware (including Azure VMware Solution)
• Azure Local
• Other cloud environments

Cloned and golden image considerations

Take extra care when using Azure Arc on systems that are:

• Cloned
• Restored from backup as a second instance of the server
• Used to create a "golden image" from which other virtual machines are created

If two agents use the same source ID, you'll encounter inconsistent behaviors when both agents try to act as one Azure resource. The best practice for these situations is to use an automation tool or script to onboard the server to Azure Arc after it's cloned, restored from backup, or created from a golden image. For more information about cloning machines to use as Arc-enabled servers, see Cloning guidelines.

Supported operating systems

Azure Arc supports Windows and Linux operating systems as listed in the table. If an OS version isn't listed, it's not supported by Azure Arc.

x86-64 (64-bit) architecture is fully supported, while only some features may be supported on Arm64. The Azure Connected Machine agent doesn't run on 32-bit architectures.

For Windows Server, both Desktop and Server Core experiences are supported. Azure Editions are supported on Azure Local.

The Azure Connected Machine agent isn't tested on operating systems hardened by the Center for Information Security (CIS) Benchmark.

Arm64 architecture support

Not all features, virtual machine extensions, and services are supported on Arm64 at this point. For full details on Arm64 compatibility or to check if other services are supported, refer to the documentation for the service you wish to use. The following are a few features known to be supported on Arm64:

• RunCommand
• CustomScriptExtension
• Azure Monitor Agent

Client operating systems

The Azure Arc service and Azure Connected Machine Agent are supported on Windows 10 and 11 client operating systems only when using those computers in a server-like environment. That is, the computer should always be:

• Connected to the internet
• Connected to a power source
• Powered on

For example, a computer running Windows 11 that's responsible for digital signage, point-of-sale solutions, and general back office management tasks is a good candidate for Azure Arc. End-user productivity machines that may go offline for long periods of time shouldn't use Azure Arc. Consider using Microsoft Intune or Microsoft Configuration Manager for those scenarios.

Short-lived servers and virtual desktop infrastructure

Microsoft doesn't recommend running Azure Arc on short-lived (ephemeral) servers or virtual desktop infrastructure (VDI) VMs. Azure Arc is designed for long-term management of servers and isn't optimized for scenarios where you are regularly creating and deleting servers. For example, Azure Arc doesn't know if the agent is offline due to planned system maintenance or because the VM was deleted, so it doesn't automatically clean up server resources that stopped sending heartbeats. As a result, you could encounter a conflict if you recreate a deleted VM with the same name and there's an existing Azure Arc resource with the same name.

Azure Virtual Desktop on Azure Local doesn't use short-lived VMs and supports running Azure Arc on the desktop VMs.

Software and system requirements

This section details the software requirements for the Azure Connected Machine agent.

Linux operating system requirements

• systemd
• wget (to download the installation script)
• openssl
• gnupg (Debian-based systems only)

Local user logon right for Windows systems

The Azure Hybrid Instance Metadata Service runs under a low-privileged virtual account, NT SERVICE\himds. This account needs the "log on as a service" right in Windows to run. In most cases, there's nothing you need to do, because this right is granted to virtual accounts by default. However, if your organization uses Group Policy to customize this setting, you'll need to add NT SERVICE\himds to the list of accounts allowed to log on as a service.

You can check the current policy on your machine by opening the Local Group Policy Editor (gpedit.msc) from the Start menu and navigating to the following policy item:

Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a service

Check if any of NT SERVICE\ALL SERVICES, NT SERVICE\himds, or S-1-5-80-4215458991-2034252225-2287069555-1155419622-2701885083 (the static security identifier for NT SERVICE\himds) are in the list. If none are in the list, you'll need to work with your Group Policy administrator to add NT SERVICE\himds to any policies that configure user rights assignments on your servers. The Group Policy administrator needs to make the change on a computer with the Azure Connected Machine agent installed so the object picker resolves the identity correctly. The agent doesn't need to be configured or connected to Azure to make this change.

Required permissions

You'll need the following Azure built-in roles for different aspects of managing connected machines:

• To onboard machines, you must have the Azure Connected Machine Onboarding or Contributor role for the resource group where you're managing the servers.
• To read, modify, and delete a machine, you must have the Azure Connected Machine Resource Administrator role for the resource group.
• To select a resource group from the drop-down list when using the Generate script method, you'll also need the Reader role for that resource group (or another role that includes Reader access).
• When associating a Private Link Scope with an Arc Server, you must have Microsoft.HybridCompute/privateLinkScopes/read permission on the Private Link Scope Resource.

Azure resource providers

The following Azure resource providers must be registered in your subscription to use Azure Arc-enabled servers:

• Microsoft.HybridCompute
• Microsoft.GuestConfiguration
• Microsoft.HybridConnectivity
• Microsoft.AzureArcData (if you plan to Arc-enable SQL Servers)
• Microsoft.Compute (for Azure Update Manager and automatic extension upgrades)

You can register the resource providers using the following commands:

Azure PowerShell:

Connect-AzAccount
Set-AzContext -SubscriptionId [subscription you want to onboard]
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute
Register-AzResourceProvider -ProviderNamespace Microsoft.GuestConfiguration
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridConnectivity
Register-AzResourceProvider -ProviderNamespace Microsoft.AzureArcData

Azure CLI:

az account set --subscription "{Your Subscription Name}"
az provider register --namespace 'Microsoft.HybridCompute'
az provider register --namespace 'Microsoft.GuestConfiguration'
az provider register --namespace 'Microsoft.HybridConnectivity'
az provider register --namespace 'Microsoft.AzureArcData'

You can also register the resource providers in the Azure portal.

Next steps

• Review the networking requirements for deploying Azure Arc-enabled servers.
• Before you deploy the Azure Connected Machine agent and integrate with other Azure management and monitoring services, review the Planning and deployment guide.* To resolve problems, review the agent connection issues troubleshooting guide.