Edit

Connected Machine agent prerequisites

  • Article

Caution

This article references CentOS, a Linux distribution that is nearing End Of Life (EOL) status. Please consider your use and planning accordingly. For more information, see the CentOS End Of Life guidance.

This topic describes the basic requirements for installing the Connected Machine agent to onboard a physical server or virtual machine to Azure Arc-enabled servers. 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. This includes support for virtual machines running on platforms like:

  • VMware (including Azure VMware Solution)
  • Azure Stack HCI
  • Other cloud environments

You shouldn't install Azure Arc on virtual machines hosted in Azure, Azure Stack Hub, or Azure Stack Edge, as they already have similar capabilities. You can, however, use an Azure VM to simulate an on-premises environment for testing purposes, only.

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 configuration, you will 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 has been cloned, restored from backup, or created from a golden image.

Note

For additional information on using Azure Arc-enabled servers in VMware environments, see the VMware FAQ.

Supported operating systems

Azure Arc supports the following Windows and Linux operating systems. Only x86-64 (64-bit) architectures are supported. The Azure Connected Machine agent does not run on x86 (32-bit) or ARM-based architectures.

  • AlmaLinux 9
  • Amazon Linux 2 and 2023
  • Azure Linux (CBL-Mariner) 1.0, 2.0
  • Azure Stack HCI
  • CentOS Linux 7 and 8
  • Debian 10, 11, and 12
  • Oracle Linux 7, 8, and 9
  • Red Hat Enterprise Linux (RHEL) 7, 8 and 9
  • Rocky Linux 8 and 9
  • SUSE Linux Enterprise Server (SLES) 12 SP3-SP5 and 15
  • Ubuntu 16.04, 18.04, 20.04, and 22.04 LTS
  • Windows 10, 11 (see client operating system guidance)
  • Windows IoT Enterprise
  • Windows Server 2008 R2 SP1, 2012, 2012 R2, 2016, 2019, and 2022
    • Both Desktop and Server Core experiences are supported
    • Azure Editions are supported on Azure Stack HCI

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

Client operating system guidance

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, such as a laptop, which may go offline for long periods of time, shouldn't use Azure Arc and instead should consider Microsoft Intune or Microsoft Configuration Manager.

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 if the VM was deleted, so it won't automatically clean up server resources that stopped sending heartbeats. As a result, you could encounter a conflict if you re-create the VM with the same name and there's an existing Azure Arc resource with the same name.

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

Software requirements

Windows operating systems:

Linux operating systems:

  • 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 will 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 will need 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.

Screen capture of the Local Group Policy Editor showing which users have permissions to log on as a service.

Required permissions

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

Azure subscription and service limits

There are no limits to the number of Azure Arc-enabled servers you can register in any single resource group, subscription or tenant.

Each Azure Arc-enabled server is associated with a Microsoft Entra object and counts against your directory quota. See Microsoft Entra service limits and restrictions for information about the maximum number of objects you can have in a Microsoft Entra directory.

Azure resource providers

To use Azure Arc-enabled servers, the following Azure resource providers must be registered in your subscription:

  • 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