One benefit of using Azure Management Services is that servers managed with Azure Arc are displayed as objects on the Azure portal. These servers can therefore be inventoried, updated, and monitored by a consolidated approach along with the servers that reside in Azure. Azure Arc also offers other features that help you manage databases and Kubernetes clusters, but in this article we focus on managing what Microsoft refers to as Azure Arc-enabled servers.

Fortunately, Microsoft offers the features of the Azure Arc control plane free of charge. The feature set includes tag-based server management, Azure management groups, the ability to find and index servers with Azure Resource Graph, access rights management with the help of Azure role-based access control (RBAC), template- and extension-based automation, and update orchestration. However, Azure Arc resources currently incur a cost of $6 per server per month if you want to use Azure Policy guest configuration (free for traditional Azure resources). Other services such as Azure Monitor or Azure Defender also incur charges if used for Azure Arc-enabled servers.

Agents Get the Job Done

The Azure Connected Machine Agent (ACMA) lets you manage Windows and Linux machines running outside of Azure in a traditional data center or hosted by another cloud provider with Azure. Microsoft provides a diagram of all the Azure Arc components online [1], which also shows the agent's tasks and its communication relationships with the Azure services.

Three components in ACMA handle communication with Azure and management tasks on the local machine. The Hybrid Instance Metadata Service (HIMDS) is responsible for establishing the connection with Azure and provides the identity of the connected machine. The Guest Configuration agent verifies that the server complies with the Azure configuration specifications and implements these specifications if needed. The Extension Agent manages the deployment of virtual machine (VM) extensions. These small applications are used for configuration and automation tasks such as installing software or running scripts.

The Azure Virtual Machine Agent (VM Agent) for Windows (also known as the Windows Azure Guest Agent) is required to process VM extensions. It comes pre-installed on Azure machines and is based on Azure Marketplace images. As part of the Extension Manager, the diagram also shows the Azure Monitor Agent (AMA), which is responsible for collecting monitoring information on the server and sending it to Azure Log Analytics.

The ACMA components also have communication relationships with Azure Resource Providers (ARPs). For security reasons, not all ARPs are registered in an Azure subscription out of the box. To use Azure Arc-enabled servers, you need to enable three ARPs for the subscription you are using. Although you can do this in just a few steps on the portal, it's even easier with PowerShell:

Login AzAccount
Set-AzContext -SubscriptionId <Subscription to register resource providers>
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute
Register-AzResourceProvider -ProviderNamespace Microsoft.GuestConfiguration
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridConnectivity

You can only install the ACMA on a supported operating system: Windows Server 2008 R2 SP1 and newer and popular Linux distributions. Microsoft provides exact details of the prerequisites, restrictions, and required rights in Azure [2].

Planning Azure Arc Deployment

The next steps to setting up Azure Arc in a pilot or production environment are the planning steps. One requirement is to create a separate Azure resource group that contains only Azure Arc-enabled servers (Figure 1). Additionally, several planning and review steps are recommended to ensure targeted use of policies, permissions, logging, and tags on Arc-enabled servers.

Figure 1: Azure Arc-managed servers require their own resource group.

On the network side, the ACMA must be able to communicate over the Internet with the Arc services on TCP port 443; of course, this communication is encrypted. To further enhance communication security, it also makes sense to use the still fairly new Azure Private Link service, which uses a private endpoint to make Azure Arc components accessible from an Azure virtual network (VNet). If the external servers then connect to Azure over a virtual private network (VPN) or Azure ExpressRoute, the network traffic generated for Arc is also no longer routed over public IP addresses. Azure Private Link generates some costs for providing the private endpoints and the transfer volume.

Rolling Out the ACMA

Now that the planning is complete, the next step is to roll out the ACMA to the target systems. You can either do this manually and interactively or automate the process in larger environments. We went for automated integration with an Azure service principal, but to do so, you have to create the principal first. To begin, use the search bar on the Azure portal to switch to the Azure Arc service and select Service principals . Clicking Add takes you to the wizard, where you need to enter the following data:

• Name: The name of your service principal (e.g., sp_AzureArc_ Servers )
• Scope assignment level: Resource group
• Subscription and Resource group: Create a resource group (e.g., rg_AzureArc )
• Client secret: Under Expires, define the validity period of the client secret string (also known as the application password), which is automatically created for your service principal. Longer validity periods improve usability and convenience, but at the price of risking misuse or disclosure of the secret.
• Role assignment: Select the Azure Connected Machine Onboarding role.

To create the service principal, select Create and in the next field copy the credentials (client ID and client secret) to a safe place, because you will need them for the onboarding scripts. A word of caution: After closing this page, the access credentials can no longer be retrieved.

Next, switch to the Server item in the Infrastructure category in the menu on the left. Clicking + Add gives you several options for adding single or multiple servers to Azure Arc. We opted for the possibility of creating generic scripts for Windows and Linux. Thanks to the client ID and client secret, these scripts can add any number of servers to Azure Arc without admin interaction within the validity period of the credentials.

In the wizard, select the subscription and resource group (rg_AzureArc ) that was created in the previous step. In Server details , you need to specify the operating system for which you will be generating the script and the region where you want the Azure Arc servers to reside after running the script. As the Connectivity method , leave the Public endpoint default, and for Authentication use the service principal you just created, which results in the client ID being listed in the script. In the final Download and run script step, you then download the script (for PowerShell, Bash, or Ansible). If you have selected Windows as the operating system, you will also be given script variants for Microsoft System Center Configuration Manager or Group Policies. Now you just need to copy the client secret into the area marked Enter secret here , after which the script is ready to use.

For this example with Azure Arc-enabled servers, prepare several Windows Server 2022 and Red Hat Enterprise Linux 8.x VMs. After copying the script and running it in PowerShell or Bash, the Azure Arc registration completes without any glitches, and the servers appear as new objects in the resource group or below Servers on the Azure Arc dashboard immediately afterwards. The metadata of the machines, such as the computer name, the exact operating system version, or the underlying server platform (in this case VMware Workstation ) were transmitted directly by ACMA.