Tell us about your PDF experience.

Azure Arc-enabled servers

Azure Arc-enabled servers

About Azure Arc-enabled servers

ｅ OVERVIEW

What is Azure Arc-enabled servers?

Azure Connected Machine agent overview

VMware FAQ

Security overview

Ｙ ARCHITECTURE

Manage configurations for hybrid servers

Azure Arc landing zone accelerator for hybrid and multicloud

Connect machines to Azure

ｐ CONCEPT

Plan for deployment

Prerequisites

ｆ QUICKSTART

Connect a hybrid machine

｀ DEPLOY

Use a deployment script

Onboard at scale using a service principal

Deploy with Windows Admin Center

All deployment options

Proof of concept

ｓ SAMPLE

Jumpstart for Azure Arc-enabled servers

ｂ GET STARTED

Test Arc-enabled servers using an Azure VM

Reference

ｉ REFERENCE

Azure CLI

Azure PowerShell

REST

Java

JavaScript

Training

ｄ TRAINING

Learning path

Azure service integration

ｇ TUTORIAL

Azure Policy

Azure Monitor

ｃ HOW-TO GUIDE
Microsoft Sentinel

Microsoft Defender for Cloud

What is Azure Arc-enabled servers?
Article • 06/03/2024

Azure Arc-enabled servers lets you manage Windows and Linux physical servers and
virtual machines hosted outside of Azure, on your corporate network, or other cloud
provider. For the purposes of Azure Arc, these machines hosted outside of Azure are
considered hybrid machines. The management of hybrid machines in Azure Arc is
designed to be consistent with how you manage native Azure virtual machines, using
standard Azure constructs such as Azure Policy and applying tags. (For additional
information about hybrid environments, see What is a hybrid cloud? )

When a hybrid machine is connected to Azure, it becomes a connected machine and is

treated as a resource in Azure. Each connected machine has a Resource ID enabling the
machine to be included in a resource group.

To connect hybrid machines to Azure, you install the Azure Connected Machine agent
on each machine. This agent doesn't replace the Azure Log Analytics agent / Azure
Monitor Agent. The Log Analytics agent or Azure Monitor Agent for Windows and Linux
is required in order to:

Proactively monitor the OS and workloads running on the machine

Manage it using Automation runbooks or solutions like Update Management
Use other Azure services like Microsoft Defender for Cloud

You can install the Connected Machine agent manually, or on multiple machines at
scale, using the deployment method that works best for your scenario.

７ Note

This service supports Azure Lighthouse, which lets service providers sign in to their
own tenant to manage subscriptions and resource groups that customers have
delegated.

７ Note

For additional guidance regarding the different services Azure Arc offers, see
Choosing the right Azure Arc service for machines.

Supported cloud operations

When you connect your machine to Azure Arc-enabled servers, you can perform many
operational functions, just as you would with native Azure virtual machines. Below are
some of the key supported actions for connected machines.

Govern:
Assign Azure machine configurations to audit settings inside the machine. To
understand the cost of using Azure Machine Configuration policies with Arc-
enabled servers, see Azure Policy pricing guide .
Protect:
Protect non-Azure servers with Microsoft Defender for Endpoint, included
through Microsoft Defender for Cloud, for threat detection, for vulnerability
management, and to proactively monitor for potential security threats.
Microsoft Defender for Cloud presents the alerts and remediation suggestions
from the threats detected.
Use Microsoft Sentinel to collect security-related events and correlate them with
other data sources.
Configure:
Use Azure Automation for frequent and time-consuming management tasks
using PowerShell and Python runbooks. Assess configuration changes for
installed software, Microsoft services, Windows registry and files, and Linux
daemons using Change Tracking and Inventory
Use Update Management to manage operating system updates for your
Windows and Linux servers. Automate onboarding and configuration of a set of
Azure services when you use Azure Automanage (preview).
Perform post-deployment configuration and automation tasks using supported
Arc-enabled servers VM extensions for your non-Azure Windows or Linux
machine.
Monitor:
Monitor operating system performance and discover application components to
monitor processes and dependencies with other resources using VM insights.
Collect other log data, such as performance data and events, from the operating
system or workloads running on the machine with the Log Analytics agent. This
data is stored in a Log Analytics workspace.

７ Note

At this time, enabling Azure Automation Update Management directly from an

Azure Arc-enabled server is not supported. See Enable Update Management from
your Automation account to understand requirements and how to enable Update
Management for non-Azure VMs.
Log data collected and stored in a Log Analytics workspace from the hybrid machine
contains properties specific to the machine, such as a Resource ID, to support resource-
context log access.

Watch this video to learn more about Azure monitoring, security, and update services
across hybrid and multicloud environments.
https://www.youtube-nocookie.com/embed/mJnmXBrU1ao

Supported regions
For a list of supported regions with Azure Arc-enabled servers, see the Azure products
by region page.

In most cases, the location you select when you create the installation script should be
the Azure region geographically closest to your machine's location. Data at rest is stored
within the Azure geography containing the region you specify, which may also affect
your choice of region if you have data residency requirements. If the Azure region your
machine connects to has an outage, the connected machine isn't affected, but
management operations using Azure may be unable to complete. If there's a regional
outage, and if you have multiple locations that support a geographically redundant
service, it's best to connect the machines in each location to a different Azure region.

Instance metadata information about the connected machine is collected and stored in
the region where the Azure Arc machine resource is configured, including the following:

Operating system name and version

Computer name
Computers fully qualified domain name (FQDN)
Connected Machine agent version

For example, if the machine is registered with Azure Arc in the East US region, the
metadata is stored in the US region.

Supported environments
Azure Arc-enabled servers support the management of physical servers and virtual
machines hosted outside of Azure. For specific details about supported hybrid cloud
environments hosting VMs, see Connected Machine agent prerequisites.

７ Note
 Azure Arc-enabled servers is not designed or supported to enable management of
virtual machines running in Azure.

Agent status
The status for a connected machine can be viewed in the Azure portal under Azure Arc
> Servers.

The Connected Machine agent sends a regular heartbeat message to the service every
five minutes. If the service stops receiving these heartbeat messages from a machine,
that machine is considered offline, and its status will automatically be changed to
Disconnected within 15 to 30 minutes. Upon receiving a subsequent heartbeat message
from the Connected Machine agent, its status will automatically be changed back to
Connected.

If a machine remains disconnected for 45 days, its status may change to Expired. An
expired machine can no longer connect to Azure and requires a server administrator to
disconnect and then reconnect it to Azure to continue managing it with Azure Arc. The
exact date upon which a machine expires is determined by the expiration date of the
managed identity's credential, which is valid up to 90 days and renewed every 45 days.

Service limits
There's no limit to how many Arc-enabled servers and VM extensions you can deploy in
a resource group or subscription. The standard 800 resource limit per resource group
applies to the Azure Arc Private Link Scope resource type.

To learn more about resource type limits, see the Resource instance limit article.

Data residency
Azure Arc-enabled servers stores customer data. By default, customer data stays within
the region the customer deploys the service instance in. For region with data residency
requirements, customer data is always kept within the same region.

Next steps
Before evaluating or enabling Azure Arc-enabled servers across multiple hybrid
machines, review the Connected Machine agent overview to understand
requirements, technical details about the agent, and deployment methods.
Try out Arc-enabled servers by using the Azure Arc Jumpstart .
Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.
Explore the Azure Arc landing zone accelerator for hybrid and multicloud.
Azure Arc-enabled servers VMware
Frequently Asked Questions
Article • 11/20/2023

This article addresses frequently asked questions about Arc-enabled servers on virtual
machines running in VMware vSphere environments.

What is Azure Arc?

Azure Arc is the overarching brand for a suite of Azure hybrid products that extend
specific Azure public cloud services and/or management capabilities beyond Azure to
on-premises environments and 3rd-party clouds. Azure Arc-enabled server, for example,
allows you to use the same Azure management tools you would with a VM running in
Azure with a VM running on-premises in a VMware vSphere cluster.

What's the difference between Azure Arc-

enabled servers and Azure Arc-enabled
VMware vSphere?

７ Note

Arc-enabled VMware vSphere supports vSphere environments anywhere, either

on-premises as well as Azure VMware Solution (AVS), VMware Cloud on AWS, and
Google Cloud VMware Engine.

The easiest way to think of this is as follows:

Azure Arc-enabled servers interact on the guest operating system level, with no
awareness of the underlying infrastructure fabric and the virtualization platform
that it’s running on. Since Arc-enabled servers also support bare-metal machines,
there may, in fact, not even be a host hypervisor in some cases.

Azure Arc-enabled VMware vSphere is a superset of Arc-enabled servers that

extends management capabilities beyond the guest operating system to the VM
itself. This provides lifecycle management and CRUD (Create, Read, Update, and
Delete) operations on a VMware vSphere VM. These lifecycle management
 capabilities are exposed in the Azure portal and look and feel just like a regular
Azure VM. See What is Azure Arc-enabled VMware vSphere to learn more.

Can I use Azure Arc-enabled server on VMs

running in VMware environments?
Yes. Azure Arc-enabled servers work with VMs running in an on-premises VMware
vSphere environment as well as Azure VMware Solution (AVS) and support the full
breadth of guest management capabilities across security, monitoring, and governance.

Which operating systems does Azure Arc-

enabled servers work with?
Azure Arc-enabled servers and/or Azure Arc-enabled VMware vSphere work with all
supported versions of Windows Server and major distributions of Linux. As mentioned,
even though Arc-enabled servers work with VMware vSphere virtual machines, the
Connected Machine agent has no notion of familiarity with the underlying infrastructure
fabric and virtualization layer.

Should I use Arc-enabled servers or Arc-

enabled VMware vSphere for my VMware VMs?
Each option has its own unique benefits and can be combined as needed. Arc-enabled
servers allows you to manage the guest OS of your VMs with the Azure Connected
Machine agent. Arc-enabled VMware vSphere enables you to onboard your VMware
environment at-scale to Azure Arc with automatic discovery, in addition to performing
full VM lifecycle and virtual hardware operations. You have the flexibility to start with
either option and incorporate the other one later without any disruption. With both
options, you'll enjoy the same consistent experience.
What's new with Azure Connected
Machine agent
Article • 06/20/2024

The Azure Connected Machine agent receives improvements on an ongoing basis. To

stay up to date with the most recent developments, this article provides you with
information about:

The latest releases

Known issues
Bug fixes

This page is updated monthly, so revisit it regularly. If you're looking for items older
than six months, you can find them in archive for What's new with Azure Connected
Machine agent.

２ Warning

Only Connected Machine agent versions within the last 1 year are officially
supported by the product group. Customers should update to an agent version
within this window.

Version 1.43 - June 2024

Download for Windows or Linux

Fixed
Fix for OpenSSL Vulnerability for Linux (Upgrading OpenSSL version from 3.0.13 to
3.014)
Added Server Name Indicator (SNI) to our service calls, fixing Proxy and Firewall
scenarios
Skipped lockdown policy on the downloads directory under Guest Configuration

Version 1.42 - May 2024 (Second Release)

Download for Windows or Linux
Fixed
Extensions and machine configuration policies can be used with private endpoints
again

Version 1.41 - May 2024

Download for Windows or Linux

Known issues
Customers using private endpoints with Azure Arc may encounter issues with extension
management and machine configuration policies with agent version 1.41. Agent version
1.42 resolves this issue.

New features
Certificate-based authentication is now supported when using a service principal
to connect or disconnect the agent. For more information, see authentication
options for the azcmagent CLI.
azcmagent check now allows you to also check for the endpoints used by the SQL
Server enabled by Azure Arc extension using the new --extensions flag. This can
help you troubleshoot networking issues for both the OS and SQL management
components. You can try this out by running azcmagent check --extensions sql --
location eastus on a server, either before or after it is connected to Azure Arc.

Fixed
Fixed a memory leak in the Hybrid Instance Metadata service
Better handling when IPv6 local loopback is disabled
Improved reliability when upgrading extensions
Improved reliability when enforcing CPU limits on Linux extensions
PowerShell telemetry is now disabled by default for the extension manager and
policy services
The extension manager and policy services now support OpenSSL 3
Colors are now disabled in the onboarding progress bar when the --no-color flag
is used
Improved detection and reporting for Windows machines that have custom logon
as a service rights configured.
Improved accuracy when obtaining system metadata on Windows:
 VMUUID is now obtained from the Win32 API
Physical memory is now checked using WMI
Fixed an issue that could prevent the region selector in the Windows GUI installer
from loading
Fixed permissions issues that could prevent the "himds" service from accessing
necessary directories on Windows

Version 1.40 - April 2024

Download for Windows or Linux

Known issues
The first release of the 1.40 agent may impact SQL Server enabled by Azure Arc when
configured with least privileges on Windows servers. The 1.40 agent was re-released to
address this problem. To check if your server is affected, run azcmagent show and locate
the agent version number. Agent version 1.40.02664.1629 has the known issue and
agent 1.40.02669.1635 fixes it. Download and install the latest version of the agent to
restore functionality for SQL Server enabled by Azure Arc.

New features
Oracle Linux 9 is now a supported operating system
Customers no longer need to download an intermediate CA certificate for delivery
of WS2012/R2 ESUs (Requires April 2024 SSU update)

Fixed
Improved error handling when a machine configuration policy has an invalid SAS
token
The installation script for Windows now includes a flag to suppress reboots in case
any agent executables are in use during an upgrade
Fixed an issue that could block agent installation or upgrades on Windows when
the installer can't change the access control list on the agent's log directories.
Extension package maximum download size increased to fix access to the latest
versions of the Azure Monitor Agent on Azure Arc-enabled servers.

Version 1.39 - March 2024

Download for Windows or Linux

New features
Check which extensions are installed and manually remove them with the new
azcmagent extension command group. These commands run locally on the
machine and work even if a machine has lost its connection to Azure.
You can now customize the CPU limit applied to the extension manager and
machine configuration policy evaluation engine. This might be helpful on small or
under-powered VMs where the default resource governance limits can cause
extension operations to time out.

Fixed
Improved reliability of the run command feature with long-running commands
Removed an unnecessary endpoint from the network connectivity check when
onboarding machines via an Azure Arc resource bridge
Improved heartbeat reliability
Removed unnecessary dependencies

Version 1.38 - February 2024

Download for Windows or Linux

Known issues
Windows machines that try and fail to upgrade to version 1.38 manually or via Microsoft
Update might not roll back to the previously installed version. As a result, the machine
will appear "Disconnected" and won't be manageable from Azure. A new version of 1.38
was released to Microsoft Update and the Microsoft Download Center on March 5, 2024
that resolves this issue.

If your machine was affected by this issue, you can repair the agent by downloading and
installing the agent again. The agent will automatically discover the existing
configuration and restore connectivity with Azure. You don't need to run azcmagent
connect .

New features
AlmaLinux 9 is now a supported operating system
Fixed
The hybrid instance metadata service (HIMDS) now listens on the IPv6 local
loopback address (::1)
Improved logging in the extension manager and policy engine
Improved reliability when fetching the latest operating system metadata
Reduced extension manager CPU usage

Next steps
Before evaluating or enabling Azure Arc-enabled servers across multiple hybrid
machines, review Connected Machine agent overview to understand requirements,
technical details about the agent, and deployment methods.
Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Archive for What's new with Azure
Connected Machine agent
Article • 05/22/2024

Ｕ 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.

The primary What's new in Azure Connected Machine agent? article contains updates
for the last six months, while this article contains all the older information.

The Azure Connected Machine agent receives improvements on an ongoing basis. This
article provides you with information about:

Previous releases
Known issues
Bug fixes

Version 1.37 - December 2023

Download for Windows or Linux

New features
Rocky Linux 9 is now a supported operating system
Added Oracle Cloud Infrastructure display name as a detected property

Fixed
Restored access to servers with Windows Admin Center in Azure
Improved detection logic for Microsoft SQL Server
Agents connected to sovereign clouds should now see the correct cloud and portal
URL in azcmagent show
The installation script for Linux now automatically approves the request to import
the packages.microsoft.com signing key to ensure a silent installation experience
 Agent installation and upgrades apply more restrictive permissions to the agent's
data directories on Windows
Improved reliability when detecting Azure Stack HCI as a cloud provider
Removed the log zipping feature introduced in version 1.37 for extension manager
and machine configuration agent logs. Log files are still rotated automatically.
Removed the scheduled tasks for automatic agent upgrades (introduced in agent
version 1.30). We'll reintroduce this functionality when the automatic upgrade
mechanism is available.
Resolved Azure Connected Machine Agent Elevation of Privilege Vulnerability

Version 1.36 - November 2023

Download for Windows or Linux

Known issues
The Windows Admin Center in Azure feature is incompatible with Azure Connected
Machine agent version 1.36. Upgrade to version 1.37 or later to use this feature.

New features
azcmagent show now reports extended security license status on Windows Server
2012 server machines.
Introduced a new proxy bypass option, ArcData , that covers the SQL Server
enabled by Azure Arc endpoints. This enables you to use a private endpoint with
Azure Arc-enabled servers with the public endpoints for SQL Server enabled by
Azure Arc.
The CPU limit for extension operations on Linux is now 30%. This increase helps
improve reliability of extension install, upgrade, and uninstall operations.
Older extension manager and machine configuration agent logs are automatically
zipped to reduce disk space requirements.
New executable names for the extension manager ( gc_extension_service ) and
machine configuration ( gc_arc_service ) agents on Windows to help you
distinguish the two services. For more information, see Windows agent installation
details.

Bug fixes
azcmagent connect now uses the latest API version when creating the Azure Arc-
enabled server resource to ensure Azure policies targeting new properties can take
 effect.
Upgraded the OpenSSL library and PowerShell runtime shipped with the agent to
include the latest security fixes.
Fixed an issue that could prevent the agent from reporting the correct product
type on Windows machines.
Improved handling of upgrades when the previously installed extension version
wasn't in a successful state.

Version 1.35 - October 2023

Download for Windows or Linux

Known issues
The Windows Admin Center in Azure feature is incompatible with Azure Connected
Machine agent version 1.35. Upgrade to version 1.37 or later to use this feature.

New features
The Linux installation script now downloads supporting assets with either wget or
curl, depending on which tool is available on the system
azcmagent connect and azcmagent disconnect now accept the --user-tenant-id
parameter to enable Lighthouse users to use a credential from their tenant and
onboard a server to a different tenant.
You can configure the extension manager to run, without allowing any extensions
to be installed, by configuring the allowlist to Allow/None . This supports Windows
Server 2012 ESU scenarios where the extension manager is required for billing
purposes but doesn't need to allow any extensions to be installed. Learn more
about local security controls.

Fixed
Improved reliability when installing Microsoft Defender for Endpoint on Linux by
increasing available system resources and extending the timeout
Better error handling when a user specifies an invalid location name to azcmagent
connect
Fixed a bug where clearing the incomingconnections.enabled configuration setting
would show <nil> as the previous value
Security fix for the extension allowlist and blocklist feature to address an issue
where an invalid extension name could impact enforcement of the lists.
Version 1.34 - September 2023
Download for Windows or Linux

New features
Extended Security Updates for Windows Server 2012 and 2012 R2 can be
purchased and enabled through Azure Arc. If your server is already running the
Azure Connected Machine agent, upgrade to agent version 1.34 or later to take
advantage of this new capability.
New system metadata is collected to enhance your device inventory in Azure:
Total physical memory
More processor information
Serial number
SMBIOS asset tag
Network requests to Microsoft Entra ID (formerly Azure Active Directory) now use
login.microsoftonline.com instead of login.windows.net

Fixed
Better handling of disconnected agent scenarios in the extension manager and
policy engine.

Version 1.33 - August 2023

Download for Windows or Linux

Security fix
Agent version 1.33 contains a fix for CVE-2023-38176 , a local elevation of privilege
vulnerability. Microsoft recommends upgrading all agents to version 1.33 or later to
mitigate this vulnerability. Azure Advisor can help you identify servers that need to be
upgraded . Learn more about CVE-2023-38176 in the Security Update Guide .

Known issue
azcmagent check validates a new endpoint in this release: <geography>-
ats.his.arc.azure.com . This endpoint is reserved for future use and not required for the

Azure Connected Machine agent to operate successfully. However, if you're using a

private endpoint, this endpoint will fail the network connectivity check. You can safely
ignore this endpoint in the results and should instead confirm that all other endpoints
are reachable.

This endpoint will be removed from azcmagent check in a future release.

Fixed
Fixed an issue that could cause a VM extension to disappear in Azure Resource
Manager if it's installed with the same settings twice. After upgrading to agent
version 1.33 or later, reinstall any missing extensions to restore the information in
Azure Resource Manager.
You can now set the agent mode before connecting the agent to Azure.
The agent now responds to instance metadata service (IMDS) requests even when
the connection to Azure is temporarily unavailable.

Version 1.32 - July 2023

Download for Windows or Linux

New features
Added support for the Debian 12 operating system
azcmagent show now reflects the "Expired" status when a machine has been
disconnected long enough for the managed identity to expire. Previously, the
agent only showed "Disconnected" while the Azure portal and API showed the
correct state, "Expired."

Fixed
Fixed an issue that could result in high CPU usage if the agent was unable to send
telemetry to Azure.
Improved local logging when there are network communication errors

Version 1.31 - June 2023

Download for Windows or Linux

Known issue
The first release of agent version 1.31 had a known issue affecting customers using
proxy servers. The issue displays as AZCM0026: Network Error and a message about "no
IP addresses found" when connecting a server to Azure Arc using a proxy server. A
newer version of agent 1.31 was released on June 14, 2023 that addresses this issue.

To check if you're running the latest version of the Azure connected machine agent,
navigate to the server in the Azure portal or run azcmagent show from a terminal on the
server itself and look for the "Agent version." The table below shows the version
numbers for the first and patched releases of agent 1.31.

ﾉ Expand table

Package type Version number with proxy issue Version number of patched agent

Windows 1.31.02347.1069 1.31.02356.1083

RPM-based Linux 1.31.02347.957 1.31.02356.970

DEB-based Linux 1.31.02347.939 1.31.02356.952

New features
Added support for Amazon Linux 2023
azcmagent show no longer requires administrator privileges
You can now filter the output of azcmagent show by specifying the properties you
wish to output

Fixed
Added an error message when a pending reboot on the machine affects extension
operations
The scheduled task that checks for agent updates no longer outputs a file
Improved formatting for clock skew calculations
Improved reliability when upgrading extensions by explicitly asking extensions to
stop before trying to upgrade.
Increased the resource limits for the Update Manager extension for Linux,
Microsoft Defender Endpoint for Linux, and Azure Security Agent for Linux to
prevent timeouts during installation
azcmagent disconnect now closes any active SSH or Windows Admin Center
connections
Improved output of the azcmagent check command
Better handling of spaces in the --location parameter of azcmagent connect
Version 1.30 - May 2023
Download for Windows or Linux

New features
Introduced a scheduled task that checks for agent updates on a daily basis.
Currently, the update mechanism is inactive and no changes are made to your
server even if a newer agent version is available. In the future, you'll be able to
schedule updates of the Azure Connected Machine agent from Azure. For more
information, see Automatic agent upgrades.

Fixed
Resolved an issue that could cause the agent to go offline after rotating its
connectivity keys.
azcmagent show no longer shows an incomplete resource ID or Azure portal page

URL when the agent isn't configured.

Version 1.29 - April 2023

Download for Windows or Linux

New features
The agent now compares the time on the local system and Azure service when
checking network connectivity and creating the resource in Azure. If the clocks are
offset by more than 120 seconds (2 minutes), a nonblocking error is shown. You
might encounter TLS connection errors if the time of your computer doesn't match
the time in Azure.
azcmagent show now supports an --os flag to print extra OS information to the

console

Fixed
Fixed an issue that could cause the guest configuration service (gc_service) to
repeatedly crash and restart on Linux systems
Resolved a rare condition under which the guest configuration service (gc_service)
could consume excessive CPU resources
 Removed "sudo" calls in internal install script that could be blocked if SELinux is
enabled
Reduced how long network checks wait before determining a network endpoint is
unreachable
Stopped writing error messages in "himds.log" referring to a missing certificate key
file for the ATS agent, an inactive component reserved for future use.

Version 1.28 - March 2023

Download for Windows or Linux

Fixed
Improved reliability of delete requests for extensions
More frequent reporting of VM UUID (system firmware identifier) changes
Improved reliability when writing changes to agent configuration files
JSON output for azcmagent connect now includes Azure portal URL for the server
Linux installation script now installs the gnupg package if it's missing on Debian
operating systems
Removed weekly restarts for the extension and guest configuration services

Version 1.27 - February 2023

Download for Windows or Linux

Fixed
The extension service now correctly restarts when the Azure Connected Machine
agent is upgraded by Update Manager
Resolved issues with the hybrid connectivity component that could result in the
"himds" service crashing, the server showing as "disconnected" in Azure, and
connectivity issues with Windows Admin Center and SSH
Improved handling of resource move scenarios that could impact Windows Admin
Center and SSH connectivity
Improved reliability when changing the agent configuration mode from "monitor"
mode to "full" mode.
Increased the resource limits for the Microsoft Sentinel DNS extension to improve
log collection reliability
Tenant IDs are better validated when connecting the server
Version 1.26 - January 2023
Download for Linux

７ Note

Version 1.26 is only available for Linux operating systems.

Fixed
Increased the resource limits for the Microsoft Defender for Endpoint extension
(MDE.Linux) on Linux to improve installation reliability

Version 1.25 - January 2023

Download for Windows or Linux

New features
Red Hat Enterprise Linux (RHEL) 9 is now a supported operating system

Fixed
Reliability improvements in the machine (guest) configuration policy engine
Improved error messages in the Windows MSI installer
Additional improvements to the detection logic for machines running on Azure
Stack HCI

Version 1.24 - November 2022

Download for Windows or Linux

New features
azcmagent logs improvements:

Only the most recent log file for each component is collected by default. To
collect all log files, use the new --full flag.
Journal logs for the agent services are now collected on Linux operating systems
Logs from extensions are now collected
 Agent telemetry is no longer sent to dc.services.visualstudio.com . You might be
able to remove this URL from any firewall or proxy server rules if no other
applications in your environment require it.
Failed extension installs can now be retried without removing the old extension as
long as the extension settings are different
Increased the resource limits for the Azure Update Manager extension on Linux to
reduce downtime during update operations

Fixed
Improved logic for detecting machines running on Azure Stack HCI to reduce false
positives
Auto-registration of required resource providers only happens when they are
unregistered
Agent will now detect drift between the proxy settings of the command line tool
and background services
Fixed a bug with proxy bypass feature that caused the agent to incorrectly use the
proxy server for bypassed URLs
Improved error handling when extensions don't download successfully, fail
validation, or have corrupt state files

Version 1.23 - October 2022

Download for Windows or Linux

New features
The minimum PowerShell version required on Windows Server has been reduced
to PowerShell 4.0
The Windows agent installer is now compatible with systems that enforce a
Microsoft publisher-based Windows Defender Application Control policy.
Added support for Rocky Linux 8 and Debian 11.

Fixed
Tag values are correctly preserved when connecting a server and specifying
multiple tags (fixes known issue from version 1.22).
An issue preventing some users who tried authenticating with an identity from a
different tenant than the tenant where the server is (will be) registered has been
fixed.
 The azcamgent check command no longer validates CNAME records to reduce
warnings that did not impact agent functionality.
The agent will now try to obtain an access token for up to 5 minutes when
authenticating with an Azure Active Directory service principal.
Cloud presence checks now only run once at the time the himds service starts on
the server to reduce local network traffic. If you live migrate your virtual machine
to a different cloud provider, it will not reflect the new cloud provider until the
service or computer has rebooted.
Improved logging during the installation process.
The install script for Windows now saves the MSI to the TEMP directory instead of
the current directory.

Version 1.22 - September 2022

Download for Windows or Linux

Known issues
The 'connect' command uses the value of the last tag for all tags. You will need to
fix the tags after onboarding to use the correct values.

New features
The default login flow for Windows computers now loads the local web browser to
authenticate with Azure Active Directory instead of providing a device code. You
can use the --use-device-code flag to return to the old behavior or provide service
principal credentials for a non-interactive authentication experience.
If the resource group provided to azcmagent connect does not exist, the agent tries
to create it and continue connecting the server to Azure.
Added support for Ubuntu 22.04
Added --no-color flag for all azcmagent commands to suppress the use of colors
in terminals that do not support ANSI codes.

Fixed
The agent now supports Red Hat Enterprise Linux 8 servers that have FIPS mode
enabled.
Agent telemetry uses the proxy server when configured.
Improved accuracy of network connectivity checks
 The agent retains extension allow and blocklists when switching the agent from
monitoring mode to full mode. Use azcmagent config clear to reset individual
configuration settings to the default state.

Version 1.21 - August 2022

Download for Windows or Linux

New features
azcmagent connect usability improvements:

The --subscription-id (-s) parameter now accepts friendly names in addition

to subscription IDs
Automatic registration of any missing resource providers for first-time users
(extra user permissions required to register resource providers)
Added a progress bar during onboarding
The onboarding script now supports both the yum and dnf package managers
on RPM-based Linux systems
You can now restrict the URLs used to download machine configuration (formerly
Azure Policy guest configuration) packages by setting the
allowedGuestConfigPkgUrls tag on the server resource and providing a comma-

separated list of URL patterns to allow.

Fixed
Improved reliability when reporting extension installation failures to prevent
extensions from staying in the "creating" state
Support for retrieving metadata for Google Cloud Platform virtual machines when
the agent uses a proxy server
Improved network connection retry logic and error handling
Linux only: resolves local escalation of privilege vulnerability CVE-2022-38007

Version 1.20 - July 2022

Download for Windows or Linux

Known issues
Some systems might incorrectly report their cloud provider as Azure Stack HCI.
New features
Added support for connecting the agent to the Microsoft Azure operated by
21Vianet cloud
Added support for Debian 10
Updates to the instance metadata collected on each machine:
GCP VM OS is no longer collected
CPU logical core count is now collected
Improved error messages and colorization

Fixed
Agents configured to use private endpoints correctly download extensions over
the private endpoint
Renamed the --use-private-link flag on azcmagent check to --enable-pls-check
to more accurately represent its function

Version 1.19 - June 2022

Download for Windows or Linux

Known issues
Agents configured to use private endpoints incorrectly download extensions from
a public endpoint. Upgrade the agent to version 1.20 or later to restore correct
functionality.
Some systems might incorrectly report their cloud provider as Azure Stack HCI.

New features
When installed on a Google Compute Engine virtual machine, the agent detects
and reports Google Cloud metadata in the "detected properties" of the Azure Arc-
enabled servers resource. Learn more about the new metadata.

Fixed
Resolved an issue that could cause the extension manager to hang during
extension installation, update, and removal operations.
Improved support for TLS 1.3
Version 1.18 - May 2022
Download for Windows or Linux

New features
You can configure the agent to operate in monitoring mode, which simplifies
configuration of the agent for scenarios where you only want to use Arc for
monitoring and security scenarios. This mode disables other agent functionality
and prevents use of extensions that could make changes to the system (for
example, the Custom Script Extension).
VMs and hosts running on Azure Stack HCI now report the cloud provider as "HCI"
when Azure benefits are enabled.

Fixed
systemd is now an official prerequisite on Linux

Guest configuration policies no longer create unnecessary files in the /tmp

directory on Linux servers
Improved reliability when extracting extensions and guest configuration policy
packages
Improved reliability for guest configuration policies that have child processes

Version 1.17 - April 2022

Download for Windows or Linux

New features
The default resource name for AWS EC2 instances is now the instance ID instead of
the hostname. To override this behavior, use the --resource-name
PreferredResourceName parameter to specify your own resource name when

connecting a server to Azure Arc.

The network connectivity check during onboarding now verifies private endpoint
configuration if you specify a private link scope. You can run the same check
anytime by running azcmagent check with the new --use-private-link parameter.
You can now disable the extension manager with the local agent security controls.

Fixed
 If you attempt to run azcmagent connect on a server already connected to Azure,
the resource ID is shown on the console to help you locate the resource in Azure.
Extended the azcmagent connect timeout to 10 minutes.
azcmagent show no longer prints the private link scope ID. You can check if the

server is associated with an Azure Arc private link scope by reviewing the machine
details in the Azure portal , CLI, or PowerShell.
azcmagent logs collects only the two most recent logs for each service to reduce

ZIP file size.

azcmagent logs collects Guest Configuration logs again.

Version 1.16 - March 2022

Download for Windows or Linux

Known issues
azcmagent logs doesn't collect Guest Configuration logs in this release. You can

locate the log directories in the agent installation details.

New features
You can now granularly control allowed and blocked extensions on your server and
disable the Guest Configuration agent. See local agent controls to enable or
disable capabilities for more information.

Fixed
The "Arc" proxy bypass keyword no longer includes Azure Active Directory
endpoints on Linux
The "Arc" proxy bypass keyword now includes Azure Storage endpoints for
extension downloads

Version 1.15 - February 2022

Download for Windows or Linux

Known issues
 The "Arc" proxy bypass feature on Linux includes some endpoints that belong to
Azure Active Directory. As a result, if you only specify the "Arc" bypass rule, traffic
destined for Azure Active Directory endpoints will not use the proxy server as
expected.

New features
Network check improvements during onboarding:
Added TLS 1.2 check
Onboarding aborts when required networking endpoints are inaccessible
New --skip-network-check flag to override the new network check behavior
On-demand network check now available using azcmagent check
Proxy bypass is now available for customers using private endpoints. This feature
allows you to send Azure Active Directory and Azure Resource Manager traffic
through a proxy server, but skip the proxy server for traffic that should stay on the
local network to reach private endpoints.
Oracle Linux 8 is now supported

Fixed
Improved reliability when disconnecting the agent from Azure
Improved reliability when installing and uninstalling the agent on Active Directory
Domain Controllers
Extended the device login timeout to 5 minutes
Removed resource constraints for Azure Monitor Agent to support high
throughput scenarios

Version 1.14 - January 2022

Download for Windows or Linux

Fixed
Fixed a state corruption issue in the extension manager that could cause extension
operations to get stuck in transient states. Customers running agent version 1.13
are encouraged to upgrade to version 1.14 as soon as possible. If you continue to
have issues with extensions after upgrading the agent, submit a support ticket .

Version 1.13 - November 2021

Download for Windows or Linux

Known issues
Extensions might get stuck in transient states (creating, deleting, updating) on
Windows machines running the 1.13 agent in certain conditions. Microsoft
recommends upgrading to agent version 1.14 as soon as possible to resolve this
issue.

Fixed
Improved reliability when installing or upgrading the agent.

New features
Local configuration of agent settings now available using the azcmagent config
command.
Support for configuring proxy server settings using agent-specific settings instead
of environment variables.
Extension operations execute faster using a new notification pipeline. You might
need to adjust your firewall or proxy server rules to allow the new network
addresses for this notification service (see networking configuration). The
extension manager falls back to the existing behavior of checking every 5 minutes
when the notification service is inaccessible.
Detection of the AWS account ID, instance ID, and region information for servers
running in Amazon Web Services.

Version 1.12 - October 2021

Download for Windows or Linux

Fixed
Improved reliability when validating signatures of extension packages.
azcmagent_proxy remove command on Linux now correctly removes environment

variables on Red Hat Enterprise Linux and related distributions.

azcmagent logs now includes the computer name and timestamp to help

disambiguate log files.

Version 1.11 - September 2021
Download for Windows or Linux

Fixed
The agent now supports on Windows systems with the System objects: Require
case insensitivity for non-Windows subsystems policy set to Disabled.
The guest configuration policy agent automatically retries if an error occurs during
service start or restart events.
Fixed an issue that prevented guest configuration audit policies from successfully
executing on Linux machines.

Version 1.10 - August 2021

Download for Windows or Linux

Fixed
The guest configuration policy agent can now configure and remediate system
settings. Existing policy assignments continue to be audit-only. Learn more about
the Azure Policy guest configuration remediation options.
The guest configuration policy agent now restarts every 48 hours instead of every
6 hours.

Version 1.9 - July 2021

Download for Windows or Linux

New features
Added support for the Indonesian language

Fixed
Fixed a bug that prevented extension management in the West US 3 region

Version 1.8 - July 2021

Download for Windows or Linux

New features
Improved reliability when installing the Azure Monitor Agent extension on Red Hat
and CentOS systems
Added agent-side enforcement of max resource name length (54 characters)
Guest Configuration policy improvements:
Added support for PowerShell-based Guest Configuration policies on Linux
operating systems
Added support for multiple assignments of the same Guest Configuration policy
on the same server
Upgraded PowerShell Core to version 7.1 on Windows operating systems

Fixed
The agent continues running if it is unable to write service start/stop events to the
Windows Application event log

Version 1.7 - June 2021

Download for Windows or Linux

New features
Improved reliability during onboarding:
Improved retry logic when HIMDS is unavailable
Onboarding continues instead of aborting if OS information isn't available
Improved reliability when installing the Log Analytics agent for Linux extension on
Red Hat and CentOS systems

Version 1.6 - May 2021

Download for Windows or Linux

New features
Added support for SUSE Enterprise Linux 12
Updated Guest Configuration agent to version 1.26.12.0 to include:
Policies execute in a separate process.
 Added V2 signature support for extension validation.
Minor update to data logging.

Version 1.5 - April 2021

Download for Windows or Linux

New features
Added support for Red Hat Enterprise Linux 8 and CentOS Linux 8.
New -useStderr parameter to direct error and verbose output to stderr.
New -json parameter to direct output results in JSON format (when used with -
useStderr).
Collect other instance metadata - Manufacturer, model, and cluster resource ID
(for Azure Stack HCI nodes).

Version 1.4 - March 2021

Download for Windows or Linux

New features
Added support for private endpoints, which is currently in limited preview.
Expanded list of exit codes for azcmagent.
You can pass agent configuration parameters from a file with the --config
parameter.
Automatically detects the presence of Microsoft SQL Server on the server

Fixed
Network endpoint checks are now faster.

Version 1.3 - December 2020

Download for Windows or Linux

New features
Added support for Windows Server 2008 R2 SP1.
Fixed
Resolved issue preventing the Custom Script Extension on Linux from installing
successfully.

Version 1.2 - November 2020

Download for Windows or Linux

Fixed
Resolved issue where proxy configuration resets after upgrade on RPM-based
distributions.

Version 1.1 - October 2020

Fixed
Fixed proxy script to handle alternate GC daemon unit file location.
GuestConfig agent reliability changes.
GuestConfig agent support for US Gov Virginia region.
GuestConfig agent extension report messages to be more verbose if there is a
failure.

Version 1.0 - September 2020

This version is the first generally available release of the Azure Connected Machine
Agent.

Plan for change

Support for preview agents (all versions older than 1.0) will be removed in a future
service update.
Removed support for fallback endpoint .azure-automation.net . If you have a
proxy, you need to allow the endpoint *.his.arc.azure.com .
VM extensions can't be installed or modified from Azure Arc if the agent detects
it's running in an Azure VM. This is to avoid conflicting extension operations being
performed from the virtual machine's Microsoft.Compute and
 Microsoft.HybridCompute resource. Use the Microsoft.Compute resource for the
machine for all extension operations.
Name of guest configuration process has changed, from gcd to gcad on Linux, and
gcservice to gcarcservice on Windows.

New features
Added azcmagent logs option to collect information for support.
Added azcmagent license option to display EULA.
Added azcmagent show --json option to output agent state in easily parseable
format.
Added flag in azcmagent show output to indicate if server is on a virtual machine
hosted in Azure.
Added azcmagent disconnect --force-local-only option to allow reset of local
agent state when Azure service cannot be reached.
Added azcmagent connect --cloud option to support other clouds. In this release,
only Azure is supported by service at time of agent release.
Agent has been localized into Azure-supported languages.

Fixed
Improvements to connectivity check.
Corrected issue with proxy server settings being lost when upgrading agent on
Linux.
Resolved issues when attempting to install agent on server running Windows
Server 2012 R2.
Improvements to extension installation reliability

Next steps
Before evaluating or enabling Arc-enabled servers across multiple hybrid
machines, review Connected Machine agent overview to understand requirements,
technical details about the agent, and deployment methods.

Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.
Quickstart: Connect hybrid machines
with Azure Arc-enabled servers
Article • 11/03/2023

Get started with Azure Arc-enabled servers to manage and govern your Windows and
Linux machines hosted across on-premises, edge, and multicloud environments.

In this quickstart, you'll deploy and configure the Azure Connected Machine agent on a
Windows or Linux machine hosted outside of Azure, so that it can be managed through
Azure Arc-enabled servers.

 Tip

If you prefer to try out things in a sample/practice experience, get started quickly
with Azure Arc Jumpstart .

Prerequisites
An Azure account with an active subscription. Create an account for free .
Deploying the Connected Machine agent on a machine requires that you have
administrator permissions to install and configure the agent. On Linux this is done
by using the root account, and on Windows, with an account that is a member of
the Local Administrators group.
The Microsoft.HybridCompute, Microsoft.GuestConfiguration,
Microsoft.HybridConnectivity, and Microsoft.AzureArcData resource providers
must be registered on your subscription. Please register these resource providers
ahead of time.
Before you get started, be sure to review the agent prerequisites and verify the
following:
Your target machine is running a supported operating system.
Your account has the required Azure built-in roles.
Ensure the machine is in a supported region.
Confirm that the Linux hostname or Windows computer name doesn't use a
reserved word or trademark.
If the machine connects through a firewall or proxy server to communicate over
the Internet, make sure the URLs listed are not blocked.

Generate installation script

Use the Azure portal to create a script that automates the agent download and
installation and establishes the connection with Azure Arc.

1. Go to the Azure portal page for adding servers with Azure Arc . Select the Add a
single server tile, then select Generate script.

７ Note

In the portal, you can also reach this page by searching for and selecting
"Servers - Azure Arc" and then selecting +Add.

2. On the Basics page, provide the following:

a. Select the subscription and resource group where you want the machine to be
managed within Azure.
b. For Region, choose the Azure region in which the server's metadata will be
stored.
c. For Operating system, select the operating system of the server you want to
connect.
d. For Connectivity method, choose how the Azure Connected Machine agent
should connect to the internet. If you select Proxy server, enter the proxy server
IP address or the name and port number that the machine will use in the format
http://<proxyURL>:<proxyport> .
e. Select Next.

3. On the Tags page, review the default Physical location tags suggested and enter a
value, or specify one or more Custom tags to support your standards. Then select
Next.

4. In the Download or copy the following script section, review the script. If you
want to make any changes, use the Previous button to go back and update your
selections. Otherwise, select Download to save the script file.
Install the agent using the script
Now that you've generated the script, the next step is to run it on the server that you
want to onboard to Azure Arc. The script will download the Connected Machine agent
from the Microsoft Download Center, install the agent on the server, create the Azure
Arc-enabled server resource, and associate it with the agent.

Follow the steps below for the operating system of your server.

Windows agent
1. Log in to the server.

2. Open an elevated 64-bit PowerShell command prompt.

3. Change to the folder or share that you copied the script to, then execute it on the
server by running the ./OnboardingScript.ps1 script.

Linux agent
1. To install the Linux agent on the target machine that can directly communicate to
Azure, run the following command:

Bash

bash ~/Install_linux_azcmagent.sh

2. Alternately, if the target machine communicates through a proxy server, run the
following command:

Bash

bash ~/Install_linux_azcmagent.sh --proxy "{proxy-url}:{proxy-port}"

Verify the connection with Azure Arc

After you install the agent and configure it to connect to Azure Arc-enabled servers, go
to the Azure portal to verify that the server has successfully connected. View your
machine in the Azure portal .
  Tip

You can repeat these steps as needed to onboard additional machines. We also
provide a variety of other options for deploying the agent, including several
methods designed to onboard machines at scale. For more information, see Azure
Connected Machine agent deployment options.

Next steps
Now that you've enabled your Linux or Windows hybrid machine and successfully
connected to the service, you are ready to enable Azure Policy to understand
compliance in Azure.

To learn how to identify Azure Arc-enabled servers enabled machine that doesn't have
the Log Analytics agent installed, continue to the tutorial:

Create a policy assignment to identify non-compliant resources

Tutorial: Create a policy assignment to
identify non-compliant resources
Article • 04/28/2022

The first step in understanding compliance in Azure is to identify the status of your
resources. Azure Policy supports auditing the state of your Azure Arc-enabled server
with guest configuration policies. Azure Policy's guest configuration definitions can audit
or apply settings inside the machine.

This tutorial steps you through the process of creating and assigning a policy in order to
identify which of your Azure Arc-enabled servers don't have the Log Analytics agent for
Windows or Linux installed. These machines are considered non-compliant with the
policy assignment.

In this tutorial, you will learn how to:

＂ Create policy assignment and assign a definition to it

＂ Identify resources that aren't compliant with the new policy
＂ Remove the policy from non-compliant resources

Prerequisites
If you don't have an Azure subscription, create a free account before you begin.

Create a policy assignment

Follow the steps below to create a policy assignment and assign the policy definition
[Preview]: Log Analytics extension should be installed on your Linux Azure Arc machines:

1. Launch the Azure Policy service in the Azure portal by selecting All services, then
searching for and selecting Policy.
2. Select Assignments on the left side of the Azure Policy page. An assignment is a
policy that has been assigned to take place within a specific scope.

3. Select Assign Policy from the top of the Policy - Assignments page.

4. On the Assign Policy page, select the Scope by clicking the ellipsis and selecting
either a management group or subscription. Optionally, select a resource group. A
scope determines what resources or grouping of resources the policy assignment
gets enforced on. Then click Select at the bottom of the Scope page.

This example uses the Parnell Aerospace subscription. Your subscription will differ.

5. Resources can be excluded based on the Scope. Exclusions start at one level lower
than the level of the Scope. Exclusions are optional, so leave it blank for now.

6. Select the Policy definition ellipsis to open the list of available definitions. Azure
Policy comes with built-in policy definitions you can use. Many are available, such
as:
 Enforce tag and its value
Apply tag and its value
Inherit a tag from the resource group if missing

For a partial list of available built-in policies, see Azure Policy samples.

7. Search through the policy definitions list to find the [Preview]: Log Analytics
extension should be installed on your Windows Azure Arc machines definition (if you
have enabled the Azure Connected Machine agent on a Windows-based machine).
For a Linux-based machine, find the corresponding [Preview]: Log Analytics
extension should be installed on your Linux Azure Arc machines policy definition.
Click on that policy and click Select.

8. The Assignment name is automatically populated with the policy name you
selected, but you can change it. For this example, leave the policy name as is, and
don't change any of the remaining options on the page.

9. For this example, we don't need to change any settings on the other tabs. Select
Review + Create to review your new policy assignment, then select Create.

You're now ready to identify non-compliant resources to understand the compliance

state of your environment.

Identify non-compliant resources

Select Compliance in the left side of the page. Then locate the [Preview]: Log Analytics
extension should be installed on your Windows Azure Arc machines or [Preview]: Log
Analytics extension should be installed on your Linux Azure Arc machines policy
assignment you created.
If there are any existing resources that aren't compliant with this new assignment, they
appear under Non-compliant resources.

When a condition is evaluated against your existing resources and found true, then
those resources are marked as non-compligitant with the policy. The following table
shows how different policy effects work with the condition evaluation for the resulting
compliance state. Although you don't see the evaluation logic in the Azure portal, the
compliance state results are shown. The compliance state result is either compliant or
non-compliant.

Resource Effect Policy Compliance

state evaluation state

Exists Deny, Audit, Append*, DeployIfNotExist*, True Non-

AuditIfNotExist* compliant

Exists Deny, Audit, Append*, DeployIfNotExist*, False Compliant

AuditIfNotExist*

New Audit, AuditIfNotExist* True Non-

compliant

New Audit, AuditIfNotExist* False Compliant

* The Append, DeployIfNotExist, and AuditIfNotExist effects require the IF statement to

be TRUE. The effects also require the existence condition to be FALSE to be non-
compliant. When TRUE, the IF condition triggers evaluation of the existence condition
for the related resources.

Clean up resources
To remove the assignment created, follow these steps:

1. Select Compliance (or Assignments) in the left side of the Azure Policy page and
locate the [Preview]: Log Analytics extension should be installed on your
Windows Azure Arc machines or [Preview]: Log Analytics extension should be
installed on your Linux Azure Arc machines policy assignment you created.

2. Right-click the policy assignment and select Delete assignment.

Next steps
In this tutorial, you assigned a policy definition to a scope and evaluated its compliance
report. The policy definition validates that all the resources in the scope are compliant
and identifies which ones aren't. Now you are ready to monitor your Azure Arc-enabled
servers machine by enabling VM insights.

To learn how to monitor and view the performance, running process and their
dependencies from your machine, continue to the tutorial:

Enable VM insights
Tutorial: Monitor a hybrid machine with
VM insights
Article • 08/04/2022

Azure Monitor can collect data directly from your hybrid machines into a Log Analytics
workspace for detailed analysis and correlation. Typically, this would require installing
the Log Analytics agent on the machine using a script, manually, or an automated
method following your configuration management standards. Now, Azure Arc-enabled
servers can install the Log Analytics and Dependency agent VM extension for Windows
and Linux, enabling VM insights to collect data from your non-Azure VMs.

In this tutorial, you will learn how to:

＂ Enable and configure VM insights for your Linux or Windows non-azure VMs
＂ Collect and view data from these VMs

Prerequisites
If you don't have an Azure subscription, create a free account before you begin.

VM extension functionality is available only in the list of supported regions.

See Supported operating systems to ensure that the servers operating system
you're enabling is supported by VM insights.

Review firewall requirements for the Log Analytics agent provided in the Log
Analytics agent overview. The VM insights Map Dependency agent doesn't
transmit any data itself, and it doesn't require any changes to firewalls or ports.

Enable VM insights
1. Launch the Azure Arc service in the Azure portal by clicking All services, then
searching for and selecting Servers - Azure Arc.
2. On the Azure Arc - Servers page, select the connected machine you created in the
quickstart article.

3. From the left-pane under the Monitoring section, select Insights and then Enable.

4. On the Azure Monitor Insights Onboarding page, you're prompted to create a

workspace. For this tutorial, don't select an existing Log Analytics workspace if you
already have one. Instead, select the default, which is a workspace with a unique
name in the same region as your registered connected machine. This workspace is
created and configured for you.

Status messages display while the configuration is performed and extensions are
installed on your connected machine. This process takes a few minutes.
 When the process is complete, a message displays that the machine has been
onboarded and that insight has been successfully deployed.

View data collected

1. After deployment and configuration is complete, select Insights, and then select
the Performance tab. The Performance tab shows a select group of performance
counters collected from the guest operating system of your machine. Scroll down
to view more counters, and move the mouse over a graph to view average and
percentiles taken starting from the time when the Log Analytics VM extension was
installed on the machine.

2. Select Map. The maps feature shows the processes running on the machine and
their dependencies. Select Properties to open the property pane (if it isn't already
open).
 3. Expand the processes for your machine. Select one of the processes to view its
details and to highlight its dependencies.

4. Select your machine again and then select Log Events. You see a list of tables that
are stored in the Log Analytics workspace for the machine. This list will be different
depending whether you're using a Windows or Linux machine.

5. Select the Event table. The Event table includes all events from the Windows event
log. Log Analytics opens with a simple query to retrieve collected event log entries.

Next steps
To learn more about Azure Monitor, see the following article:

Azure Monitor overview

Azure Resource Graph sample queries
for Azure Arc-enabled servers
Article • 06/11/2024

This page is a collection of Azure Resource Graph sample queries for Azure Arc-enabled
servers.

Sample queries

Get count and percentage of Arc-enabled servers by

domain
This query summarizes the domainName property on Azure Arc-enabled servers and uses
a calculation with bin to create a Pct column for the percent of Arc-enabled servers per
domain.

Kusto

Resources
| where type == 'microsoft.hybridcompute/machines'
| project domain=tostring(properties.domainName)
| summarize Domains=make_list(domain), TotalMachineCount=sum(1)
| mvexpand EachDomain = Domains
| summarize PerDomainMachineCount = count() by tostring(EachDomain),
TotalMachineCount
| extend Pct = 100 * bin(todouble(PerDomainMachineCount) /
todouble(TotalMachineCount), 0.001)

Azure CLI

Azure CLI

az graph query -q "Resources | where type ==

'microsoft.hybridcompute/machines' | project
domain=tostring(properties.domainName) | summarize
Domains=make_list(domain), TotalMachineCount=sum(1) | mvexpand
EachDomain = Domains | summarize PerDomainMachineCount = count() by
tostring(EachDomain), TotalMachineCount | extend Pct = 100 *
bin(todouble(PerDomainMachineCount) / todouble(TotalMachineCount),
0.001)"
List all extensions installed on an Azure Arc-enabled
server
First, this query uses project on the hybrid machine resource type to get the ID in
uppercase ( toupper() ), get the computer name, and the operating system running on
the machine. Getting the resource ID in uppercase is a good way to prepare to join to
another property. Then, the query uses join with kind as leftouter to get extensions
by matching an uppercase substring of the extension ID. The portion of the ID before
/extensions/<ExtensionName> is the same format as the hybrid machine ID, so we use

this property for the join . summarize is then used with make_list on the name of the
virtual machine extension to combine the name of each extension where ID, OSName,
and ComputerName are the same into a single array property. Lastly, we order by
lowercase OSName with asc . By default, order by is descending.

Kusto

Resources
| where type == 'microsoft.hybridcompute/machines'
| project
id,
JoinID = toupper(id),
ComputerName = tostring(properties.osProfile.computerName),
OSName = tostring(properties.osName)
| join kind=leftouter(
Resources
| where type == 'microsoft.hybridcompute/machines/extensions'
| project
MachineId = toupper(substring(id, 0, indexof(id, '/extensions'))),
ExtensionName = name
) on $left.JoinID == $right.MachineId
| summarize Extensions = make_list(ExtensionName) by id, ComputerName,
OSName
| order by tolower(OSName) asc

Azure CLI

Azure CLI

az graph query -q "Resources | where type ==

'microsoft.hybridcompute/machines' | project id, JoinID = toupper(id),
ComputerName = tostring(properties.osProfile.computerName), OSName =
tostring(properties.osName) | join kind=leftouter( Resources | where
type == 'microsoft.hybridcompute/machines/extensions' | project
MachineId = toupper(substring(id, 0, indexof(id, '/extensions'))),
ExtensionName = name ) on \$left.JoinID == \$right.MachineId | summarize
 Extensions = make_list(ExtensionName) by id, ComputerName, OSName |
order by tolower(OSName) asc"

List Arc-enabled servers not running latest released agent

version
This query returns all Arc-enabled servers running an outdated version of the Connected
Machine agent. Agents with a status of Expired are excluded from the results. The query
uses leftouter join to bring together the Advisor recommendations raised about any
Connected Machine agents identified as out of date, and Hybrid Computer machines to
filter out any agent that haven't communicated with Azure over a period of time.

Kusto

AdvisorResources
| 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

Azure CLI

Azure CLI

az graph query -q "AdvisorResources | 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"

Next steps
Learn more about the query language.
Learn more about how to explore resources.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Overview of Azure Connected Machine
agent
Article • 06/03/2024

The Azure Connected Machine agent enables you to manage your Windows and Linux
machines hosted outside of Azure on your corporate network or other cloud providers.

２ Warning

Only Connected Machine agent versions within the last 1 year are officially
supported by the product group. Customers should update to an agent version
within this window.

Agent components

The Azure Connected Machine agent package contains several logical components
bundled together:

The Hybrid Instance Metadata service (HIMDS) manages the connection to Azure
and the connected machine's Azure identity.

The guest configuration agent provides functionality such as assessing whether the
machine complies with required policies and enforcing compliance.
 Note the following behavior with Azure Policy guest configuration for a
disconnected machine:
An Azure Policy assignment that targets disconnected machines is unaffected.
Guest assignment is stored locally for 14 days. Within the 14-day period, if the
Connected Machine agent reconnects to the service, policy assignments are
reapplied.
Assignments are deleted after 14 days, and aren't reassigned to the machine
after the 14-day period.

The Extension agent manages VM extensions, including install, uninstall, and

upgrade. Azure downloads extensions and copies them to the
%SystemDrive%\%ProgramFiles%\AzureConnectedMachineAgent\ExtensionService\downl
oads folder on Windows, and to /opt/GC_Ext/downloads on Linux. On Windows, the

extension installs to the following path %SystemDrive%\Packages\Plugins\

<extension> , and on Linux the extension installs to /var/lib/waagent/<extension> .

７ Note

The Azure Monitor agent (AMA) is a separate agent that collects monitoring data,
and it does not replace the Connected Machine agent; the AMA only replaces the
Log Analytics agent, Diagnostics extension, and Telegraf agent for both Windows
and Linux machines.

Agent resources
The following information describes the directories and user accounts used by the Azure
Connected Machine agent.

Windows agent installation details

The Windows agent is distributed as a Windows Installer package (MSI). Download the
Windows agent from the Microsoft Download Center . Installing the Connected
Machine agent for Window applies the following system-wide configuration changes:

The installation process creates the following folders during setup.

ﾉ Expand table
 Directory Description

%ProgramFiles%\AzureConnectedMachineAgent azcmagent CLI and

instance metadata
service
executables.

%ProgramFiles%\AzureConnectedMachineAgent\ExtensionService\GC Extension service

executables.

%ProgramFiles%\AzureConnectedMachineAgent\GCArcService\GC Guest
configuration
(policy) service
executables.

%ProgramData%\AzureConnectedMachineAgent Configuration, log

and identity token
files for azcmagent
CLI and instance
metadata service.

%ProgramData%\GuestConfig Extension package

downloads, guest
configuration
(policy) definition
downloads, and
logs for the
extension and
guest
configuration
services.

%SYSTEMDRIVE%\packages Extension package

executables

Installing the agent creates the following Windows services on the target machine.

ﾉ Expand table

Service name Display name Process name Description

himds Azure Hybrid himds.exe Synchronizes metadata

Instance with Azure and hosts a
Metadata local REST API for
Service extensions and
applications to access
the metadata and
request Microsoft Entra
 Service name Display name Process name Description

managed identity
tokens

GCArcService Guest gc_arc_service.exe Audits and enforces

configuration (gc_service.exe prior to Azure guest
Arc Service version 1.36) configuration policies
on the machine.

ExtensionService Guest gc_extension_service.exe Installs, updates, and

configuration (gc_service.exe prior to manages extensions on
Extension version 1.36) the machine.
Service

Agent installation creates the following virtual service account.

ﾉ Expand table

Virtual Account Description

NT Unprivileged account used to run the Hybrid Instance Metadata

SERVICE\himds Service.

 Tip

This account requires the "Log on as a service" right. This right is

automatically granted during agent installation, but if your organization
configures user rights assignments with Group Policy, you might need to
adjust your Group Policy Object to grant the right to "NT SERVICE\himds" or
"NT SERVICE\ALL SERVICES" to allow the agent to function.

Agent installation creates the following local security group.

ﾉ Expand table

Security group name Description

Hybrid agent extension Members of this security group can request Microsoft Entra
applications tokens for the system-assigned managed identity

Agent installation creates the following environmental variables

ﾉ Expand table
 Name Default value Description

IDENTITY_ENDPOINT http://localhost:40342/metadata/identity/oauth2/token

IMDS_ENDPOINT http://localhost:40342

There are several log files available for troubleshooting, described in the following
table.

ﾉ Expand table

Log Description

%ProgramData%\AzureConnectedMachineAgent\Log\himds.log Records details of

the heartbeat and
identity agent
component.

%ProgramData%\AzureConnectedMachineAgent\Log\azcmagent.log Contains the output

of the azcmagent
tool commands.

%ProgramData%\GuestConfig\arc_policy_logs\gc_agent.log Records details

about the guest
configuration
(policy) agent
component.

%ProgramData%\GuestConfig\ext_mgr_logs\gc_ext.log Records details

about extension
manager activity
(extension install,
uninstall, and
upgrade events).

%ProgramData%\GuestConfig\extension_logs Directory containing

logs for individual
extensions.

The process creates the local security group Hybrid agent extension applications.

After uninstalling the agent, the following artifacts remain.

%ProgramData%\AzureConnectedMachineAgent\Log
%ProgramData%\AzureConnectedMachineAgent
%ProgramData%\GuestConfig
%SystemDrive%\packages
Linux agent installation details
The preferred package format for the distribution ( .rpm or .deb ) that's hosted in the
Microsoft package repository provides the Connected Machine agent for Linux. The
shell script bundle Install_linux_azcmagent.sh installs and configures the agent.

Installing, upgrading, and removing the Connected Machine agent isn't required after
server restart.

Installing the Connected Machine agent for Linux applies the following system-wide
configuration changes.

Setup creates the following installation folders.

ﾉ Expand table

Directory Description

/opt/azcmagent/ azcmagent CLI and instance metadata service executables.

/opt/GC_Ext/ Extension service executables.

/opt/GC_Service/ Guest configuration (policy) service executables.

/var/opt/azcmagent/ Configuration, log and identity token files for azcmagent CLI and
instance metadata service.

/var/lib/GuestConfig/ Extension package downloads, guest configuration (policy)

definition downloads, and logs for the extension and guest
configuration services.

Installing the agent creates the following daemons.

ﾉ Expand table

Service name Display name Process name Description

himdsd.service Azure himds This service implements the Hybrid

Connected Instance Metadata service (IMDS) to
Machine Agent manage the connection to Azure and
Service the connected machine's Azure
identity.

gcad.service GC Arc Service gc_linux_service Audits and enforces Azure guest

configuration policies on the
machine.
 Service name Display name Process name Description

extd.service Extension gc_linux_service Installs, updates, and manages

Service extensions on the machine.

There are several log files available for troubleshooting, described in the following
table.

ﾉ Expand table

Log Description

/var/opt/azcmagent/log/himds.log Records details of the heartbeat and identity

agent component.

/var/opt/azcmagent/log/azcmagent.log Contains the output of the azcmagent tool

commands.

/var/lib/GuestConfig/arc_policy_logs Records details about the guest configuration

(policy) agent component.

/var/lib/GuestConfig/ext_mgr_logs Records details about extension manager activity

(extension install, uninstall, and upgrade events).

/var/lib/GuestConfig/extension_logs Directory containing logs for individual

extensions.

Agent installation creates the following environment variables, set in

/lib/systemd/system.conf.d/azcmagent.conf .

ﾉ Expand table

Name Default value Description

IDENTITY_ENDPOINT http://localhost:40342/metadata/identity/oauth2/token

IMDS_ENDPOINT http://localhost:40342

After uninstalling the agent, the following artifacts remain.

/var/opt/azcmagent
/var/lib/GuestConfig

Agent resource governance

The Azure Connected Machine agent is designed to manage agent and system resource
consumption. The agent approaches resource governance under the following
conditions:

The Machine Configuration (formerly Guest Configuration) service can use up to

5% of the CPU to evaluate policies.

The Extension service can use up to 5% of the CPU on Windows machines and 30%
of the CPU on Linux machines to install, upgrade, run, and delete extensions. Some
extensions might apply more restrictive CPU limits once installed. The following
exceptions apply:

ﾉ Expand table

Extension type Operating system CPU limit

AzureMonitorLinuxAgent Linux 60%

AzureMonitorWindowsAgent Windows 100%

LinuxOsUpdateExtension Linux 60%

MDE.Linux Linux 60%

MicrosoftDnsAgent Windows 100%

MicrosoftMonitoringAgent Windows 60%

OmsAgentForLinux Linux 60%

During normal operations, defined as the Azure Connected Machine agent being
connected to Azure and not actively modifying an extension or evaluating a policy, you
can expect the agent to consume the following system resources:

ﾉ Expand table

Windows Linux

CPU usage (normalized to 1 core) 0.07% 0.02%

Memory usage 57 MB 42 MB

The performance data above was gathered in April 2023 on virtual machines running
Windows Server 2022 and Ubuntu 20.04. Actual agent performance and resource
consumption will vary based on the hardware and software configuration of your
servers.

Custom resource limits

The default resource governance limits are the best choice for most servers. However,
small virtual machines and servers with limited CPU resources might encounter timeouts
when managing extensions or evaluating policies because there aren't enough CPU
resources to complete the tasks. Starting with agent version 1.39, you can customize the
CPU limits applied to the extension manager and Machine Configuration services to
help the agent complete these tasks faster.

To see the current resource limits for the extension manager and Machine Configuration
services, run the following command.

Bash

azcmagent config list

In the output, you'll see two fields, guestconfiguration.agent.cpulimit and

extensions.agent.cpulimit with the current resource limit specified as a percentage. On

a fresh install of the agent, both will show 5 because the default limit is 5% of the CPU.

To change the resource limit for the extension manager to 80%, run the following
command:

Bash

azcmagent config set extensions.agent.cpulimit 80

Instance metadata
Metadata information about a connected machine is collected after the Connected
Machine agent registers with Azure Arc-enabled servers. Specifically:

Operating system name, edition, type, and version

Computer name
Computer manufacturer and model
Computer fully qualified domain name (FQDN)
Domain name (if joined to an Active Directory domain)
Active Directory and DNS fully qualified domain name (FQDN)
UUID (BIOS ID)
Connected Machine agent heartbeat
Connected Machine agent version
Public key for managed identity
Policy compliance status and details (if using guest configuration policies)
 SQL Server installed (Boolean value)
Cluster resource ID (for Azure Stack HCI nodes)
Hardware manufacturer
Hardware model
CPU family, socket, physical core and logical core counts
Total physical memory
Serial number
SMBIOS asset tag
Network interface information
IP address
Subnet
Windows licensing information
OS license status
OS license channel
Extended Security Updates eligibility
Extended Security Updates license status
Extended Security Updates license channel
Cloud provider
Amazon Web Services (AWS) metadata, when running in AWS:
Account ID
Instance ID
Region
Google Cloud Platform (GCP) metadata, when running in GCP:
Instance ID
Image
Machine type
Project ID
Project number
Service accounts
Zone
Oracle Cloud Infrastructure metadata, when running in OCI:
Display name

The agent requests the following metadata information from Azure:

Resource location (region)

Virtual machine ID
Tags
Microsoft Entra managed identity certificate
Guest configuration policy assignments
Extension requests - install, update, and delete.
 ７ Note

Azure Arc-enabled servers doesn't store/process customer data outside the region
the customer deploys the service instance in.

Deployment options and requirements

Agent deployment and machine connection require certain prerequisites. There are also
networking requirements to be aware of.

We provide several options for deploying the agent. For more information, see Plan for
deployment and Deployment options.

Disaster Recovery
There are no customer-enabled disaster recovery options for Arc-enabled servers. In the
event of an outage in an Azure region, the system will failover to another region in the
same Azure geography (if one exists). While this failover procedure is automatic, it
does take some time. The Connected Machine agent will be disconnected during this
period and will show a status of Disconnected until the failover is complete. The system
will failback to its original region once the outage has been restored.

An outage of Azure Arc won't affect the customer workload itself; only management of
the applicable servers via Arc will be impaired.

Next steps
To begin evaluating Azure Arc-enabled servers, see Quickstart: Connect hybrid
machines with 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.
Review troubleshooting information in the agent connection issues
troubleshooting guide.
Deployment options for Azure Monitor
agent on Azure Arc-enabled servers
Article • 05/08/2024

Azure Monitor supports multiple methods to install the Azure Monitor agent and
connect your machine or server registered with Azure Arc-enabled servers to the service.
Azure Arc-enabled servers support the Azure VM extension framework, which provides
post-deployment configuration and automation tasks, enabling you to simplify
management of your hybrid machines like you can with Azure VMs.

The Azure Monitor agent is required if you want to:

Monitor the operating system and any workloads running on the machine or
server using VM insights
Analyze and alert using Azure Monitor
Perform security monitoring in Azure by using Microsoft Defender for Cloud or
Microsoft Sentinel
Collect inventory and track changes by using Azure Automation Change Tracking
and Inventory

７ Note

Azure Monitor agent logs are stored locally and are updated after temporary
disconnection of an Arc-enabled machine.

This article reviews the deployment methods for the Azure Monitor agent VM extension,
across multiple production physical servers or virtual machines in your environment, to
help you determine which works best for your organization. If you are interested in the
new Azure Monitor agent and want to see a detailed comparison, see Azure Monitor
agents overview.

Installation options
Review the different methods to install the VM extension using one method or a
combination and determine which one works best for your scenario.

Use Azure Arc-enabled servers

This method supports managing the installation, management, and removal of VM
extensions (including the Azure Monitor agent) from the Azure portal, using PowerShell,
the Azure CLI, or with an Azure Resource Manager (ARM) template.

Advantages
Can be useful for testing purposes
Useful if you have a few machines to manage

Disadvantages

Limited automation when using an Azure Resource Manager template

Can only focus on a single Arc-enabled server, and not multiple instances
Only supports specifying a single workspace to report to; requires using
PowerShell or the Azure CLI to configure the Log Analytics Windows agent VM
extension to report to up to four workspaces
Doesn't support deploying the Dependency agent from the portal; you can only
use PowerShell, the Azure CLI, or ARM template

Use Azure Policy

You can use Azure Policy to deploy the Azure Monitor agent VM extension at-scale to
machines in your environment, and maintain configuration compliance. This is
accomplished by using either the Configure Linux Arc-enabled machines to run Azure
Monitor Agent or the Configure Windows Arc-enabled machines to run Azure
Monitor Agent policy definition.

Azure Policy includes several prebuilt definitions related to Azure Monitor. For a
complete list of the built-in policies in the Monitoring category, see Azure Policy built-in
definitions for Azure Monitor.

Advantages
Reinstalls the VM extension if removed (after policy evaluation)
Identifies and installs the VM extension when a new Azure Arc-enabled server is
registered with Azure

Disadvantages
The Configure operating system Arc-enabled machines to run Azure Monitor
Agent policy only installs the Azure Monitor agent extension and configures the
 agent to report to a specified Log Analytics workspace.
Standard compliance evaluation cycle is once every 24 hours. An evaluation scan
for a subscription or a resource group can be started with Azure CLI, Azure
PowerShell, a call to the REST API, or by using the Azure Policy Compliance Scan
GitHub Action. For more information, see Evaluation triggers.

Use Azure Automation

The process automation operating environment in Azure Automation and its support for
PowerShell and Python runbooks can help you automate the deployment of the Azure
Monitor agent VM extension at scale to machines in your environment.

Advantages
Can use a scripted method to automate its deployment and configuration using
scripting languages you're familiar with
Runs on a schedule that you define and control
Authenticate securely to Arc-enabled servers from the Automation account using a
managed identity

Disadvantages

Requires an Azure Automation account

Experience authoring and managing runbooks in Azure Automation
Must create a runbook based on PowerShell or Python, depending on the target
operating system

Use Azure portal

The Azure Monitor agent VM extension can be installed using the Azure portal. See
Automatic extension upgrade for Azure Arc-enabled servers for more information about
installing extensions from the Azure portal.

Advantages
Point and click directly from Azure portal
Useful for testing with small set of servers
Immediate deployment of extension

Disadvantages
 Not scalable to many servers
Limited automation

Next steps
To start collecting security-related events with Microsoft Sentinel, see onboard to
Microsoft Sentinel, or to collect with Microsoft Defender for Cloud, see onboard to
Microsoft Defender for Cloud.

Read the VM insights Monitor performance and Map dependencies articles to see
how well your machine is performing and view discovered application
components.
Plan and deploy Azure Arc-enabled
servers
Article • 02/26/2024

Deployment of an IT infrastructure service or business application is a challenge for any

company. In order to execute it well and avoid any unwelcome surprises and unplanned
costs, you need to thoroughly plan for it to ensure that you're as ready as possible. To
plan for deploying Azure Arc-enabled servers at any scale, it should cover the design
and deployment criteria that needs to be met in order to successfully complete the
tasks.

For the deployment to proceed smoothly, your plan should establish a clear
understanding of:

Roles and responsibilities.

Inventory of physical servers or virtual machines to verify they meet network and
system requirements.
The skill set and training required to enable successful deployment and on-going
management.
Acceptance criteria and how you track its success.
Tools or methods to be used to automate the deployments.
Identified risks and mitigation plans to avoid delays, disruptions, etc.
How to avoid disruption during deployment.
What's the escalation path when a significant issue occurs?

The purpose of this article is to ensure you are prepared for a successful deployment of
Azure Arc-enabled servers across multiple production physical servers or virtual
machines in your environment.

To learn more about our at-scale deployment recommendations, you can also refer to
this video.
https://www.youtube-nocookie.com/embed/Cf1jUPOB_vs

Prerequisites
Consider the following basic requirements when planning your deployment:

Your machines must run a supported operating system for the Connected Machine
agent.
 Your machines must have connectivity from your on-premises network or other
cloud environment to resources in Azure, either directly or through a proxy server.
To install and configure the Azure Connected Machine agent, you must have an
account with elevated privileges (that is, an administrator or as root)on the
machines.
To onboard machines, you must have the Azure Connected Machine Onboarding
Azure built-in role.
To read, modify, and delete a machine, you must have the Azure Connected
Machine Resource Administrator Azure built-in role.

For more details, see the prerequisites and network requirements for installing the
Connected Machine agent.

Pilot
Before deploying to all production machines, start by evaluating the deployment
process before adopting it broadly in your environment. For a pilot, identify a
representative sampling of machines that aren't critical to your companies ability to
conduct business. You'll want to be sure to allow enough time to run the pilot and
assess its impact: we recommend a minimum of 30 days.

Establish a formal plan describing the scope and details of the pilot. The following is a
sample of what a plan should include to help get you started.

Objectives - Describes the business and technical drivers that led to the decision
that a pilot is necessary.
Selection criteria - Specifies the criteria used to select which aspects of the solution
will be demonstrated via a pilot.
Scope - Describes the scope of the pilot, which includes but not limited to solution
components, anticipated schedule, duration of the pilot, and number of machines
to target.
Success criteria and metrics - Define the pilot's success criteria and specific
measures used to determine level of success.
Training plan - Describes the plan for training system engineers, administrators,
etc. who are new to Azure and it services during the pilot.
Transition plan - Describes the strategy and criteria used to guide transition from
pilot to production.
Rollback - Describes the procedures for rolling back a pilot to pre-deployment
state.
Risks - List all identified risks for conducting the pilot and associated with
production deployment.
Phase 1: Build a foundation
In this phase, system engineers or administrators enable the core features in their
organization's Azure subscription to start the foundation before enabling machines for
management by Azure Arc-enabled servers and other Azure services.

ﾉ Expand table

Task Detail Estimated

duration

Create a resource A dedicated resource group to include only Azure Arc- One hour
group enabled servers and centralize management and
monitoring of these resources.

Apply Tags to help Evaluate and develop an IT-aligned tagging strategy that One day
organize machines. can help reduce the complexity of managing your Azure
Arc-enabled servers and simplify making management
decisions.

Design and deploy Evaluate design and deployment considerations to One day
Azure Monitor Logs determine if your organization should use an existing or
implement another Log Analytics workspace to store
collected log data from hybrid servers and machines.1

Develop an Azure Determine how you will implement governance of hybrid One day
Policy governance servers and machines at the subscription or resource group
plan scope with Azure Policy.

Configure Role Develop an access plan to control who has access to One day
based access manage Azure Arc-enabled servers and ability to view their
control (RBAC) data from other Azure services and solutions.

Identify machines Run the following log query in Log Analytics to support One hour
with Log Analytics conversion of existing Log Analytics agent deployments to
agent already extension-managed agent:
installed Heartbeat
| summarize arg_max(TimeGenerated, OSType, ResourceId,
ComputerEnvironment) by Computer
| where ComputerEnvironment == "Non-Azure" and
isempty(ResourceId)
| project Computer, OSType

1
When evaluating your Log Analytics workspace design, consider integration with Azure
Automation in support of its Update Management and Change Tracking and Inventory
feature, as well as Microsoft Defender for Cloud and Microsoft Sentinel. If your
organization already has an Automation account and enabled its management features
linked with a Log Analytics workspace, evaluate whether you can centralize and
streamline management operations, as well as minimize cost, by using those existing
resources versus creating a duplicate account, workspace, etc.

Phase 2: Deploy Azure Arc-enabled servers

Next, we add to the foundation laid in Phase 1 by preparing for and deploying the Azure
Connected Machine agent.

ﾉ Expand table

Task Detail Estimated duration

Download the pre- Review and customize the pre-defined One or more days depending on
defined installation installation script for at-scale requirements, organizational
script deployment of the Connected Machine processes (for example, Change
agent to support your automated and Release Management), and
deployment requirements. automation method used.

Sample at-scale onboarding resources:

At-scale basic deployment script

At-scale onboarding VMware

vSphere Windows Server VMs

At-scale onboarding VMware

vSphere Linux VMs

At-scale onboarding AWS EC2

instances using Ansible

Create service Create a service principal to connect One hour

principal machines non-interactively using Azure
PowerShell or from the portal.

Deploy the Use your automation tool to deploy One or more days depending on
Connected the scripts to your servers and connect your release plan and if following
Machine agent to them to Azure. a phased rollout.
your target servers
and machines

Phase 3: Manage and operate

Phase 3 is when administrators or system engineers can enable automation of manual
tasks to manage and operate the Connected Machine agent and the machines during
their lifecycle.

ﾉ Expand table

Task Detail Estimated

duration

Create a Resource If a server stops sending heartbeats to Azure for longer than One hour
Health alert 15 minutes, it can mean that it is offline, the network
connection has been blocked, or the agent is not running.
Develop a plan for how you’ll respond and investigate these
incidents and use Resource Health alerts to get notified
when they start.

Specify the following when configuring the alert:

Resource type = Azure Arc-enabled servers
Current resource status = Unavailable
Previous resource status = Available

Create an Azure For the best experience and most recent security and bug One hour
Advisor alert fixes, we recommend keeping the Azure Connected Machine
agent up to date. Out-of-date agents will be identified with
an Azure Advisor alert.

Specify the following when configuring the alert:

Recommendation type = Upgrade to the latest version of
the Azure Connected Machine agent

Assign Azure Assign the Enable Azure Monitor for VMs policy (and Varies
policies to your others that meet your needs) to the subscription or resource
subscription or group scope. Azure Policy allows you to assign policy
resource group definitions that install the required agents for VM insights
scope across your environment.

Enable Azure Configure Azure Update Manager on your Arc-enabled 5 minutes

Update Manager servers to manage system updates for your Windows and
for your Azure Arc- Linux virtual machines. You can choose to deploy updates
enabled servers. on-demand or apply updates using custom schedule.

Next steps
Learn about best practices and design patterns through the Azure Arc landing
zone accelerator for hybrid and multicloud.
Learn about reconfiguring, upgrading, and removing the Connected Machine
agent.
Review troubleshooting information in the agent connection issues
troubleshooting guide.
Learn how to simplify deployment with other Azure services like Azure Automation
State Configuration and other supported Azure VM extensions.
Connected Machine agent prerequisites
Article • 07/02/2024

Ｕ Caution

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

This article 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
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 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.

Limited support operating systems

The following operating system versions have limited support. In each case, newer
agent versions won't support these operating systems. The last agent version that
supports the operating system is listed, and newer agent releases won't be made
available for that system. The listed version is supported until the End of Arc Support
Date. If critical security issues are identified that affect these agent versions, the fixes can
be backported to the last supported version, but new functionality or other bug fixes
won't be.

ﾉ Expand table
 Operating Last supported End of Arc Notes
system agent version Support Date

Windows 1.39 Download 03/31/2025 Windows Server 2008 and 2008 R2 reached
Server 2008 R2 End of Support in January 2020. See End of
SP1 support for Windows Server 2008 and
Windows Server 2008 R2.

CentOS 7 and 1.42 05/31/2025 See the CentOS End Of Life guidance.
8

Connect new limited support servers

To connect a new server running a Limited Support operating system to Azure Arc, you
will need to make some adjustments to the onboarding script.

For Windows, modify the installation script to specify the version required, using the -
AltDownload parameter.

Instead of

pwsh

# Install the hybrid agent

& "$env:TEMP\install_windows_azcmagent.ps1";

Use

pwsh

# Install the hybrid agent

& "$env:TEMP\install_windows_azcmagent.ps1" -AltDownload
https://aka.ms/AzureConnectedMachineAgent-1.39;

For Linux, the relevant package repository will only contain releases that are applicable,
so no special considerations are required.

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:

Windows Server 2008 R2 SP1 requires PowerShell 4.0 or later. Microsoft

recommends running the latest version, Windows Management Framework 5.1 .

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'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 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:

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:

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.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Connected Machine agent network
requirements
Article • 06/25/2024

This topic describes the networking requirements for using the Connected Machine
agent to onboard a physical server or virtual machine to Azure Arc-enabled servers.

Details
Generally, connectivity requirements include these principles:

All connections are TCP unless otherwise specified.

All HTTP connections use HTTPS and SSL/TLS with officially signed and verifiable
certificates.
All connections are outbound unless otherwise specified.

To use a proxy, verify that the agents and the machine performing the onboarding
process meet the network requirements in this article.

Azure Arc-enabled server endpoints are required for all server based Arc offerings.

Networking configuration
The Azure Connected Machine agent for Linux and Windows communicates outbound
securely to Azure Arc over TCP port 443. By default, the agent uses the default route to
the internet to reach Azure services. You can optionally configure the agent to use a
proxy server if your network requires it. Proxy servers don't make the Connected
Machine agent more secure because the traffic is already encrypted.

To further secure your network connectivity to Azure Arc, instead of using public
networks and proxy servers, you can implement an Azure Arc Private Link Scope .

７ Note

Azure Arc-enabled servers does not support using a Log Analytics gateway as a
proxy for the Connected Machine agent. At the same time, Azure Monitor Agent
supports Log Analytics gateway.

If outbound connectivity is restricted by your firewall or proxy server, make sure the
URLs and Service Tags listed below are not blocked.
Service tags
Be sure to allow access to the following Service Tags:

AzureActiveDirectory
AzureTrafficManager
AzureResourceManager
AzureArcInfrastructure
Storage
WindowsAdminCenter (if using Windows Admin Center to manage Arc-enabled
servers)

For a list of IP addresses for each service tag/region, see the JSON file Azure IP Ranges
and Service Tags – Public Cloud . Microsoft publishes weekly updates containing each
Azure Service and the IP ranges it uses. This information in the JSON file is the current
point-in-time list of the IP ranges that correspond to each service tag. The IP addresses
are subject to change. If IP address ranges are required for your firewall configuration,
then the AzureCloud Service Tag should be used to allow access to all Azure services.
Do not disable security monitoring or inspection of these URLs, allow them as you
would other Internet traffic.

If you filter traffic to the AzureArcInfrastructure service tag, you must allow traffic to the
full service tag range. The ranges advertised for individual regions, for example
AzureArcInfrastructure.AustraliaEast, do not include the IP ranges used by global
components of the service. The specific IP address resolved for these endpoints may
change over time within the documented ranges, so just using a lookup tool to identify
the current IP address for a given endpoint and allowing access to that will not be
sufficient to ensure reliable access.

For more information, see Virtual network service tags.

URLs
The table below lists the URLs that must be available in order to install and use the
Connected Machine agent.

Azure Cloud

７ Note

When configuring the Azure connected machine agent to communicate with

Azure through a private link, some endpoints must still be accessed through
 the internet. The Endpoint used with private link column in the following table
shows which endpoints can be configured with a private endpoint. If the
column shows Public for an endpoint, you must still allow access to that
endpoint through your organization's firewall and/or proxy server for the
agent to function.

ﾉ Expand table

Agent resource Description When required Endpoint

used with
private link

aka.ms Used to At installation Public

resolve the time, only
download
script during
installation

download.microsoft.com Used to At installation Public

download the time, only
Windows
installation
package

packages.microsoft.com Used to At installation Public

download the time, only
Linux
installation
package

login.windows.net Microsoft Entra Always Public

ID

login.microsoftonline.com Microsoft Entra Always Public

ID

pas.windows.net Microsoft Entra Always Public

ID

management.azure.com Azure When Public, unless

Resource connecting or a resource
Manager - to disconnecting a management
create or server, only private link is
delete the Arc also
server resource configured

*.his.arc.azure.com Metadata and Always Private

hybrid identity
Agent resource Description When required Endpoint
used with
private link

services

*.guestconfiguration.azure.com Extension Always Private

management
and guest
configuration
services

guestnotificationservice.azure.com , Notification Always Public

*.guestnotificationservice.azure.com service for
extension and
connectivity
scenarios

azgn*.servicebus.windows.net Notification Always Public

service for
extension and
connectivity
scenarios

*.servicebus.windows.net For Windows If using SSH or Public

Admin Center Windows
and SSH Admin Center
scenarios from Azure

*.waconazure.com For Windows If using Public

Admin Center Windows
connectivity Admin Center

*.blob.core.windows.net Download Always, except Not used

source for when using when private
Azure Arc- private link is
enabled endpoints configured
servers
extensions

dc.services.visualstudio.com Agent Optional, not Public

telemetry used in agent
versions 1.24+

*.<region>.arcdataservices.com 1 For Arc SQL Always Public

Server. Sends
data
processing
service, service
telemetry, and
performance
 Agent resource Description When required Endpoint
used with
private link

monitoring to
Azure. Allows
TLS 1.3.

www.microsoft.com/pkiops/certs Intermediate If using ESUs Public

certificate enabled by
updates for Azure Arc.
ESUs (note: Required
uses HTTP/TCP always for
80 and automatic
HTTPS/TCP updates, or
443) temporarily if
downloading
certificates
manually.

1
For extension versions up to and including February 13, 2024, use san-af-
<region>-prod.azurewebsites.net . Beginning with March 12, 2024 both Azure Arc

data processing, and Azure Arc data telemetry use *.<region>.arcdataservices.com .

７ Note

To translate the *.servicebus.windows.net wildcard into specific endpoints, use

the command \GET
https://guestnotificationservice.azure.com/urls/allowlist?api-
version=2020-01-01&location=<region> . Within this command, the region must

be specified for the <region> placeholder. These endpoints may change

periodically.

To get the region segment of a regional endpoint, remove all spaces from the Azure
region name. For example, East US 2 region, the region name is eastus2 .

For example: *.<region>.arcdataservices.com should be

*.eastus2.arcdataservices.com in the East US 2 region.

To see a list of all regions, run this command:

Azure CLI

az account list-locations -o table

 Azure PowerShell

Get-AzLocation | Format-Table

Transport Layer Security 1.2 protocol

To ensure the security of data in transit to Azure, we strongly encourage you to
configure machine to use Transport Layer Security (TLS) 1.2. Older versions of
TLS/Secure Sockets Layer (SSL) have been found to be vulnerable and while they still
currently work to allow backwards compatibility, they are not recommended.

ﾉ Expand table

Platform/Language Support More Information

Linux Linux distributions tend to Check the OpenSSL Changelog to

rely on OpenSSL for TLS 1.2 confirm your version of OpenSSL is
support. supported.

Windows Server 2012 R2 Supported, and enabled by To confirm that you are still using
and higher default. the default settings.

Subset of endpoints for ESU only

If you're using Azure Arc-enabled servers only for Extended Security Updates for either
or both of the following products:

Windows Server 2012

SQL Server 2012

You can enable the following subset of endpoints:

Azure Cloud

ﾉ Expand table

Agent resource Description When required Endpoint used

with private
link

aka.ms Used to resolve At installation Public

the download time, only
Agent resource Description When required Endpoint used
with private
link

script during
installation

download.microsoft.com Used to At installation Public

download the time, only
Windows
installation
package

login.windows.net Microsoft Entra Always Public

ID

*blob.core.windows.net Download Arc SQL Server ESUs Public

SQL Extension

login.microsoftonline.com Microsoft Entra Always Public

ID

management.azure.com Azure Resource When connecting Public, unless a

Manager - to or disconnecting resource
create or delete a server, only management
the Arc server private link is
resource also configured

*.his.arc.azure.com Metadata and Always Private

hybrid identity
services

*.guestconfiguration.azure.com Extension Always Private

management and
guest
configuration
services

www.microsoft.com/pkiops/certs Intermediate Always for Public

certificate automatic
updates for ESUs updates, or
(note: uses temporarily if
HTTP/TCP 80 and downloading
HTTPS/TCP 443) certificates
manually.

*.<region>.arcdataservices.com Azure Arc data SQL Server ESUs Public

processing
service and
service telemetry.
 Agent resource Description When required Endpoint used
with private
link

*.blob.core.windows.net Download Sql SQL Server ESUs Not required if

Server Extension using Private
package Link

Next steps
Review additional prerequisites for deploying the Connected Machine agent.
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.
For a complete list of network requirements for Azure Arc features and Azure Arc-
enabled services, see Azure Arc network requirements (Consolidated).

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Simplify network configuration
requirements through Azure Arc
gateway (Limited preview)
Article • 06/27/2024

７ Note

This is a Limited Public Preview, so customer subscriptions must be allowed by

Microsoft to use the feature. To participate, complete the Azure Arc gateway
Limited Public Preview Sign-up form .

If you use enterprise firewalls or proxies to manage outbound traffic, the Azure Arc
gateway lets you onboard infrastructure to Azure Arc using only seven (7) endpoints.
With Azure Arc gateway, you can:

Connect to Azure Arc by opening public network access to only seven Fully
Qualified Domains (FQDNs).
View and audit all traffic an Azure Connected Machine agent sends to Azure via
the Arc gateway.

This article explains how to set up and use an Arc gateway Resource.

） Important

The Arc gateway feature for Azure Arc-enabled servers is currently in Limited
preview in all regions where Azure Arc-enabled servers is present. See the
Supplemental Terms of Use for Microsoft Azure Limited previews for legal terms
that apply to Azure features that are in beta, limited preview, or otherwise not yet
released into general availability.

Supported scenarios
Azure Arc gateway supports the following scenarios:

Azure Monitor (Azure Monitor Agent + Dependency Agent) 1

Microsoft Defender for Cloud 2
Windows Admin Center
SSH
 Microsoft Sentinel
Azure Update Management
Azure Extension for SQL Server

1 Traffic to Log Analytics workspaces isn't covered by Arc gateway, so the FQDNs for
your Log Analytics workspaces must still be allowed in your firewalls or enterprise
proxies.

2 To send Microsoft Defender traffic via Arc gateway, you must configure the extension’s
proxy settings.

How it works
Azure Arc gateway consists of two main components:

The Arc gateway resource: An Azure resource that serves as a common front-end for
Azure traffic. This gateway resource is served on a specific domain. Once the Arc
gateway resource is created, the domain is returned to you in the success response.

The Arc Proxy: A new component added to Arc agentry. This component runs as a
service called "Azure Arc Proxy" and acts as a forward proxy used by the Azure Arc
agents and extensions. No configuration is required on your part for the gateway router.
This router is part of Arc core agentry and runs within the context of an Arc-enabled
resource.

When the gateway is in place, traffic flows via the following hops: Arc agentry → Arc
Proxy → Enterprise proxy → Arc gateway → Target service
Restrictions and limitations
The Arc gateway object has limits you should consider when planning your setup. These
limitations apply only to the Limited public preview. These limitations might not apply
when the Arc gateway feature is generally available.

TLS Terminating Proxies aren't supported.

ExpressRoute/Site-to-Site VPN used with the Arc gateway (Limited preview) isn't
supported.
The Arc gateway (Limited preview) is only supported for Azure Arc-enabled servers.
There's a limit of five Arc gateway (Limited preview) resources per Azure
subscription.

How to use the Arc gateway (Limited preview)

After completing the Azure Arc gateway Limited Public Preview Sign-up form , your
subscription will be allowed to use the feature within 1 business day. You'll receive an
email when the Arc gateway (Limited preview) feature has been allowed on the
subscription you submitted.

There are six main steps to use the feature:

1. Download the az connected.whl file and use it to install the az connectedmachine

extension.
2. Create an Arc gateway resource.
3. Ensure the required URLs are allowed in your environment.
4. Associate new or existing Azure Arc resources with your Arc gateway resource.
5. Verify that the setup succeeded.
6. Ensure other scenarios use the Arc gateway (Linux only).

Step 1: Download the az connectedmachine.whl file

1. Select the link to download the az connectedmachine.whl file .

This file contains the az connected machine commands required to create and
manage your gateway Resource.

2. Install the Azure CLI (if you haven't already).

3. Execute the following command to add the connectedmachine extension:

az extension add --allow-preview true --source [whl file path]

Step 2: Create an Arc gateway resource

On a machine with access to Azure, run the following commands to create your Arc
gateway resource:

Azure CLI

az login --use-device-code
az account set --subscription [subscription name or id]
az connectedmachine gateway create --name [Your gateway’s Name] --resource-
group [Your Resource Group] --location [Location] --gateway-type public --
allowed-features * --subscription [subscription name or id]

The gateway creation process takes 9-10 minutes to complete.

Step 3: Ensure the required URLs are allowed in your
environment
When the resource is created, the success response includes the Arc gateway URL.
Ensure your Arc gateway URL and all URLs in the following table are allowed in the
environment where your Arc resources live:

ﾉ Expand table

URL Purpose

[Your URL Your gateway URL (This URL can be obtained by running az
Prefix].gw.arc.azure.com connectedmachine gateway list after you create your gateway
Resource)

management.azure.com Azure Resource Manager Endpoint, required for Azure Resource

Manager control channel

login.microsoftonline.com Microsoft Entra ID’s endpoint, for acquiring Identity access

tokens

gbl.his.arc.azure.com The cloud service endpoint for communicating with Azure Arc
agents

<region>.his.arc.azure.com Used for Arc’s core control channel

packages.microsoft.com Required to acquire Linux based Arc agentry payload, only

needed to connect Linux servers to Arc

download.microsoft.com Used to download the Windows installation package

Step 4: Associate new or existing Azure Arc resources

with your gateway resource
To onboard a new server with Arc gateway, generate an installation script, then edit the
script to specify your gateway resource:

1. Generate the installation script. Follow the instructions at Quickstart: Connect

hybrid machines with Azure Arc-enabled servers to create a script that automates
the downloading and installation of the Azure Connected Machine agent and
establishes the connection with Azure Arc.

2. Edit the installation script. Your gateway Resource must be specific in the
installation script. To accomplish this, a new parameter called --gateway-id is
added to the connect command.
For Linux servers:
a. Obtain your gateway's Resource ID by running the az connectedmachine gateway
list command. Note the "id" parameter in the output (that is, the full ARM

resource ID).
b. In the installation script, add the "id" found in the previous step as the following
parameter: --gateway-id "[Your-gateway’s-Resource-ID]"

Linux server onboarding script example:

This script template includes parameters for you to specify your enterprise proxy
server.

export subscriptionId="SubscriptionId";
export resourceGroup="ResourceGroup";
export tenantId="TenantID";
export location="Region";
export authType="AuthType";
export cloud="AzureCloud";
export gatewayID="gatewayResourceID";

# Download the installation package

output=$(wget https://aka.ms/azcmagent -e use_proxy=yes -e
https_proxy="[Your Proxy URL]" -O /tmp/install_linux_azcmagent.sh
2>&1);
if [ $? != 0 ]; then wget -qO- -e use_proxy=yes -e https_proxy="[Your
Proxy URL]" --method=PUT --body-data="
{\"subscriptionId\":\"$subscriptionId\",\"resourceGroup\":\"$resourceGr
oup\",\"tenantId\":\"$tenantId\",\"location\":\"$location\",\"correlati
onId\":\"$correlationId\",\"authType\":\"$authType\",\"operation\":\"on
boarding\",\"messageType\":\"DownloadScriptFailed\",\"message\":\"$outp
ut\"}" "https://gbl.his.arc.azure.com/log" &> /dev/null || true; fi;
echo "$output";

# Install the hybrid agent

bash /tmp/install_linux_azcmagent.sh --proxy "[Your Proxy URL]";

# Run connect command

sudo azcmagent connect --resource-group "$resourceGroup" --tenant-id
"$tenantId" --location "$location" --subscription-id "$subscriptionId"
--cloud "$cloud" --correlation-id "$correlationId" --gateway-id
"$gatewayID";

For Windows servers:

a. Obtain your gateway's Resource ID by running the az connectedmachine gateway
list command. This command outputs information about all the gateway

resources in your subscription. Note the ID parameter in the output (that is, the
full ARM resource ID).
b. In the try section of the installation script, add the ID found in the previous step
as the following parameter: --gateway-id "[Your-gateway’s-Resource-ID]"
c. In the catch section of the installation script, add the ID found in the previous
step as the following parameter: gateway-id="[Your-gateway’s-Resource-ID]"

Windows server onboarding script example:

This script template includes parameters for you to specify your enterprise proxy
server.

$global:scriptPath = $myinvocation.mycommand.definition

function Restart-AsAdmin {
$pwshCommand = "powershell"
if ($PSVersionTable.PSVersion.Major -ge 6) {
$pwshCommand = "pwsh"
}

try {
Write-Host "This script requires administrator permissions to
install the Azure Connected Machine Agent. Attempting to restart script
with elevated permissions..."
$arguments = "-NoExit -Command `"& '$scriptPath'`""
Start-Process $pwshCommand -Verb runAs -ArgumentList $arguments
exit 0
} catch {
throw "Failed to elevate permissions. Please run this script as
Administrator."
}
}

try {
if (-not ([Security.Principal.WindowsPrincipal]
[Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.
Principal.WindowsBuiltInRole]::Administrator)) {
if ([System.Environment]::UserInteractive) {
Restart-AsAdmin
} else {
throw "This script requires administrator permissions to
install the Azure Connected Machine Agent. Please run this script as
Administrator."
}
}

$env:SUBSCRIPTION_ID = "SubscriptionId";
$env:RESOURCE_GROUP = "ResourceGroup";
$env:TENANT_ID = "TenantID";
$env:LOCATION = "Region";
$env:AUTH_TYPE = "AuthType";
$env:CLOUD = "AzureCloud";
 $env:GATEWAY_ID = "gatewayResourceID";

[Net.ServicePointManager]::SecurityProtocol =
[Net.ServicePointManager]::SecurityProtocol -bor 3072;

# Download the installation package

Invoke-WebRequest -UseBasicParsing -Uri "https://aka.ms/azcmagent-
windows" -TimeoutSec 30 -OutFile
"$env:TEMP\install_windows_azcmagent.ps1" -proxy "[Your Proxy URL]";

# Install the hybrid agent

& "$env:TEMP\install_windows_azcmagent.ps1" -proxy "[Your Proxy
URL]";
if ($LASTEXITCODE -ne 0) { exit 1; }

# Run connect command

& "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe"
connect --resource-group "$env:RESOURCE_GROUP" --tenant-id
"$env:TENANT_ID" --location "$env:LOCATION" --subscription-id
"$env:SUBSCRIPTION_ID" --cloud "$env:CLOUD" --gateway-id
"$env:GATEWAY_ID";
}
catch {
$logBody =
@{subscriptionId="$env:SUBSCRIPTION_ID";resourceGroup="$env:RESOURCE_GR
OUP";tenantId="$env:TENANT_ID";location="$env:LOCATION";authType="$env:
AUTH_TYPE";gatewayId="$env:GATEWAY_ID";operation="onboarding";messageTy
pe=$_.FullyQualifiedErrorId;message="$_";};
Invoke-WebRequest -UseBasicParsing -Uri
"https://gbl.his.arc.azure.com/log" -Method "PUT" -Body ($logBody |
ConvertTo-Json) -proxy "[Your Proxy URL]" | out-null;
Write-Host -ForegroundColor red $_.Exception;
}

3. Run the installation script to onboard your servers to Azure Arc.

To configure an existing machine to use Arc gateway, follow these steps:

７ Note

The existing machine must be using the Arc-enabled servers connected machine
agent version 1.43 or higher to use the Arc gateway Limited Public preview.

1. Associate your existing machine with your Arc gateway resource:

Azure CLI

az connectedmachine setting update --resource-group [res-group] --

subscription [subscription name] --base-provider
Microsoft.HyrbridCompute --base-resource-type machines --base-resource-
 name [Arc-server's resource name] --settings-resource-name default --
gateway-resource-id [Full Arm resourceid]

2. Update the machine to use the Arc gateway resource. Run the following command
on the Arc-enabled server to set it to use Arc gateway:

Azure CLI

azcmagent config set connection.type gateway

3. Await reconciliation.

Once your machines have been updated to use the Arc gateway, some Azure Arc
endpoints that were previously allowed in your enterprise proxy or firewalls won't
be needed. However, there's a transition period, so allow 1 hour before removing
unneeded endpoints from your firewall/enterprise proxy.

Step 5: Verify that the setup succeeded

On the onboarded server, run the following command: azcmagent show The result
should indicate the following values:

Agent Status should show as Connected.

Using HTTPS Proxy should show as http://localhost:40343
Upstream Proxy should show as your enterprise proxy (if you set one)

Additionally, to verify successful set-up, you can run the following command: azcmagent
check The result should indicate that the connection.type is set to gateway, and the

Reachable column should indicate true for all URLs.

Step 6: Ensure additional scenarios use the Arc gateway

(Linux only)
On Linux, to use Azure Monitor or Microsoft Defender for Endpoint, additional
commands need to be executed to work with the Azure Arc gateway (Limited preview).

For Azure Monitor, explicit proxy settings should be provided when deploying Azure
Monitor Agent. From Azure Cloud Shell, execute the following commands:

$settings = @{"proxy" = @{mode = "application"; address =

"http://127.0.0.1:40343"; auth = false}}
 New-AzConnectedMachineExtension -Name AzureMonitorLinuxAgent -ExtensionType
AzureMonitorLinuxAgent -Publisher Microsoft.Azure.Monitor -ResourceGroupName
<resource-group-name> -MachineName <arc-server-name> -Location <arc-server-
location> -Setting $settings

If you’re deploying Azure Monitor through the Azure portal, be sure to select the Use
Proxy setting and set the Proxy Address to http://127.0.0.1:40343 .

For Microsoft Defender for Endpoint, run the following command:

mdatp config proxy set --value http://127.0.0.1:40343

Cleanup instructions
To clean up your gateway, detach the gateway resource from the applicable server(s);
the resource can then be deleted safely:

1. Set the connection type of the Azure Arc-enabled server to "direct" instead of
"gateway":

azcmagent config set connection.type direct

2. Run the following command to delete the resource:

az connectedmachine gateway delete --resource group [resource group name] --

gateway-name [gateway resource name]

This operation can take couple of minutes.

Troubleshooting
You can audit your Arc gateway’s traffic by viewing the gateway Router’s logs.

To view gateway Router logs on Windows:

1. Run azcmagent logs in PowerShell.

2. In the resulting .zip file, the logs are located in the
C:\ProgramData\Microsoft\ArcGatewayRouter folder.

To view gateway Router logs on Linux:

1. Run sudo azcmagent logs .

2. In the resulting log file, the logs are located in the /usr/local/arcrtr/logs/ folder.
Known issues
It's not yet possible to use the Azure CLI to disassociate a gateway Resource from an
Arc-enabled server. To make an Arc-enabled server stop using an Arc gateway, use the
azcmagent config set connection.type direct command. This command configures the

Arc-enabled resource to use the direct route instead of the Arc gateway.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Use Azure Private Link to securely
connect servers to Azure Arc
Article • 10/12/2023

Azure Private Link allows you to securely link Azure PaaS services to your virtual network
using private endpoints. For many services, you just set up an endpoint per resource.
This means you can connect your on-premises or multi-cloud servers with Azure Arc and
send all traffic over an Azure ExpressRoute or site-to-site VPN connection instead of
using public networks.

Starting with Azure Arc-enabled servers, you can use a Private Link Scope model to
allow multiple servers or machines to communicate with their Azure Arc resources using
a single private endpoint.

This article covers when to use and how to set up an Azure Arc Private Link Scope.

Advantages
With Private Link you can:

Connect privately to Azure Arc without opening up any public network access.
Ensure data from the Azure Arc-enabled machine or server is only accessed
through authorized private networks. This also includes data from VM extensions
installed on the machine or server that provide post-deployment management and
monitoring support.
Prevent data exfiltration from your private networks by defining specific Azure Arc-
enabled servers and other Azure services resources, such as Azure Monitor, that
connects through your private endpoint.
Securely connect your private on-premises network to Azure Arc using
ExpressRoute and Private Link.
Keep all traffic inside the Microsoft Azure backbone network.

For more information, see Key Benefits of Private Link.

How it works
Azure Arc Private Link Scope connects private endpoints (and the virtual networks
they're contained in) to an Azure resource, in this case Azure Arc-enabled servers. When
you enable any one of the Azure Arc-enabled servers supported VM extensions, such as
Azure Automation Update Management or Azure Monitor, those resources connect
other Azure resources. Such as:

Log Analytics workspace, required for Azure Automation Update Management,

Azure Automation Change Tracking and Inventory, Azure Monitor VM insights, and
Azure Monitor log collection with Log Analytics agent.
Azure Automation account, required for Update Management and Change
Tracking and Inventory.
Azure Key Vault
Azure Blob storage, required for Custom Script Extension.

Connectivity to any other Azure resource from an Azure Arc-enabled server requires
configuring Private Link for each service, which is optional, but recommended. Azure
Private Link requires separate configuration per service.

For more information about configuring Private Link for the Azure services listed earlier,
see the Azure Automation, Azure Monitor, Azure Key Vault, or Azure Blob storage
articles.

） Important

Azure Private Link is now generally available. Both Private Endpoint and Private Link
service (service behind standard load balancer) are generally available. Different
Azure PaaS onboard to Azure Private Link following different schedules. See Private
Link availability for an updated status of Azure PaaS on Private Link. For known
limitations, see Private Endpoint and Private Link Service.
 The Private Endpoint on your VNet allows it to reach Azure Arc-enabled servers
endpoints through private IPs from your network's pool, instead of using to the
public IPs of these endpoints. That allows you to keep using your Azure Arc-
enabled servers resource without opening your VNet to outbound traffic not
requested.

Traffic from the Private Endpoint to your resources will go over the Microsoft Azure
backbone, and not routed to public networks.

You can configure each of your components to allow or deny ingestion and
queries from public networks. That provides a resource-level protection, so that
you can control traffic to specific resources.

Restrictions and limitations

The Azure Arc-enabled servers Private Link Scope object has a number of limits you
should consider when planning your Private Link setup.

You can associate at most one Azure Arc Private Link Scope with a virtual network.
An Azure Arc-enabled machine or server resource can only connect to one Azure
Arc-enabled servers Private Link Scope.
All on-premises machines need to use the same private endpoint by resolving the
correct private endpoint information (FQDN record name and private IP address)
using the same DNS forwarder. For more information, see Azure Private Endpoint
DNS configuration
The Azure Arc-enabled server and Azure Arc Private Link Scope must be in the
same Azure region. The Private Endpoint and the virtual network must also be in
the same Azure region, but this region can be different from that of your Azure Arc
Private Link Scope and Arc-enabled server.
Network traffic to Microsoft Entra ID and Azure Resource Manager does not
traverse the Azure Arc Private Link Scope and will continue to use your default
network route to the internet. You can optionally configure a resource
management private link to send Azure Resource Manager traffic to a private
endpoint.
Other Azure services that you will use, for example Azure Monitor, requires their
own private endpoints in your virtual network.
Remote access to the server using Windows Admin Center or SSH is not supported
over private link at this time.

Planning your Private Link setup

To connect your server to Azure Arc over a private link, you need to configure your
network to accomplish the following:

1. Establish a connection between your on-premises network and an Azure virtual

network using a site-to-site VPN or ExpressRoute circuit.

2. Deploy an Azure Arc Private Link Scope, which controls which machines or servers
can communicate with Azure Arc over private endpoints and associate it with your
Azure virtual network using a private endpoint.

3. Update the DNS configuration on your local network to resolve the private
endpoint addresses.

4. Configure your local firewall to allow access to Microsoft Entra ID and Azure
Resource Manager.

5. Associate the machines or servers registered with Azure Arc-enabled servers with
the private link scope.

6. Optionally, deploy private endpoints for other Azure services your machine or
server is managed by, such as:

Azure Monitor
Azure Automation
Azure Blob storage
Azure Key Vault

This article assumes you have already set up your ExpressRoute circuit or site-to-site
VPN connection.

Network configuration
Azure Arc-enabled servers integrate with several Azure services to bring cloud
management and governance to your hybrid machines or servers. Most of these services
already offer private endpoints, but you need to configure your firewall and routing
rules to allow access to Microsoft Entra ID and Azure Resource Manager over the
internet until these services offer private endpoints.

There are two ways you can achieve this:

If your network is configured to route all internet-bound traffic through the Azure
VPN or ExpressRoute circuit, you can configure the network security group (NSG)
associated with your subnet in Azure to allow outbound TCP 443 (HTTPS) access to
 Microsoft Entra ID and Azure using service tags. The NSG rules should look like the
following:

Setting Microsoft Entra ID rule Azure rule

Source Virtual network Virtual network

Source port * *
ranges

Destination Service Tag Service Tag

Destination AzureActiveDirectory AzureResourceManager

service tag

Destination 443 443

port ranges

Protocol Tcp Tcp

Action Allow Allow

Priority 150 (must be lower than any rules 151 (must be lower than any rules
that block internet access) that block internet access)

Name AllowAADOutboundAccess AllowAzOutboundAccess

Configure the firewall on your local network to allow outbound TCP 443 (HTTPS)
access to Microsoft Entra ID and Azure using the downloadable service tag files.
The JSON file contains all the public IP address ranges used by Microsoft Entra
ID and Azure and is updated monthly to reflect any changes. Azure ADs service tag
is AzureActiveDirectory and Azure's service tag is AzureResourceManager . Consult
with your network administrator and network firewall vendor to learn how to
configure your firewall rules.

See the visual diagram under the section How it works for the network traffic flows.

Create a Private Link Scope

1. Sign in to the Azure portal .

2. Go to Create a resource in the Azure portal and search for Azure Arc Private Link
Scope. Or you can use the following link to open the Azure Arc Private Link
Scope page in the portal.
 

3. Select Create.

4. In the Basics tab, select a Subscription and Resource Group.

5. Enter a name for the Azure Arc Private Link Scope. It's best to use a meaningful
and clear name.

Optionally, you can require every Azure Arc-enabled machine or server associated
with this Azure Arc Private Link Scope to send data to the service through the
private endpoint. To do so, check the box for Allow public network access so
machines or servers associated with this Azure Arc Private Link Scope can
communicate with the service over both private or public networks. You can
change this setting after creating the scope if you change your mind.

6. Select the Private endpoint tab, then select Create.

7. In the Create private endpoint window:

a. Enter a Name for the endpoint.

b. Choose Yes for Integrate with private DNS zone, and let it automatically create
a new Private DNS Zone.

７ Note

If you choose No and prefer to manage DNS records manually, first

complete setting up your Private Link - including this Private Endpoint and
the Private Scope configuration. Then, configure your DNS according to the
instructions in Azure Private Endpoint DNS configuration. Make sure not
to create empty records as preparation for your Private Link setup. The
DNS records you create can override existing settings and impact your
connectivity with Azure Arc-enabled servers.
 c. Select OK.

8. Select Review + Create.

9. Let the validation pass, and then select Create.

Configure on-premises DNS forwarding

Your on-premises machines or servers need to be able to resolve the private link DNS
records to the private endpoint IP addresses. How you configure this depends on
whether you're using Azure private DNS zones to maintain DNS records, or if you're
using your own DNS server on-premises and how many servers you're configuring.

DNS configuration using Azure-integrated private DNS

zones
If you set up private DNS zones for Azure Arc-enabled servers and Guest Configuration
when creating the private endpoint, your on-premises machines or servers need to be
able to forward DNS queries to the built-in Azure DNS servers to resolve the private
endpoint addresses correctly. You need a DNS forwarder in Azure (either a purpose-built
VM or an Azure Firewall instance with DNS proxy enabled), after which you can
configure your on-premises DNS server to forward queries to Azure to resolve private
endpoint IP addresses.

The private endpoint documentation provides guidance for configuring on-premises

workloads using a DNS forwarder.

Manual DNS server configuration

If you opted out of using Azure private DNS zones during private endpoint creation, you
will need to create the required DNS records in your on-premises DNS server.

1. Go to the Azure portal.

2. Navigate to the private endpoint resource associated with your virtual network and
private link scope.

3. From the left-hand pane, select DNS configuration to see a list of the DNS records
and corresponding IP addresses you'll need to set up on your DNS server. The
FQDNs and IP addresses will change based on the region you selected for your
private endpoint and the available IP addresses in your subnet.

4. Follow the guidance from your DNS server vendor to add the necessary DNS zones
and A records to match the table in the portal. Ensure that you select a DNS server
that is appropriately scoped for your network. Every machine or server that uses
this DNS server now resolves the private endpoint IP addresses and must be
associated with the Azure Arc Private Link Scope, or the connection will be refused.

Single server scenarios

If you're only planning to use Private Links to support a few machines or servers, you
may not want to update your entire network's DNS configuration. In this case, you can
add the private endpoint hostnames and IP addresses to your operating systems Hosts
file. Depending on the OS configuration, the Hosts file can be the primary or alternative
method for resolving hostname to IP address.

Windows
1. Using an account with administrator privileges, open
C:\Windows\System32\drivers\etc\hosts.

2. Add the private endpoint IPs and hostnames as shown in the table from step 3
under Manual DNS server configuration. The hosts file requires the IP address first
followed by a space and then the hostname.

3. Save the file with your changes. You may need to save to another directory first,
then copy the file to the original path.

Linux
1. Open the /etc/hosts hosts file in a text editor.

2. Add the private endpoint IPs and hostnames as shown in the table from step 3
under Manual DNS server configuration. The hosts file asks for the IP address first
followed by a space and then the hostname.

3. Save the file with your changes.

Connect to an Azure Arc-enabled servers

７ Note

The minimum supported version of the Azure Arc-connected machine agent with
private endpoint is version 1.4. The Azure Arc-enabled servers deployment script
generated in the portal downloads the latest version.

Configure a new Azure Arc-enabled server to use Private

link
When connecting a machine or server with Azure Arc-enabled servers for the first time,
you can optionally connect it to a Private Link Scope. The following steps are

1. From your browser, go to the Azure portal .

2. Navigate to Servers -Azure Arc.

3. On the Servers - Azure Arc page, select Add at the upper left.

4. On the Add servers with Azure Arc page, select either the Add a single server or
Add multiple servers depending on your deployment scenario, and then select
Generate script.

5. On the Generate script page, select the subscription and resource group where
you want the machine to be managed within Azure. Select an Azure location where
the machine metadata will be stored. This location can be the same or different, as
the resource group's location.

6. On the Prerequisites page, review the information and then select Next: Resource
details.

7. On the Resource details page, provide the following:

a. In the Resource group drop-down list, select the resource group the machine
will be managed from.

b. In the Region drop-down list, select the Azure region to store the machine or
server metadata.

c. In the Operating system drop-down list, select the operating system that the
script is configured to run on.

d. Under Network Connectivity, select Private endpoint and select the Azure Arc
Private Link Scope created in Part 1 from the drop-down list.
 e. Select Next: Tags.

8. If you selected Add multiple servers, on the Authentication page, select the
service principal created for Azure Arc-enabled servers from the drop-down list. If
you have not created a service principal for Azure Arc-enabled servers, first review
how to create a service principal to familiarize yourself with permissions required
and the steps to create one. Select Next: Tags to continue.

9. On the Tags page, review the default Physical location tags suggested and enter a
value, or specify one or more Custom tags to support your standards.

10. Select Next: Download and run script.

11. On the Download and run script page, review the summary information, and then
select Download. If you still need to make changes, select Previous.

After downloading the script, you have to run it on your machine or server using a
privileged (administrator or root) account. Depending on your network configuration,
you may need to download the agent from a computer with internet access and transfer
it to your machine or server, and then modify the script with the path to the agent.

The Windows agent can be downloaded from

https://aka.ms/AzureConnectedMachineAgent and the Linux agent can be
downloaded from https://packages.microsoft.com . Look for the latest version of the
azcmagent under your OS distribution directory and installed with your local package
manager.

The script will return status messages letting you know if onboarding was successful
after it completes.

 Tip

Network traffic from the Azure Connected Machine agent to Microsoft Entra ID and
Azure Resource Manager will continue to use public endpoints. If your server needs
to communicate through a proxy server to reach these endpoints, configure the
agent with the proxy server URL before connecting it to Azure. You may also need
to configure a proxy bypass for the Azure Arc services if your private endpoint is
not accessible from your proxy server.

Configure an existing Azure Arc-enabled server

For Azure Arc-enabled servers that were set up prior to your private link scope, you can
allow them to start using the Azure Arc-enabled servers Private Link Scope by
completing the following steps.

1. In the Azure portal, navigate to your Azure Arc Private Link Scope resource.

2. From the left-hand pane, select Azure Arc resources and then + Add.

3. Select the servers in the list that you want to associate with the Private Link Scope,
and then select Select to save your changes.

７ Note

Only Azure Arc-enabled servers in the same subscription and region as your
Private Link Scope is shown.
 

It may take up to 15 minutes for the Private Link Scope to accept connections from the
recently associated server(s).

Troubleshooting
1. Check your on-premises DNS server(s) to verify it is either forwarding to Azure
DNS or is configured with appropriate A records in your private link zone. These
lookup commands should return private IP addresses in your Azure virtual
network. If they resolve public IP addresses, double check your machine or server
and network's DNS configuration.

nslookup gbl.his.arc.azure.com
nslookup agentserviceapi.guestconfiguration.azure.com

2. If you are having trouble onboarding a machine or server, confirm that you've
added the Microsoft Entra ID and Azure Resource Manager service tags to your
local network firewall. The agent needs to communicate with these services over
the internet until private endpoints are available for these services.

Next steps
To learn more about Private Endpoint, see What is Azure Private Endpoint?.

If you are experiencing issues with your Azure Private Endpoint connectivity setup,
see Troubleshoot Azure Private Endpoint connectivity problems.

See the following to configure Private Link for Azure Automation, Azure Monitor,
Azure Key Vault, or Azure Blob storage.
Azure Connected Machine agent
deployment options
Article • 06/12/2024

Connecting machines in your hybrid environment directly with Azure can be

accomplished using different methods, depending on your requirements and the tools
you prefer to use.

Onboarding methods
The following table highlights each method so that you can determine which works best
for your deployment. For detailed information, follow the links to view the steps for each
topic.

ﾉ Expand table

Method Description

Interactively Manually install the agent on a single or small number of machines by

connecting machines using a deployment script.
From the Azure portal, you can generate a script and execute it on the machine
to automate the install and configuration steps of the agent.

Interactively Connect machines from Windows Admin Center

Interactively Connect machines using PowerShell

or at scale

At scale Connect machines using a service principal to install the agent at scale non-
interactively.

At scale Connect machines by running PowerShell scripts with Configuration Manager

At scale Connect machines with a Configuration Manager custom task sequence

At scale Connect Windows machines using Group Policy

At scale Connect machines from Automation Update Management to create a service

principal that installs and configures the agent for multiple machines managed
with Azure Automation Update Management to connect machines non-
interactively.

At scale Install the Arc agent on VMware VMs at scale using Arc enabled VMware
vSphere. Arc enabled VMware vSphere allows you to connect your VMware
 Method Description

vCenter server to Azure, automatically discover your VMware VMs, and install the
Arc agent on them. Requires VMware tools on VMs.

At scale Install the Arc agent on SCVMM VMs at scale using Arc-enabled System Center
Virtual Machine Manager. Arc-enabled System Center Virtual Machine Manager
allows you to connect your SCVMM management server to Azure, automatically
discover your SCVMM VMs, and install the Arc agent on them.

At scale Connect your AWS cloud through the multicloud connector enabled by Azure
Arc and enable the Arc onboarding solution to auto-discover and onboard EC2
VMs.

） Important

The Connected Machine agent cannot be installed on an Azure virtual machine. The
install script will warn you and roll back if it detects the server is running in Azure.

Be sure to review the basic prerequisites and network configuration requirements before
deploying the agent, as well as any specific requirements listed in the steps for the
onboarding method you choose. To learn more about what changes the agent will make
to your system, see Overview of the Azure Connected Machine Agent.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.

For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

Next steps
 Learn about the Azure Connected Machine agent prerequisites and network
requirements.
Review the Planning and deployment guide for Azure Arc-enabled servers
Learn about reconfiguring, upgrading, and removing the Connected Machine
agent.
Try out Arc-enabled servers by using the Azure Arc Jumpstart .

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Connect hybrid machines to Azure using
a deployment script
Article • 04/15/2024

You can enable Azure Arc-enabled servers for one or a small number of Windows or
Linux machines in your environment by performing a set of steps manually. Or you can
use an automated method by running a template script that we provide. This script
automates the download and installation of both agents.

This method requires that you have administrator permissions on the machine to install
and configure the agent. On Linux, by using the root account, and on Windows, you are
member of the Local Administrators group.

Before you get started, be sure to review the prerequisites and verify that your
subscription and resources meet the requirements. For information about supported
regions and other related considerations, see supported Azure regions.

If you don't have an Azure subscription, create a free account before you begin.

７ Note

Follow best security practices and avoid using an Azure account with Owner access
to onboard servers. Instead, use an account that only has the Azure Connected
Machine onboarding or Azure Connected Machine resource administrator role
assignment. See Azure Identity Management and access control security best
practices for more information.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.
For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

Generate the installation script from the Azure

portal
The script to automate the download and installation, and to establish the connection
with Azure Arc, is available from the Azure portal. To complete the process, perform the
following steps:

1. From your browser, sign in to the Azure portal .

2. On the Azure Arc - Machines page, select Add/Create at the upper left, and then
select Add a machine from the drop-down menu.

3. On the Add servers with Azure Arc page, under the Add a single server tile, select
Generate script.

4. On the Basics page, provide the following:

a. In the Project Details section, select the Subscription and Resource group the
machine will be managed from.
b. In the Region drop-down list, select the Azure region to store the servers
metadata.
c. In the Operating system drop-down list, select the operating system that the
script is configured to run on.
d. In the Connectivity method section, If the machine is communicating through a
proxy server to connect to the internet, select Proxy server option and specify
the proxy server IP address or the name and port number that the machine will
use to communicate with the proxy server. Enter the value in the format
http://<proxyURL>:<proxyport> . Else if the machine is communicating through a

private endpoint then select Private endpoint option and appropriate private
link scope in the drop-down list. Else if the machine is communicating through a
public endpoint then select Public endpoint option.
e. In the Automanage machine best practices section, you may enable
automanage if you want to onboard and configure best practice services like
Machine configuration and Insights, based on your server needs.
f. Select Next to go to the Tags page.

5. On the Tags page, review the default Physical location tags suggested and enter a
value, or specify one or more Custom tags to support your standards.

6. Select Next to Download and run script page.

 7. On the Download and run script page, review the summary information, and then
select Download. If you still need to make changes, select Previous.

Install and validate the agent on Windows

Install manually
You can install the Connected Machine agent manually by running the Windows Installer
package AzureConnectedMachineAgent.msi. You can download the latest version of the
Windows agent Windows Installer package from the Microsoft Download Center.

７ Note

To install or uninstall the agent, you must have Administrator permissions.

You must first download and copy the Installer package to a folder on the
target server, or from a shared network folder. If you run the Installer package
without any options, it starts a setup wizard that you can follow to install the
agent interactively.

If the machine needs to communicate through a proxy server to the service, after you
install the agent you need to run a command that's described in the steps below. This
command sets the proxy server system environment variable https_proxy . Using this
configuration, the agent communicates through the proxy server using the HTTP
protocol.

If you are unfamiliar with the command-line options for Windows Installer packages,
review Msiexec standard command-line options and Msiexec command-line options.

For example, run the installation program with the /? parameter to review the help and
quick reference option.

dos

msiexec.exe /i AzureConnectedMachineAgent.msi /?

1. To install the agent silently and create a setup log file in the C:\Support\Logs
folder that exist, run the following command.

dos
 msiexec.exe /i AzureConnectedMachineAgent.msi /qn /l*v
"C:\Support\Logs\Azcmagentsetup.log"

If the agent fails to start after setup is finished, check the logs for detailed error
information. The log directory is
%ProgramData%\AzureConnectedMachineAgent\log.

2. If the machine needs to communicate through a proxy server, to set the proxy
server environment variable, run the following command:

PowerShell

[Environment]::SetEnvironmentVariable("https_proxy", "http://{proxy-
url}:{proxy-port}", "Machine")
$env:https_proxy =
[System.Environment]::GetEnvironmentVariable("https_proxy","Machine")
# For the changes to take effect, the agent service needs to be
restarted after the proxy environment variable is set.
Restart-Service -Name himds

７ Note

The agent does not support setting proxy authentication.

3. After installing the agent, you need to configure it to communicate with the Azure
Arc service by running the following command:

dos

"%ProgramFiles%\AzureConnectedMachineAgent\azcmagent.exe" connect --
resource-group "resourceGroupName" --tenant-id "tenantID" --location
"regionName" --subscription-id "subscriptionID"

Install with the scripted method

1. Log in to the server.

2. Open an elevated PowerShell command prompt.

７ Note
 The script only supports running from a 64-bit version of Windows
PowerShell.

3. Change to the folder or share that you copied the script to, and execute it on the
server by running the ./OnboardingScript.ps1 script.

If the agent fails to start after setup is finished, check the logs for detailed error
information. The log directory is %ProgramData%\AzureConnectedMachineAgent\log.

Install and validate the agent on Linux

The Connected Machine agent for Linux is provided in the preferred package format for
the distribution (.RPM or .DEB) that's hosted in the Microsoft package repository . The
shell script bundle Install_linux_azcmagent.sh performs the following actions:

Configures the host machine to download the agent package from

packages.microsoft.com.

Installs the Hybrid Resource Provider package.

Optionally, you can configure the agent with your proxy information by including the --
proxy "{proxy-url}:{proxy-port}" parameter. Using this configuration, the agent

communicates through the proxy server using the HTTP protocol.

The script also contains logic to identify the supported and unsupported distributions,
and it verifies the permissions that are required to perform the installation.

The following example downloads the agent and installs it:

Bash

# Download the installation package.

wget https://aka.ms/azcmagent -O ~/Install_linux_azcmagent.sh

# Install the Azure Connected Machine agent.

bash ~/Install_linux_azcmagent.sh

1. To download and install the agent, run the following commands. If your machine
needs to communicate through a proxy server to connect to the internet, include
the --proxy parameter.

Bash
 # Download the installation package.
wget https://aka.ms/azcmagent -O ~/Install_linux_azcmagent.sh

# Install the AZure Connected Machine agent.

bash ~/Install_linux_azcmagent.sh --proxy "{proxy-url}:{proxy-port}"

2. After installing the agent, you need to configure it to communicate with the Azure
Arc service by running the following command:

Bash

azcmagent connect --resource-group "resourceGroupName" --tenant-id

"tenantID" --location "regionName" --subscription-id "subscriptionID" -
-cloud "cloudName"
if [ $? = 0 ]; then echo "\033[33mTo view your onboarded server(s),
navigate to
https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceTy
pe/Microsoft.HybridCompute%2Fmachines\033[m"; fi

Install with the scripted method

1. Log in to the server with an account that has root access.

2. Change to the folder or share that you copied the script to, and execute it on the
server by running the ./OnboardingScript.sh script.

If the agent fails to start after setup is finished, check the logs for detailed error
information. The log directory is var/opt/azcmagent/log.

Verify the connection with Azure Arc

After you install the agent and configure it to connect to Azure Arc-enabled servers, go
to the Azure portal to verify that the server has successfully connected. View your
machines in the Azure portal .
Next steps
Troubleshooting information can be found in the Troubleshoot Connected
Machine agent guide.

Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.

Learn how to manage your machine using Azure Policy, for such things as VM
guest configuration, verify the machine is reporting to the expected Log Analytics
workspace, enable monitoring with VM insights, and much more.
Connect hybrid machines to Azure from
Windows Admin Center
Article • 04/15/2024

You can enable Azure Arc-enabled servers for one or more Windows machines in your
environment by performing a set of steps manually. Or you can use Windows Admin
Center to deploy the Connected Machine agent and register your on-premises servers
without having to perform any steps outside of this tool.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.

For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

Prerequisites
Azure Arc-enabled servers - Review the prerequisites and verify that your
subscription, your Azure account, and resources meet the requirements.

Windows Admin Center - Review the requirements to prepare your environment to

deploy and configure Azure integration.

An Azure subscription. If you don't have one, create a free account before you
begin.

The target Windows servers that you want to manage must have Internet
connectivity to access Azure.

Security
This deployment method requires that you have administrator rights on the target
Windows machine or server to install and configure the agent. You also need to be a
member of the Gateway users role.

Deploy
Perform the following steps to configure the Windows server with Azure Arc-enabled
servers.

1. Sign in to Windows Admin Center.

2. From the connection list on the Overview page, in the list of connected Windows
servers, select a server from the list to connect to it.

3. From the left-hand pane, select Azure hybrid services.

4. On the Azure hybrid services page, select Discover Azure services.

5. On the Discover Azure services page, under Leverage Azure policies and
solutions to manage your servers with Azure Arc, select Set up.

6. On the Settings\Azure Arc for servers page, if prompted authenticate to Azure

and then select Get started.

7. On the Connect server to Azure page, provide the following:

a. In the Azure subscription drop-down list, select the Azure subscription.
b. For Resource group, either select New to create a new resource group, or under
the Resource group drop-down list, select an existing resource group to
register and manage the machine from.
c. In the Region drop-down list, select the Azure region to store the servers
metadata.
d. If the machine or server is communicating through a proxy server to connect to
the internet, select the option Use proxy server. Using this configuration, the
agent communicates through the proxy server using the HTTP protocol. Specify
the proxy server IP address or the name, and port number that the machine will
use to communicate with the proxy server.

8. Select Set up to proceed with configuring the Windows server with Azure Arc-
enabled servers.

The Windows server will connect to Azure, download the Connected Machine agent,
install it and register with Azure Arc-enabled servers. To track the progress, select
Notifications in the menu.
To confirm installation of the Connected Machine Agent, in Windows Admin Center
select Events from the left-hand pane to review MsiInstaller events in the Application
Event Log.

Verify the connection with Azure Arc

After you install the agent and configure it to connect to Azure Arc-enabled servers, go
to the Azure portal to verify that the server has successfully connected. View your
machine in the Azure portal .

Next steps
Troubleshooting information can be found in the Troubleshoot Connected
Machine agent guide.

Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.

Learn how to manage your machine using Azure Policy, for such things as VM
guest configuration, verifying the machine is reporting to the expected Log
Analytics workspace, enable monitoring with VM insights, and much more.
Connect hybrid machines to Azure by
using PowerShell
Article • 04/15/2024

For servers enabled with Azure Arc, you can take manual steps to enable them for one
or more Windows or Linux machines in your environment. Alternatively, you can use the
PowerShell cmdlet Connect-AzConnectedMachine to download the Connected Machine
agent, install the agent, and register the machine with Azure Arc. The cmdlet downloads
the Windows agent package (Windows Installer) from the Microsoft Download Center,
and the Linux agent package from the Microsoft package repository.

This method requires that you have administrator permissions on the machine to install
and configure the agent. On Linux, by using the root account, and on Windows, you are
member of the Local Administrators group. You can complete this process interactively
or remotely on a Windows server by using PowerShell remoting.

Before you get started, review the prerequisites and verify that your subscription and
resources meet the requirements. For information about supported regions and other
related considerations, see supported Azure regions.

If you don't have an Azure subscription, create a free account before you begin.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.

For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

Prerequisites
 A machine with Azure PowerShell. For instructions, see Install and configure Azure
PowerShell.

You use PowerShell to manage VM extensions on your hybrid servers managed by Azure
Arc-enabled servers. Before using PowerShell, install the Az.ConnectedMachine module
on the server you want to Arc-enable. Run the following command on your server
enabled with Azure Arc:

PowerShell

Install-Module -Name Az.ConnectedMachine

When the installation finishes, you see the following message:

The installed extension ``Az.ConnectedMachine`` is experimental and not covered by

customer support. Please use with discretion.

Install the agent and connect to Azure

1. Open a PowerShell console with elevated privileges.

2. Sign in to Azure by running the command Connect-AzAccount .

3. To install the Connected Machine agent, use Connect-AzConnectedMachine with the

-Name , -ResourceGroupName , and -Location parameters. Use the -SubscriptionId

parameter to override the default subscription as a result of the Azure context

created after sign-in. Run one of the following commands:

To install the Connected Machine agent on the target machine that can
directly communicate to Azure, run:

Azure PowerShell

Connect-AzConnectedMachine -ResourceGroupName myResourceGroup -

Name myMachineName -Location <region>

To install the Connected Machine agent on the target machine that

communicates through a proxy server, run:

Azure PowerShell

Connect-AzConnectedMachine -ResourceGroupName myResourceGroup -

Name myMachineName -Location <region> -Proxy http://<proxyURL>:
 <proxyport>

Using this configuration, the agent communicates through the proxy server
using the HTTP protocol.

If the agent fails to start after setup is finished, check the logs for detailed error
information. On Windows, check this file:
%ProgramData%\AzureConnectedMachineAgent\Log\himds.log. On Linux, check this file:
/var/opt/azcmagent/log/himds.log.

Install and connect by using PowerShell

remoting
Here's how to configure one or more Windows servers with servers enabled with Azure
Arc. You must enable PowerShell remoting on the remote machine. Use the Enable-
PSRemoting cmdlet to do this.

1. Open a PowerShell console as an Administrator.

2. Sign in to Azure by running the command Connect-AzAccount .

3. To install the Connected Machine agent, use Connect-AzConnectedMachine with the

-ResourceGroupName , and -Location parameters. The Azure resource names will

automatically use the hostname of each server. Use the -SubscriptionId

parameter to override the default subscription as a result of the Azure context
created after sign-in.

To install the Connected Machine agent on the target machine that can
directly communicate to Azure, run the following command:

Azure PowerShell

$sessions = New-PSSession -ComputerName myMachineName

Connect-AzConnectedMachine -ResourceGroupName myResourceGroup -
Location <region> -PSSession $sessions

To install the Connected Machine agent on multiple remote machines at the

same time, add a list of remote machine names, each separated by a comma.

Azure PowerShell

$sessions = New-PSSession -ComputerName myMachineName1,

myMachineName2, myMachineName3
 Connect-AzConnectedMachine -ResourceGroupName myResourceGroup -
Location <region> -PSSession $sessions

The following example shows the results of the command targeting a single
machine:

Azure PowerShell

time="2020-08-07T13:13:25-07:00" level=info msg="Onboarding Machine. It

usually takes a few minutes to complete. Sometimes it may take longer
depending on network and server load status."
time="2020-08-07T13:13:25-07:00" level=info msg="Check network
connectivity to all endpoints..."
time="2020-08-07T13:13:29-07:00" level=info msg="All endpoints are
available... continue onboarding"
time="2020-08-07T13:13:50-07:00" level=info msg="Successfully Onboarded
Resource to Azure" VM Id=f65bffc7-4734-483e-b3ca-3164bfa42941

Name Location OSName Status ProvisioningState

---- -------- ------ ------ -----------------
myMachineName eastus windows Connected Succeeded

Verify the connection with Azure Arc

After you install and configure the agent to register with Azure Arc-enabled servers, go
to the Azure portal to verify that the server has successfully connected. View your
machine in the Azure portal .

Next steps
If necessary, see the Troubleshoot Connected Machine agent guide.

Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.
Learn how to manage your machine by using Azure Policy. You can use VM guest
configuration, verify that the machine is reporting to the expected Log Analytics
workspace, and enable monitoring with VM insights.
Connect Windows Server machines to
Azure through Azure Arc Setup
Article • 04/15/2024

Windows Server machines can be onboarded directly to Azure Arc through a

graphical wizard included in Windows Server. The wizard automates the onboarding
process by checking the necessary prerequisites for successful Azure Arc onboarding
and fetching and installing the latest version of the Azure Connected Machine (AzCM)
agent. Once the wizard process completes, you're directed to your Window Server
machine in the Azure portal, where it can be viewed and managed like any other Azure
Arc-enabled resource.

Onboarding to Azure Arc is not needed if the Windows Server machine is already
running in Azure.

For Windows Server 2022, Azure Arc Setup is an optional component that can be
removed using the Remove Roles and Features Wizard. For Windows Server 2025 and
later, Azure Arc Setup is a Features On Demand. Essentially, this means that the
procedures for removal and enablement differ between OS versions. See for more
information.

７ Note

The Azure Arc Setup feature only applies to Windows Server 2022 and later. It was
released in the Cumulative Update of 10/10/2023 .

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.
For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

Prerequisites
Azure Arc-enabled servers - Review the prerequisites and verify that your
subscription, your Azure account, and resources meet the requirements.

An Azure subscription. If you don't have one, create a free account before you
begin.

Modern browser (Microsoft Edge) for authentication to Microsoft Azure.

Configuration of the Azure Connected Machine agent requires authentication to
your Azure account, either through interactive authentication on a modern
browser or device code login on a separate device (if the machine doesn't have a
modern browser).

Launch Azure Arc Setup and connect to Azure

Arc
The Azure Arc Setup wizard is launched from a system tray icon at the bottom of the
Windows Server machine when the Azure Arc Setup feature is enabled. This feature is
enabled by default. Alternatively, you can launch the wizard from a pop-up window in
the Server Manager or from the Windows Server Start menu.

1. Select the Azure Arc system tray icon, then select Launch Azure Arc Setup.
2. The introduction window of the Azure Arc Setup wizard explains the benefits of
onboarding your machine to Azure Arc. When you're ready to proceed, click Next.

3. The wizard automatically checks for the prerequisites necessary to install the Azure
Connected Machine agent on your Windows Server machine. Once this process
 completes and the agent is installed, select Configure.

4. The configuration window details the steps required to configure the Azure
Connected Machine agent. When you're ready to begin configuration, select Next.

5. Sign-in to Azure by selecting the applicable Azure cloud, and then selecting Sign
in to Azure. You'll be asked to provide your sign-in credentials.

6. Provide the resource details of how your machine will work within Azure Arc, such
as the Subscription and Resource group, and then select Next.

7. Once the configuration completes and your machine is onboarded to Azure Arc,
select Finish.

8. Go to the Server Manager and select Local Server to view the status of the
machine in the Azure Arc Management field. A successfully onboarded machine
has a status of Enabled.
Server Manager functions
You can select the Enabled/Disabled link in the Azure Arc Management field of the
Server Manager to launch different functions based on the status of the machine:

If Azure Arc Setup isn't installed, selecting Enabled/Disabled launches the Add
Roles and Features Wizard.
If Azure Arc Setup is installed and the Azure Connected Machine agent hasn't been
installed, selecting Disabled launches AzureArcSetup.exe , the executable file for
the Azure Arc Setup wizard.
If Azure Arc Setup is installed and the Azure Connected Machine agent is already
installed, selecting Enabled/Disabled launches AzureArcConfiguration.exe , the
executable file for configuring the Azure Connected Machine agent to work with
your machine.

Viewing the connected machine

The Azure Arc system tray icon at the bottom of your Windows Server machine indicates
if the machine is connected to Azure Arc; a red symbol means the machine does not
have the Azure Connected Machine agent installed. To view a connected machine in
Azure Arc, select the icon and then select View Machine in Azure. You can then view the
machine in the Azure portal , just as you would other Azure Arc-enabled resources.
Uninstalling Azure Arc Setup

７ Note

Uninstalling Azure Arc Setup does not uninstall the Azure Connected Machine
agent from the machine. For instructions on uninstalling the agent, see Managing
and maintaining the Connected Machine agent.

To uninstall Azure Arc Setup from a Windows Server 2022 machine:

1. In the Server Manager, navigate to the Remove Roles and Features Wizard. (See
Remove roles, role services, and features by using the Remove Roles and Features
Wizard for more information.)

2. On the Features page, uncheck the box for Azure Arc Setup.

3. On the confirmation page, select Restart the destination server automatically if

required, then select Remove.

To uninstall Azure Arc Setup through PowerShell, run the following command:

PowerShell
 Disable-WindowsOptionalFeature -Online -FeatureName AzureArcSetup

To uninstall Azure Arc Setup from a Windows Server 2025 machine:

1. Open the Settings app on the machine and select System, then select Optional
features.

2. Select AzureArcSetup, and then select Remove.

To uninstall Azure Arc Setup from a Windows Server 2025 machine from the command
line, run the following line of code:

DISM /online /Remove-Capability /CapabilityName:AzureArcSetup~~~~

Next steps
Troubleshooting information can be found in the Troubleshoot Azure Connected
Machine agent guide.

Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.

Learn how to manage your machine using Azure Policy, for such things as VM
guest configuration, verifying the machine is reporting to the expected Log
Analytics workspace, enable monitoring with VM insights, and much more.
Connect hybrid machines to Azure at
scale
Article • 04/15/2024

You can enable Azure Arc-enabled servers for multiple Windows or Linux machines in
your environment with several flexible options depending on your requirements. Using
the template script we provide, you can automate every step of the installation,
including establishing the connection to Azure Arc. However, you are required to
execute this script manually with an account that has elevated permissions on the target
machine and in Azure.

One method to connect the machines to Azure Arc-enabled servers is to use a Microsoft
Entra service principal. This service principal method can be used instead of your
privileged identity to interactively connect the machine. This service principal is a special
limited management identity that has only the minimum permission necessary to
connect machines to Azure using the azcmagent command. This method is safer than
using a higher privileged account like a Tenant Administrator and follows our access
control security best practices. The service principal is used only during onboarding; it
is not used for any other purpose.

Before you start connecting your machines, review the following requirements:

1. Make sure you have administrator permission on the machines you want to
onboard.

Administrator permissions are required to install the Connected Machine agent on

the machines; on Linux by using the root account, and on Windows as a member
of the Local Administrators group.

2. Review the prerequisites and verify that your subscription and resources meet the
requirements. You will need to have the Azure Connected Machine Onboarding
role or the Contributor role for the resource group of the machine. Make sure to
register the below Azure resource providers beforehand in your target
subscription.

Microsoft.HybridCompute
Microsoft.GuestConfiguration
Microsoft.HybridConnectivity
Microsoft.AzureArcData (if you plan to Arc-enable SQL Server instances)

See detailed how to here: Azure resource providers prerequisites

 For information about supported regions and other related considerations, see
supported Azure regions. Also review our at-scale planning guide to understand
the design and deployment criteria, as well as our management and monitoring
recommendations.

If you don't have an Azure subscription, create a free account before you begin.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.

For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

Create a service principal for onboarding at

scale
You can create a service principal in the Azure portal or by using Azure PowerShell.

７ Note

To create a service principal, your Microsoft Entra tenant needs to allow users to
register applications. If it does not, your account must be a member of the
Application Administrator or Cloud Application Administrator administrative role.
See Delegate app registration permissions in Microsoft Entra ID for more
information about tenant-level requirements. To assign Arc-enabled server roles,
your account must be a member of the Owner or User Access Administrator role
in the subscription that you want to use for onboarding.

Azure portal
The Azure Arc service in the Azure portal provides a streamlined way to create a service
principal that can be used to connect your hybrid machines to Azure.

1. In the Azure portal, navigate to Azure Arc, then select Service principals in the left
menu.
2. Select Add.
3. Enter a name for your service principal.
4. Choose whether the service principal will have access to an entire subscription, or
only to a specific resource group.
5. Select the subscription (and resource group, if applicable) to which the service
principal will have access.
6. In the Client secret section, select the duration for which your generated client
secret will be in use. You can optionally enter a friendly name of your choice in the
Description field.
7. In the Role assignment section, select Azure Connected Machine Onboarding.
8. Select Create.

Azure PowerShell
You can use Azure PowerShell to create a service principal with the New-
AzADServicePrincipal cmdlet.

1. Check the context of your Azure PowerShell session to ensure you're working in
the correct subscription. Use Set-AzContext if you need to change the subscription.

Azure PowerShell

Get-AzContext

2. Run the following command to create a service principal and assign it the Azure
Connected Machine Onboarding role for the selected subscription. After the
service principal is created, it will print the application ID and secret. The secret is
valid for 1 year, after which you'll need to generate a new secret and update any
scripts with the new secret.

Azure PowerShell

$sp = New-AzADServicePrincipal -DisplayName "Arc server onboarding

account" -Role "Azure Connected Machine Onboarding"
$sp | Format-Table AppId, @{ Name = "Secret"; Expression = {
$_.PasswordCredentials.SecretText }}

Output

AppId Secret
----- ------
aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee PASSWORD_SHOWN_HERE

The values from the following properties are used with parameters passed to the
azcmagent :

The value from the AppId property is used for the --service-principal-id
parameter value
The value from the Secret property is used for the --service-principal-
secret parameter used to connect the agent.

Generate the installation script from the Azure

portal
The script to automate the download and installation, and to establish the connection
with Azure Arc, is available from the Azure portal. To complete the process, do the
following steps:

1. From your browser, go to the Azure portal .

2. On the Machines - Azure Arc page, select Add/Create at the upper left, then select
Add a machine from the drop-down menu.

3. On the Add servers with Azure Arc page, select the Add multiple servers tile, and
then select Generate script.

4. On the Basics page, provide the following:

a. Select the Subscription and Resource group for the machines.
b. In the Region drop-down list, select the Azure region to store the servers'
metadata.
c. In the Operating system drop-down list, select the operating system that the
script is configured to run on.
d. If the machine is communicating through a proxy server to connect to the
internet, specify the proxy server IP address or the name and port number that
the machine will use to communicate with the proxy server. Using this
configuration, the agent communicates through the proxy server using the
HTTP protocol. Enter the value in the format http://<proxyURL>:<proxyport> .
e. Select Next.
f. In the Authentication section, under the Service principal drop-down list, select
Arc-for-servers. Then select, Next.

5. On the Tags page, review the default Physical location tags suggested and enter a
value, or specify one or more Custom tags to support your standards.

6. Select Next.

7. On the Download and run script page, review the summary information, and then
select Download. If you still need to make changes, select Previous.

For Windows, you are prompted to save OnboardingScript.ps1 , and for Linux
OnboardingScript.sh to your computer.

Install the agent and connect to Azure

Taking the script template created earlier, you can install and configure the Connected
Machine agent on multiple hybrid Linux and Windows machines using your
organizations preferred automation tool. The script performs similar steps described in
the Connect hybrid machines to Azure from the Azure portal article. The difference is in
the final step, where you establish the connection to Azure Arc using the azcmagent
command using the service principal.

The following are the settings that you configure the azcmagent command to use for the
service principal.

service-principal-id : The unique identifier (GUID) that represents the application

ID of the service principal.

service-principal-secret | The service principal password.

tenant-id : The unique identifier (GUID) that represents your dedicated instance of

Microsoft Entra ID.

subscription-id : The subscription ID (GUID) of your Azure subscription that you

want the machines in.

resource-group : The resource group name where you want your connected

machines to belong to.

location : See supported Azure regions. This location can be the same or different,

as the resource group's location.

resource-name : (Optional) Used for the Azure resource representation of your on-

premises machine. If you do not specify this value, the machine hostname is used.

You can learn more about the azcmagent command-line tool by reviewing the
Azcmagent Reference.

７ Note

The Windows PowerShell script only supports running from a 64-bit version of
Windows PowerShell.

After you install the agent and configure it to connect to Azure Arc-enabled servers, go
to the Azure portal to verify that the server has successfully connected. View your
machines in the Azure portal .
Next steps
Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.
Learn how to troubleshoot agent connection issues.
Learn how to manage your machines using Azure Policy for such things as VM
guest configuration, verifying that machines are reporting to the expected Log
Analytics workspace, monitoring with VM insights, and more.
Connect machines at scale by running
PowerShell scripts with Configuration
Manager
Article • 04/15/2024

Microsoft Configuration Manager facilitates comprehensive management of servers

supporting the secure and scalable deployment of applications, software updates, and
operating systems. Configuration Manager has an integrated ability to run PowerShell
scripts.

You can use Configuration Manager to run a PowerShell script that automates at-scale
onboarding to Azure Arc-enabled servers.

Before you get started, be sure to review the prerequisites and verify that your
subscription and resources meet the requirements. For information about supported
regions and other related considerations, see supported Azure regions. Also review our
at-scale planning guide to understand the design and deployment criteria, as well as our
management and monitoring recommendations.

If you don't have an Azure subscription, create a free account before you begin.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.

For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

Prerequisites for Configuration Manager to run

PowerShell scripts
The following prerequisites must be met to use PowerShell scripts in Configuration
Manager:

The Configuration Manager version must be 1706 or higher.

To import and author scripts, your Configuration Manager account must have
Create permissions for SMS Scripts.
To approve or deny scripts, your Configuration Manager account must have
Approve permissions for SMS Scripts.
To run scripts, your Configuration Manager account must have Run Script
permissions for Collections.

Generate a service principal and prepare the

installation script
Before you can run the script to connect your machines, you'll need to do the following:

1. Follow the steps to create a service principal for onboarding at scale. Assign the
Azure Connected Machine Onboarding role to your service principal, and limit the
scope of the role to the target Azure landing zone. Make a note of the Service
Principal Secret, as you'll need this value later.

2. Follow the steps to generate the installation script from the Azure portal. While
you will use this installation script later, do not run the script in PowerShell.

Create the script in Configuration Manager

Before you begin, check in Configuration Manager Default Settings that the PowerShell
execution policy under Computer Agent is set to Bypass.

1. In the Configuration Manager console, select Software Library.

2. In the Software Library workspace, select Scripts.
3. On the Home tab, in the Create group, select Create Script.
4. On the Script page of the Create Script wizard, configure the following settings:
a. Script Name – Onboard Azure Arc
b. Script language - PowerShell
 c. Import – Import the installation script that you generated in the Azure portal.

5. In the Script Wizard, paste the script generated from Azure portal. Edit this pasted
script with the Service Principal Secret for the service principal you generated.
6. Complete the wizard. The new script is displayed in the Script list with a status of
Waiting for approval.

Approve the script in Configuration Manager

With an account that has Approve permissions for SMS Scripts, do the following:

1. In the Configuration Manager console, select Software Library.

2. In the Software Library workspace, select Scripts.
3. In the Script list, choose the script you want to approve or deny. Then, on the
Home tab, in the Script group, select Approve/Deny.
 4. In the Approve or deny script dialog box, select Approve for the script.

5. Complete the wizard, then confirm that the new script is shown as Approved in the
Script list.

Run the script in Configuration Manager

Select a collection of targets for your script by doing the following:

1. In the Configuration Manager console, select Assets and Compliance.

2. In the Assets and Compliance workspace, select Device Collections.
3. In the Device Collections list, select the collection of devices on which you want to
run the script.
4. Select a collection of your choice, and then select Run Script.
5. On the Script page of the Run Script wizard, choose the script you authored and
approved.
6. Click Next, and then complete the wizard.
Verify successful connection to Azure Arc
The script status monitoring will indicate whether the script has successfully installed the
Connected Machine Agent to the collection of devices. Successfully onboarded Azure
Arc-enabled servers will also be visible in the Azure portal .

Next steps
Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.
Review connection troubleshooting information in the Troubleshoot Connected
Machine agent guide.
Learn how to manage your machine using Azure Policy for such things as VM
guest configuration, verifying that the machine is reporting to the expected Log
Analytics workspace, enabling monitoring with VM insights, and much more.
Connect machines at scale with a
Configuration Manager custom task
sequence
Article • 04/15/2024

Microsoft Configuration Manager facilitates comprehensive management of servers

supporting the secure and scalable deployment of applications, software updates, and
operating systems. Configuration Manager offers the custom task sequence as a flexible
paradigm for application deployment.

You can use a custom task sequence, that can deploy the Connected Machine Agent to
onboard a collection of devices to Azure Arc-enabled servers.

Before you get started, be sure to review the prerequisites and verify that your
subscription and resources meet the requirements. For information about supported
regions and other related considerations, see supported Azure regions. Also review our
at-scale planning guide to understand the design and deployment criteria, as well as our
management and monitoring recommendations.

If you don't have an Azure subscription, create a free account before you begin.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.

For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

Generate a service principal

Follow the steps to create a service principal for onboarding at scale. Assign the Azure
Connected Machine Onboarding role to your service principal, and limit the scope of
the role to the target Azure landing zone. Make a note of the Service Principal ID and
Service Principal Secret, as you'll need these values later.

Download the agent and create the application

First, download the Azure Connected Machine agent package
(AzureConnectedMachineAgent.msi) for Windows from the Microsoft Download
Center . The Azure Connected Machine agent for Windows can be upgraded to the
latest release manually or automatically, depending on your requirements. The .msi
must be saved in a server share for the custom task sequence.

Next, create an application in Configuration Manager using the installed Azure

Connected Machine agent package:

1. In the Configuration Manager console, select Software Library > Application

Management > Applications.
2. On the Home tab, in the Create group, select Create Application.
3. On the General page of the Create Application Wizard, select Automatically detect
information about this application from installation files. This action pre-
populates some of the information in the wizard with information that is extracted
from the installation .msi file. Then, specify the following information:
a. Type: Select Windows Installer (*.msi file)
b. Location: Select Browse to choose the location where you saved the installation
file AzureConnectedMachineAgent.msi.
 4. Select Next, and on the Import Information page, select Next again.
5. On the General Information page, you can supply further information about the
application to help you sort and locate it in the Configuration Manager console.
Once complete, select Next.
6. On the Installation program page, select Next.
7. On the Summary page, confirm your application settings and then complete the
wizard.

You have finished creating the application. To find it, in the Software Library workspace,
expand Application Management, and then choose Applications.

Create a task sequence

The next step is to define a custom task sequence that installs the Azure Connected
Machine Agent on a machine, then connects it to Azure Arc.

1. In the Configuration Manager console, go to the Software Library workspace,

expand Operating Systems, and then select the Task Sequences node.

2. On the Home tab of the ribbon, in the Create group, select Create Task Sequence.
This will launch the Create Task Sequence Wizard.
 3. On the Create a New Task Sequence page, select Create a new custom task
sequence.

4. On the Task Sequence Information page, specify a name for the task sequence
and optionally a description of the task sequence.

After you complete the Create Task Sequence Wizard, Configuration Manager adds the
custom task sequence to the Task Sequences node. You can now edit this task sequence
to add steps to it.

1. In the Configuration Manager console, go to the Software Library workspace,

expand Operating Systems, and then select the Task Sequences node.

2. In the Task Sequence list, select the task sequence that you want to edit.

3. Define Install Application as the first task in the task sequence.

a. On the Home tab of the ribbon, in theTask Sequence group, select Edit. Then,
select Add, select Software, and select Install Application.
b. Set the name to Install Connected Machine Agent .
 c. Select the Azure Connected Machine Agent.

4. Define Run PowerShell Script as the second task in the task sequence.
a. Select Add, select General, and select Run PowerShell Script.
b. Set the name to Connect to Azure Arc .
c. Select Enter a PowerShell script.
d. Select Add Script, and then edit the script to connect to Arc as shown below.
Note that this template script has placeholder values for the service principal,
tenant, subscription, resource group, and location, which you should update to
the appropriate values.

Azure PowerShell

& "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" connect

--service-principal-id <serviceprincipalAppID> --service-principal-
secret <serviceprincipalPassword> --tenant-id <tenantID> --
subscription-id <subscriptionID> --resource-group <ResourceGroupName> -
-location <resourceLocation>
 5. Set PowerShell execution policy to Bypass (if not already set by default).

6. Select OK to save the changes to your custom task sequence.

Deploy the custom task sequence and verify

connection to Azure Arc
Follow the steps outlined in Deploy a task sequence to deploy the task sequence to the
target collection of devices. Choose the following parameter settings.

Under Deployment Settings, set Purpose as Required so that Configuration

Manager automatically runs the task sequence according to the configured
schedule. If Purpose is set to Available instead, the task sequence will need to be
installed on demand from Software Center.
Under Scheduling, set Rerun Behavior to Rerun if failed previous attempt.

Verify successful connection to Azure Arc

To verify that the machines have been successfully connected to Azure Arc, verify that
they are visible in the Azure portal .
Next steps
Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.
Review connection troubleshooting information in the Troubleshoot Connected
Machine agent guide.
Learn how to manage your machine using Azure Policy for such things as VM
guest configuration, verifying that the machine is reporting to the expected Log
Analytics workspace, enabling monitoring with VM insights, and much more.
Connect machines at scale using Group
Policy
Article • 04/15/2024

You can onboard Active Directory–joined Windows machines to Azure Arc-enabled

servers at scale using Group Policy.

You'll first need to set up a local remote share with the Connected Machine agent and
modify a script specifying the Arc-enabled server's landing zone within Azure. You'll
then run a script that generates a Group Policy Object (GPO) to onboard a group of
machines to Azure Arc-enabled servers. This Group Policy Object can be applied to the
site, domain, or organizational level. Assignment can also use Access Control List (ACL)
and other security filtering native to Group Policy. Machines in the scope of the Group
Policy will be onboarded to Azure Arc-enabled servers. Scope your GPO to only include
machines that you want to onboard to Azure Arc.

Before you get started, be sure to review the prerequisites and verify that your
subscription and resources meet the requirements. For information about supported
regions and other related considerations, see supported Azure regions. Also review our
at-scale planning guide to understand the design and deployment criteria, as well as our
management and monitoring recommendations.

If you don't have an Azure subscription, create a free account before you begin.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.

For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.
Prepare a remote share and create a service
principal
The Group Policy Object, which is used to onboard Azure Arc-enabled servers, requires a
remote share with the Connected Machine agent. You will need to:

1. Prepare a remote share to host the Azure Connected Machine agent package for
Windows and the configuration file. You need to be able to add files to the
distributed location. The network share should provide Domain Controllers, and
Domain Computers with Change permissions, and Domain Admins with Full
Control permissions.

2. Follow the steps to create a service principal for onboarding at scale.

Assign the Azure Connected Machine Onboarding role to your service

principal and limit the scope of the role to the target Azure landing zone.
Make a note of the Service Principal Secret; you'll need this value later.

3. Download and unzip the folder ArcEnabledServersGroupPolicy_vX.X.X from

https://github.com/Azure/ArcEnabledServersGroupPolicy/releases/latest/ . This
folder contains the ArcGPO project structure with the scripts EnableAzureArc.ps1 ,
DeployGPO.ps1 , and AzureArcDeployment.psm1 . These assets will be used for

onboarding the machine to Azure Arc-enabled servers.

4. Download the latest version of the Azure Connected Machine agent Windows
Installer package from the Microsoft Download Center and save it to the remote
share.

5. Execute the deployment script DeployGPO.ps1 , modifying the run parameters for
the DomainFQDN, ReportServerFQDN, ArcRemoteShare, Service Principal secret,
Service Principal Client ID, Subscription ID, Resource Group, Region, Tenant, and
AgentProxy (if applicable):

.\DeployGPO.ps1 -DomainFQDN contoso.com -ReportServerFQDN

Server.contoso.com -ArcRemoteShare AzureArcOnBoard -
ServicePrincipalSecret $ServicePrincipalSecret -
ServicePrincipalClientId $ServicePrincipalClientId -SubscriptionId
$SubscriptionId -ResourceGroup $ResourceGroup -Location $Location -
TenantId $TenantId [-AgentProxy $AgentProxy]

Apply the Group Policy Object

On the Group Policy Management Console (GPMC), right-click on the desired
Organizational Unit and link the GPO named [MSFT] Azure Arc Servers (datetime). This
is the Group Policy Object which has the Scheduled Task to onboard the machines. After
10 or 20 minutes, the Group Policy Object will be replicated to the respective domain
controllers. Learn more about creating and managing group policy in Microsoft Entra
Domain Services.

After you have successfully installed the agent and configured it to connect to Azure
Arc-enabled servers, go to the Azure portal to verify that the servers in your
Organizational Unit have successfully connected. View your machines in the Azure
portal .

） Important

Once you've confirmed that your servers have successfully onboarded to Arc,
disable the Group Policy Object. This will prevent the same Powershell commands
in the scheduled tasks from executing when the system reboots or when the group
policy is updated.

Next steps
Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.
Review connection troubleshooting information in the Troubleshoot Connected
Machine agent guide.
Learn how to manage your machine using Azure Policy for such things as VM
guest configuration, verifying that the machine is reporting to the expected Log
Analytics workspace, enabling monitoring with VM insights, and much more.
Learn more about Group Policy.
Connect machines at scale using Ansible
playbooks
Article • 04/15/2024

You can onboard Ansible-managed nodes to Azure Arc-enabled servers at scale using
Ansible playbooks. To do so, you'll need to download, modify, and then run the
appropriate playbook.

Before you get started, be sure to review the prerequisites and verify that your
subscription and resources meet the requirements. For information about supported
regions and other related considerations, see supported Azure regions. Also review our
at-scale planning guide to understand the design and deployment criteria, as well as our
management and monitoring recommendations.

If you don't have an Azure subscription, create a free account before you begin.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.

For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

Generate a service principal and collect Azure

details
Before you can run the script to connect your machines, you'll need to do the following:

1. Follow the steps to create a service principal for onboarding at scale.

 Assign the Azure Connected Machine Onboarding role to your service
principal and limit the scope of the role to the target Azure subscription or
resource group.
Make a note of the Service Principal Secret and Service Principal Client ID;
you'll need these values later.

2. Collect details on the Tenant ID, Subscription ID, Resource Group, and Region
where the Azure Arc-enabled resource will be onboarded.

Download the Ansible playbook

If you are onboarding machines to Azure Arc-enabled servers, copy the following
Ansible playbook template and save the playbook as arc-server-onboard-playbook.yml .

YAML

---
- name: Onboard Linux and Windows Servers to Azure Arc-enabled servers with
public endpoint connectivity
hosts: all
# vars:
# azure:
# service_principal_id: 'INSERT-SERVICE-PRINCIPAL-CLIENT-ID'
# service_principal_secret: 'INSERT-SERVICE-PRINCIPAL-SECRET'
# resource_group: 'INSERT-RESOURCE-GROUP'
# tenant_id: 'INSERT-TENANT-ID'
# subscription_id: 'INSERT-SUBSCRIPTION-ID'
# location: 'INSERT-LOCATION'
tasks:
- name: Check if the Connected Machine Agent has already been downloaded
on Linux servers
stat:
path: /usr/bin/azcmagent
get_attributes: False
get_checksum: False
register: azcmagent_lnx_downloaded
when: ansible_system == 'Linux'

- name: Download the Connected Machine Agent on Linux servers

become: yes
get_url:
url: https://aka.ms/azcmagent
dest: ~/install_linux_azcmagent.sh
mode: '700'
when: (ansible_system == 'Linux') and
(azcmagent_lnx_downloaded.stat.exists == false)

- name: Install the Connected Machine Agent on Linux servers

become: yes
shell: bash ~/install_linux_azcmagent.sh
 when: (ansible_system == 'Linux') and (not
azcmagent_lnx_downloaded.stat.exists)

- name: Check if the Connected Machine Agent has already been downloaded
on Windows servers
win_stat:
path: C:\Program Files\AzureConnectedMachineAgent
register: azcmagent_win_downloaded
when: ansible_os_family == 'Windows'

- name: Download the Connected Machine Agent on Windows servers

win_get_url:
url: https://aka.ms/AzureConnectedMachineAgent
dest: C:\AzureConnectedMachineAgent.msi
when: (ansible_os_family == 'Windows') and (not
azcmagent_win_downloaded.stat.exists)

- name: Install the Connected Machine Agent on Windows servers

win_package:
path: C:\AzureConnectedMachineAgent.msi
when: (ansible_os_family == 'Windows') and (not
azcmagent_win_downloaded.stat.exists)

- name: Check if the Connected Machine Agent has already been connected
become: true
command:
cmd: azcmagent check
register: azcmagent_lnx_connected
ignore_errors: yes
when: ansible_system == 'Linux'
failed_when: (azcmagent_lnx_connected.rc not in [ 0, 16 ])
changed_when: False

- name: Check if the Connected Machine Agent has already been connected on
windows
win_command: azcmagent check
register: azcmagent_win_connected
when: ansible_os_family == 'Windows'
ignore_errors: yes
failed_when: (azcmagent_win_connected.rc not in [ 0, 16 ])
changed_when: False

- name: Connect the Connected Machine Agent on Linux servers to Azure Arc
become: yes
shell: azcmagent connect --service-principal-id "{{
azure.service_principal_id }}" --service-principal-secret "{{
azure.service_principal_secret }}" --resource-group "{{ azure.resource_group
}}" --tenant-id "{{ azure.tenant_id }}" --location "{{ azure.location }}" --
subscription-id "{{ azure.subscription_id }}"
when: (ansible_system == 'Linux') and (azcmagent_lnx_connected.rc is
defined and azcmagent_lnx_connected.rc != 0)

- name: Connect the Connected Machine Agent on Windows servers to Azure

win_shell: '& $env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe
connect --service-principal-id "{{ azure.service_principal_id }}" --service-
 principal-secret "{{ azure.service_principal_secret }}" --resource-group "{{
azure.resource_group }}" --tenant-id "{{ azure.tenant_id }}" --location "{{
azure.location }}" --subscription-id "{{ azure.subscription_id }}"'
when: (ansible_os_family == 'Windows') and (azcmagent_win_connected.rc
is defined and azcmagent_win_connected.rc != 0)

Modify the Ansible playbook

After downloading the Ansible playbook, complete the following steps:

1. Within the Ansible playbook, modify the variables under the vars section with the
service principal and Azure details collected earlier:

Service Principal ID
Service Principal Secret
Resource Group
Tenant ID
Subscription ID
Region

2. Enter the correct hosts field capturing the target servers for onboarding to Azure
Arc. You can employ Ansible patterns to selectively target which hybrid machines
to onboard.

3. This template passes the service principal secret as a variable in the Ansible
playbook. Please note that an Ansible vault could be used to encrypt this secret
and the variables could be passed through a configuration file.

Run the Ansible playbook

From the Ansible control node, run the Ansible playbook by invoking the ansible-
playbook command:

ansible-playbook arc-server-onboard-playbook.yml

After the playbook has run, the PLAY RECAP will indicate if all tasks were completed
successfully and surface any nodes where tasks failed.

Verify the connection with Azure Arc

After you have successfully installed the agent and configured it to connect to Azure
Arc-enabled servers, go to the Azure portal to verify that the servers in your target hosts
have successfully connected. View your machines in the Azure portal .

Next steps
Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.
Review connection troubleshooting information in the Troubleshoot Connected
Machine agent guide.
Learn how to manage your machine using Azure Policy for such things as VM
guest configuration, verifying that the machine is reporting to the expected Log
Analytics workspace, enabling monitoring with VM insights, and much more.
Connect hybrid machines to Azure from
Automation Update Management
Article • 04/15/2024

You can enable Azure Arc-enabled servers for one or more of your Windows or Linux
virtual machines or physical servers hosted on-premises or other cloud environment
that are managed with Azure Automation Update Management. This onboarding
process automates the download and installation of the Connected Machine agent. To
connect the machines to Azure Arc-enabled servers, a Microsoft Entra service principal is
used instead of your privileged identity to interactively connect the machine. This
service principal is created automatically as part of the onboarding process for these
machines.

Before you get started, be sure to review the prerequisites and verify that your
subscription and resources meet the requirements. For information about supported
regions and other related considerations, see supported Azure regions.

If you don't have an Azure subscription, create a free account before you begin.

Automatic connection for SQL Server

When you connect a Windows or Linux server to Azure Arc that also has Microsoft SQL
Server installed, the SQL Server instances will automatically be connected to Azure Arc
as well. SQL Server enabled by Azure Arc provides a detailed inventory and additional
management capabilities for your SQL Server instances and databases. As part of the
connection process, an extension is deployed to your Azure Arc-enabled server and new
roles will be applied to your SQL Server and databases. If you don't want to
automatically connect your SQL Servers to Azure Arc, you can opt out by adding a tag
to the Windows or Linux server with the name ArcSQLServerExtensionDeployment and
value Disabled when it's connected to Azure Arc.

For more information, see Manage automatic connection for SQL Server enabled by
Azure Arc.

How it works
When the onboarding process is launched, an Active Directory service principal is
created in the tenant.
To install and configure the Connected Machine agent on the target machine, a master
runbook named Add-UMMachinesToArc runs in the Azure sandbox. Based on the
operating system detected on the machine, the master runbook calls a child runbook
named Add-UMMachinesToArcWindowsChild or Add-UMMachinesToArcLinuxChild
that runs under the system Hybrid Runbook Worker role directly on the machine.
Runbook job output is written to the job history, and you can view their status summary
or drill into details of a specific runbook job in the Azure portal or using Azure
PowerShell. Execution of runbooks in Azure Automation writes details in an activity log
for the Automation account. For details of using the log, see Retrieve details from
Activity log.

The final step establishes the connection to Azure Arc using the azcmagent command
using the service principal to register the machine as a resource in Azure.

Prerequisites
This method requires that you are a member of the Automation Job Operator role or
higher so you can create runbook jobs in the Automation account.

If you have enabled Azure Policy to manage runbook execution and enforce targeting of
runbook execution against a Hybrid Runbook Worker group, this policy must be
disabled. Otherwise, the runbook jobs that onboard the machine(s) to Arc-enabled
servers will fail.

Add machines from the Azure portal

Perform the following steps to configure the hybrid machine with Arc-enabled servers.
The server or machine must be powered on and online in order for the process to
complete successfully.

1. From your browser, go to the Azure portal .

2. Navigate to the Machines - Azure Arc page, select Add/Create, and then select
Add a machine from the drop-down menu.

3. On the Add servers with Azure Arc page, select Add servers from the Add
managed servers from Update Management tile.

4. On the Resource details page, configure the following:

a. Select the Subscription and Resource group where you want the server to be
managed within Azure.
 b. In the Region drop-down list, select the Azure region to store the servers
metadata.
c. If the machine is communicating through a proxy server to connect to the
internet, specify the proxy server IP address or the name and port number that
the machine will use to communicate with the proxy server. Enter the value in
the format http://<proxyURL>:<proxyport> .
d. Select Next.

5. On the Servers page, select Add Servers, then select the Subscription and
Automation account from the drop-down list that has the Update Management
feature enabled and includes the machines you want to onboard to Azure Arc-
enabled servers.

After specifying the Automation account, the list below returns non-Azure
machines managed by Update Management for that Automation account. Both
Windows and Linux machines are listed and for each one, select add.

You can review your selection by selecting Review selection and if you want to
remove a machine select remove from under the Action column.

Once you confirm your selection, select Next.

6. On the Tags page, specify one or more Name/Value pairs to support your
standards. Select Next: Review + add.

7. On the Review _ add page, review the summary information, and then select Add
machines. If you still need to make changes, select Previous.

Verify the connection with Azure Arc

After the agent is installed and configured to connect to Azure Arc-enabled servers, go
to the Azure portal to verify that the server has successfully connected. View your
machines in the Azure portal .
Next steps
Troubleshooting information can be found in the Troubleshoot Connected
Machine agent guide.

Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.

Learn how to manage your machine using Azure Policy, for such things as VM
guest configuration, verify the machine is reporting to the expected Log Analytics
workspace, enable monitoring with VM insights, and much more.
Install Arc agents at scale for your
VMware VMs
Article • 07/08/2024

In this article, you learn how to install Arc agents at scale for VMware VMs and use
Azure management capabilities.

Prerequisites
Ensure the following before you install Arc agents at scale for VMware VMs:

The resource bridge must be in running state.

The vCenter must be in connected state.

The user account must have permissions listed in Azure Arc VMware Administrator
role.

All the target machines are:

Powered on and the resource bridge has network connectivity to the host
running the VM.
Running a supported operating system.
VMware tools are installed on the machines. If VMware tools aren't installed,
enable guest management operation is grayed out in the portal.

７ Note

You can use the out-of-band method to install Arc agents if VMware tools
aren't installed.

Able to connect through the firewall to communicate over the internet, and
these URLs aren't blocked.

７ Note

If you're using a Linux VM, the account must not prompt for login on sudo
commands. To override the prompt, from a terminal, run sudo visudo , and
add <username> ALL=(ALL) NOPASSWD:ALL at the end of the file. Ensure you
replace <username> .
 If your VM template has these changes incorporated, you won't need to do
this for the VM created from that template.

Approach A: Install Arc agents at scale from

portal
An admin can install agents for multiple machines from the Azure portal if the machines
share the same administrator credentials.

1. Navigate to Azure Arc center and select vCenter resource.

2. Select all the machines and choose Enable in Azure option.

3. Select Enable guest management checkbox to install Arc agents on the selected
machine.

4. If you want to connect the Arc agent via proxy, provide the proxy server details.

5. If you want to connect Arc agent via private endpoint, follow these steps to set up
Azure private link.

７ Note

Private endpoint connectivity is only available for Arc agent to Azure

communications. For Arc resource bridge to Azure connectivity, Azure private
link isn't supported.

6. Provide the administrator username and password for the machine.

７ Note

For Windows VMs, the account must be part of local administrator group; and for
Linux VM, it must be a root account.

Approach B: Install Arc agents using AzCLI

commands
The following Azure CLI commands can be used to install Arc agents.

Azure CLI
 az connectedvmware vm guest-agent enable --password

--resource-group

--username

--vm-name

[--https-proxy]

[--no-wait]

Approach C: Install Arc agents at scale using

helper script
Arc agent installation can be automated using the helper script built using the AzCLI
command provided here. Download this helper script to enable VMs and install Arc
agents at scale. In a single ARM deployment, the helper script can enable and install Arc
agents on 200 VMs.

Features of the script

Creates a log file (vmware-batch.log) for tracking its operations.

Generates a list of Azure portal links to all the deployments created (all-
deployments-<timestamp>.txt) .

Creates ARM deployment files (vmw-dep-<timestamp>-<batch>.json) .

Can enable up to 200 VMs in a single ARM deployment if guest management is

enabled, else enables 400 VMs.

Supports running as a cron job to enable all the VMs in a vCenter.

Allows for service principal authentication to Azure for automation.

Before running this script, install az cli and the connectedvmware extension.

Prerequisites
Before running this script, install:

Azure CLI from here.

 The connectedvmware extension for Azure CLI: Install it by running az extension add
--name connectedvmware .

Usage
1. Download the script to your local machine.

2. Open a PowerShell terminal and navigate to the directory containing the script.

3. Run the following command to allow the script to run, as it's an unsigned script (if
you close the session before you complete all the steps, run this command again
for the new session): Set-ExecutionPolicy -Scope Process -ExecutionPolicy
Bypass .

4. Run the script with the required parameters. For example, .\arcvmware-batch-
enablement.ps1 -VCenterId "<vCenterId>" -EnableGuestManagement -
VMCountPerDeployment 3 -DryRun . Replace <vCenterId> with the ARM ID of your

vCenter.

Parameters
VCenterId : The ARM ID of the vCenter where the VMs are located.

EnableGuestManagement : If this switch is specified, the script will enable guest

management on the VMs.

VMCountPerDeployment : The number of VMs to enable per ARM deployment. The

maximum value is 200 if guest management is enabled, else it's 400.

DryRun : If this switch is specified, the script will only create the ARM deployment
files. Else, the script will also deploy the ARM deployments.

Running as a Cron Job

You can set up this script to run as a cron job using the Windows Task Scheduler. Here's
a sample script to create a scheduled task:

Azure CLI

$action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-File

"C:\Path\To\vmware-batch-enable.ps1" -VCenterId "<vCenterId>" -
EnableGuestManagement -VMCountPerDeployment 3 -DryRun'
$trigger = New-ScheduledTaskTrigger -Daily -At 3am
 Register-ScheduledTask -Action $action -Trigger $trigger -TaskName
"EnableVMs"

Replace <vCenterId> with the ARM ID of your vCenter.

To unregister the task, run the following command:

Azure CLI

Unregister-ScheduledTask -TaskName "EnableVMs"

Approach D: Install Arc agents at scale using

out-of-band approach
Arc agents can be installed directly on machines without relying on VMware tools or
APIs. By following the out-of-band approach, first onboard the machines as Arc-enabled
Server resources with Resource type as Microsoft.HybridCompute/machines. After that,
perform Link to vCenter operation to update the machine's Kind property as VMware,
enabling virtual lifecycle operations.

1. Connect the machines as Arc-enabled Server resources: Install Arc agents using
Arc-enabled Server scripts.

You can use any of the following automation approaches to install Arc agents at
scale:

Install Arc agents at scale using a Service Principal.

Install Arc agents at scale using Configuration Manager script.
Install Arc agents at scale with a Configuration Manager custom task
sequence.
Install Arc agents at scale using Group policy.
Install Arc agents at scale using Ansible playbook.

2. Link Arc-enabled Server resources to the vCenter: The following commands will
update the Kind property of Hybrid Compute machines as VMware. Linking the
machines to vCenter will enable virtual lifecycle operations and power cycle
operations (start, stop, etc.) on the machines.

The following command scans all the Arc for Server machines that belong to
the vCenter in the specified subscription and links the machines with that
vCenter.
 Azure CLI

az connectedvmware vm create-from-machines --subscription contoso-

sub --vcenter-id /subscriptions/999998ee-cd13-9999-b9d4-
55ca5c25496d/resourceGroups/allhands-
demo/providers/microsoft.connectedvmwarevsphere/VCenters/ContosovC
entervcenters/contoso-vcenter

The following command scans all the Arc for Server machines that belong to
the vCenter in the specified Resource Group and links the machines with that
vCenter.

Azure CLI

az connectedvmware vm create-from-machines --resource-group

contoso-rg --vcenter-id /subscriptions/999998ee-cd13-9999-b9d4-
55ca5c25496d/resourceGroups/allhands-
demo/providers/microsoft.connectedvmwarevsphere/VCenters/ContosovC
entervcenters/contoso-vcenter

The following command can be used to link an individual Arc for Server
resource to vCenter.

Azure CLI

az connectedvmware vm create-from-machines --subscription contoso-

sub --vcenter-id /subscriptions/999998ee-cd13-9999-b9d4-
55ca5c25496d/resourceGroups/allhands-
demo/providers/microsoft.connectedvmwarevsphere/VCenters/ContosovC
entervcenters/contoso-vcenter

Next steps
Set up and manage self-service access to VMware resources through Azure RBAC.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Install Arc agents at scale for Arc-
enabled SCVMM VMs
Article • 03/27/2024

In this article, you learn how to install Arc agents at scale for SCVMM VMs and use
Azure management capabilities.

） Important

We recommend maintaining the SCVMM management server and the SCVMM

console in the same Long-Term Servicing Channel (LTSC) and Update Rollup (UR)
version.

７ Note

This article is applicable only if you are running:

SCVMM 2022 UR1 or later versions of SCVMM server or console

SCVMM 2019 UR5 or later versions of SCVMM server or console
VMs running Windows Server 2012 R2, 2016, 2019, 2022, Windows 10, and
Windows 11
For other SCVMM versions, Linux VMs or Windows VMs running WS 2012 or
earlier, install Arc agents through the script.

Prerequisites
Ensure the following before you install Arc agents at scale for SCVMM VMs:

The resource bridge must be in a running state.

The SCVMM management server must be in a connected state.
The user account must have permissions listed in Azure Arc SCVMM Administrator
role.
All the target machines are:
Powered on and the resource bridge has network connectivity to the host
running the VM.
Running a supported operating system.
 Able to connect through the firewall to communicate over the internet and
these URLs aren't blocked.

Install Arc agents at scale from portal

An admin can install agents for multiple machines from the Azure portal if the machines
share the same administrator credentials.

1. Navigate to the SCVMM management servers blade on Azure Arc Center , and
select the SCVMM management server resource.

2. Select all the machines and choose the Enable in Azure option.

3. Select Enable guest management checkbox to install Arc agents on the selected
machine.

4. If you want to connect the Arc agent via proxy, provide the proxy server details.

5. If you want to connect Arc agent via private endpoint, follow these steps to set up
Azure private link.

７ Note

Private endpoint connectivity is only available for Arc agent to Azure

communications. For Arc resource bridge to Azure connectivity, Azure Private
link isn't supported.

6. Provide the administrator username and password for the machine.

７ Note

For Windows VMs, the account must be part of the local administrator group;
and for Linux VM, it must be a root account.

Next steps
Manage VM extensions to use Azure management services for your SCVMM VMs.
Migrate your on-premises or other
cloud Azure Arc-enabled server to Azure
Article • 08/04/2022

This article is intended to help you plan and successfully migrate your on-premises
server or virtual machine managed by Azure Arc-enabled servers to Azure. By following
these steps, you are able to transition management from Azure Arc-enabled servers
based on the supported VM extensions installed and Azure services based on its Arc
server resource identity.

Before performing these steps, review the Azure Migrate Prepare on-premises machines
for migration to Azure article to understand requirements how to prepare for using
Azure Migrate.

In this article, you:

Inventory Azure Arc-enabled servers supported VM extensions installed.

Uninstall all VM extensions from the Azure Arc-enabled server.
Identify Azure services configured to authenticate with your Azure Arc-enabled
server-managed identity and prepare to update those services to use the Azure
VM identity after migration.
Review Azure role-based access control (Azure RBAC) access rights granted to the
Azure Arc-enabled server resource to maintain who has access to the resource
after it has been migrated to an Azure VM.
Delete the Azure Arc-enabled server resource identity from Azure and remove the
Azure Connected Machine agent.
Install the Azure guest agent.
Migrate the server or VM to Azure.

Step 1: Inventory and remove VM extensions

To inventory the VM extensions installed on your Azure Arc-enabled server, you can list
them using the Azure CLI or with Azure PowerShell.

With Azure PowerShell, use the Get-AzConnectedMachineExtension command with the

-MachineName and -ResourceGroupName parameters.

With the Azure CLI, use the az connectedmachine extension list command with the --
machine-name and --resource-group parameters. By default, the output of Azure CLI
commands is in JSON (JavaScript Object Notation). To change the default output to a list
or table, for example, use az configure --output. You can also add --output to any
command for a one time change in output format.

After identifying which VM extensions are deployed, you can remove them using the
Azure portal, using the Azure PowerShell, or using the Azure CLI. If the Log Analytics VM
extension or Dependency agent VM extension was deployed using Azure Policy and the
VM insights initiative, it is necessary to create an exclusion to prevent re-evaluation and
deployment of the extensions on the Azure Arc-enabled server before the migration is
complete.

Step 2: Review access rights

List role assignments for the Azure Arc-enabled servers resource, using Azure
PowerShell and with other PowerShell code, you can export the results to CSV or
another format.

If you're using a managed identity for an application or process running on an Azure

Arc-enabled server, you need to make sure the Azure VM has a managed identity
assigned. To view the role assignment for a managed identity, you can use the Azure
PowerShell Get-AzADServicePrincipal cmdlet. For more information, see List role
assignments for a managed identity.

A system-managed identity is also used when Azure Policy is used to audit or configure
settings inside a machine or server. With Azure Arc-enabled servers, the guest
configuration agent service is included, and performs validation of audit settings. After
you migrate, see Deploy requirements for Azure virtual machines for information on
how to configure your Azure VM manually or with policy with the guest configuration
extension.

Update role assignment with any resources accessed by the managed identity to allow
the new Azure VM identity to authenticate to those services. See the following to learn
how managed identities for Azure resources work for an Azure Virtual Machine (VM).

Step 3: Uninstall the Azure Connected Machine

agent
Follow the guidance to uninstall the agent from the server. Double check that all
extensions are removed before disconnecting the agent.

Step 4: Install the Azure Guest Agent

The VM that is migrated to Azure from on-premises doesn't have the Linux or Windows
Azure Guest Agent installed. In these scenarios, you have to manually install the VM
agent. For more information about how to install the VM Agent, see Azure Virtual
Machine Windows Agent Overview or Azure Virtual Machine Linux Agent Overview.

Step 5: Migrate server or machine to Azure

Before proceeding with the migration with Azure Migration, review the Prepare on-
premises machines for migration to Azure article to learn about requirements necessary
to use Azure Migrate. To complete the migration to Azure, review the Azure Migrate
migration options based on your environment.

Step 6: Deploy Azure VM extensions

After migration and completion of all post-migration configuration steps, you can now
deploy the Azure VM extensions based on the VM extensions originally installed on your
Azure Arc-enabled server. Review Azure virtual machine extensions and features to help
plan your extension deployment.

To resume using audit settings inside a machine with guest configuration policy
definitions, see Enable guest configuration.

If the Log Analytics VM extension or Dependency agent VM extension was deployed

using Azure Policy and the VM insights initiative, remove the exclusion you created
earlier. To use Azure Policy to enable Azure virtual machines, see Deploy Azure Monitor
at scale using Azure Policy.

Next steps
Troubleshooting information can be found in the Troubleshoot Connected Machine
agent guide.
Virtual machine extension management
with Azure Arc-enabled servers
Article • 05/21/2024

Ｕ 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.

Virtual machine (VM) extensions are small applications that provide post-deployment configuration
and automation tasks on Azure VMs. For example, if a virtual machine requires software installation,
anti-virus protection, or to run a script in it, a VM extension can be used.

Azure Arc-enabled servers enables you to deploy, remove, and update Azure VM extensions to non-
Azure Windows and Linux VMs, simplifying the management of your hybrid machine through their
lifecycle. VM extensions can be managed using the following methods on your hybrid machines or
servers managed by Arc-enabled servers:

The Azure portal

The Azure CLI
Azure PowerShell
Azure Resource Manager templates

７ Note

Azure Arc-enabled servers does not support deploying and managing VM extensions to Azure
virtual machines. For Azure VMs, see the following VM extension overview article.

７ Note

Currently you can only update extensions from the Azure portal or the Azure CLI. Performing this
operation from Azure PowerShell, or using an Azure Resource Manager template is not
supported at this time.

Key benefits
Azure Arc-enabled servers VM extension support provides the following key benefits:

Collect log data for analysis with Logs in Azure Monitor by enabling the Log Analytics agent VM
extension. Log Analytics makes it useful for doing complex analysis across log data from
different kinds of sources.
 With VM insights, it analyzes the performance of your Windows and Linux VMs, and monitors
their processes and dependencies on other resources and external processes. This is achieved
through enabling both the Log Analytics agent and Dependency agent VM extensions.

Download and execute scripts on hybrid connected machines using the Custom Script
Extension. This extension is useful for post deployment configuration, software installation, or
any other configuration or management tasks.

Automatically refresh of certificates stored in an Azure Key Vault.

Availability
VM extension functionality is available only in the list of supported regions. Ensure you onboard your
machine in one of these regions.

Additionally, you can configure lists of the extensions you wish to allow and block on servers. See
Extension allowlists and blocklists for more information.

Extensions
In this release, we support the following VM extensions on Windows and Linux machines.

To learn about the Azure Connected Machine agent package and details about the Extension agent
component, see Agent overview.

７ Note

The Desired State Configuration VM extension is no longer available for Azure Arc-enabled
servers. Alternatively, we recommend migrating to machine configuration or using the Custom
Script Extension to manage the post-deployment configuration of your server.

Arc-enabled servers support moving machines with one or more VM extensions installed between
resource groups or another Azure subscription without experiencing any impact to their
configuration. The source and destination subscriptions must exist within the same Microsoft Entra
tenant. This support is enabled starting with the Connected Machine agent version 1.8.21197.005. For
more information about moving resources and considerations before proceeding, see Move
resources to a new resource group or subscription.

Windows extensions

ﾉ Expand table

Extension Publisher Type Additional

information

Microsoft Qualys WindowsAgent.AzureSecurityCenter Microsoft

Defender Defender for
Extension Publisher Type Additional
information

for Cloud Cloud’s

integrated integrated
vulnerability vulnerability
scanner assessment
solution for
Azure and
hybrid
machines

Microsoft Microsoft.Azure.Security IaaSAntimalware Microsoft

Antimalware Antimalware
extension extension
for Windows

Custom Microsoft.Compute CustomScriptExtension Windows

Script Custom
extension Script
Extension

Log Microsoft.EnterpriseCloud.Monitoring MicrosoftMonitoringAgent Log

Analytics Analytics
agent VM
extension
for Windows

Azure Microsoft.Azure.Monitoring.DependencyAgent DependencyAgentWindows Dependency

Monitor for agent virtual
VMs machine
(insights) extension
for Windows

Azure Key Microsoft.Azure.Key.Vault KeyVaultForWindows Key Vault

Vault virtual
Certificate machine
Sync extension
for Windows

Azure Microsoft.Azure.Monitor AzureMonitorWindowsAgent Install the

Monitor Azure
Agent Monitor
agent

Azure Microsoft.Compute HybridWorkerForWindows Deploy an

Automation extension-
Hybrid based User
Runbook Hybrid
Worker Runbook
extension Worker to
execute
runbooks
locally

Azure Microsoft.AzureData WindowsAgent.SqlServer Install Azure

Extension extension
for SQL
Extension Publisher Type Additional
information

for SQL Server to

Server initiate SQL
Server
connection
to Azure

Windows Microsoft.AdminCenter AdminCenter Manage

Admin Azure Arc-
Center enabled
(preview) Servers
using
Windows
Admin
Center in
Azure

Windows WindowsOsUpdateExtension Microsoft.SoftwareUpdateManagement Overview of

OS Update Azure
Extension Update
Manager

Windows Microsoft.CPlat.Core WindowsPatchExtension Automatic

Patch Guest
Extension Patching for
Azure
Virtual
Machines
and Scale
Sets

Linux extensions

ﾉ Expand table

Extension Publisher Type Additional

information

Microsoft Qualys LinuxAgent.AzureSecurityCenter Microsoft

Defender for Defender for
Cloud Cloud’s
integrated integrated
vulnerability vulnerability
scanner assessment
solution for
Azure and
hybrid
machines

Custom Microsoft.Azure.Extensions CustomScript Linux Custom

Script Script
extension Extension
Version 2
 Extension Publisher Type Additional
information

Log Microsoft.EnterpriseCloud.Monitoring OmsAgentForLinux Log Analytics

Analytics VM extension
agent for Linux

Azure Microsoft.Azure.Monitoring.DependencyAgent DependencyAgentLinux Dependency

Monitor for agent virtual
VMs machine
(insights) extension for
Linux

Azure Key Microsoft.Azure.Key.Vault KeyVaultForLinux Key Vault

Vault virtual
Certificate machine
Sync extension for
Linux

Azure Microsoft.Azure.Monitor AzureMonitorLinuxAgent Install the

Monitor Azure
Agent Monitor
agent

Azure Microsoft.Compute HybridWorkerForLinux Deploy an

Automation extension-
Hybrid based User
Runbook Hybrid
Worker Runbook
extension Worker to
execute
runbooks
locally

Linux OS Microsoft.SoftwareUpdateManagement LinuxOsUpdateExtension Overview of

Update Azure Update
Extension Manager

Linux Patch Microsoft.CPlat.Core LinuxPatchExtension Automatic

Extension Guest
Patching for
Azure Virtual
Machines and
Scale Sets

Prerequisites
This feature depends on the following Azure resource providers in your subscription:

Microsoft.HybridCompute
Microsoft.GuestConfiguration

If they aren't already registered, follow the steps under Register Azure resource providers.
Be sure to review the documentation for each VM extension referenced in the previous table to
understand if it has any network or system requirements. This can help you avoid experiencing any
connectivity issues with an Azure service or feature that relies on that VM extension.

Required Permissions
To deploy an extension to Arc-enabled servers, a user requires the following permissions.

microsoft.hybridcompute/machines/read

microsoft.hybridcompute/machines/extensions/read

microsoft.hybridcompute/machines/extensions/write

The role Azure Connected Machine Resource Administrator includes the permissions required to
deploy extensions, however it also includes permission to delete Arc-enabled server resources.

Log Analytics VM extension

The Log Analytics agent VM extension for Linux requires Python 2.x is installed on the target machine.

Before you install the extension we suggest you review the deployment options for the Log Analytics
agent to understand the different methods available and which meets your requirements.

Azure Key Vault VM extension

The Key Vault VM extension doesn't support the following Linux operating systems:

CentOS Linux 7 (x64)

Red Hat Enterprise Linux (RHEL) 7 (x64)
Amazon Linux 2 (x64)

Deploying the Key Vault VM extension is only supported using:

The Azure CLI

The Azure PowerShell
Azure Resource Manager template

Before you deploy the extension, you need to complete the following:

1. Create a vault and certificate (self-signed or import).

2. Grant the Azure Arc-enabled server access to the certificate secret. If you’re using the RBAC
preview, search for the name of the Azure Arc resource and assign it the Key Vault Secrets User
(preview) role. If you’re using Key Vault access policy, assign Secret Get permissions to the
Azure Arc resource’s system assigned identity.

Connected Machine agent

Verify your machine matches the supported versions of Windows and Linux operating system for the
Azure Connected Machine agent.

The minimum version of the Connected Machine agent that is supported with this feature on
Windows and Linux is the 1.0 release.

To upgrade your machine to the version of the agent required, see Upgrade agent.

Operating system extension availability

The following extensions are available for Windows and Linux machines:

Windows extension availability

ﾉ Expand table

Operating Azure Log Dependency Qualys Custom Key Hybrid Antimalware Windows
system Monitor Analytics VM Insights Script Vault Runbook Extension Admin
agent agent Center

Windows X X X X X X X
Server
2022

Windows X X X X X X X
Server
2019

Windows X X X X X X X Built-in X
Server
2016

Windows X X X X X X X
Server
2012 R2

Windows X X X X X X X X
Server
2012

Windows X X X X X X X
Server
2008 R2
SP1

Windows X X X X
Server
2008 R2

Windows X X X X
Server
2008 SP2
Operating Azure Log Dependency Qualys Custom Key Hybrid Antimalware Windows
system Monitor Analytics VM Insights Script Vault Runbook Extension Admin
agent agent Center

Windows X X
11 client
OS

Windows X X X
10 1803
(RS4) and
higher

Windows X X X X X X
10
Enterprise
(including
multi-
session)
and Pro
(Server
scenarios
only)

Windows X X X X
8
Enterprise
and Pro
(Server
scenarios
only)

Windows X X X X
7 SP1
(Server
scenarios
only)

Azure X X X
Stack HCI
(Server
scenarios
only)

Linux extension availability

ﾉ Expand table

Operating Azure Log Dependency Qualys Custom Key Hybrid Antimalware Connected
system Monitor Analytics VM Insights Script Vault Runbook Extension Machine
agent agent agent

Amazon X X X X
Linux 2
Operating Azure Log Dependency Qualys Custom Key Hybrid Antimalware Connected
system Monitor Analytics VM Insights Script Vault Runbook Extension Machine
agent agent agent

CentOS X X X X X X X
Linux 8

CentOS X X X X X X X
Linux 7

CentOS X X X X
Linux 6

Debian 10 X X X X

Debian 9 X X X X X

Debian 8 X X X X

Debian 7 X X

OpenSUSE X X
13.1+

Oracle X X X X X X
Linux 8

Oracle X X X X X X
Linux 7

Oracle X X X X X
Linux 6

Red Hat X X X X X X
Enterprise
Linux
Server 8

Red Hat X X X X X X X
Enterprise
Linux
Server 7

Red Hat X X X X
Enterprise
Linux
Server 6

SUSE X X X X X
Linux
Enterprise
Server
15.2

SUSE X X X X X X X
Linux
Enterprise
 Operating Azure Log Dependency Qualys Custom Key Hybrid Antimalware Connected
system Monitor Analytics VM Insights Script Vault Runbook Extension Machine
agent agent agent

Server
15.1

SUSE X X X X X X X X
Linux
Enterprise
Server 15
SP1

SUSE X X X X X X X X
Linux
Enterprise
Server 15

SUSE X X X X X X X
Linux
Enterprise
Server 15
SP5

SUSE X X X X X X X
Linux
Enterprise
Server 12
SP5

Ubuntu X X X X X X X
20.04 LTS

Ubuntu X X X X X X X X
18.04 LTS

Ubuntu X X X X X X
16.04 LTS

Ubuntu X X X
14.04 LTS

For the regional availabilities of different Azure services and VM extensions available for Azure Arc-
enabled servers, refer to Azure Global's Product Availability Roadmap .

Next steps
You can deploy, manage, and remove VM extensions using the Azure CLI, Azure PowerShell, from the
Azure portal, or Azure Resource Manager templates.
Enable Azure VM extensions from the
Azure portal
Article • 11/06/2023

This article shows you how to deploy, update, and uninstall Azure VM extensions
supported by Azure Arc enabled servers, on a Linux or Windows hybrid machine using
the Azure portal.

７ Note

The Key Vault VM extension does not support deployment from the Azure portal,
only using the Azure CLI, the Azure PowerShell, or using an Azure Resource
Manager template.

７ Note

Azure Arc-enabled servers does not support deploying and managing VM

extensions to Azure virtual machines. For Azure VMs, see the following VM
extension overview article.

Enable extensions
VM extensions can be applied to your Azure Arc-enabled server-managed machine via
the Azure portal.

1. From your browser, go to the Azure portal .

2. In the portal, browse to Machines - Azure Arc and select your machine from the
list.

3. Choose Extensions, then select Add.

4. Choose the extension you want from the list of available extensions and follow the
instructions in the wizard. In this example, we will deploy the Log Analytics VM
extension.
 To complete the installation, you are required to provide the workspace ID and
primary key. If you are not familiar with how to find this information, see obtain
workspace ID and key.

5. After confirming the required information provided, select Review + Create. A

summary of the deployment is displayed and you can review the status of the
deployment.

７ Note

While multiple extensions can be batched together and processed, they are
installed serially. Once the first extension installation is complete, installation of the
next extension is attempted.

List extensions installed

You can get a list of the VM extensions on your Azure Arc-enabled server from the
Azure portal. Perform the following steps to see them.

1. From your browser, go to the Azure portal .

2. In the portal, browse to Machines - Azure Arc and select your machine from the
list.
 3. Choose Extensions, and the list of installed extensions is returned.

Upgrade extensions
When a new version of a supported extension is released, you can upgrade the
extension to that latest release. Azure Arc-enabled servers presents a banner in the
Azure portal when you navigate to Azure Arc-enabled servers, informing you there are
upgrades available for one or more extensions installed on a machine. When you view
the list of installed extensions for a selected Azure Arc-enabled server, you'll notice a
column labeled Update available. If a newer version of an extension is released, the
Update available value for that extension shows a value of Yes.

７ Note

While the word Update is used in the Azure portal for this experience currently, it
does not accurately represent the behavior of the operation. Extensions are
upgraded by installing a newer version of the extension currently installed on the
machine or server.

Upgrading an extension to the newest version does not affect the configuration of that
extension. You are not required to respecify configuration information for any extension
you upgrade.
You can upgrade one, or select multiple extensions eligible for an upgrade from the
Azure portal by performing the following steps.

７ Note

Currently you can only upgrade extensions from the Azure portal. Performing this
operation from the Azure CLI or using an Azure Resource Manager template is not
supported at this time.

1. From your browser, go to the Azure portal .

2. In the portal, browse to Machines - Azure Arc and select your hybrid machine
from the list.

3. Choose Extensions, and review the status of extensions under the Update
available column.

You can upgrade one extension by one of three ways:

By selecting an extension from the list of installed extensions, and under the
properties of the extension, select the Update option.
 By selecting the extension from the list of installed extensions, and select the
Update option from the top of the page.

By selecting one or more extensions that are eligible for an upgrade from the list
of installed extensions, and then select the Update option.

Remove extensions
You can remove one or more extensions from an Azure Arc-enabled server from the
Azure portal. Perform the following steps to remove an extension.

1. From your browser, go to the Azure portal .

2. In the portal, browse to Machines - Azure Arc and select your hybrid machine
from the list.
 3. Choose Extensions, and then select an extension from the list of installed
extensions.

4. Select Uninstall and when prompted to verify, select Yes to proceed.

Next steps
You can deploy, manage, and remove VM extensions using the Azure CLI,
PowerShell, or Azure Resource Manager templates.

Troubleshooting information can be found in the Troubleshoot VM extensions

guide.
Enable Azure VM extensions using the
Azure CLI
Article • 03/29/2023

This article shows you how to deploy, upgrade, update, and uninstall VM extensions,
supported by Azure Arc-enabled servers, to a Linux or Windows hybrid machine using
the Azure CLI.

７ Note

Azure Arc-enabled servers does not support deploying and managing VM

extensions to Azure virtual machines. For Azure VMs, see the following VM
extension overview article.

Prerequisites
Use the Bash environment in Azure Cloud Shell. For more information, see
Quickstart for Bash in Azure Cloud Shell.

If you prefer to run CLI reference commands locally, install the Azure CLI. If you're
running on Windows or macOS, consider running Azure CLI in a Docker container.
For more information, see How to run the Azure CLI in a Docker container.

If you're using a local installation, sign in to the Azure CLI by using the az login
command. To finish the authentication process, follow the steps displayed in
your terminal. For other sign-in options, see Sign in with the Azure CLI.

When you're prompted, install the Azure CLI extension on first use. For more
information about extensions, see Use extensions with the Azure CLI.

Run az version to find the version and dependent libraries that are installed. To
upgrade to the latest version, run az upgrade.

Install the Azure CLI extension

The ConnectedMachine commands aren't shipped as part of the Azure CLI. Before using
the Azure CLI to connect to Azure and manage VM extensions on your hybrid server
managed by Azure Arc-enabled servers, you need to load the ConnectedMachine
extension. These management operations can be performed from your workstation, you
don't need to run them on the Azure Arc-enabled server.

Run the following command to get it:

Azure CLI

az extension add --name connectedmachine

Enable extension
To enable a VM extension on your Azure Arc-enabled server, use az connectedmachine
extension create with the --machine-name , --extension-name , --location , --type ,
settings , and --publisher parameters.

The following example enables the Log Analytics VM extension on an Azure Arc-enabled
server:

Azure CLI

az connectedmachine extension create --machine-name "myMachineName" --name

"OmsAgentForLinux or MicrosoftMonitoringAgent" --location "regionName" --
settings '{\"workspaceId\":\"myWorkspaceId\"}' --protected-settings
'{\"workspaceKey\":\"myWorkspaceKey\"}' --resource-group "myResourceGroup" -
-type-handler-version "1.13" --type "OmsAgentForLinux or
MicrosoftMonitoringAgent" --publisher "Microsoft.EnterpriseCloud.Monitoring"

The following example enables the Custom Script Extension on an Azure Arc-enabled
server:

Azure CLI

az connectedmachine extension create --machine-name "myMachineName" --name

"CustomScriptExtension" --location "regionName" --type
"CustomScriptExtension" --publisher "Microsoft.Compute" --settings "
{\"commandToExecute\":\"powershell.exe -c \\\"Get-Process | Where-Object {
$_.CPU -gt 10000 }\\\"\"}" --type-handler-version "1.10" --resource-group
"myResourceGroup"

The following example enables the Key Vault VM extension on an Azure Arc-enabled
server:

Azure CLI
 az connectedmachine extension create --resource-group "resourceGroupName" --
machine-name "myMachineName" --location "regionName" --publisher
"Microsoft.Azure.KeyVault" --type "KeyVaultForLinux or KeyVaultForWindows" -
-name "KeyVaultForLinux or KeyVaultForWindows" --settings
'{"secretsManagementSettings": { "pollingIntervalInS": "60",
"observedCertificates": ["observedCert1"] }, "authenticationSettings": {
"msiEndpoint": "http://localhost:40342/metadata/identity" }}'

The following example enables the Microsoft Antimalware extension on an Azure Arc-
enabled Windows server:

Azure CLI

az connectedmachine extension create --resource-group "resourceGroupName" --

machine-name "myMachineName" --location "regionName" --publisher
"Microsoft.Azure.Security" --type "IaaSAntimalware" --name "IaaSAntimalware"
--settings '"{\"AntimalwareEnabled\": \"true\"}"'

The following example enables the Datadog extension on an Azure Arc-enabled

Windows server:

Azure CLI

az connectedmachine extension create --resource-group "resourceGroupName" --

machine-name "myMachineName" --location "regionName" --publisher
"Datadog.Agent" --type "DatadogWindowsAgent" --settings '{"site":
"us3.datadoghq.com"}' --protected-settings '{"api_key": "YourDatadogAPIKey"
}'

List extensions installed

To get a list of the VM extensions on your Azure Arc-enabled server, use az
connectedmachine extension list with the --machine-name and --resource-group
parameters.

Example:

Azure CLI

az connectedmachine extension list --machine-name "myMachineName" --

resource-group "myResourceGroup"

By default, the output of Azure CLI commands is in JSON (JavaScript Object Notation).
To change the default output to a list or table, for example, use az config set
core.output=table. You can also add --output to any command for a one time change
in output format.

The following example shows the partial JSON output from the az connectedmachine
extension -list command:

JSON

[
{
"autoUpgradingMinorVersion": "false",
"forceUpdateTag": null,
"id":
"/subscriptions/subscriptionId/resourceGroups/resourceGroupName/providers/Mi
crosoft.HybridCompute/machines/SVR01/extensions/DependencyAgentWindows",
"location": "regionName",
"name": "DependencyAgentWindows",
"namePropertiesInstanceViewName": "DependencyAgentWindows",

Update extension configuration

Some VM extensions require configuration settings in order to install them on the Arc-
enabled server, like the Custom Script Extension and the Log Analytics agent VM
extension. To upgrade the configuration of an extension, use az connectedmachine
extension update.

The following example shows how to configure the Custom Script Extension:

Azure CLI

az connectedmachine extension update --name "CustomScriptExtension" --type

"CustomScriptExtension" --publisher "Microsoft.HybridCompute" --settings "
{\"commandToExecute\":\"powershell.exe -c \\\"Get-Process | Where-Object {
$_.CPU -lt 100 }\\\"\"}" --type-handler-version "1.10" --machine-name
"myMachine" --resource-group "myResourceGroup"

Upgrade extensions
When a new version of a supported VM extension is released, you can upgrade it to that
latest release. To upgrade a VM extension, use az connectedmachine upgrade-extension
with the --machine-name , --resource-group , and --extension-targets parameters.

For the --extension-targets parameter, you need to specify the extension and the
latest version available. To find out what the latest version available is, you can get this
information from the Extensions page for the selected Arc-enabled server in the Azure
portal, or by running az vm extension image list. You may specify multiple extensions in
a single upgrade request by providing a comma-separated list of extensions, defined by
their publisher and type (separated by a period) and the target version for each
extension, as shown in the example below.

To upgrade the Log Analytics agent extension for Windows that has a newer version
available, run the following command:

Azure CLI

az connectedmachine upgrade-extension --machine-name "myMachineName" --

resource-group "myResourceGroup" --extension-targets
'{\"Microsoft.EnterpriseCloud.Monitoring.MicrosoftMonitoringAgent\":
{\"targetVersion\":\"1.0.18053.0\"}}'

You can review the version of installed VM extensions at any time by running the
command az connectedmachine extension list. The typeHandlerVersion property value
represents the version of the extension.

Remove extensions
To remove an installed VM extension on your Azure Arc-enabled server, use az
connectedmachine extension delete with the --extension-name , --machine-name , and --
resource-group parameters.

For example, to remove the Log Analytics VM extension for Linux, run the following
command:

Azure CLI

az connectedmachine extension delete --machine-name "myMachineName" --name

"OmsAgentForLinux" --resource-group "myResourceGroup"

Next steps
You can deploy, manage, and remove VM extensions using the Azure PowerShell,
from the Azure portal, or Azure Resource Manager templates.

Troubleshooting information can be found in the Troubleshoot VM extensions

guide.
Review the Azure CLI VM extension Overview article for more information about
the commands.
Enable Azure VM extensions using
Azure PowerShell
Article • 03/29/2023

This article shows you how to deploy, update, and uninstall Azure VM extensions,
supported by Azure Arc-enabled servers, to a Linux or Windows hybrid machine using
Azure PowerShell.

７ Note

Azure Arc-enabled servers does not support deploying and managing VM

extensions to Azure virtual machines. For Azure VMs, see the following VM
extension overview article.

Prerequisites
A computer with Azure PowerShell. For instructions, see Install and configure Azure
PowerShell.

Before using Azure PowerShell to manage VM extensions on your hybrid server

managed by Azure Arc-enabled servers, you need to install the Az.ConnectedMachine
module. These management operations can be performed from your workstation, you
don't need to run them on the Azure Arc-enabled server.

Run the following command on your Azure Arc-enabled server:

Install-Module -Name Az.ConnectedMachine .

When the installation completes, the following message is returned:

The installed extension 'Az.ConnectedMachine' is experimental and not covered by

customer support. Please use with discretion.

Enable extension
To enable a VM extension on your Azure Arc-enabled server, use New-
AzConnectedMachineExtension with the -Name , -ResourceGroupName , -MachineName , -
Location , -Publisher , - ExtensionType , and -Settings parameters.
The following example enables the Log Analytics VM extension on a Azure Arc-enabled
Linux server:

PowerShell

$Setting = @{ "workspaceId" = "workspaceId" }

$protectedSetting = @{ "workspaceKey" = "workspaceKey" }
New-AzConnectedMachineExtension -Name OMSLinuxAgent -ResourceGroupName
"myResourceGroup" -MachineName "myMachineName" -Location "regionName" -
Publisher "Microsoft.EnterpriseCloud.Monitoring" -Settings $Setting -
ProtectedSetting $protectedSetting -ExtensionType "OmsAgentForLinux"

To enable the Log Analytics VM extension on an Azure Arc-enabled Windows server,

change the value for the -ExtensionType parameter to "MicrosoftMonitoringAgent" in
the previous example.

The following example enables the Custom Script Extension on an Azure Arc-enabled
server:

PowerShell

$Setting = @{ "commandToExecute" = "powershell.exe -c Get-Process" }

New-AzConnectedMachineExtension -Name "custom" -ResourceGroupName
"myResourceGroup" -MachineName "myMachineName" -Location "regionName" -
Publisher "Microsoft.Compute" -Settings $Setting -ExtensionType
CustomScriptExtension

The following example enables the Microsoft Antimalware extension on an Azure Arc-
enabled Windows server:

PowerShell

$Setting = @{ "AntimalwareEnabled" = $true }

New-AzConnectedMachineExtension -Name "IaaSAntimalware" -ResourceGroupName
"myResourceGroup" -MachineName "myMachineName" -Location "regionName" -
Publisher "Microsoft.Azure.Security" -Settings $Setting -ExtensionType
"IaaSAntimalware"

Key Vault VM extension

２ Warning

PowerShell clients often add \ to " in the settings.json which will cause
akvvm_service fails with error: [CertificateManagementConfiguration] Failed to
 parse the configuration settings with:not an object.

The following example enables the Key Vault VM extension on an Azure Arc-enabled
server:

PowerShell

# Build settings
$settings = @{
secretsManagementSettings = @{
observedCertificates = @(
"observedCert1"
)
certificateStoreLocation = "myMachineName" # For Linux use
"/var/lib/waagent/Microsoft.Azure.KeyVault.Store/"
certificateStore = "myCertificateStoreName"
pollingIntervalInS = "pollingInterval"
}
authenticationSettings = @{
msiEndpoint = "http://localhost:40342/metadata/identity"
}
}

$resourceGroup = "resourceGroupName"
$machineName = "myMachineName"
$location = "regionName"

# Start the deployment

New-AzConnectedMachineExtension -ResourceGroupName $resourceGroup -
Location $location -MachineName $machineName -Name "KeyVaultForWindows or
KeyVaultforLinux" -Publisher "Microsoft.Azure.KeyVault" -ExtensionType
"KeyVaultforWindows or KeyVaultforLinux" -Setting $settings

Datadog VM extension
The following example enables the Datadog VM extension on an Azure Arc-enabled
server:

Azure PowerShell

$resourceGroup = "resourceGroupName"
$machineName = "machineName"
$location = "machineRegion"
$osType = "Windows" # change to Linux if appropriate
$settings = @{
# change to your preferred Datadog site
site = "us3.datadoghq.com"
}
$protectedSettings = @{
 # change to your Datadog API key
api_key = "APIKEY"
}

New-AzConnectedMachineExtension -ResourceGroupName $resourceGroup -Location

$location -MachineName $machineName -Name "Datadog$($osType)Agent" -
Publisher "Datadog.Agent" -ExtensionType "Datadog$($osType)Agent" -Setting
$settings -ProtectedSetting $protectedSettings

List extensions installed

To get a list of the VM extensions on your Azure Arc-enabled server, use Get-
AzConnectedMachineExtension with the -MachineName and -ResourceGroupName
parameters.

Example:

PowerShell

Get-AzConnectedMachineExtension -ResourceGroupName myResourceGroup -

MachineName myMachineName

Name Location PropertiesType ProvisioningState

---- -------- -------------- -----------------
custom westus2 CustomScriptExtension Succeeded

Update extension configuration

To reconfigure an installed extension, you can use the Update-
AzConnectedMachineExtension cmdlet with the -Name , -MachineName , -
ResourceGroupName , and -Settings parameters.

Refer to the reference article for the cmdlet to understand the different methods to
provide the changes you want to the extension.

Upgrade extension
When a new version of a supported VM extension is released, you can upgrade it to that
latest release. To upgrade a VM extension, use Update-AzConnectedExtension with the
-MachineName , -ResourceGroupName , and -ExtensionTarget parameters.

For the -ExtensionTarget parameter, you need to specify the extension and the latest
version available. To find out what the latest version available is, you can get this
information from the Extensions page for the selected Arc-enabled server in the Azure
portal, or by running Get-AzVMExtensionImage. You may specify multiple extensions in
a single upgrade request by providing a comma-separated list of extensions, defined by
their publisher and type (separated by a period) and the target version for each
extension, as shown in the example below.

To upgrade the Log Analytics agent extension for Windows that has a newer version
available, run the following command:

PowerShell

Update-AzConnectedExtension -MachineName "myMachineName" -ResourceGroupName

"myResourceGroup" -ExtensionTarget
'{\"Microsoft.EnterpriseCloud.Monitoring.MicrosoftMonitoringAgent\":
{\"targetVersion\":\"1.0.18053.0\"}}'

You can review the version of installed VM extensions at any time by running the
command Get-AzConnectedMachineExtension. The TypeHandlerVersion property value
represents the version of the extension.

Remove extensions
To remove an installed VM extension on your Azure Arc-enabled server, use Remove-
AzConnectedMachineExtension with the -Name , -MachineName and -ResourceGroupName
parameters.

For example, to remove the Log Analytics VM extension for Linux, run the following
command:

PowerShell

Remove-AzConnectedMachineExtension -MachineName myMachineName -

ResourceGroupName myResourceGroup -Name OmsAgentforLinux

Next steps
You can deploy, manage, and remove VM extensions using the Azure CLI, from the
Azure portal, or Azure Resource Manager templates.

Troubleshooting information can be found in the Troubleshoot VM extensions

guide.
Enable Azure VM extensions by using
ARM template
Article • 03/09/2023

This article shows you how to use an Azure Resource Manager template (ARM template)
to deploy Azure VM extensions, supported by Azure Arc-enabled servers.

VM extensions can be added to an Azure Resource Manager template and executed

with the deployment of the template. With the VM extensions supported by Azure Arc-
enabled servers, you can deploy the supported VM extension on Linux or Windows
machines using Azure PowerShell. Each sample below includes a template file and a
parameters file with sample values to provide to the template.

７ Note

While multiple extensions can be batched together and processed, they are
installed serially. Once the first extension installation is complete, installation of the
next extension is attempted.

７ Note

Azure Arc-enabled servers does not support deploying and managing VM

extensions to Azure virtual machines. For Azure VMs, see the following VM
extension overview article.

Deploy the Log Analytics VM extension

To easily deploy the Log Analytics agent, the following sample is provided to install the
agent on either Windows or Linux.

Template file for Linux

JSON

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json",
"contentVersion": "1.0.0.0",
"parameters": {
 "vmName": {
"type": "string"
},
"location": {
"type": "string"
},
"workspaceId": {
"type": "string"
},
"workspaceKey": {
"type": "string"
}
},
"resources": [
{
"name": "[concat(parameters('vmName'),'/OMSAgentForLinux')]",
"type": "Microsoft.HybridCompute/machines/extensions",
"location": "[parameters('location')]",
"apiVersion": "2022-03-10",
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "OmsAgentForLinux",
"enableAutomaticUpgrade": true,
"settings": {
"workspaceId": "[parameters('workspaceId')]"
},
"protectedSettings": {
"workspaceKey": "[parameters('workspaceKey')]"
}
}
}
]
}

Template file for Windows

JSON

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string"
},
"location": {
"type": "string"
},
"workspaceId": {
"type": "string"
},
 "workspaceKey": {
"type": "string"
}
},
"resources": [
{
"name": "
[concat(parameters('vmName'),'/MicrosoftMonitoringAgent')]",
"type": "Microsoft.HybridCompute/machines/extensions",
"location": "[parameters('location')]",
"apiVersion": "2022-03-10",
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "MicrosoftMonitoringAgent",
"autoUpgradeMinorVersion": true,
"enableAutomaticUpgrade": true,
"settings": {
"workspaceId": "[parameters('workspaceId')]"
},
"protectedSettings": {
"workspaceKey": "[parameters('workspaceKey')]"
}
}
}
]
}

Parameter file
JSON

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"value": "<vmName>"
},
"location": {
"value": "<region>"
},
"workspaceId": {
"value": "<MyWorkspaceID>"
},
"workspaceKey": {
"value": "<MyWorkspaceKey>"
}
}
}
Save the template and parameter files to disk, and edit the parameter file with the
appropriate values for your deployment. You can then install the extension on all the
connected machines within a resource group with the following command. The
command uses the TemplateFile parameter to specify the template and the
TemplateParameterFile parameter to specify a file that contains parameters and
parameter values.

PowerShell

New-AzResourceGroupDeployment -ResourceGroupName "ContosoEngineering" -

TemplateFile "D:\Azure\Templates\LogAnalyticsAgent.json" -
TemplateParameterFile "D:\Azure\Templates\LogAnalyticsAgentParms.json"

Deploy the Custom Script extension

To use the Custom Script extension, the following sample is provided to run on
Windows and Linux. If you are unfamiliar with the Custom Script extension, see Custom
Script extension for Windows or Custom Script extension for Linux. There are a couple of
differing characteristics that you should understand when using this extension with
hybrid machines:

The list of supported operating systems with the Azure VM Custom Script
extension is not applicable to Azure Arc-enabled servers. The list of supported OSs
for Azure Arc-enabled servers can be found here.

Configuration details regarding Azure Virtual Machine Scale Sets or Classic VMs
are not applicable.

If your machines need to download a script externally and can only communicate
through a proxy server, you need to configure the Connected Machine agent to set
the proxy server environmental variable.

The Custom Script extension configuration specifies things like script location and the
command to be run. This configuration is specified in an Azure Resource Manager
template, provided below for both Linux and Windows hybrid machines.

Template file for Linux

JSON

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string"
},
"location": {
"type": "string"
},
"fileUris": {
"type": "array"
},
"commandToExecute": {
"type": "securestring"
}
},
"resources": [
{
"name": "[concat(parameters('vmName'),'/CustomScript')]",
"type": "Microsoft.HybridCompute/machines/extensions",
"location": "[parameters('location')]",
"apiVersion": "2022-03-10",
"properties": {
"publisher": "Microsoft.Azure.Extensions",
"type": "CustomScript",
"autoUpgradeMinorVersion": true,
"settings": {},
"protectedSettings": {
"commandToExecute": "[parameters('commandToExecute')]",
"fileUris": "[parameters('fileUris')]"
}
}
}
]
}

Template file for Windows

JSON

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string"
},
"location": {
"type": "string"
},
"fileUris": {
"type": "string"
 },
"arguments": {
"type": "securestring",
"defaultValue": " "
}
},
"variables": {
"UriFileNamePieces": "[split(parameters('fileUris'), '/')]",
"firstFileNameString": "[variables('UriFileNamePieces')
[sub(length(variables('UriFileNamePieces')), 1)]]",
"firstFileNameBreakString": "
[split(variables('firstFileNameString'), '?')]",
"firstFileName": "[variables('firstFileNameBreakString')[0]]"
},
"resources": [
{
"name": "
[concat(parameters('vmName'),'/CustomScriptExtension')]",
"type": "Microsoft.HybridCompute/machines/extensions",
"location": "[parameters('location')]",
"apiVersion": "2022-03-10",
"properties": {
"publisher": "Microsoft.Compute",
"type": "CustomScriptExtension",
"autoUpgradeMinorVersion": true,
"settings": {
"fileUris": "[split(parameters('fileUris'), ' ')]"
},
"protectedSettings": {
"commandToExecute": "[concat ('powershell -
ExecutionPolicy Unrestricted -File ', variables('firstFileName'), ' ',
parameters('arguments'))]"
}
}
}
]
}

Parameter file
JSON

{
"$schema": "https://schema.management.azure.com/schemas/0.1.2-
preview/CreateUIDefinition.MultiVm.json#",
"handler": "Microsoft.Azure.CreateUIDef",
"version": "0.1.2-preview",
"parameters": {
"basics": [
{}
],
"steps": [
 {
"name": "customScriptExt",
"label": "Add Custom Script Extension",
"elements": [
{
"name": "fileUris",
"type": "Microsoft.Common.FileUpload",
"label": "Script files",
"toolTip": "The script files that will be downloaded to the
virtual machine.",
"constraints": {
"required": false
},
"options": {
"multiple": true,
"uploadMode": "url"
},
"visible": true
},
{
"name": "commandToExecute",
"type": "Microsoft.Common.TextBox",
"label": "Command",
"defaultValue": "sh script.sh",
"toolTip": "The command to execute, for example: sh script.sh",
"constraints": {
"required": true
},
"visible": true
}
]
}
],
"outputs": {
"vmName": "[vmName()]",
"location": "[location()]",
"fileUris": "[steps('customScriptExt').fileUris]",
"commandToExecute": "[steps('customScriptExt').commandToExecute]"
}
}
}

Deploy the Dependency agent extension

To use the Azure Monitor Dependency agent extension, the following sample is
provided to run on Windows and Linux. If you are unfamiliar with the Dependency
agent, see Overview of Azure Monitor agents.

Template file for Linux

 JSON

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string",
"metadata": {
"description": "The name of existing Linux machine."
}
}
},
"resources": [
{
"type": "Microsoft.HybridCompute/machines/extensions",
"name": "[concat(parameters('vmName'),'/DAExtension')]",
"apiVersion": "2022-03-10",
"location": "[resourceGroup().location]",
"dependsOn": [
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "DependencyAgentLinux",
"enableAutomaticUpgrade": true
}
}
],
"outputs": {
}
}

Template file for Windows

JSON

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string",
"metadata": {
"description": "The name of existing Windows machine."
}
}
},
"resources": [
{
"type": "Microsoft.HybridCompute/machines/extensions",
 "name": "[concat(parameters('vmName'),'/DAExtension')]",
"apiVersion": "2022-03-10",
"location": "[resourceGroup().location]",
"dependsOn": [
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "DependencyAgentWindows",
"enableAutomaticUpgrade": true
}
}
],
"outputs": {
}
}

Template deployment
Save the template file to disk. You can then deploy the extension to the connected
machine with the following command.

PowerShell

New-AzResourceGroupDeployment -ResourceGroupName "ContosoEngineering" -

TemplateFile "D:\Azure\Templates\DependencyAgent.json"

Deploy Azure Key Vault VM extension (preview)

The following JSON shows the schema for the Key Vault VM extension (preview). The
extension does not require protected settings - all its settings are considered public
information. The extension requires a list of monitored certificates, polling frequency,
and the destination certificate store. Specifically:

Template file for Linux

JSON

{
"$schema": "https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string"
},
"location": {
 "type": "string"
},
"autoUpgradeMinorVersion":{
"type": "bool"
},
"pollingIntervalInS":{
"type": "int"
},
"certificateStoreName":{
"type": "string"
},
"certificateStoreLocation":{
"type": "string"
},
"observedCertificates":{
"type": "string"
},
"msiEndpoint":{
"type": "string"
},
"msiClientId":{
"type": "string"
}
},
"resources": [
{
"type": "Microsoft.HybridCompute/machines/extensions",
"name": "[concat(parameters('vmName'),'/KVVMExtensionForLinux')]",
"apiVersion": "2022-03-10",
"location": "[parameters('location')]",
"properties": {
"publisher": "Microsoft.Azure.KeyVault",
"type": "KeyVaultForLinux",
"enableAutomaticUpgrade": true,
"settings": {
"secretsManagementSettings": {
"pollingIntervalInS": <polling interval in seconds, e.g. "3600">,
"certificateStoreName": <ignored on linux>,
"certificateStoreLocation": <disk path where certificate is
stored, default: "/var/lib/waagent/Microsoft.Azure.KeyVault">,
"observedCertificates": <list of KeyVault URIs representing
monitored certificates, e.g.:
"https://myvault.vault.azure.net/secrets/mycertificate"
},
"authenticationSettings": {
"msiEndpoint": "http://localhost:40342/metadata/identity"
}
}
}
}
]
}
Template file for Windows
JSON

{
"$schema": "https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string"
},
"location": {
"type": "string"
},
"autoUpgradeMinorVersion":{
"type": "bool"
},
"pollingIntervalInS":{
"type": "int"
},
"certificateStoreName":{
"type": "string"
},
"linkOnRenewal":{
"type": "bool"
},
"certificateStoreLocation":{
"type": "string"
},
"requireInitialSync":{
"type": "bool"
},
"observedCertificates":{
"type": "string"
},
"msiEndpoint":{
"type": "string"
},
"msiClientId":{
"type": "string"
}
},
"resources": [
{
"type": "Microsoft.HybridCompute/machines/extensions",
"name": "[concat(parameters('vmName'),'/KVVMExtensionForWindows')]",
"apiVersion": "2022-03-10",
"location": "[parameters('location')]",
"properties": {
"publisher": "Microsoft.Azure.KeyVault",
"type": "KeyVaultForWindows",
"enableAutomaticUpgrade": true,
"settings": {
 "secretsManagementSettings": {
"pollingIntervalInS": "3600",
"certificateStoreName": <certificate store name, e.g.: "MY">,
"linkOnRenewal": <Only Windows. This feature ensures s-channel
binding when certificate renews, without necessitating a re-deployment.
e.g.: false>,
"certificateStoreLocation": <certificate store location, currently
it works locally only e.g.: "LocalMachine">,
"requireInitialSync": <initial synchronization of certificates
e.g.: true>,
"observedCertificates": <list of KeyVault URIs representing
monitored certificates, e.g.: "https://myvault.vault.azure.net"
},
"authenticationSettings": {
"msiEndpoint": "http://localhost:40342/metadata/identity"
}
}
}
}
]
}

７ Note

Your observed certificates URLs should be of the form

https://myVaultName.vault.azure.net/secrets/myCertName .

This is because the /secrets path returns the full certificate, including the private
key, while the /certificates path does not. More information about certificates
can be found here: Key Vault Certificates

Template deployment
Save the template file to disk. You can then deploy the extension to the connected
machine with the following command.

７ Note

The VM extension would require a system-assigned identity to be assigned to

authenticate to Key vault. See How to authenticate to Key Vault using managed
identity for Windows and Linux Azure Arc-enabled servers.

PowerShell
 New-AzResourceGroupDeployment -ResourceGroupName "ContosoEngineering" -
TemplateFile "D:\Azure\Templates\KeyVaultExtension.json"

Next steps
You can deploy, manage, and remove VM extensions using the Azure PowerShell,
from the Azure portal, or the Azure CLI.

Troubleshooting information can be found in the Troubleshoot VM extensions

guide.
Enable Azure VM extensions using Red
Hat Ansible automation
Article • 05/23/2023

This article shows you how to deploy VM extensions to Azure Arc-enabled servers at
scale using the Red Hat Ansible Automation Platform. The examples in this article rely
on content developed and incubated by Red Hat through the Ansible Content Lab for
Cloud Content . This article also uses the Azure Infrastructure Configuration Demo
collection. This collection contains many roles and playbooks that are pertinent to this
article, including the following:

File or Folder Description

playbook_enable_arc_extension.yml Playbook that's used as a job template to enable Azure Arc

extensions.

playbook_disable_arc- Playbook that's used as a job template to disable Azure Arc

extension.yml extensions.

roles/arc Ansible role that contains the reusable automation

leveraged by the playbooks.

７ Note

The examples in this article target Linux hosts.

Prerequisites

Automation controller 2.x

This article is applicable to both self-managed Ansible Automation Platform and Red
Hat Ansible Automation Platform on Microsoft Azure.

Automation execution environment

To use the examples in this article, you'll need an automation execution environment
with both the Azure Collection and the Azure CLI installed, since both are required to
run the automation.
If you don't have an automation execution environment that meets these requirements,
you can use this example .

See the Red Hat Ansible documentation for more information about building and
configuring automation execution environments.

Azure Resource Manager credential

A working account credential configured in Ansible Automation Platform for the Azure
Resource Manager is required. This credential is used by Ansible Automation Platform to
authenticate operations using the Azure Collection and the Azure CLI.

Configuring the content

To use the Azure Infrastructure Configuration Demo collection in Automation
Controller, follow the steps below to set up a project with the repository:

1. Log in to automation controller.

2. In the left menu, select Projects.

3. Select Add, and then complete the fields of the form as follows:

Name: Content Lab - Azure Infrastructure Configuration Collection

Automation Environment: (select with the Azure Collection and CLI instead)

Source Control Type: Git

Source Control URL: https://github.com/ansible-content-

lab/azure.infrastructure_config_demos.git
 4. Select Save.

Once saved, the project should be synchronized with the automation controller.

Create job templates

The project you created from the Azure Infrastructure Configuration Demo collection
contains example playbooks that implement the reusable content implemented in roles.
You can learn more about the individual roles in the collection by viewing the README
file included with the collection. Within the collection, the following mapping has
been performed to make it easy to identify which extension you want to enable.

Extension Extension Variable Name

Microsoft Defender for Cloud integrated vulnerability scanner microsoft_defender

Custom Script extension custom_script

Log Analytics Agent log_analytics_agent

Azure Monitor for VMs (insights) azure_monitor_for-vms

Azure Key Vault Certificate Sync azure_key_vault

Azure Monitor Agent azure_monitor_agent

Azure Automation Hybrid Runbook Worker extension azure_hybrid_rubook

You'll need to create templates in order to enable and disable Arc-enabled server VM
extensions (explained below).

７ Note
 There are additional VM extensions not included in this collection, outlined in
Virtual machine extension management with Azure Arc-enabled servers.

Enable Azure Arc VM extensions

This template is responsible for enabling an Azure Arc-enabled server VM extension on
the hosts you identify.

） Important

Arc only supports enabling or disabling a single extension at a time, so this process
can take some time. If you attempt to enable or disable another VM extension with
this template prior to Azure completing this process, the template reports an error.

Once the job template has run, it may take minutes to hours for each machine to
report that the extension is operational. Once the extension is operational, then this
job template can be run again with another extension and will not report an error.

Follow the steps below to create the template:

1. On the right menu, select Templates.

2. Select Add.

3. Select Add job template, then complete the fields of the form as follows:

Name: Content Lab - Enable Arc Extension

Job Type: Run

Inventory: localhost

Project: Content Lab - Azure Infrastructure Configuration Collection

Playbook: playbook_enable_arc-extension.yml

Credentials:

Your Azure Resource Manager credential

Variables:

Bash
 ---
resource_group: <your_resource_group>
region: <your_region>
arc_hosts:
<first_arc_host>
<second_arc_host>
extension: microsoft_defender

７ Note

Change the resource group and arc_hosts to match the names of your Azure
resources. If you have a large number of Arc hosts, use Jinja2 formatting to
extract the list from your inventory sources.

4. Check the Prompt on launch box for Variables so you can change the extension at
run time.

5. Select Save.

Disable Azure Arc VM extensions

This template is responsible for disabling an Azure Arc-enabled server VM extension on
the hosts you identify. Follow the steps below to create the template:

1. On the right menu, select Templates.

2. Select Add.

3. Select Add job template, then complete the fields of the form as follows:

Name: Content Lab - Disable Arc Extension

Job Type: Run

Inventory: localhost

Project: Content Lab - Azure Infrastructure Configuration Collection

Playbook: playbook_disable_arc-extension.yml

Credentials:

Your Azure Resource Manager credential

Variables:
 Bash

---
resource_group: <your_resource_group>
region: <your_region>
arc_hosts:
<first_arc_host>
<second_arc_host>
extension: microsoft_defender

７ Note

Change the resource group and arc_hosts to match the names of your Azure
resources. If you have a large number of Arc hosts, use Jinja2 formatting to
extract the list from your inventory sources.

4. Check the Prompt on launch box for Variables so you can change the extension at
run time.

5. Select Save.

Run the automation

Now that you have the job templates created, you can enable or disable Arc extensions
by simply changing the name of the extension variable. Azure Arc extensions are
mapped in the "arc" role in this file .

When you click the “launch” 🚀 icon, the template will ask you to confirm that the
variables are accurate. For example, to enable the Microsoft Defender extension, ensure
that the extension variable is set to microsoft_defender . Then, click Next and then
Launch to run the template:
If no errors are reported, the extension will be enabled and active on the applicable
servers after a short period of time. You can then proceed to enable (or disable) other
extensions by changing the extension variable in the template.

Next steps
You can deploy, manage, and remove VM extensions using the Azure PowerShell,
from the Azure portal, or the Azure CLI.

Troubleshooting information can be found in the Troubleshoot VM extensions

guide.
Automatic extension upgrade for Azure
Arc-enabled servers
Article • 11/03/2023

Automatic extension upgrade is available for Azure Arc-enabled servers that have
supported VM extensions installed. Automatic extension upgrades reduce the amount
of operational overhead for you by scheduling the installation of new extension versions
when they become available. The Azure Connected Machine agent takes care of
upgrading the extension (preserving its settings along the way) and automatically rolling
back to the previous version if something goes wrong during the upgrade process.

Automatic extension upgrade has the following features:

You can opt in and out of automatic upgrades at any time. By default, all
extensions are opted into automatic extension upgrades.
Each supported extension is enrolled individually, and you can choose which
extensions to upgrade automatically.
Supported in all Azure Arc regions.

How does automatic extension upgrade work?

The extension upgrade process replaces the existing Azure VM extension version
supported by Azure Arc-enabled servers with a new version of the same extension when
published by the extension publisher. This feature is enabled by default for all
extensions you deploy the Azure Arc-enabled servers unless you explicitly opt-out of
automatic upgrades.

Availability-first updates
The availability-first model for platform orchestrated updates ensures that availability
configurations in Azure are respected across multiple availability levels.

For a group of Arc-enabled servers undergoing an update, the Azure platform will
orchestrate updates following the model described in the Automation Extension
Upgrade. However, there are some notable differences between Arc-enabled servers
and Azure VMs:

Across regions:

Geo-paired regions aren't applicable.

Within a region:

Availability Zones aren't applicable.

Machines are batched on a best effort basis to avoid concurrent updates for all
machines registered with Arc-enabled servers in a subscription.

Automatic rollback and retries

If an extension upgrade fails, Azure will try to repair the extension by performing the
following actions:

1. The Azure Connected Machine agent will automatically reinstall the last known
good version of the extension to attempt to restore functionality.
2. If the rollback is successful, the extension status will show as Succeeded and the
extension will be added to the automatic upgrade queue again. The next upgrade
attempt can be as soon as the next hour and will continue until the upgrade is
successful.
3. If the rollback fails, the extension status will show as Failed and the extension will
no longer function as intended. You'll need to remove and reinstall the extension
to restore functionality.

If you continue to have trouble upgrading an extension, you can disable automatic
extension upgrade to prevent the system from trying again while you troubleshoot the
issue. You can enable automatic extension upgrade again when you're ready.

Timing of automatic extension upgrades

When a new version of a VM extension is published, it becomes available for installation
and manual upgrade on Arc-enabled servers. For servers that already have the extension
installed and automatic extension upgrade enabled, it might take 5 - 8 weeks for every
server with that extension to get the automatic upgrade. Upgrades are issued in batches
across Azure regions and subscriptions, so you might see the extension get upgraded
on some of your servers before others. If you need to upgrade an extension
immediately, follow the guidance to manually upgrade extensions using the Azure
portal, Azure PowerShell or Azure CLI.

Extension versions fixing critical security vulnerabilities are rolled out much faster. These
automatic upgrades happen using a specialized roll out process which can take 1 - 3
weeks to automatically upgrade every server with that extension. Azure handles
identifying which extension version should be rollout quickly to ensure all servers are
protected. If you need to upgrade the extension immediately, follow the guidance to
manually upgrade extensions using the Azure portal, Azure PowerShell or Azure CLI.
Supported extensions
Automatic extension upgrade supports the following extensions:

Azure Monitor agent - Linux and Windows

Log Analytics agent (OMS agent) - Linux only
Dependency agent – Linux and Windows
Azure Security agent - Linux and Windows
Key Vault Extension - Linux only
Azure Update Manager - Linux and Windows
Azure Automation Hybrid Runbook Worker - Linux and Windows
Azure Arc-enabled SQL Server agent - Linux and Windows

More extensions will be added over time. Extensions that do not support automatic
extension upgrade today are still configured to enable automatic upgrades by default.
This setting will have no effect until the extension publisher chooses to support
automatic upgrades.

Manage automatic extension upgrade

Automatic extension upgrade is enabled by default when you install extensions on
Azure Arc-enabled servers. To enable automatic upgrades for an existing extension, you
can use Azure CLI or Azure PowerShell to set the enableAutomaticUpgrade property on
the extension to true . You'll need to repeat this process for every extension where
you'd like to enable or disable automatic upgrades.

Azure portal

Use the following steps to configure automatic extension upgrades in using the
Azure portal:

1. Go to the Azure portal navigate to Machines - Azure Arc.

2. Select the applicable server.
3. In the left pane, select the Extensions tab to see a list of all extensions
installed on the server.
 4. The Automatic upgrade column in the table shows whether upgrades are
enabled, disabled, or not supported for each extension. Select the checkbox
next to the extensions for which you want automatic upgrades enabled, then
select Enable automatic upgrade to turn on the feature. Select Disable
automatic upgrade to turn off the feature.

Extension upgrades with multiple extensions

A machine managed by Arc-enabled servers can have multiple extensions with
automatic extension upgrade enabled. The same machine can also have other
extensions without automatic extension upgrade enabled.

If multiple extension upgrades are available for a machine, the upgrades might be
batched together, but each extension upgrade is applied individually on a machine. A
failure on one extension doesn't impact the other extension(s) to be upgraded. For
example, if two extensions are scheduled for an upgrade, and the first extension
upgrade fails, the second extension will still be upgraded.

Check automatic extension upgrade history

You can use the Azure Activity Log to identify extensions that were automatically
upgraded. You can find the Activity Log tab on individual Azure Arc-enabled server
resources, resource groups, and subscriptions. Extension upgrades are identified by the
Upgrade Extensions on Azure Arc machines

(Microsoft.HybridCompute/machines/upgradeExtensions/action) operation.

To view automatic extension upgrade history, search for the Azure Activity Log in the
Azure portal. Select Add filter and choose the Operation filter. For the filter criteria,
search for "Upgrade Extensions on Azure Arc machines" and select that option. You can
optionally add a second filter for Event initiated by and set "Azure Regional Service
Manager" as the filter criteria to only see automatic upgrade attempts and exclude
upgrades manually initiated by users.

Next steps
You can deploy, manage, and remove VM extensions using the Azure CLI,
PowerShell, or Azure Resource Manager templates.

Troubleshooting information can be found in the Troubleshoot VM extensions

guide.
Authenticate against Azure resources
with Azure Arc-enabled servers
Article • 10/12/2023

Applications or processes running directly on an Azure Arc-enabled servers can use

managed identities to access other Azure resources that support Microsoft Entra ID-
based authentication. An application can obtain an access token representing its
identity, which is system-assigned for Azure Arc-enabled servers, and use it as a 'bearer'
token to authenticate itself to another service.

Refer to the managed identity overview documentation for a detailed description of

managed identities, and understand the distinction between system-assigned and user-
assigned identities.

In this article, we show you how a server can use a system-assigned managed identity to
access Azure Key Vault. Serving as a bootstrap, Key Vault makes it possible for your
client application to then use a secret to access resources not secured by Microsoft
Entra ID. For example, TLS/SSL certificates used by your IIS web servers can be stored in
Azure Key Vault, and securely deploy the certificates to Windows or Linux servers
outside of Azure.

Security overview
While onboarding your server to Azure Arc-enabled servers, several actions are
performed to configure using a managed identity, similar to what is performed for an
Azure VM:

Azure Resource Manager receives a request to enable the system-assigned

managed identity on the Azure Arc-enabled server.

Azure Resource Manager creates a service principal in Microsoft Entra ID for the
identity of the server. The service principal is created in the Microsoft Entra tenant
that's trusted by the subscription.

Azure Resource Manager configures the identity on the server by updating the
Azure Instance Metadata Service (IMDS) identity endpoint for Windows or Linux
with the service principal client ID and certificate. The endpoint is a REST endpoint
accessible only from within the server using a well-known, non-routable IP address.
This service provides a subset of metadata information about the Azure Arc-
enabled server to help manage and configure it.
The environment of a managed-identity-enabled server will be configured with the
following variables on a Windows Azure Arc-enabled server:

IMDS_ENDPOINT: The IMDS endpoint IP address http://localhost:40342 for

Azure Arc-enabled servers.

IDENTITY_ENDPOINT: the localhost endpoint corresponding to service's managed

identity http://localhost:40342/metadata/identity/oauth2/token .

Your code that's running on the server can request a token from the Azure Instance
Metadata service endpoint, accessible only from within the server.

The system environment variable IDENTITY_ENDPOINT is used to discover the identity

endpoint by applications. Applications should try to retrieve IDENTITY_ENDPOINT and
IMDS_ENDPOINT values and use them. Applications with any access level are allowed to
make requests to the endpoints. Metadata responses are handled as normal and given
to any process on the machine. However, when a request is made that would expose a
token, we require the client to provide a secret to attest that they are able to access data
only available to higher-privileged users.

Prerequisites
An understanding of Managed identities.

On Windows, you must be a member of the local Administrators group or the

Hybrid Agent Extension Applications group.

On Linux, you must be a member of the himds group.

A server connected and registered with Azure Arc-enabled servers.

You are a member of the Owner group in the subscription or resource group, in
order to perform required resource creation and role management steps.

An Azure Key Vault to store and retrieve your credential, and assign the Azure Arc
identity access to the KeyVault.
If you don't have a Key Vault created, see Create Key Vault.
To configure access by the managed identity used by the server, see Grant
access for Linux or Grant access for Windows. For step number 5, you are going
to enter the name of the Azure Arc-enabled server. To complete this using
PowerShell, see Assign an access policy using PowerShell.

Acquiring an access token using REST API

The method to obtain and use a system-assigned managed identity to authenticate with
Azure resources is similar to how it is performed with an Azure VM.

For an Azure Arc-enabled Windows server, using PowerShell, you invoke the web
request to get the token from the local host in the specific port. Specify the request
using the IP address or the environmental variable IDENTITY_ENDPOINT.

PowerShell

$apiVersion = "2020-06-01"
$resource = "https://management.azure.com/"
$endpoint = "{0}?resource={1}&api-version={2}" -f
$env:IDENTITY_ENDPOINT,$resource,$apiVersion
$secretFile = ""
try
{
Invoke-WebRequest -Method GET -Uri $endpoint -Headers @{Metadata='True'}
-UseBasicParsing
}
catch
{
$wwwAuthHeader = $_.Exception.Response.Headers["WWW-Authenticate"]
if ($wwwAuthHeader -match "Basic realm=.+")
{
$secretFile = ($wwwAuthHeader -split "Basic realm=")[1]
}
}
Write-Host "Secret file path: " $secretFile`n
$secret = cat -Raw $secretFile
$response = Invoke-WebRequest -Method GET -Uri $endpoint -Headers
@{Metadata='True'; Authorization="Basic $secret"} -UseBasicParsing
if ($response)
{
$token = (ConvertFrom-Json -InputObject $response.Content).access_token
Write-Host "Access token: " $token
}

The following response is an example that is returned:

For an Azure Arc-enabled Linux server, using Bash, you invoke the web request to get
the token from the local host in the specific port. Specify the following request using the
IP address or the environmental variable IDENTITY_ENDPOINT. To complete this step,
you need an SSH client.

Bash

CHALLENGE_TOKEN_PATH=$(curl -s -D - -H Metadata:true
"http://127.0.0.1:40342/metadata/identity/oauth2/token?api-version=2019-11-
01&resource=https%3A%2F%2Fmanagement.azure.com" | grep Www-Authenticate |
cut -d "=" -f 2 | tr -d "[:cntrl:]")
CHALLENGE_TOKEN=$(cat $CHALLENGE_TOKEN_PATH)
if [ $? -ne 0 ]; then
echo "Could not retrieve challenge token, double check that this command
is run with root privileges."
else
curl -s -H Metadata:true -H "Authorization: Basic $CHALLENGE_TOKEN"
"http://127.0.0.1:40342/metadata/identity/oauth2/token?api-version=2019-11-
01&resource=https%3A%2F%2Fmanagement.azure.com"
fi

The following response is an example that is returned:

The response includes the access token you need to access any resource in Azure. To
complete the configuration to authenticate to Azure Key Vault, see Access Key Vault with
Windows or Access Key Vault with Linux.

Next steps
To learn more about Azure Key Vault, see Key Vault overview.

Learn how to assign a managed identity access to a resource using PowerShell or

using the Azure CLI.
Managing and maintaining the
Connected Machine agent
Article • 06/07/2023

After initial deployment of the Azure Connected Machine agent, you may need to
reconfigure the agent, upgrade it, or remove it from the computer. These routine
maintenance tasks can be done manually or through automation (which reduces both
operational error and expenses). This article describes the operational aspects of the
agent. See the azcmagent CLI documentation for command line reference information.

Installing a specific version of the agent

Microsoft recommends using the most recent version of the Azure Connected Machine
agent for the best experience. However, if you need to run an older version of the agent
for any reason, you can follow these instructions to install a specific version of the agent.

Windows

Links to the current and previous releases of the Windows agents are available
below the heading of each release note. If you're looking for an agent version that's
more than 6 months old, check out the release notes archive.

Upgrade the agent

The Azure Connected Machine agent is updated regularly to address bug fixes, stability
enhancements, and new functionality. Azure Advisor identifies resources that are not
using the latest version of the machine agent and recommends that you upgrade to the
latest version. It will notify you when you select the Azure Arc-enabled server by
presenting a banner on the Overview page or when you access Advisor through the
Azure portal.

The Azure Connected Machine agent for Windows and Linux can be upgraded to the
latest release manually or automatically depending on your requirements. Installing,
upgrading, or uninstalling the Azure Connected Machine Agent will not require you to
restart your server.

The following table describes the methods supported to perform the agent upgrade:
 Operating system Upgrade method

Windows Manually
Microsoft Update

Ubuntu apt

SUSE Linux Enterprise Server zypper

RedHat Enterprise, Amazon, CentOS Linux yum

Windows agent
The latest version of the Azure Connected Machine agent for Windows-based machines
can be obtained from:

Microsoft Update

Microsoft Update Catalog

Microsoft Download Center

Microsoft Update configuration

The recommended way of keeping the Windows agent up to date is to automatically

obtain the latest version through Microsoft Update. This allows you to utilize your
existing update infrastructure (such as Microsoft Configuration Manager or Windows
Server Update Services) and include Azure Connected Machine agent updates with your
regular OS update schedule.

Windows Server doesn't check for updates in Microsoft Update by default. To receive
automatic updates for the Azure Connected Machine Agent, you must configure the
Windows Update client on the machine to check for other Microsoft products.

For Windows Servers that belong to a workgroup and connect to the Internet to check
for updates, you can enable Microsoft Update by running the following commands in
PowerShell as an administrator:

PowerShell

$ServiceManager = (New-Object -com "Microsoft.Update.ServiceManager")

$ServiceID = "7971f918-a847-4430-9279-4a52d1efe18d"
$ServiceManager.AddService2($ServiceId,7,"")
For Windows Servers that belong to a domain and connect to the Internet to check for
updates, you can configure this setting at-scale using Group Policy:

1. Sign into a computer used for server administration with an account that can
manage Group Policy Objects (GPO) for your organization.

2. Open the Group Policy Management Console.

3. Expand the forest, domain, and organizational unit(s) to select the appropriate
scope for your new GPO. If you already have a GPO you wish to modify, skip to
step 6.

4. Right-click the container and select Create a GPO in this domain, and Link it
here....

5. Provide a name for your policy such as "Enable Microsoft Update".

6. Right-click the policy and select Edit.

7. Navigate to Computer Configuration > Administrative Templates > Windows

Components > Windows Update.

8. Select the Configure Automatic Updates setting to edit it.

9. Select the Enabled radio button to allow the policy to take effect.

10. At the bottom of the Options section, check the box for Install updates for other
Microsoft products at the bottom.

11. Select OK.

The next time computers in your selected scope refresh their policy, they will start to
check for updates in both Windows Update and Microsoft Update.

For organizations that use Microsoft Configuration Manager (MECM) or Windows Server
Update Services (WSUS) to deliver updates to their servers, you need to configure WSUS
to synchronize the Azure Connected Machine Agent packages and approve them for
installation on your servers. Follow the guidance for Windows Server Update Services or
MECM to add the following products and classifications to your configuration:

Product Name: Azure Connected Machine Agent (select all 3 sub-options)

Classifications: Critical Updates, Updates

Once the updates are being synchronized, you can optionally add the Azure Connected
Machine Agent product to your auto-approval rules so your servers automatically stay
up to date with the latest agent software.
To manually upgrade using the Setup Wizard
1. Sign in to the computer with an account that has administrative rights.

2. Download the latest agent installer from

https://aka.ms/AzureConnectedMachineAgent

3. Run AzureConnectedMachineAgent.msi to start the Setup Wizard.

If the Setup Wizard discovers a previous version of the agent, it will upgrade it
automatically. When the upgrade completes, the Setup Wizard closes automatically.

To upgrade from the command line

If you're unfamiliar with the command-line options for Windows Installer packages,
review Msiexec standard command-line options and Msiexec command-line options.

1. Sign on to the computer with an account that has administrative rights.

2. Download the latest agent installer from

https://aka.ms/AzureConnectedMachineAgent

3. To upgrade the agent silently and create a setup log file in the C:\Support\Logs
folder, run the following command:

dos

msiexec.exe /i AzureConnectedMachineAgent.msi /qn /l*v

"C:\Support\Logs\azcmagentupgradesetup.log"

Linux agent
Updating the agent on a Linux machine involves two commands; one command to
update the local package index with the list of latest available packages from the
repositories, and another command to upgrade the local package.

You can download the latest agent package from Microsoft's package repository .

７ Note

To upgrade the agent, you must have root access permissions or an account that
has elevated rights using Sudo.
Upgrade the agent on Ubuntu
1. To update the local package index with the latest changes made in the
repositories, run the following command:

Bash

sudo apt update

2. To upgrade your system, run the following command:

Bash

sudo apt upgrade azcmagent

Actions of the apt command, such as installation and removal of packages, are logged
in the /var/log/dpkg.log log file.

Upgrade the agent on Red Hat/CentOS/Oracle Linux/Amazon Linux

1. To update the local package index with the latest changes made in the
repositories, run the following command:

Bash

sudo yum check-update

2. To upgrade your system, run the following command:

Bash

sudo yum update azcmagent

Actions of the yum command, such as installation and removal of packages, are
logged in the /var/log/yum.log log file.

Upgrade the agent on SUSE Linux Enterprise

1. To update the local package index with the latest changes made in the
repositories, run the following command:

Bash
 sudo zypper refresh

2. To upgrade your system, run the following command:

Bash

sudo zypper update azcmagent

Actions of the zypper command, such as installation and removal of packages, are
logged in the /var/log/zypper.log log file.

Automatic agent upgrades

The Azure Connected Machine agent will support automatic and manual upgrades of
the agent, initiated by Azure, in an upcoming release. To facilitate this capability, the
agent enables a scheduled task on Windows or cron job on Linux that runs daily to see if
the agent should be upgraded. The scheduler job will be installed when you install agent
versions 1.30 or higher. While the scheduler job is currently enabled, the complete
automatic upgrade experience is not yet available, so no changes will be made to your
system even if a newer version of the Azure Connected Machine agent is available.

To view these scheduler jobs in Windows through PowerShell, run the following
command:

PowerShell

schtasks /query /TN azcmagent

To view these scheduler jobs in Windows through Task Scheduler:

To view these scheduler jobs in Linux, run the following command:

cat /etc/cron.d/azcmagent_autoupgrade

To opt-out of any future automatic upgrades or the scheduler jobs, execute the
following Azure CLI commands:

For Windows:

PowerShell

az rest --method patch --url

https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<
resourceGroup>/providers/Microsoft.HybridCompute/machines/<machineName>?api-
version=2022-12-27-preview --resource https://management.azure.com/ --
headers Content-Type=application/json --body '{\"properties\":
{\"agentUpgrade\": {\"enableAutomaticUpgrade\": false}}}'

For Linux:

Bash
 az rest --method patch --url
https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<
resourceGroup>/providers/Microsoft.HybridCompute/machines/<machineName>?api-
version=2022-12-27-preview --resource https://management.azure.com/ --
headers Content-Type=application/json --body '{"properties":
{"agentUpgrade": {"enableAutomaticUpgrade": false}}}'

Renaming an Azure Arc-enabled server

resource
When you change the name of a Linux or Windows machine connected to Azure Arc-
enabled servers, the new name is not recognized automatically because the resource
name in Azure is immutable. As with other Azure resources, you must delete the
resource and re-create it in order to use the new name.

For Azure Arc-enabled servers, before you rename the machine, it's necessary to remove
the VM extensions before proceeding:

1. Audit the VM extensions installed on the machine and note their configuration
using the Azure CLI or Azure PowerShell.

2. Remove any VM extensions installed on the machine. You can do this using the
Azure portal, the Azure CLI, or Azure PowerShell.

3. Use the azcmagent tool with the Disconnect parameter to disconnect the machine
from Azure Arc and delete the machine resource from Azure. You can run this
manually while logged on interactively, with a Microsoft identity access token, or
with the service principal you used for onboarding (or with a new service principal
that you create.

Disconnecting the machine from Azure Arc-enabled servers doesn't remove the
Connected Machine agent, and you do not need to remove the agent as part of
this process.

4. Re-register the Connected Machine agent with Azure Arc-enabled servers. Run the
azcmagent tool with the Connect parameter to complete this step. The agent will

default to using the computer's current hostname, but you can choose your own
resource name by passing the --resource-name parameter to the connect
command.

5. Redeploy the VM extensions that were originally deployed to the machine from
Azure Arc-enabled servers. If you deployed the Azure Monitor for VMs (insights)
 agent or the Log Analytics agent using an Azure Policy definition, the agents are
redeployed after the next evaluation cycle.

Uninstall the agent

For servers you no longer want to manage with Azure Arc-enabled servers, follow the
steps below to remove any VM extensions from the server, disconnect the agent, and
uninstall the software from your server. It's important to complete all of these steps to
fully remove all related software components from your system.

Step 1: Remove VM extensions

If you have deployed Azure VM extensions to an Azure Arc-enabled server, you must
uninstall the extensions before disconnecting the agent or uninstalling the software.
Uninstalling the Azure Connected Machine agent doesn't automatically remove
extensions, and these extensions won't be recognized if you reconnect the server to
Azure Arc.

For guidance on how to identify and remove any extensions on your Azure Arc-enabled
server, see the following resources:

Manage VM extensions with the Azure portal

Manage VM extensions with Azure PowerShell
Manage VM extensions with Azure CLI

Step 2: Disconnect the server from Azure Arc

Disconnecting the agent deletes the corresponding Azure resource for the server and
clears the local state of the agent. To disconnect the agent, run the azcmagent
disconnect command as an administrator on the server. You'll be prompted to log in

with an Azure account that has permission to delete the resource in your subscription. If
the resource has already been deleted in Azure, you'll need to pass an additional flag to
clean up the local state: azcmagent disconnect --force-local-only .

Step 3a: Uninstall the Windows agent

Both of the following methods remove the agent, but they do not remove the
C:\Program Files\AzureConnectedMachineAgent folder on the machine.

Uninstall from Control Panel

Follow these steps to uninstall the Windows agent from the machine:

1. Sign in to the computer with an account that has administrator permissions.

2. In Control panel, select Programs and Features.

3. In Programs and Features, select Azure Connected Machine Agent, select

Uninstall, and then select Yes.

You can also delete the Windows agent directly from the agent setup wizard. Run the
AzureConnectedMachineAgent.msi installer package to do so.

Uninstall from the command line

You can uninstall the agent manually from the Command Prompt or by using an
automated method (such as a script) by following the example below. First you need to
retrieve the product code, which is a GUID that is the principal identifier of the
application package, from the operating system. The uninstall is performed by using the
Msiexec.exe command line - msiexec /x {Product Code} .

1. Open the Registry Editor.

2. Under registry key

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall , look
for and copy the product code GUID.

3. Uninstall the agent using Msiexec, as in the following examples:

From the command-line type:

dos

msiexec.exe /x {product code GUID} /qn

You can perform the same steps using PowerShell:

PowerShell

Get-ChildItem -Path
HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall | `
Get-ItemProperty | `
Where-Object {$_.DisplayName -eq "Azure Connected Machine Agent"}
| `
ForEach-Object {MsiExec.exe /x "$($_.PsChildName)" /qn}
Step 3b: Uninstall the Linux agent

７ Note

To uninstall the agent, you must have root access permissions or an account that
has elevated rights using sudo.

The command used to uninstall the Linux agent depends on the Linux operating system.

For Ubuntu, run the following command:

Bash

sudo apt purge azcmagent

For RHEL, CentOS, Oracle Linux, and Amazon Linux, run the following command:

Bash

sudo yum remove azcmagent

For SLES, run the following command:

Bash

sudo zypper remove azcmagent

Update or remove proxy settings

To configure the agent to communicate to the service through a proxy server or to
remove this configuration after deployment, use one of the methods described below.
Note that the agent communicates outbound using the HTTP protocol under this
scenario.

As of agent version 1.13, proxy settings can be configured using the azcmagent config
command or system environment variables. If a proxy server is specified in both the
agent configuration and system environment variables, the agent configuration will take
precedence and become the effective setting. Use azcmagent show to view the effective
proxy configuration for the agent.

７ Note
 Azure Arc-enabled servers doesn't support using proxy servers that require
authentication, TLS (HTTPS) connections, or a Log Analytics gateway as a proxy for
the Connected Machine agent.

Agent-specific proxy configuration

Agent-specific proxy configuration is available starting with version 1.13 of the Azure
Connected Machine agent and is the preferred way of configuring proxy server settings.
This approach prevents the proxy settings for the Azure Connected Machine agent from
interfering with other applications on your system.

７ Note

Extensions deployed by Azure Arc will not inherit the agent-specific proxy
configuration. Refer to the documentation for the extensions you deploy for
guidance on how to configure proxy settings for each extension.

To configure the agent to communicate through a proxy server, run the following
command:

Bash

azcmagent config set proxy.url "http://ProxyServerFQDN:port"

You can use an IP address or simple hostname in place of the FQDN if your network
requires it. If your proxy server runs on port 80, you may omit ":80" at the end.

To check if a proxy server URL is configured in the agent settings, run the following
command:

Bash

azcmagent config get proxy.url

To stop the agent from communicating through a proxy server, run the following
command:

Bash

azcmagent config clear proxy.url

You do not need to restart any services when reconfiguring the proxy settings with the
azcmagent config command.

Proxy bypass for private endpoints

Starting with agent version 1.15, you can also specify services which should not use the
specified proxy server. This can help with split-network designs and private endpoint
scenarios where you want Azure Active Directory and Azure Resource Manager traffic to
go through your proxy server to public endpoints but want Azure Arc traffic to skip the
proxy and communicate with a private IP address on your network.

The proxy bypass feature does not require you to enter specific URLs to bypass. Instead,
you provide the name of the service(s) that should not use the proxy server.

Proxy bypass value Affected endpoints

AAD login.windows.net , login.microsoftonline.com , pas.windows.net

ARM management.azure.com

Arc his.arc.azure.com , guestconfiguration.azure.com

To send Azure Active Directory and Azure Resource Manager traffic through a proxy
server but skip the proxy for Azure Arc traffic, run the following command:

Bash

azcmagent config set proxy.url "http://ProxyServerFQDN:port"

azcmagent config set proxy.bypass "Arc"

To provide a list of services, separate the service names by commas:

Bash

azcmagent config set proxy.bypass "ARM,Arc"

To clear the proxy bypass, run the following command:

Bash

azcmagent config clear proxy.bypass

You can view the effective proxy server and proxy bypass configuration by running
azcmagent show .
Windows environment variables
On Windows, the Azure Connected Machine agent will first check the proxy.url agent
configuration property (starting with agent version 1.13), then the system-wide
HTTPS_PROXY environment variable to determine which proxy server to use. If both are

empty, no proxy server is used, even if the default Windows system-wide proxy setting is
configured.

Microsoft recommends using the agent-specific proxy configuration instead of the

system environment variable.

To set the proxy server environment variable, run the following commands:

PowerShell

# If a proxy server is needed, execute these commands with the proxy URL and
port.
[Environment]::SetEnvironmentVariable("HTTPS_PROXY",
"http://ProxyServerFQDN:port", "Machine")
$env:HTTPS_PROXY =
[System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine")
# For the changes to take effect, the agent services need to be restarted
after the proxy environment variable is set.
Restart-Service -Name himds, ExtensionService, GCArcService

To configure the agent to stop communicating through a proxy server, run the following
commands:

PowerShell

[Environment]::SetEnvironmentVariable("HTTPS_PROXY", $null, "Machine")

$env:HTTPS_PROXY =
[System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine")
# For the changes to take effect, the agent services need to be restarted
after the proxy environment variable removed.
Restart-Service -Name himds, ExtensionService, GCArcService

Linux environment variables

On Linux, the Azure Connected Machine agent first checks the proxy.url agent
configuration property (starting with agent version 1.13), and then the HTTPS_PROXY
environment variable set for the himds, GC_Ext, and GCArcService daemons. There's an
included script that will configure systemd's default proxy settings for the Azure
Connected Machine agent and all other services on the machine to use a specified proxy
server.
To configure the agent to communicate through a proxy server, run the following
command:

Bash

sudo /opt/azcmagent/bin/azcmagent_proxy add "http://ProxyServerFQDN:port"

To remove the environment variable, run the following command:

Bash

sudo /opt/azcmagent/bin/azcmagent_proxy remove

Migrating from environment variables to agent-specific

proxy configuration
If you're already using environment variables to configure the proxy server for the Azure
Connected Machine agent and want to migrate to the agent-specific proxy
configuration based on local agent settings, follow these steps:

1. Upgrade the Azure Connected Machine agent to the latest version (starting with
version 1.13) to use the new proxy configuration settings.

2. Configure the agent with your proxy server information by running azcmagent
config set proxy.url "http://ProxyServerFQDN:port" .

3. Remove the unused environment variables by following the steps for Windows or
Linux.

Next steps
Troubleshooting information can be found in the Troubleshoot Connected
Machine agent guide.

Review the Planning and deployment guide to plan for deploying Azure Arc-
enabled servers at any scale and implement centralized management and
monitoring.

Learn how to manage your machine using Azure Policy, for such things as VM
guest configuration, verifying the machine is reporting to the expected Log
Analytics workspace, enable monitoring with VM insights, and much more.
How to migrate Azure Arc-enabled
servers across regions
Article • 08/04/2022

There are scenarios in which you'll want to move your existing Azure Arc-enabled server
from one region to another. For example, you might want to move regions to improve
manageability, for governance reasons, or because you realized the machine was
originally registered in the wrong region.

To migrate an Azure Arc-enabled server from one Azure region to another, you have to
uninstall the VM extensions, delete the resource in Azure, and re-create it in the other
region. Before you perform these steps, you should audit the machine to verify which
VM extensions are installed.

７ Note

While installed extensions continue to run and perform their normal operation after
this procedure is complete, you won't be able to manage them. If you attempt to
redeploy the extensions on the machine, you may experience unpredictable
behavior.

Move machine to other region

７ Note

Performing this operation will result in downtime during the migration.

1. Remove any VM extensions that are installed on the machine. You can do this by
using the Azure portal, Azure CLI, or Azure PowerShell.

2. Use the azcmagent tool with the Disconnect parameter to disconnect the machine
from Azure Arc and delete the machine resource from Azure. You can run this
manually while logged on interactively, with a Microsoft identity platform access
token, or with the service principal you used for onboarding (or with a new service
principal that you create).

Disconnecting the machine from Azure Arc-enabled servers does not remove the
Connected Machine agent, and you don't need to remove the agent as part of this
 process.

3. Run the azcmagent tool with the Connect parameter to re-register the Connected
Machine agent with Azure Arc-enabled servers in the other region.

4. Redeploy the VM extensions that were originally deployed to the machine from
Azure Arc-enabled servers.

If you deployed the Azure Monitor for VMs (insights) agent or the Log Analytics
agent using an Azure Policy definition, the agents are redeployed after the next
evaluation cycle.

Next steps
Troubleshooting information can be found in the Troubleshoot Connected
Machine agent guide.

Learn how to manage your machine using Azure Policy, for such things as VM
guest configuration, verifying the machine is reporting to the expected Log
Analytics workspace, enable monitoring with VM insights policy, and much more.
Evaluate Azure Arc-enabled servers on
an Azure virtual machine
Article • 05/02/2024

Ｕ 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.

Azure Arc-enabled servers is designed to help you connect servers running on-premises
or in other clouds to Azure. Normally, you wouldn't connect an Azure virtual machine to
Azure Arc because all the same capabilities are natively available for these VMs. Azure
VMs already have a representation in Azure Resource Manager, VM extensions,
managed identities, and Azure Policy. If you attempt to install Azure Arc-enabled servers
on an Azure VM, you'll receive an error message stating that it is unsupported.

While you cannot install Azure Arc-enabled servers on an Azure VM for production
scenarios, it's possible to configure Azure Arc-enabled servers to run on an Azure VM
for evaluation and testing purposes only. This article walks you through how to prepare
an Azure VM to look like an on-premises server for testing purposes.

７ Note

The steps in this article are intended for virtual machines hosted in the Azure cloud.
Azure Arc-enabled servers is not supported on virtual machines running on Azure
Stack Hub or Azure Stack Edge.

Prerequisites
Your account is assigned to the Virtual Machine Contributor role.
The Azure virtual machine is running an operating system supported by Azure Arc-
enabled servers. If you don't have an Azure VM, you can deploy a simple Windows
VM or a simple Ubuntu Linux 18.04 LTS VM .
Your Azure VM can communicate outbound to download the Azure Connected
Machine agent package for Windows from the Microsoft Download Center , and
Linux from the Microsoft package repository . If outbound connectivity to the
 Internet is restricted following your IT security policy, you can download the agent
package manually and copy it to a folder on the Azure VM.
An account with elevated (that is, an administrator or as root) privileges on the VM,
and RDP or SSH access to the VM.
To register and manage the Azure VM with Azure Arc-enabled servers, you are a
member of the Azure Connected Machine Resource Administrator or Contributor
role in the resource group.

Plan
To start managing your Azure VM as an Azure Arc-enabled server, you need to make the
following changes to the Azure VM before you can install and configure Azure Arc-
enabled servers.

1. Remove any VM extensions deployed to the Azure VM, such as the Log Analytics
agent. While Azure Arc-enabled servers support many of the same extensions as
Azure VMs, the Azure Connected Machine agent can't manage VM extensions
already deployed to the VM.

2. Disable the Azure Windows or Linux Guest Agent. The Azure VM guest agent
serves a similar purpose to the Azure Connected Machine agent. To avoid conflicts
between the two, the Azure VM Agent needs to be disabled. Once it is disabled,
you cannot use VM extensions or some Azure services.

3. Create a security rule to deny access to the Azure Instance Metadata Service
(IMDS). IMDS is a REST API that applications can call to get information about the
VM's representation in Azure, including its resource ID and location. IMDS also
provides access to any managed identities assigned to the machine. Azure Arc-
enabled servers provides its own IMDS implementation and returns information
about the Azure Arc representation of the VM. To avoid situations where both
IMDS endpoints are available and apps have to choose between the two, you block
access to the Azure VM IMDS so that the Azure Arc-enabled server IMDS
implementation is the only one available.

After you make these changes, your Azure VM behaves like any machine or server
outside of Azure and is at the necessary starting point to install and evaluate Azure Arc-
enabled servers.

When Azure Arc-enabled servers is configured on the VM, you see two representations
of it in Azure. One is the Azure VM resource, with a Microsoft.Compute/virtualMachines
resource type, and the other is an Azure Arc resource, with a
Microsoft.HybridCompute/machines resource type. As a result of preventing management
of the guest operating system from the shared physical host server, the best way to
think about the two resources is the Azure VM resource is the virtual hardware for your
VM, and let's you control the power state and view information about its SKU, network,
and storage configurations. The Azure Arc resource manages the guest operating
system in that VM, and can be used to install extensions, view compliance data for Azure
Policy, and complete any other supported task by Azure Arc-enabled servers.

Reconfigure Azure VM

７ Note

For windows, set the environment variable to override the ARC on an Azure VM
installation.

PowerShell

[System.Environment]::SetEnvironmentVariable("MSFT_ARC_TEST",'true',
[System.EnvironmentVariableTarget]::Machine)

1. Remove any VM extensions on the Azure VM.

In the Azure portal, navigate to your Azure VM resource and from the left-hand
pane, select Extensions. If there are any extensions installed on the VM, select each
extension individually and then select Uninstall. Wait for all extensions to finish
uninstalling before proceeding to step 2.

2. Disable the Azure VM Guest Agent.

To disable the Azure VM Guest Agent, connect to your VM using Remote Desktop
Connection (Windows) or SSH (Linux) and run the following commands to disable
the guest agent.

For Windows, run the following PowerShell commands:

PowerShell

Set-Service WindowsAzureGuestAgent -StartupType Disabled -Verbose

Stop-Service WindowsAzureGuestAgent -Force -Verbose

For Linux, run the following commands:

Bash
 sudo systemctl stop walinuxagent
sudo systemctl disable walinuxagent

3. Block access to the Azure IMDS endpoint.

７ Note

The configurations below need to be applied for 169.254.169.254 and

169.254.169.253. These are endpoints used for IMDS in Azure and Azure Stack
HCI respectively.

While still connected to the server, run the following commands to block access to
the Azure IMDS endpoint. For Windows, run the following PowerShell command:

PowerShell

New-NetFirewallRule -Name BlockAzureIMDS -DisplayName "Block access to

Azure IMDS" -Enabled True -Profile Any -Direction Outbound -Action
Block -RemoteAddress 169.254.169.254

For Linux, consult your distribution's documentation for the best way to block
outbound access to 169.254.169.254/32 over TCP port 80. Normally you'd block
outbound access with the built-in firewall, but you can also temporarily block it
with iptables or nftables.

If your Azure VM is running Ubuntu, perform the following steps to configure its
uncomplicated firewall (UFW):

Bash

sudo ufw --force enable

sudo ufw deny out from any to 169.254.169.254
sudo ufw default allow incoming

If your Azure VM is running CentOS, Red Hat, or SUSE Linux Enterprise Server
(SLES), perform the following steps to configure firewalld:

Bash

sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1

-p tcp -d 169.254.169.254 -j REJECT
sudo firewall-cmd --reload
 For other distributions, consult your firewall docs or configure a generic iptables
rule with the following command:

Bash

sudo iptables -I OUTPUT 1 -d 169.254.169.254 -j REJECT

７ Note

The iptables configuration needs to be set after every reboot unless a

persistent iptables solution is used.

4. Install and configure the Azure Connected Machine agent.

The VM is now ready for you to begin evaluating Azure Arc-enabled servers. To
install and configure the Azure Connected Machine agent, see Connect hybrid
machines using the Azure portal and follow the steps to generate an installation
script and install using the scripted method.

７ Note

If outbound connectivity to the internet is restricted from your Azure VM, you
can download the agent package manually. Copy the agent package to the
Azure VM, and modify the Azure Arc-enabled servers installation script to
reference the source folder.

If you missed one of the steps, the installation script detects it is running on an Azure
VM and terminates with an error. Verify you've completed steps 1-3, and then rerun the
script.

Verify the connection with Azure Arc

After you install and configure the agent to register with Azure Arc-enabled servers, go
to the Azure portal to verify that the server has successfully connected. View your
machine in the Azure portal .
Next steps
Learn how to plan and enable a large number of machines to Azure Arc-enabled
servers to simplify configuration of essential security management and monitoring
capabilities in Azure.

Learn about our supported Azure VM extensions available to simplify deployment

with other Azure services like Automation, KeyVault, and others for your Windows
or Linux machine.

When you have finished testing, uninstall the Azure Connected Machine agent.
Onboard Azure Arc-enabled servers to
Microsoft Sentinel
Article • 05/26/2022

This article is intended to help you onboard your Azure Arc-enabled server to Microsoft
Sentinel and start collecting security-related events. Microsoft Sentinel provides a single
solution for alert detection, threat visibility, proactive hunting, and threat response
across the enterprise.

Prerequisites
Before you start, make sure that you've met the following requirements:

A Log Analytics workspace. For more information about Log Analytics workspaces,
see Designing your Azure Monitor Logs deployment.

Microsoft Sentinel enabled in your subscription.

Your machine or server is connected to Azure Arc-enabled servers.

Onboard Azure Arc-enabled servers to

Microsoft Sentinel
Microsoft Sentinel comes with a number of connectors for Microsoft solutions, available
out of the box and providing real-time integration. For physical and virtual machines,
you can install the Log Analytics agent that collects the logs and forwards them to
Microsoft Sentinel. Azure Arc-enabled servers supports deploying the Log Analytics
agent using the following methods:

Using the VM extensions framework.

This feature in Azure Arc-enabled servers allows you to deploy the Log Analytics
agent VM extension to a non-Azure Windows and/or Linux server. VM extensions
can be managed using the following methods on your hybrid machines or servers
managed by Azure Arc-enabled servers:
The Azure portal
The Azure CLI
Azure PowerShell
Azure Resource Manager templates
 Using Azure Policy.

Using this approach, you use the Azure Policy Deploy Log Analytics agent to Linux
or Windows Azure Arc machines built-in policy to audit if the Azure Arc-enabled
server has the Log Analytics agent installed. If the agent is not installed, it
automatically deploys it using a remediation task. Alternatively, if you plan to
monitor the machines with Azure Monitor for VMs, instead use the Enable Azure
Monitor for VMs initiative to install and configure the Log Analytics agent.

We recommend installing the Log Analytics agent for Windows or Linux using Azure
Policy.

After your Arc-enabled servers are connected, your data starts streaming into Microsoft
Sentinel and is ready for you to start working with. You can view the logs in the built-in
workbooks and start building queries in Log Analytics to investigate the data.

Next steps
Get started detecting threats with Microsoft Sentinel.
Migrate to Azure Monitor Agent on
Azure Arc using Red Hat Ansible
Automation Platform
Article • 10/25/2022

This article covers how to use Red Hat Ansible Automation Platform to migrate non-
Azure machines from the Azure Log Analytics agent to Azure Monitor agent. This
includes onboarding the machines to Azure Arc-enabled servers. Once you have
completed the configuration steps in this article, you'll be able to run a workflow against
an automation controller inventory that performs the following tasks:

Ensure that the Azure Connected Machine agent is installed on each machine.
Install and enable the Azure Monitor agent.
Disable and uninstall the Log Analytics agent.

Content from the Ansible Content Lab for Cloud Automation has already been
developed to automate this scenario. This article will walk through how you can import
that content as a project in an automation controller to build a workflow to perform the
tasks above.

Ansible Automation Platform can automate the deployment of Azure services across
your IT landscape to make onboarding to Azure Arc fast and reliable.

７ Note

The Ansible content examples in this article target Linux hosts, but the playbooks
can be altered to accommodate Windows hosts as well.

Prerequisites

Azure Log Analytics workspace

This article assumes you are using the Azure Log Analytics agent and that the servers are
pre-configured to report data to a Log Analytics workspace. You will need the name and
resource group of the workspace from which you are migrating.

Automation controller 2.x

This article is applicable to both self-managed Ansible Automation Platform and Red
Hat Ansible Automation Platform on Microsoft Azure.

Automation execution environment

To use the examples in this article, you'll need an automation execution environment
with both the Azure Collection and the Azure CLI installed, since both are required to
run the automation.

If you don't have an automation execution environment that meets these requirements,
you can use this example .

See the Red Hat Ansible documentation for more information about building and
configuring automation execution environments.

Host inventory
You will need an inventory of Linux hosts configured in automation controller that
contains a list of VMs that will use Azure Arc and the Azure Monitor Agent.

Azure Resource Manager credential

A working account credential configured in Ansible Automation Platform for the Azure
Resource Manager is required. This credential is used by Ansible Automation Platform to
authenticate operations using the Azure Collection and the Azure CLI.

Server machine credential

A “Machine Credential” configured in Automation Controller for SSH access to the
servers in your host inventory is required.

Configuring the content

The examples in this article rely on content developed and incubated by Red Hat
through the Ansible Content Lab for Cloud Content .

This article also uses the Azure Infrastructure Configuration Demo collection. This
collection contains a number of roles and playbooks that manage Azure use cases
including those with Azure Arc-enabled servers. To use this collection in Automation
Controller, follow the steps below to set up a project with the repository:
 1. Log in to automation controller.

2. In the left menu, select Projects.

3. Select Add, and then complete the fields of the form as follows:

Name: Content Lab - Azure Infrastructure Configuration Collection

Automation Environment: (select with the Azure Collection and CLI instead)

Source Control Type: Git

Source Control URL: https://github.com/ansible-content-

lab/azure.infrastructure_config_demos.git

4. Select Save.

Once saved, the project should be synchronized with the automation controller.

Migrating Azure agents

In this example, we will assume that our Linux servers are already running the Azure Log
Analytics agent, but do not yet have the Azure Connected Machine agent installed. If
your organization relies on other Azure services that use the Log Analytics agent, you
may need to plan for extra data collection rules prior to migrating to the Azure Monitor
agent.

We will create a workflow that leverages the following playbooks to install the Azure
Connected Machine agent, deploy the Azure Monitor Agent, disable the Log Analytics
agent, and then uninstall the Log Analytics agent:

install_arc_agent.yml
 replace_log_analytics_with_arc_linux.yml
uninstall_log_analytics_agent.yml

This workflow performs the following tasks:

Installs the Azure Connected Machine agent on all of the VMs identified in
inventory.
Enables the Azure Monitor agent extension via Azure Arc.
Disables the Azure Log Analytics agent extension via Azure Arc.
Uninstalls the Azure Log Analytics agent if flagged.

Create template to install Azure Connected Machine

agent
This template is responsible for installing the Azure Arc Connected Machine agent on
hosts within the provided inventory. A successful run will have installed the agent on all
machines.

Follow the steps below to create the template:

1. On the right menu, select Templates.

2. Select Add.

3. Select Add job template, then complete the fields of the form as follows:

Name: Content Lab - Install Arc Connected Machine Agent

Job Type: Run

Inventory: (Your linux host inventory)

Project: Content Lab - Azure Infrastructure Configuration Collection

Playbook: playbooks/replace_log_analytics_with_arc_linux.yml

Credentials:

Your Azure Resource Manager credential

Your Host Inventory Machine credential

Variables:

Bash
 ---
region: eastus
resource_group_name: sh-rg
subscription_id: "{{ lookup('env', 'AZURE_SUBSCRIPTION_ID') }}"
service_principal_id: "{{ lookup('env', 'AZURE_CLIENT_ID') }}"
service_principal_secret: "{{ lookup('env', 'AZURE_SECRET') }}"
tenant_id: "{{ lookup('env', 'AZURE_TENANT') }}"

７ Note

The operations in this playbook happen through the Azure CLI. Most of these
variables are set to pass along the proper variable from the Azure Resource
Manager credential to the CL.

Options: Privilege Escalation: true

4. Select Save.

Create template to replace log analytics

This template is responsible for migrating from the Log Analytics agent to the Azure
Monitor agent by enabling the Azure Monitor Agent extension and disabling the Azure
Log Analytics extension (if used via the Azure Connected Machine agent).

Follow the steps below to create the template:

1. On the right menu, select Templates.

2. Select Add.

3. Select Add job template, then complete the fields of the form as follows:

Name: Content Lab - Replace Log Analytics agent with Arc Connected Machine
agent

Job Type: Run

Inventory: (Your linux host inventory)

Project: Content Lab - Azure Infrastructure Configuration Collection

Playbook: playbooks/replace_log_analytics_with_arc_linux.yml

Credentials:
 Your Azure Resource Manager credential
Your Host Inventory Machine credential

Variables:

Bash

—
Region: <Azure Region>
resource_group_name: <Resource Group Name>
linux_hosts: "{{ hostvars.values() |
selectattr('group_names','contains', 'linux') |
map(attribute='inventory_hostname') | list }}"

７ Note

The linux_hosts variable is used to create a list of hostnames to send to the

Azure Collection and is not directly related to a host inventory. You may set
this list in any way that Ansible supports. In this case, the variable attempts to
pull host names from groups with “linux” in the group name.

4. Select Save.

Create template to uninstall Log Analytics

This template will attempt to run the Log Analytics agent uninstall script if the Log
Analytics agent was installed outside of the Azure Connected Machine agent.

Follow the steps below to create the template:

1. On the right menu, select Templates.

2. Select Add.

3. Select Add job template, then complete the fields of the form as follows:

Name: Content Lab - Uninstall Log Analytics agent

Job Type: Run

Inventory: (Your linux host inventory)

Project: Content Lab - Azure Infrastructure Configuration Collection

Playbook: playbooks/uninstall_log_analytics_with_arc_linux.yml
 Credentials:

Your Host Inventory Machine credential

Options:

Privilege Escalation: true

4. Select Save.

Create the workflow

An automation controller workflow allows you to construct complex automation by
connecting automation templates and other actions together. This workflow example is
a simple linear flow that enables the end-to-end scenario in this example, but other
nodes could be added for context such as error handling, human approvals, etc.

1. On the right menu, select Templates.

2. Select Add.

3. Select Add workflow template, then complete the following fields as follows:

Name: Content Lab - Migrate Log Agent to Azure Monitor

Job Type: Run

Inventory: (Your linux host inventory)

Project: Content Lab - Azure Infrastructure Configuration Collection

4. Select Save.

5. Select Start to begin the workflow designer.

6. Set Node Type to "Job Template" and select Content Lab - Replace Log Analytics
with Arc Connected Machine Agent.

7. Select Next.

8. Select Save.

9. Hover over the Content Lab - Replace Log Analytics with Arc Connected Machine
Agent node and select the + button.

10. Select On Success.

11. Select Next.

 12. Set Node Type to "Job Template" and select Content Lab - Uninstall Log Analytics
Agent.

13. Select Save.

14. Select Save at the top right corner of the workflow designer.

You will now have a workflow that looks like the following:

Add a survey to the workflow

We want to add survey questions to the workflow so that we can collect input when the
workflow is run.

1. Select Survey from the workflow details screen.

2. Select Add, then complete the form using the following values:

Question: Which Azure region will your Arc servers reside?

Answer variable name: region

Required: true

Answer type: Text

3. Select Save.

4. Select Add, then complete the form using the following values:

Question: What is the name of the resource group?

Answer variable name: resource_group_name

 Required: true

Answer type: Text

5. Select Save.

6. Select Add, then complete the form using the following values:

Question: What is the name of your Log Analytics workspace?

Answer variable name: analytics_workspace_name

Required: true

Answer type: Text

7. Select Save.

8. From the Survey list screen, ensure that the survey is enabled.

Your workflow has now been created.

Running the workflow

Now that you have the workflow created, you can run the workflow at any time. When
you click the “launch” 🚀 icon, the survey that you configured will be presented so that
you can update the variables across automation runs. This will allow you to move Log
Analytics connected servers that are assigned to different regions or resource groups as
needed.
Conclusion
After following the steps in this article, you have created an automation workflow that
migrates your Linux machines from the Azure Log Analytics agent to the Azure Monitor
agent. This workflow will onboard the Linux machine to Azure Arc-enabled servers. This
example uses the Ansible Content Lab for Cloud Automation to make implementation
fast and easy.

Next steps
Learn more about connecting machines using Ansible playbooks.
Migrate from legacy Log Analytics
agents in non-Azure environments with
Azure Arc
Article • 07/02/2024

Azure Monitor Agent (AMA) replaces the Log Analytics agent (also known as Microsoft
Monitor Agent (MMA) and OMS) for Windows and Linux machines. Azure Arc is
required to migrate off the legacy Log Analytics agents for non-Azure environments,
including on-premises or multicloud infrastructure.

Azure Arc is a bridge, extending not only Azure Monitor but the breadth of Azure
management capabilities across Microsoft Defender, Azure Policy, and Azure Update
Manager to non-Azure environments. Through the lightweight Connected Machine
agent, Azure Arc projects non-Azure servers into the Azure control plane, providing a
consistent management experience across Azure VMs and non-Azure servers.

This article focuses on considerations when migrating from legacy Log Analytics agents
in non-Azure environments. For core migration guidance, see Migrate to Azure Monitor
Agent from Log Analytics agent.

Advantages of Azure Arc

Deploying Azure Monitor Agent as an extension with Azure Arc-enabled servers
provides several benefits over the legacy Log Analytics agents (MMA and OMS), which
directly connect non-Azure servers to Log Analytics workspaces:

Azure Arc centralizes the identity, connectivity, and governance of non-Azure

resources. This streamlines operational overhead and improves the security
posture and performance.

Azure Arc offers extension management capabilities including auto-extension

upgrade, reducing typical maintenance overhead.

Azure Arc enables access to the breadth of server management capabilities

beyond monitoring, such as Cloud Security Posture Management with Microsoft
Defender or scripting with Run Command. As you centralize operations in Azure,
Azure Arc provides a robust foundation for these other capabilities.

Azure Arc is the foundation for a cloud-based inventory bringing together Azure and
on-premises, multicloud, and edge infrastructure that can be queried and organized
through Azure Resource Manager (ARM).

Limitations on Azure Arc

Azure Arc relies on the Connected Machine agent and is an agent-based solution
requiring connectivity and designed for server infrastructure:

Azure Arc requires the Connected Machine agent in addition to the Azure Monitor
Agent as a VM extension. The Connected Machine agent must be configured
specifying details of the Azure resource.

Azure Arc only supports client-like Operating Systems when computers are in a
server-like environment and doesn't support short-lived servers or virtual desktop
infrastructure.

Azure Arc has two regional availability gaps with Azure Monitor Agent:
Qatar Central (Availability expected in August 2024)
Australia Central (Other Australia regions are available)

Azure Arc requires servers to have regular connectivity and the allowance of key
endpoints. While proxy and private link connectivity are supported, Azure Arc
doesn't support completely disconnected scenarios. Azure Arc doesn't support the
Log Analytics (OMS) Gateway.

Azure Arc defines a System Managed Identity for connected servers, but doesn't
support User Assigned Identities.

Learn more about the full Connected Machine agent prerequisites for environmental
constraints.

Relevant services
Azure Arc-enabled servers is required for deploying all solutions that previously required
the legacy Log Analytics agents (MMA/OMS) to non-Azure infrastructure. The new
Azure Monitor Agent is only required for a subset of these services.

ﾉ Expand table

Azure Monitor Agent and Azure Arc required Only Azure Arc required

Microsoft Sentinel Microsoft Defender for Cloud

Virtual Machine Insights (previously Dependency Agent) Azure Update Management

 Azure Monitor Agent and Azure Arc required Only Azure Arc required

Change Tracking and Inventory Automation Hybrid Runbook Worker

As you design the holistic migration from the legacy Log Analytics agents (MMA/OMS),
it's critical to consider and prepare for the migration of these solutions.

Deploying Azure Arc

Azure Arc can be deployed interactively on a single server basis or programmatically at
scale:

PowerShell and Bash deployment scripts can be generated from Azure portal or
written manually following documentation.

Windows Server machines can be connected through Windows Admin Center and
the Windows Server Graphical Installer.

At scale deployment options include Configuration Manager, Ansible, and Group

Policy using the Azure service principal, a limited identity for Arc server
onboarding.

Azure Automation Update Manager customers can onboard from Azure portal
with the Arc-enablement of all detected non-Azure servers connected to the Log
Analytics workspace with the Azure Automation Update Management solution.

See Azure Connected Machine agent deployment options to learn more.

Agent control and footprint

You can lock down the Connected Machine agent by specifying the extensions and
capabilities that are enabled. If migrating from the legacy Log Analytics agent, the
Monitor mode is especially salient. Monitor mode applies a Microsoft-managed
extension allowlist, disables remote connectivity, and disables the machine configuration
agent. If you’re using Azure Arc solely for monitoring purposes, setting the agent to
Monitor mode makes it easy to restrict the agent to just the functionality required to
use Azure Monitor and solutions that use Azure Monitor. You can configure the agent
mode with the following command (run locally on each machine):

azcmagent config set config.mode monitor

See Extensions security to learn more.

Networking options
Azure Arc-enabled servers supports three networking options:

Connectivity over public endpoint

Proxy
Private Link (Azure Express Route).

All connections are TCP and outbound over port 443 unless specified. All HTTP
connections use HTTPS and SSL/TLS with officially signed and verifiable certificates.

Azure Arc doesn't officially support using the Log Analytics gateway as a proxy for the
Connected Machine agent.

The connectivity method specified can be changed after onboarding.

See Connected Machine agent network requirements to learn more.

Deploying Azure Monitor Agent with Azure Arc

There are multiple methods to deploy the Azure Monitor Agent extension on Azure Arc-
enabled servers programmatically, graphically, and automatically. Some popular
methods to deploy Azure Monitor Agent on Azure Arc-enabled servers include:

Azure portal
PowerShell, Azure CLI, or Azure Resource Manager (ARM) templates
Azure Policy

Azure Arc doesn't eliminate the need to configure and define Data Collection Rules. You
should configure Data Collection Rules similar to your Azure VMs for Azure Arc-enabled
servers.

See Deployment options for Azure Monitor Agent on Azure Arc-enabled servers to learn
more.

Standalone Azure Monitor Agent installation

For Windows client machines running in non-Azure environments, use a standalone
Azure Monitor Agent installation that doesn't require deployment of the Azure
Connected Machine agent through Azure Arc. See Install Azure Monitor Agent on
Windows client devices using the client installer to learn more.
Feedback
Was this page helpful?  Yes  No

Provide product feedback

Deploy and configure Azure Monitor
Agent using Azure Policy
Article • 07/10/2023

This article covers how to deploy and configure the Azure Monitor Agent (AMA) to Arc-
enabled servers through Azure Policy using a custom Policy definition. Using Azure
Policy ensures that Azure Monitor is running on your selected Arc-enabled servers, and
automatically install the Azure Monitor Agent on newly added Arc resources.

Deploying the Azure Monitor Agent through a custom Policy definition involves two
main steps:

Selecting an existing or creating a new Data Collection Rule (DCR)

Creating and deploying the Policy definition

In this scenario, the Policy definition is used to verify that the AMA is installed on your
Arc-enabled servers. It will also install the AMA on newly added machines or on existing
machines that don't have the AMA installed.

In order for Azure Monitor to work on a machine, it needs to be associated with a Data
Collection Rule. Therefore, you'll need to include the resource ID of the DCR when you
create your Policy definition.

Select a Data Collection Rule

Data Collection Rules define the data collection process in Azure Monitor. They specify
what data should be collected and where that data should be sent. You'll need to select
or create a DCR to be associated with your Policy definition.

1. From your browser, go to the Azure portal .

2. Navigate to the Monitor | Overview page. Under Settings, select Data Collection
Rules. A list of existing DCRs displays. You can filter this at the top of the window. If
you need to create a new DCR, see Data collection rules in Azure Monitor for more
information.

3. Select the DCR to apply to your ARM template to view its overview.

4. Select Resources to view a list of resources (such as Arc-enabled VMs) assigned to

the DCR. To add more resources, select Add*. (You'll need to add resources if you
created a new DCR.)
 5. Select Overview, then select JSON View to view the JSON code for the DCR:

6. Locate the Resource ID field at the top of the window and select the button to
copy the resource ID for the DCR to the clipboard. Save this resource ID; you'll
need to use it when creating your Policy definition.

Create and deploy the Policy definition

In order for Azure Policy to check if AMA is installed on your Arc-enabled, you'll need to
create a custom policy definition that does the following:

Evaluates if new VMs have the AMA installed and the association with the DCR.
 Enforces a remediation task to install the AMA and create the association with the
DCR on VMs that aren't compliant with the policy.

1. Select one of the following policy definition templates (that is, for Windows or
Linux machines):

Configure Windows machines

Configure Linux machines

These templates are used to create a policy to configure machines to run Azure
Monitor Agent and associate those machines to a DCR.

2. Select Assign to begin creating the policy definition. Enter the applicable
information for each tab (that is, Basics, Advanced, etc.).

3. On the Parameters tab, paste the Data Collection Rule Resource ID that you
copied during the previous procedure:

4. Complete the creation of the policy to deploy it for the applicable machines. Once
Azure Monitor Agent is deployed, your Azure Arc-enabled servers can apply its
services and use it for log collection.

Additional resources
Azure Monitor overview

Tutorial: Monitor a hybrid machine with VM insights

Remotely and securely configure servers
using Run command (Preview)
Article • 02/08/2024

Run Command on Azure Arc-enabled servers (Public Preview) uses the Connected
Machine agent to let you remotely and securely run a script inside your servers. This can
be helpful for myriad scenarios across troubleshooting, recovery, diagnostics, and
maintenance.

Supported environment and configuration

Experiences: Run Command is currently supported through Azure CLI and
PowerShell.

Operating Systems: Run Command supports both Windows and Linux operating
systems.

Environments: Run Command supports non-Azure environments including on-

premises, VMware, SCVMM, AWS, GCP, and OCI.

Cost: Run Command is free of charge, however storage of scripts in Azure may
incur billing.

Configuration: Run Command doesn't require more configuration or the

deployment of any extensions. The Connected Machine agent version must be 1.33
or higher.

Limiting access to Run Command using RBAC

Listing the run commands or showing details of a command requires the
Microsoft.HybridCompute/machines/runCommands/read permission. The built-in Reader

role and higher levels have this permission.

Running a command requires the Microsoft.HybridCompute/machines/runCommands/write

permission. The Azure Connected Machine Resource Administrator role and higher
levels have this permission.

You can use one of the built-in roles or create a custom role to use Run Command.
Blocking run commands locally
The Connected Machine agent supports local configurations that allow you to set an
allowlist or a blocklist. See Extension allowlists and blocklists to learn more.

For Windows:

azcmagent config set extensions.blocklist

"microsoft.cplat.core/runcommandhandlerwindows"

For Linux:

azcmagent config set extensions.blocklist

"microsoft.cplat.core/runcommandhandlerlinux"

Azure CLI
The following examples use az connectedmachine run-command to run a shell script on
an Azure Windows machine.

Execute a script with the machine

This command delivers the script to the machine, executes it, and returns the captured
output.

Azure CLI

az connectedmachine run-command create –-name "myRunCommand" --machine-name

"myMachine" --resource-group "myRG" --script "Write-Host Hello World!"

List all deployed RunCommand resources on a machine

This command returns a full list of previously deployed run commands along with their
properties.

Azure CLI

az connectedmachine run-command list --machine-name "myMachine" --resource-

group "myRG"

Get execution status and results

This command retrieves current execution progress, including latest output, start/end
time, exit code, and terminal state of the execution.

Azure CLI

az connectedmachine run-command show --name "myRunCommand" --machine-name

"myMachine" --resource-group "myRG"

７ Note

Output and error fields in instanceView is limited to the last 4KB. To access the full
output and error, you can forward the output and error data to storage append
blobs using -outputBlobUri and -errorBlobUri parameters while executing Run
Command.

Delete RunCommand resource from the machine

Remove the RunCommand resource previously deployed on the machine. If the script
execution is still in progress, execution will be terminated.

Azure CLI

az connectedmachine run-command delete --name "myRunCommand" --machine-name

"myMachine" --resource-group "myRG"

PowerShell

Execute a script with the machine

PowerShell

New-AzConnectedMachineRunCommand -ResourceGroupName "myRG" -MachineName

"myMachine" -Location "EastUS" -RunCommandName "RunCommandName" –
SourceScript "echo Hello World!"

Execute a script on the machine using SourceScriptUri

parameter
OutputBlobUri and ErrorBlobUri are optional parameters.
 PowerShell

New-AzConnectedMachineRunCommand -ResourceGroupName -MachineName -

RunCommandName -SourceScriptUri “< SAS URI of a storage blob with read
access or public URI>” -OutputBlobUri “< SAS URI of a storage append blob
with read, add, create, write access>” -ErrorBlobUri “< SAS URI of a storage
append blob with read, add, create, write access>”

List all deployed RunCommand resources on a machine

This command returns a full list of previously deployed Run Commands along with their
properties.

PowerShell

Get-AzConnectedMachineRunCommand -ResourceGroupName "myRG" -MachineName

"myMachine"

Get execution status and results

This command retrieves current execution progress, including latest output, start/end
time, exit code, and terminal state of the execution.

PowerShell

Get-AzConnectedMachineRunCommand -ResourceGroupName "myRG" - MachineName

"myMachine" -RunCommandName "RunCommandName"

Create or update Run Command on a machine using

SourceScriptUri (storage blob SAS URL)
Create or update Run Command on a Windows machine using a SAS URL of a storage
blob that contains a PowerShell script. SourceScriptUri can be a storage blob’s full SAS
URL or public URL.

PowerShell

New-AzConnectedMachineRunCommand -ResourceGroupName MyRG0 -MachineName

MyMachine -RunCommandName MyRunCommand -Location EastUS2EUAP -
SourceScriptUri <SourceScriptUri>
 ７ Note

SAS URL must provide read access to the blob. An expiration time of 24 hours is
suggested for SAS URL. SAS URLs can be generated on the Azure portal using blob
options, or SAS token using New-AzStorageBlobSASToken . If generating SAS token
using New-AzStorageBlobSASToken , your SAS URL = "base blob URL" + "?" + "SAS
token from New-AzStorageBlobSASToken "

Get a Run Command Instance View for a machine after

creating or updating Run Command
Get a Run Command for machine with Instance View. Instance View contains the
execution state of run command (Succeeded, Failed, etc.), exit code, standard output,
and standard error generated by executing the script using Run Command. A non-zero
ExitCode indicates an unsuccessful execution.

PowerShell

Get-AzConnectedMachineRunCommand -ResourceGroupName MyRG -MachineName

MyMachine -RunCommandName MyRunCommand

InstanceViewExecutionState : Status of user's Run Command script. Refer to this state to

know whether your script was successful or not.

ProvisioningState : Status of general extension provisioning end to end (whether

extension platform was able to trigger Run Command script or not).

Create or update Run Command on a machine using

SourceScript (script text)
Create or update Run Command on a machine passing the script content directly to -
SourceScript parameter. Use ; to separate multiple commands.

PowerShell

New-AzConnectedMachineRunCommand -ResourceGroupName MyRG0 -MachineName

MyMachine -RunCommandName MyRunCommand2 -Location EastUS2EUAP -SourceScript
"id; echo HelloWorld"
Create or update Run Command on a machine using
OutputBlobUri, ErrorBlobUri to stream standard output
and standard error messages to output and error Append
blobs
Create or update Run Command on a machine and stream standard output and
standard error messages to output and error Append blobs.

PowerShell

New-AzConnectedMachineRunCommand -ResourceGroupName MyRG0 - MachineName

MyMachine -RunCommandName MyRunCommand3 -Location EastUS2EUAP -SourceScript
"id; echo HelloWorld"-OutputBlobUri <OutPutBlobUrI> -ErrorBlobUri
<ErrorBlobUri>

７ Note

Output and error blobs must be the AppendBlob type and their SAS URLs must
provide read, append, create, write access to the blob. An expiration time of 24
hours is suggested for SAS URL. If output or error blob does not exist, a blob of
type AppendBlob will be created. SAS URLs can be generated on Azure portal using
blob's options, or SAS token from using New-AzStorageBlobSASToken .

Create or update Run Command on a machine as a

different user using RunAsUser and RunAsPassword
parameters
Create or update Run Command on a machine as a different user using RunAsUser and
RunAsPassword parameters. For RunAs to work properly, contact the administrator the of

machine and make sure user is added on the machine, user has access to resources
accessed by the Run Command (directories, files, network etc.), and in case of Windows
machine, 'Secondary Logon' service is running on the machine.

PowerShell

New-AzMachineRunCommand -ResourceGroupName MyRG0 -MachineName MyMachine -

RunCommandName MyRunCommand -Location EastUS2EUAP -SourceScript "id; echo
HelloWorld" -RunAsUser myusername -RunAsPassword mypassword
Create or update Run Command on a machine resource
using SourceScriptUri (storage blob SAS URL)
Create or update Run Command on a Windows machine resource using a SAS URL of a
storage blob that contains a PowerShell script.

PowerShell

New-AzMachineRunCommand -ResourceGroupName MyRG0 -MachineName MyMachine -

RunCommandName MyRunCommand -Location EastUS2EUAP -SourceScriptUri
<SourceScriptUri>

７ Note

SAS URL must provide read access to the blob. An expiry time of 24 hours is
suggested for SAS URL. SAS URLs can be generated on Azure portal using blob
options or SAS token using New-AzStorageBlobSASToken . If generating SAS token
using New-AzStorageBlobSASToken , the SAS URL format is: base blob URL + "?" + the
SAS token from New-AzStorageBlobSASToken .

Create or update Run Command on a machine instance

using Parameter and ProtectedParameter parameters
(Public and Protected Parameters to script)
Use ProtectedParameter to pass any sensitive inputs to script such as passwords, keys
etc.

Windows: Parameters and ProtectedParameters are passed to script as arguments

are passed to script and run like this: myscript.ps1 -publicParam1
publicParam1value -publicParam2 publicParam2value -secret1 secret1value -

secret2 secret2value

Linux: Named Parameters and its values are set to environment config, which
should be accessible within the .sh script. For Nameless arguments, pass an empty
string to name input. Nameless arguments are passed to script and run like this:
myscript.sh publicParam1value publicParam2value secret1value secret2value

Delete RunCommand resource from the machine

Remove the RunCommand resource previously deployed on the machine. If the script
execution is still in progress, execution will be terminated.

PowerShell

Remove-AzConnetedMachineRunCommand -ResourceGroupName "myRG" -MachineName

"myMachine" -RunCommandName "RunCommandName"

Run Command operations

Run Command on Azure Arc-enabled servers supports the following operations:

ﾉ Expand table

Operation Description

Create The operation to create a run command. This runs the run command.

Delete The operation to delete a run command. If it's running, delete will also stop the run
command.

Get The operation to get a run command.

List The operation to get all the run commands of an Azure Arc-enabled server.

Update The operation to update the run command. This stops the previous run command.

７ Note

Output and error blobs are overwritten each time the run command script
executes.

Example scenarios
Suppose you have an Azure Arc-enabled server called “2012DatacenterServer1” in
resource group “ContosoRG” with Subscription ID “aaaaaaaa-aaaa-aaaa-aaaa-
aaaaaaaaaaaa”. Consider a scenario where you need to provide remote access to an
endpoint for Windows Server 2012 / R2 servers. Access to Extended Security Updates
enabled by Azure Arc requires access to the endpoint www.microsoft.com/pkiops/certs .
You need to remotely configure a firewall rule that allows access to this endpoint. Use
Run Command in order to allow connectivity to this endpoint.
Example 1: Endpoint access with Run Command
Start off by creating a Run Command script to provide endpoint access to the
www.microsoft.com/pkiops/certs endpoint on your target Arc-enabled server using the

PUT operation.

To directly provide the script in line, use the following operation:

PUT https://management.azure.com/subscriptions/aaaaaaaa-aaaa-aaaa-aaaa-
aaaaaaaaaaaa/resourceGroups/ContosoRG/providers/Microsoft.HybridCompute/mach
ines/2012DatacenterServer1/runCommands/EndpointAccessCommand?api-
version=2023-10-03-preview

{
"location": "eastus2",
"properties": {
"source": {
"script": " New-NetFirewallRule -DisplayName $ruleName -Direction
Outbound -Action Allow -RemoteAddress $endpoint -RemotePort $port -Protocol
$protocol”
},
"parameters": [
{
"name": "ruleName",
"value": " Allow access to www.microsoft.com/pkiops/certs"
},
{
"name": "endpoint",
"value": "www.microsoft.com/pkiops/certs"
},
{
"name": "port",
"value": 433
},
{
"name": "protocol",
"value": "TCP"
}

],
"asyncExecution": false,
"runAsUser": "contoso-user1",
"runAsPassword": "Contoso123!”
"timeoutInSeconds": 3600,
"outputBlobUri":
"https://mystorageaccount.blob.core.windows.net/myscriptoutputcontainer/MySc
riptoutput.txt",
"errorBlobUri":
"https://mystorageaccount.blob.core.windows.net/mycontainer/MyScriptError.tx
t"
 }
}

To instead link to the script file, you can use the Run Command operation’s ScriptURI
option. For this it's assumed you have prepared a newnetfirewallrule.ps1 file
containing the in-line script and uploaded this script to blob storage.

PUT https://management.azure.com/subscriptions/aaaaaaaa-aaaa-aaaa-aaaa-
aaaaaaaaaaaa/resourceGroups/ContosoRG/providers/Microsoft.HybridCompute/mach
ines/2012DatacenterServer1/runCommands/EndpointAccessCommand?api-
version=2023-10-03-preview

{
"location": "eastus2",
"properties": {
"source": {
"scriptUri":
"https://mystorageaccount.blob.core.windows.net/myscriptoutputcontainer/newn
etfirewallrule.ps1"
},
"parameters": [
{
"name": "ruleName",
"value": " Allow access to www.microsoft.com/pkiops/certs"
},
{
"name": "endpoint",
"value": "www.microsoft.com/pkiops/certs"
},
{
"name": "port",
"value": 433
},
{
"name": "protocol",
"value": "TCP"
}

],
"asyncExecution": false,
"runAsUser": "contoso-user1",
"runAsPassword": "Contoso123!”
"timeoutInSeconds": 3600,
"outputBlobUri":
"https://mystorageaccount.blob.core.windows.net/myscriptoutputcontainer/MySc
riptoutput.txt",
"errorBlobUri":
"https://mystorageaccount.blob.core.windows.net/mycontainer/MyScriptError.tx
t"
 }
}

SAS URL must provide read access to the blob. An expiry time of 24 hours is suggested
for SAS URL. SAS URLs can be generated on Azure portal using blobs options or SAS
token using New-AzStorageBlobSASToken . If generating SAS token using New-
AzStorageBlobSASToken , the SAS URL format is: base blob URL + "?" + the SAS token

from New-AzStorageBlobSASToken .

Output and error blobs must be the AppendBlob type and their SAS URLs must provide
read, append, create, write access to the blob. An expiration time of 24 hours is
suggested for SAS URL. SAS URLs can be generated on Azure portal using blob's
options, or SAS token from using New- AzStorageBlobSASToken .

Example 2: Get Run Command details

To verify that you've correctly provisioned the Run Command, use the GET command to
retrieve details on the provisioned Run Command:

GET https://management.azure.com/subscriptions/aaaaaaaa-aaaa-aaaa-aaaa-
aaaaaaaaaaaa/resourceGroups/ContosoRG/providers/Microsoft.HybridCompute/mach
ines/2012DatacenterServer1/runCommands/EndpointAccessCommand?api-
version=2023-10-03-preview

Example 3: Update the Run Command

Let’s suppose you want to open up access to an additional endpoint *.waconazure.com
for connectivity to Windows Admin Center. You can update the existing Run Command
with new parameters:

PATCH https://management.azure.com/subscriptions/aaaaaaaa-aaaa-aaaa-aaaa-
aaaaaaaaaaaa/resourceGroups/ContosoRG/providers/Microsoft.HybridCompute/mach
ines/2012DatacenterServer1/runCommands/EndpointAccessCommand?api-
version=2023-10-03-preview

{
"location": "eastus2",
"properties": {
"source": {
"script": " New-NetFirewallRule -DisplayName $ruleName -Direction
Outbound -Action Allow -RemoteAddress $endpoint -RemotePort $port -Protocol
 $protocol”
},
"parameters": [
{
"name": "ruleName",
"value": " Allow access to WAC endpoint"
},
{
"name": "endpoint",
"value": “*.waconazure.com”
},
{
"name": "port",
"value": 433
},
{
"name": "protocol",
"value": "TCP"
}
],
"asyncExecution": false,
"runAsUser": "contoso-user1",
"runAsPassword": "Contoso123!",
"timeoutInSeconds": 3600,
"outputBlobUri":
"https://mystorageaccount.blob.core.windows.net/myscriptoutputcontainer/MySc
riptoutput.txt",
"errorBlobUri":
"https://mystorageaccount.blob.core.windows.net/mycontainer/MyScriptError.tx
t"
}
}

Example 4: List Run Commands

Ahead of deleting the Run Command for Endpoint Access, make sure there are no other
Run Commands for the Arc-enabled server. You can use the list command to get all of
the Run Commands:

LIST https://management.azure.com/subscriptions/aaaaaaaa-aaaa-aaaa-aaaa-
aaaaaaaaaaaa/resourceGroups/ContosoRG/providers/Microsoft.HybridCompute/mach
ines/2012DatacenterServer1/runCommands/

Example 5: Delete a Run Command

If you no longer need the Run Command extension, you can delete it using the
following command:

DELETE https://management.azure.com/subscriptions/ aaaaaaaa-aaaa-aaaa-aaaa-

aaaaaaaaaaaa/resourceGroups/ContosoRG/providers/Microsoft.HybridCompute/mach
ines/2012DatacenterServer1/runCommands/EndpointAccessCommand?api-
version=2023-10-03-preview

Disabling Run Command

To disable the Run Command on Azure Arc-enabled servers, open an administrative
command prompt and run the following commands. These commands use the local
agent configuration capabilities for the Connected Machine agent in the Extension
blocklist.

Windows

azcmagent config set extensions.blocklist

"microsoft.cplat.core/runcommandhandlerwindows"

Linux

sudo azcmagent config set extensions.blocklist

"microsoft.cplat.core/runcommandhandlerlinux"
Organize and inventory servers with
hierarchies, tagging, and reporting
Article • 03/15/2023

Azure Arc-enabled servers allows customers to develop an inventory across hybrid,

multicloud, and edge workloads with the organizational and reporting capabilities native
to Azure management. Azure Arc-enabled servers supports a breadth of platforms and
distributions across Windows and Linux. Arc-enabled servers is also domain agnostic
and integrates with Azure Lighthouse for multi-tenant customers.

By projecting resources into the Azure management plane, Azure Arc empowers
customers to leverage the organizational, tagging, and querying capabilities native to
Azure.

Organize resources with built-in Azure

hierarchies
Azure provides four levels of management scope:

Management groups
Subscriptions
Resource groups
Resources

These levels of management help to manage access, policies, and compliance more
efficiently. For example, if you apply a policy at one level, it propagates down to lower
levels, helping improve governance posture. Moreover, these levels can be used to
scope policies and security controls. For Arc-enabled servers, the different business
units, applications, or workloads can be used to derive the hierarchical structure in
Azure. Once resources have been onboarded to Azure Arc, you can seamlessly move an
Arc-enabled server between different resource groups and scopes.
Tagging resources to capture additional,
customizable metadata
Tags are metadata elements you apply to your Azure resources. They are key-value pairs
that help identify resources, based on settings relevant to your organization. For
example, you can tag the environment for a resource as Production or Testing.
Alternatively, you can use tagging to capture the ownership for a resource, separating
the Creator or Administrator. Tags can also capture details on the resource itself, such as
the physical datacenter, business unit, or workload. You can apply tags to your Azure
resources, resource groups, and subscriptions. This extends to infrastructure outside of
Azure as well, through Azure Arc.

You can define tags in Azure portal through a simple point and click method. Tags can
be defined when onboarding servers to Azure Arc-enabled servers or on a per-server
basis. Alternatively, you can use Azure CLI, Azure PowerShell, ARM templates, or Azure
policy for scalable tag deployments. Tags can be used to filter operations as well, such as
the deployment of extensions or service attachments. This provides not only a more
comprehensive inventory of your servers, but also operational flexibility and ease of
management.
Reporting and querying with Azure Resource
Graph (ARG)
Numerous types of data are collected with Azure Arc-enabled servers as part of the
instance metadata. This includes the platform, operating system, presence of SQL server,
or AWS and GCP details. These attributes can be queried at scale using Azure Resource
Graph.

Azure Resource Graph is an Azure service designed to extend Azure Resource

Management by providing efficient and performant resource exploration with the ability
to query at scale across a given set of subscriptions so that you can effectively govern
your environment. These queries provide the ability to query resources with complex
filtering, grouping, and sorting by resource properties.

Results can be easily visualized and exported to other reporting solutions. Moreover
there are dozens of built-in Azure Resource Graph queries capturing salient information
across Azure VMs and Arc-enabled servers, such as their VM extensions, regional
breakdown, and operating systems.

Additional resources
What is Azure Resource Graph?
Azure Resource Graph sample queries for Azure Arc-enabled servers

Use tags to organize your Azure resources and management hierarchy

Connect your non-Azure machines to
Microsoft Defender for Cloud
Article • 01/03/2024

Microsoft Defender for Cloud can monitor the security posture of your non-Azure
machines, but first you need to connect them to Azure.

You can connect your non-Azure computers in any of the following ways:

Onboarding with Azure Arc:

By using Azure Arc-enabled servers (recommended)
By using the Azure portal
Onboarding directly with Microsoft Defender for Endpoint

This article describes the methods for onboarding with Azure Arc.

If you're connecting machines from other cloud providers, see Connect your AWS
account or Connect your GCP project. The multicloud connectors for Amazon Web
Services (AWS) and Google Cloud Platform (GCP) in Defender for Cloud transparently
handle the Azure Arc deployment for you.

Prerequisites
To complete the procedures in this article, you need:

A Microsoft Azure subscription. If you don't have an Azure subscription, you can
sign up for a free one .

Microsoft Defender for Cloud set up on your Azure subscription.

Access to an on-premises machine.

Connect on-premises machines by using Azure

Arc
A machine that has Azure Arc-enabled servers becomes an Azure resource. When you
install the Log Analytics agent on it, it appears in Defender for Cloud with
recommendations, like your other Azure resources.

Azure Arc-enabled servers provide enhanced capabilities, such as enabling guest

configuration policies on the machine and simplifying deployment with other Azure
services. For an overview of the benefits of Azure Arc-enabled servers, see Supported
cloud operations.

To deploy Azure Arc on one machine, follow the instructions in Quickstart: Connect
hybrid machines with Azure Arc-enabled servers.

To deploy Azure Arc on multiple machines at scale, follow the instructions in Connect
hybrid machines to Azure at scale.

Defender for Cloud tools for automatically deploying the Log Analytics agent work with
machines running Azure Arc. However, this capability is currently in preview. When you
connect your machines by using Azure Arc, use the relevant Defender for Cloud
recommendation to deploy the agent and benefit from the full range of protections that
Defender for Cloud offers:

Log Analytics agent should be installed on your Linux-based Azure Arc machines
Log Analytics agent should be installed on your Windows-based Azure Arc
machines

Connect on-premises machines by using the

Azure portal
After you connect Defender for Cloud to your Azure subscription, you can start
connecting your on-premises machines from the Getting started page in Defender for
Cloud.

1. Sign in to the Azure portal .

2. Search for and select Microsoft Defender for Cloud.

3. On the Defender for Cloud menu, select Getting started.

4. Select the Get started tab.

5. Find Add non-Azure servers and select Configure.

 

A list of your Log Analytics workspaces appears.

6. (Optional) If you don't already have a Log Analytics workspace in which to store
the data, select Create new workspace and follow the on-screen guidance.

7. From the list of workspaces, select Upgrade for the relevant workspace to turn on
Defender for Cloud paid plans for 30 free days.

8. From the list of workspaces, select Add Servers for the relevant workspace.

9. On the Agents management page, choose one of the following procedures,

depending on the type of machines you're onboarding:

Onboard your Windows server

Onboard your Linux server

Onboard your Windows server

When you add a Windows server, you need to get the information on the Agents
management page and download the appropriate agent file (32 bit or 64 bit).

To onboard a Windows server:

1. Select Windows servers.

2. Select the Download Windows Agent link that's applicable to your computer
processor type to download the setup file.

3. From the Agents management page, copy the Workspace ID and Primary Key
values into Notepad.

4. Copy the downloaded setup file to the target computer and run it.

5. Follow the installation wizard (select Next > I Agree > Next > Next).

6. On the Azure Log Analytics page, paste the Workspace ID and Primary Key values
that you copied into Notepad.

7. If the computer should report to a Log Analytics workspace in the Azure

Government cloud, select Azure US Government from the Azure Cloud dropdown
list.

8. If the computer needs to communicate through a proxy server to the Log Analytics
service, select Advanced. Then provide the URL and port number of the proxy
server.
 9. When you finish entering all of the configuration settings, select Next.

10. On the Ready to Install page, review the settings to be applied and select Install.

11. On the Configuration completed successfully page, select Finish.

When the process is complete, Microsoft Monitoring agent appears in Control Panel.
You can review your configuration there and verify that the agent is connected.

For more information on installing and configuring the agent, see Connect Windows
machines.

Onboard your Linux server

To add Linux machines, you need the wget command from the Agents management
page.

To onboard your Linux server:

1. Select Linux servers.

2. Copy the wget command into Notepad. Save this file to a location that you can
access from your Linux computer.

3. On your Linux computer, open the file that contains the wget command. Copy the
entire contents and paste them into a terminal console.

4. When the installation finishes, validate that the Operations Management Suite
Agent is installed by running the pgrep command. The command returns the
omsagent persistent ID.

You can find the logs for the agent at /var/opt/microsoft/omsagent/<workspace

id>/log/ . The new Linux machine might take up to 30 minutes to appear in

Defender for Cloud.

Verify that your machines are connected
Your Azure and on-premises machines are available to view in one location.

To verify that your machines are connected:

1. Sign in to the Azure portal .

2. Search for and select Microsoft Defender for Cloud.

3. On the Defender for Cloud menu, select Inventory to show the asset inventory.

4. Filter the page to view the relevant resource types. These icons distinguish the
types:

Non-Azure machine

Azure VM

Azure Arc-enabled server

Integrate with Microsoft Defender XDR

When you enable Defender for Cloud, Defender for Cloud's alerts are automatically
integrated into the Microsoft Defender Portal. No further steps are needed.

The integration between Microsoft Defender for Cloud and Microsoft Defender XDR
brings your cloud environments into Microsoft Defender XDR. With Defender for
Cloud's alerts and cloud correlations integrated into Microsoft Defender XDR, SOC
teams can now access all security information from a single interface.

Learn more about Defender for Cloud's alerts in Microsoft Defender XDR.

Clean up resources
There's no need to clean up any resources for this article.

Next steps
Protect all of your resources with Defender for Cloud.
Set up your AWS account and GCP projects.
Manage Azure Arc-enabled Servers
using Windows Admin Center in Azure
(preview)
Article • 11/22/2023

） Important

Windows Admin Center in the Azure portal is currently in preview. See the
Supplemental Terms of Use for Microsoft Azure Previews for legal terms that
apply to Azure features that are in beta, preview, or otherwise not yet released into
general availability.

） Important

Updating to the latest versions (1.36 and 1.35) of the Azure Connected Machine
Agent (Arc agent) breaks connection to Windows Admin Center. This will be fixed in
the December release of the agent (1.37). This message will be updated once that
has been released. If you have upgraded and wish to downgrade, you can
download version 1.34 .

Using Windows Admin Center in the Azure portal you can manage the Windows Server
operating system of your Arc-enabled servers, known as hybrid machines. You can
securely manage hybrid machines from anywhere–without needing a VPN, public IP
address, or other inbound connectivity to your machine.

With Windows Admin Center extension in Azure, you get the management,
configuration, troubleshooting, and maintenance functionality for managing your Arc-
enabled servers in the Azure portal. Windows Server infrastructure and workload
management no longer requires you to establish line-of-sight or Remote Desktop
Protocol (RDP)–it can all be done natively from the Azure portal. Windows Admin Center
provides tools that you'd normally find in Server Manager, Device Manager, Task
Manager, Hyper-V Manager, and most other Microsoft Management Console (MMC)
tools.

This article provides an overview of using Windows Admin Center in the Azure portal,
requirements, and how to install Windows Admin Center in the Azure portal and use it
to manage your hybrid machine. It also answers frequently asked questions, and
provides a list of known issues and tips for troubleshooting in case something doesn't
work.

Overview of Windows Admin Center in Azure

Windows Admin Center in the Azure portal provides essential tools for managing
Windows Server running on a single hybrid machine. You can manage hybrid machines
without the need to open any inbound ports on your firewall.

Using Windows Admin Center in the Azure portal, you can manage:

Certificates
Devices
Events
Files and file sharing
Firewall
Installed apps
Local users and groups
Performance Monitor
PowerShell
Processes
Registry
Remote Desktop
Roles and Features
Scheduled tasks
Services
Storage
 Updates
Virtual machines
Virtual switches

We don't support other extensions for Windows Admin Center in the Azure portal at this
time.

２ Warning

If you manually installed Windows Admin Center on your hybrid machine to

manage multiple systems, enabling Windows Admin Center in Azure will replace
your existing instance of Windows Admin Center and removes the capability to
manage other machines. You will lose access to your previously deployed instance
of Windows Admin Center.

Requirements
This section provides the requirements for using Windows Admin Center in the Azure
portal to manage a hybrid machine:

Azure account with an active subscription

Azure permissions
Azure region availability
Hybrid machine requirements
Networking requirements

Azure account with an active subscription

You'll need an Azure account with an active subscription to deploy Windows Admin
Center. If you don't have one already, you can create an account for free .

During the deployment of Windows Admin Center, we will attempt to register the
Microsoft.HybridConnectivity resource provider for your subscription.

） Important

You must have permission to register a resource provider, which requires the
*/register/action operation. This is included if you are assigned the contributor

or owner role on your subscription.

 ７ Note

Resource provider registration is a one time task per subscription.

To check the status of the resource provider and register if needed:

1. Sign in to the Azure portal .

2. Select Subscriptions.
3. Select the name of your subscription.
4. Select Resource providers.
5. Search for Microsoft.HybridConnectivity.
6. Verify that the status of Microsoft.HybridConnectivity is Registered.
a. If the status is NotRegistered, select Microsoft.HybridConnectivity, and then
select Register.

Azure permissions
To install the Windows Admin Center extension for an Arc-enabled server resource, your
account must be granted the Owner, Contributor, or Windows Admin Center
Administrator Login role in Azure.

Connecting to Windows Admin center requires you to have Reader and Windows
Admin Center Administrator Login permissions at the Arc-enabled server resource.

Learn more about assigning Azure roles using the Azure portal

Azure region availability

Windows Admin Center is supported in the following Azure regions:

Australia East
Brazil South
Canada Central
Canada East
Central India
Central US
East Asia
East US
East US 2
France Central
Japan East
 Korea Central
North Central US
North Europe
South Africa North
South Central US
Southeast Asia
Sweden Central
Switzerland North
UAE North
UK South
UK West
West Central US
West Europe
West US
West US 2
West US 3

７ Note

Windows Admin Center isn't supported in Azure China 21Vianet, Azure

Government, or other non-public clouds

Hybrid machine requirements

To use Windows Admin Center in the Azure portal, the Windows Admin Center agent
must be installed on each hybrid machine you wish to manage via an Azure VM
extension. The hybrid machine should meet the following requirements:

Windows Server 2016 or later

3 GB of RAM or more
Azure Arc agent version 1.13.21320.014 or later

Networking requirements
The hybrid machine must meet the following networking requirements:

Outbound internet access or an outbound port rule allowing HTTPS traffic to the
following endpoints:
*service.waconazure.com or the WindowsAdminCenter service tag

pas.windows.net
 *.servicebus.windows.net

７ Note

No inbound ports are required in order to use Windows Admin Center.

The management machine where the Azure Portal is running must meet the following
networking requirements:

Outbound internet access over port 443

Make sure you review the supported devices and recommended browsers before
accessing the Azure portal from the management machine or system.

Install Windows Admin Center in the Azure

portal
Before you can use Windows Admin Center in the Azure portal, you must deploy the
Windows Admin Center VM extension using the following steps:

1. Open the Azure portal and navigate to your Arc-enabled server.

2. Under the Settings group, select Windows Admin Center.
3. Specify the port on which you wish to install Windows Admin Center, and then
select Install.


Connecting to Windows Admin Center in the
Azure portal
After you've installed Windows Admin Center on your hybrid machine, perform the
following steps to connect to it and use it to manage Windows Server:

1. Open the Azure portal and navigate to your Arc-enabled server, and then under
the Settings group, select Windows Admin Center (preview).
2. Select Connect.

７ Note

Starting August 2022, Windows Admin Center now allows you to use Azure AD-
based authentication for your hybrid machine. You will no longer be prompted for
the credentials of a local administrator account.

Windows Admin Center opens in the portal, giving you access to the same tools you
might be familiar with from using Windows Admin Center in an on-premises
deployment.

Configuring role assignments

Access to Windows Admin Center is controlled by the Windows Admin Center
Administrator Login Azure role.
 ７ Note

The Windows Admin Center Administrator Login role uses dataActions and thus
cannot be assigned at management group scope. Currently these roles can only be
assigned at the subscription, resource group or resource scope.

To configure role assignments for your hybrid machines using the Azure AD Portal
experience:

1. Open the hybrid machine that you wish to manage using Windows Admin Center

2. Select Access control (IAM).

3. Select Add > Add role assignment to open the Add role assignment page.

4. Assign the following role. For detailed steps, see Assign Azure roles using the
Azure portal.

Setting Value

Role Windows Admin Center Administrator Login

Assign access to User, group, service principal, or managed identity

For more information on how to use Azure RBAC to manage access to your Azure
subscription resources, see the following articles:

Assign Azure roles using Azure CLI

Assign Azure roles using the Azure CLI examples. Azure CLI can also be used in the
Azure Cloud Shell experience.
Assign Azure roles using the Azure portal
Assign Azure roles using Azure PowerShell.

Proxy configuration
If the machine connects through a proxy server to communicate over the internet,
review the following requirements to understand the network configuration required.

The Windows Admin Center extension can communicate through a proxy server by
using the HTTPS protocol. Use the extensions settings for configuration as described in
the following steps. Authenticated proxies are not supported.

７ Note
 Proxy configuration is only supported for extension versions greater than 0.0.0.321.

1. Use this flowchart to determine the values of the Settings parameters

2. After you determine the Settings parameter values, provide these other
parameters when you deploy the AdminCenter Agent. Use PowerShell commands,
as shown in the following example:

PowerShell

$wacPort = "6516"
$settings = @{"port" = $wacPort; "proxy" = @{"mode" = "application";
"address" = "http://[address]:[port]";}}
New-AzConnectedMachineExtension -Name AdminCenter -ExtensionType AdminCenter
-Publisher Microsoft.AdminCenter -ResourceGroupName <resource-group-name> -
MachineName <arc-server-name> -Location <arc-server-location> -Setting
$settings -SubscriptionId <subscription-id>

How it works
By using Windows Admin Center in Azure, you can connect to your hybrid machine
without requiring any inbound port to be enabled on the firewall. Windows Admin
Center, via the Arc agent, is able to securely establish a reverse proxy session connection
with the Azure Arc service in an outbound manner.

For each hybrid machine that you want to manage with Windows Admin Center in the
Azure portal, you must deploy an agent to each machine.

The agent communicates to an external service that manages certificates so that you
can easily connect to your hybrid machine.

Clicking Install performs the following actions:

1. Registers the Microsoft.HybridConnectivity resource provider on your subscription.

The resource provider hosts the proxy used for communication to your Arc-
enabled server.
2. Deploys an Azure endpoint resource on top of your Arc-enabled resource that
enables a reverse proxy connection on the specified port. This is simply a logical
resource in Azure, and doesn't deploy anything on your server itself.
3. Installs the Windows Admin Center agent on your hybrid machine with a valid TLS
certificate.

７ Note

Uninstalling Windows Admin Center does not delete the logical Azure endpoint
resource. This is kept for other experiences that might leverage this resource, such
as SSH.

Clicking Connect performs the following actions:

1. The Azure portal asks the Microsoft.HybridConnectivity resource provider for access
to the Arc-enabled server.
2. The resource provider communicates with a Layer 4 SNI proxy to establish a short-
lived session-specific access to your Arc-enabled server on the Windows Admin
Center port.
3. A unique short-lived URL is generated and connection to Windows Admin Center
is established from the Azure portal.

Connection to Windows Admin Center is end-to-end encrypted with SSL termination

happening on your hybrid machine.
Automate Windows Admin Center deployment
using PowerShell
You can automate Windows Admin Center deployment in Azure portal using this
example PowerShell script.

PowerShell

$location = "<location_of_hybrid_machine>"
$machineName = "<name_of_hybrid_machine>"
$resourceGroup = "<resource_group>"
$subscription = "<subscription_id>"
$port = "6516"

#Deploy Windows Admin Center

$Setting = @{"port" = $port; "proxy" = @{"mode" = "application"; "address" =
"http://[address]:[port]";}} #proxy configuration is optional
New-AzConnectedMachineExtension -Name "AdminCenter" -ResourceGroupName
$resourceGroup -MachineName $machineName -Location $location -Publisher
"Microsoft.AdminCenter" -Settings $Setting -ExtensionType "AdminCenter" -
SubscriptionId $subscription

#Allow connectivity
$putPayload = "{'properties': {'type': 'default'}}"
Invoke-AzRestMethod -Method PUT -Uri
"https://management.azure.com/subscriptions/${subscription}/resourceGroups/$
{resourceGroup}/providers/Microsoft.HybridCompute/machines/${machineName}/pr
oviders/Microsoft.HybridConnectivity/endpoints/default?api-version=2023-03-
15" -Payload $putPayload

$patch = @{ "properties" = @{ "serviceName" = "WAC"; "port" = $port}}

$patchPayload = ConvertTo-Json $patch
Invoke-AzRestMethod -Method PUT -Path
/subscriptions/${subscription}/resourceGroups/${resourceGroup}/providers/Mic
rosoft.HybridCompute/machines/${machineName}/providers/Microsoft.HybridConne
ctivity/endpoints/default/serviceconfigurations/WAC?api-version=2023-03-15 -
Payload $patchPayload

Troubleshooting
Here are some tips to try in case something isn't working. For general Windows Admin
Center troubleshooting (not specifically in Azure), see Troubleshooting Windows Admin
Center.

Failed to connect with "404 endpoint not found"

 1. Updating to the latest versions (1.36 and 1.35) of the Azure Connected Machine
Agent (Arc agent) breaks connection to Windows Admin Center. This will be fixed
in the December release of the agent (1.37). This message will be updated once
that has been released.
2. If you have upgraded and wish to downgrade, you can download version 1.34 .

Failed to connect error

1. Restart the HIMDS service.

a. RDP into your server.

b. Open PowerShell as an administrator and run:

PowerShell

Restart-Service -Name himds

2. Check that your Extension version is 0.0.0.169 or higher.

a. Navigate to "Extensions"
b. Check that the "AdminCenter" extension version is 0.0.0.169 or higher
c. If not, uninstall the extension and reinstall it

3. Make sure that the Windows Admin Center service is running on your machine.
a. RDP into your server.
b. Open Task Manager (Ctrl+Shift+Esc) and navigate to Services.
c. Make sure ServerManagementGateway / Windows Admin Center is running.
d. If it isn't running, start the service.

4. Check that the port is enabled for reverse proxy session.

a. RDP into your server.

b. Open PowerShell as an administrator and run:

PowerShell

azcmagent config list

c. This should return a list of ports under the incomingconnections.ports (preview)

configuration that are enabled to be connected from Azure. Confirm that the
port on which you installed Windows Admin Center is on this list. For example, if
Windows Admin Center is installed on port 443, the result would be:
 Output

Local configuration setting

incomingconnections.ports (preview): 443

d. In the event it isn't on this list, run

PowerShell

azcmagent config set incomingconnections.ports <port>

If you're using another experience (like SSH) using this solution, you can specify
multiple ports separated by a comma.

5. Ensure you have outbound connectivity to the necessary ports

a. The hybrid machine should have outbound connectivity to the following
endpoints:

*.wac.azure.com , *.waconazure.com or the WindowsAdminCenter

ServiceTag
pas.windows.net

*.servicebus.windows.net

One of the Windows Admin Center tools isn’t loading or

gives an error
1. Navigate to any other tool in Windows Admin Center and navigate back to the one
that isn’t loading.

2. If no other tool is loading, there might be a problem with your network

connectivity. Try closing the blade and then connecting again. If this doesn’t work,
open a support ticket.

The Windows Admin Center extension failed to install

1. Double-check to make sure that the hybrid machine meets the requirements.

2. Make sure that outbound traffic to Windows Admin Center is allowed on your
hybrid machine

a. Test connectivity by running the following command using PowerShell inside of

your virtual machine:
 PowerShell

Invoke-RestMethod -Method GET -Uri

https://<your_region>.service.waconazure.com

Expected

Microsoft Certificate and DNS service for Windows Admin Center in

the Azure Portal

3. If you've allowed all outbound traffic and are getting an error from the command
above, check that there are no firewall rules blocking the connection.

If nothing seems wrong and Windows Admin Center still won't install, open a support
request with the following information:

Logs from the Azure portal. Windows Admin Center logs can be found under
Settings > Extensions > AdminCenter > View Detailed Status.

Logs in the hybrid machine. Run the following PowerShell command and share the
resulting .zip file.

PowerShell

azcmagent logs

Network trace, if appropriate. Network traces can contain customer data and
sensitive security details, such as passwords, so we recommend reviewing the trace
and removing any sensitive details before sharing it.

Known issues
Chrome incognito mode isn't supported.
Azure portal desktop app isn't supported.
Detailed error messages for failed connections aren't yet available.

Frequently asked questions

Find answers to the frequently asked questions about using Windows Admin Center in
Azure.
How much does it cost to use Windows Admin Center?
There's no associated cost using the Windows Admin Center in the Azure portal.

Can I use Windows Admin Center to manage the virtual

machines running on my server?
You can install the Hyper-V role using the Roles and Features extension. Once installed,
refresh your browser, and Windows Admin Center will show the Virtual Machine and
Switch extensions.

What servers can I manage using this extension?

You can use the capability to manage Arc-enabled Windows Server 2016 and later. You
can also use Windows Admin Center in Azure to manage Azure Stack HCI.

How does Windows Admin Center handle security?

Traffic from the Azure portal to Windows Admin Center is end-to-end encrypted. Your
Arc-enabled server is managed using PowerShell and WMI over WinRM.

Do I need an inbound port to use Windows Admin

Center?
No inbound connection is required to use Windows Admin Center.

Why must I create an outbound port rule?

An outbound port rule is required for the service that we have built to communicate
with your server. Our service issues you a certificate free-of-cost for your instance of
Windows Admin Center. This service ensures that you can always connect to your
instance of Windows Admin Center from the Azure portal by keeping your WAC
certificate up to date.

Furthermore, accessing Windows Admin Center from Azure requires no inbound port
and only outbound connectivity via a reverse proxy solution. These outbound rules are
required in order to establish the connection.

How do I find the port used for Windows Admin Center

installation?
To verify the value of SmePort registry setting:

1. RDP into your server

2. Open the Registry Editor
3. Navigate to the key
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManagementGateway

4. Read the value of SmePort to find the port used

Can I use PowerShell or the Azure CLI to install the

extension on my VM?
Yes, to install the extension using the Azure CLI, run the following command from a
command prompt:

Azure CLI

az connectedmachine extension create

You can also install the extension using PowerShell. Learn more about how to automate
Windows Admin Center deployment using PowerShell.

I already have Windows Admin Center installed on my

Arc server. Can I access it from the portal?
Yes. You can follow the same steps outlined in this document.

２ Warning

Enabling this capability will replace your existing instance of Windows Admin
Center and removes the capability to manage other machines. Your previously
deployed instance of Windows Admin Center will no longer be usable. Please don’t
do this if you use your instance of Admin Center to manage multiple servers.

Next steps
Learn about Windows Admin Center
Learn about managing servers with Windows Admin Center
Learn about Azure Arc
SSH access to Azure Arc-enabled servers
Article • 07/10/2023

SSH for Arc-enabled servers enables SSH based connections to Arc-enabled servers
without requiring a public IP address or additional open ports. This functionality can be
used interactively, automated, or with existing SSH based tooling, allowing existing
management tools to have a greater impact on Azure Arc-enabled servers.

Key benefits
SSH access to Arc-enabled servers provides the following key benefits:

No public IP address or open SSH ports required

Access to Windows and Linux machines
Ability to log in as a local user or an Azure user (Linux only)
Support for other OpenSSH based tooling with config file support

Prerequisites
To enable this functionality, ensure the following:

Ensure the Arc-enabled server has a hybrid agent version of "1.31.xxxx" or higher.
Run: azcmagent show on your Arc-enabled Server.
Ensure the Arc-enabled server has the "sshd" service enabled. For Linux machines
openssh-server can be installed via a package manager and needs to be enabled.

SSHD needs to be enabled on Windows.

Ensure you have the Owner or Contributer role assigned.

Authenticating with Azure AD credentials has additional requirements:

aadsshlogin and aadsshlogin-selinux (as appropriate) must be installed on the

Arc-enabled server. These packages are installed with the Azure AD based SSH
Login – Azure Arc VM extension.

Configure role assignments for the VM. Two Azure roles are used to authorize VM
login:
Virtual Machine Administrator Login: Users who have this role assigned can
log in to an Azure virtual machine with administrator privileges.
Virtual Machine User Login: Users who have this role assigned can log in to an
Azure virtual machine with regular user privileges.
 An Azure user who has the Owner or Contributor role assigned for a VM doesn't
automatically have privileges to Azure AD login to the VM over SSH. There's an
intentional (and audited) separation between the set of people who control virtual
machines and the set of people who can access virtual machines.

７ Note

The Virtual Machine Administrator Login and Virtual Machine User Login roles
use dataActions and can be assigned at the management group,
subscription, resource group, or resource scope. We recommend that you
assign the roles at the management group, subscription, or resource level and
not at the individual VM level. This practice avoids the risk of reaching the
Azure role assignments limit per subscription.

Availability
SSH access to Arc-enabled servers is currently supported in all regions supported by
Arc-Enabled Servers with the following exceptions:

Germany West Central

Getting started

Register the HybridConnectivity resource provider

７ Note

This is a one-time operation that needs to be performed on each subscription.

Check if the HybridConnectivity resource provider (RP) has been registered:

az provider show -n Microsoft.HybridConnectivity

If the RP hasn't been registered, run the following:

az provider register -n Microsoft.HybridConnectivity

This operation can take 2-5 minutes to complete. Before moving on, check that the RP
has been registered.
Create default connectivity endpoint

７ Note

The following step will not need to be run for most users as it should complete
automatically at first connection. This step must be completed for each Arc-enabled
server.

Create the default endpoint with Azure CLI:

Bash

az rest --method put --uri

https://management.azure.com/subscriptions/<subscription>/resourceGroups
/<resourcegroup>/providers/Microsoft.HybridCompute/machines/<arc enabled
server name>/providers/Microsoft.HybridConnectivity/endpoints/default?
api-version=2023-03-15 --body '{"properties": {"type": "default"}}'

７ Note

If using Azure CLI from PowerShell, the following should be used.

PowerShell

az rest --method put --uri

https://management.azure.com/subscriptions/<subscription>/resourceGroups
/<resourcegroup>/providers/Microsoft.HybridCompute/machines/<arc enabled
server name>/providers/Microsoft.HybridConnectivity/endpoints/default?
api-version=2023-03-15 --body '{\"properties\":{\"type\":\"default\"}}'

Validate endpoint creation:

Bash

az rest --method get --uri

https://management.azure.com/subscriptions/<subscription>/resourceGroups
/<resourcegroup>/providers/Microsoft.HybridCompute/machines/<arc enabled
server name>/providers/Microsoft.HybridConnectivity/endpoints/default?
api-version=2023-03-15

Install local command line tool

This functionality is currently packaged in an Azure CLI extension and an Azure
PowerShell module.

Install Azure CLI extension

az extension add --name ssh

７ Note

The Azure CLI extension version must be greater than 2.0.0.

Enable functionality on your Arc-enabled server

In order to use the SSH connect feature, you must update the Service Configuration in
the Connectivity Endpoint on the Arc-Enabled Server to allow SSH connection to a
specific port. You may only allow connection to a single port. The CLI tools attempt to
update the allowed port at runtime, but the port can be manually configured with the
following:

７ Note

There may be a delay after updating the Service Configuration until you are able to
connect.

Azure CLI

az rest --method put --uri

https://management.azure.com/subscriptions/<subscription>/resourceGroups/<resou

rcegroup>/providers/Microsoft.HybridCompute/machines/<arc enabled server

name>/providers/Microsoft.HybridConnectivity/endpoints/default/serviceconfigura

tions/SSH?api-version=2023-03-15 --body '{\"properties\": {\"serviceName\":

\"SSH\", \"port\": \"22\"}}'

If you're using a nondefault port for your SSH connection, replace port 22 with your
desired port in the previous command.

Optional: Install Azure AD login extension

The Azure AD based SSH Login – Azure Arc VM extension can be added from the
extensions menu of the Arc server. The Azure AD login extension can also be installed
locally via a package manager via: apt-get install aadsshlogin or the following
command.

az connectedmachine extension create --machine-name <arc enabled server name> --

resource-group <resourcegroup> --publisher Microsoft.Azure.ActiveDirectory --name

AADSSHLogin --type AADSSHLoginForLinux --location <location>

Examples
To view examples, view the Az CLI documentation page for az ssh or the Azure
PowerShell documentation page for Az.Ssh.

Next steps
Learn about OpenSSH for Windows
Learn about troubleshooting SSH access to Azure Arc-enabled servers.
Learn about troubleshooting agent connection issues.
PowerShell remoting to Azure Arc-
enabled servers
Article • 04/09/2024

SSH for Arc-enabled servers enables SSH based connections to Arc-enabled servers
without requiring a public IP address or additional open ports. PowerShell remoting over
SSH is available for Windows and Linux machines.

Prerequisites
To leverage PowerShell remoting over SSH access to Azure Arc-enabled servers, ensure
the following:

Ensure the requirements for SSH access to Azure Arc-enabled servers are met.
Ensure the requirements for PowerShell remoting over SSH are met.
The Azure PowerShell module or the Azure CLI extension for connecting to Arc
machines is present on the client machine.

How to connect via PowerShell remoting

Follow the below steps to connect via PowerShell remoting to an Arc-enabled server.

Generate a SSH config file with Azure CLI:

Bash

az ssh config --resource-group <myRG> --name <myMachine> --local-user

<localUser> --resource-type Microsoft.HybridCompute --file <SSH config
file>

Find newly created entry in the SSH config file

Open the created or modified SSH config file. The entry should have a similar format to
the following.

PowerShell

Host <myRG>-<myMachine>-<localUser>
HostName <myMachine>
 User <localUser>
ProxyCommand "<path to
proxy>\.clientsshproxy\sshProxy_windows_amd64_1_3_022941.exe" -r "<path to
relay info>\az_ssh_config\<myRG>-<myMachine>\<myRG>-<myMachine>-relay_info"

Leveraging the -Options parameter

Levering the options parameter allows you to specify a hashtable of SSH options used
when connecting to a remote SSH-based session. Create the hashtable by following the
below format. Be mindful of the locations of quotation marks.

PowerShell

$options = @{ProxyCommand = '"<path to

proxy>\.clientsshproxy\sshProxy_windows_amd64_1_3_022941.exe -r <path to
relay info>\az_ssh_config\<myRG>-<myMachine>\<myRG>-<myMachine>-
relay_info"'}

Next leverage the options hashtable in a PowerShell remoting command.

PowerShell

New-PSSession -HostName <myMachine> -UserName <localUser> -Options $options

Next steps
Learn about OpenSSH for Windows
Learn about troubleshooting SSH access to Azure Arc-enabled servers.
Learn about troubleshooting agent connection issues.
Troubleshoot SSH access to Azure Arc-
enabled servers
Article • 01/29/2024

This article provides information on troubleshooting and resolving issues that may occur
while attempting to connect to Azure Arc-enabled servers via SSH. For general
information, see SSH access to Arc-enabled servers overview.

Client-side issues
These issues are due to errors that occur on the machine that the user is connecting
from.

Unable to locate client binaries

This issue occurs when the client side SSH binaries required to connect aren't found.
Possible errors:

Failed to create ssh key file with error: \<ERROR\>.

Failed to run ssh command with error: \<ERROR\>.

Failed to get certificate info with error: \<ERROR\>.

Failed to create ssh key file with error: [WinError 2] The system cannot find
the file specified.

Failed to create ssh key file with error: [Errno 2] No such file or directory:

'ssh-keygen'.

Resolution:

Provide the path to the folder that contains the SSH client executables by using the
--ssh-client-folder parameter.

Ensure that the folder is in the PATH environment variable for Azure PowerShell

Azure PowerShell module version mismatch

This issue occurs when the installed Azure PowerShell submodule, Az.Ssh.ArcProxy, isn't
supported by the installed version of Az.Ssh. Error:

This version of Az.Ssh only supports version 1.x.x of the Az.Ssh.ArcProxy

PowerShell Module. The Az.Ssh.ArcProxy module {ModulePath} version is
 {ModuleVersion}, and it is not supported by this version of the Az.Ssh module.
Check that this version of Az.Ssh is the latest available.

Resolution:

Update the Az.Ssh and Az.Ssh.ArcProxy modules

Az.Ssh.ArcProxy not installed

This issue occurs when the proxy module isn't found on the client machine. Error:

Failed to find the PowerShell module Az.Ssh.ArcProxy installed in this

machine. You must have the Az.Ssh.Proxy PowerShell module installed in the

client machine in order to connect to Azure Arc resources. You can find the
module in the PowerShell Gallery (see: https://aka.ms/PowerShellGallery-

Az.Ssh.ArcProxy).

Resolution:

Install the module from the PowerShell Gallery : Install-Module -Name

Az.Ssh.ArcProxy

User doesn't have permissions to execute proxy

This issue happens when the user doesn't have permissions to execute the SSH proxy
that is used to connect. Errors:

/bin/bash: line 1: exec:

/usr/local/share/powershell/Modules/Az.Ssh.ArcProxy/1.0.0/sshProxy_linux_amd64

_1.3.022941: cannot execute: Permission denied

CreateProcessW failed error:5 posix_spawnp: Input/output error

Resolution:

Ensure that the user has permissions to execute the proxy file.

Server-side issues

Unable to connect after the public preview

If the user had participated in the public preview and has updated their Arc agent and
the Azure CLI/PowerShell to the general availability releases, then the connectivity may
fail.

Resolution:

Re-enable the functionality on the Azure Arc-enabled servers.

SSH traffic not allowed on the server

This issue occurs when SSHD isn't running on the server, or SSH traffic isn't allowed on
the server. Error:

{"level":"fatal","msg":"sshproxy: error copying information from the

connection: read tcp 192.168.1.180:60887-\u003e40.122.115.96:443: wsarecv: An

existing connection was forcibly closed by the remote host.","time":"2022-02-

24T13:50:40-05:00"}

{"level":"fatal","msg":"sshproxy: error connecting to the address: 503

connection to localhost:22 failed: dial tcp [::1]:22: connectex: No connection

could be made because the target machine actively refused it.. websocket: bad

handshake","proxyVersion":"1.3.022941"}
SSH connection is not enabled in the target port {Port}.

Resolution:

Ensure that the SSHD service is running on the Arc-enabled server.

Ensure that the functionality is enabled on your Arc-enabled server on port 22 (or
other nondefault port)

Azure CLI

az rest --method put --uri

https://management.azure.com/subscriptions/<subscription>/resourceGroups/<resou

rcegroup>/providers/Microsoft.HybridCompute/machines/<arc enabled server

name>/providers/Microsoft.HybridConnectivity/endpoints/default/serviceconfigura
tions/SSH?api-version=2023-03-15 --body '{\"properties\": {\"serviceName\":

\"SSH\", \"port\": \"22\"}}'

Azure permissions issues

Incorrect role assignments to enable SSH connectivity

This issue occurs when the current user doesn't have the proper role assignment to
make contributions to the target resource. Error:

Client is not authorized to create a Default connectivity endpoint for {Name}

in the Resource Group {ResourceGroupName}. This is a one-time operation that

must be performed by an account with Owner or Contributor role to allow

connections to target resource

Resolution:

Ensure that you have the Owner or Contributor role on the resource or contact the
owner/contributor of the resource to set up SSH connectivity.

Incorrect role assignments to connect

This issue occurs when the current user doesn't have the proper role assignment on the
target resource, specifically a lack of read permissions. Possible errors:

Unable to determine the target machine type as Azure VM or Arc Server

Unable to determine that the target machine is an Arc Server

Unable to determine that the target machine is an Azure VM

Permission denied (publickey).

Request for Azure Relay Information Failed: (AuthorizationFailed) The client

'\<user name\>' with object id '\<ID\>' does not have authorization to perform

action 'Microsoft.HybridConnectivity/endpoints/listCredentials/action' over

scope '/subscriptions/\<Subscription ID\>/resourceGroups/\<Resource

Group\>/providers/Microsoft.HybridCompute/machines/\<Machine
Name\>/providers/Microsoft.HybridConnectivity/endpoints/default' or the scope

is invalid. If access was recently granted, please refresh your credentials.

Resolution:

Ensure that you have the Virtual Machine Local user Login role on the resource
you're connecting to. If using Microsoft Entra login, ensure you have the Virtual
Machine User Login or the Virtual Machine Administrator Login roles and that the
Microsoft Entra SSH Login extension is installed on the Arc-Enabled Server.

HybridConnectivity RP not registered

This issue occurs when the HybridConnectivity resource provider isn't registered for the
subscription. Error:
 Request for Azure Relay Information Failed: (NoRegisteredProviderFound) Code:
NoRegisteredProviderFound

Resolution:

Run az provider register -n Microsoft.HybridConnectivity

Confirm success by running az provider show -n Microsoft.HybridConnectivity ,
verify that registrationState is set to Registered
Restart the hybrid agent on the Arc-enabled server

Cannot connect after updating CLI tool and Arc agent

This issue occurs when the updated command creates a new service configuration
before the Arc agent is updated. This will only impact Azure Arc versions older than 1.31
when updating to a version 1.31 or newer. Error:

Connection closed by UNKNOWN port 65535

Resolution:
Delete the existing service configuration and allow it to be re-created by the CLI
command at the next connection. Run az rest --method delete --uri
https://management.azure.com/subscriptions/<SUB_ID>/resourceGroups/<RG_NAME
>/providers/Microsoft.HybridCompute/machines/<VM_NAME>/providers/Microsoft.

HybridConnectivity/endpoints/default/serviceconfigurations/SSH?api-

version=2023-03-15

Disable SSH to Arc-enabled servers

This functionality can be disabled by completing the following actions:

Azure CLI

Remove the SSH port and functionality from the Arc-enabled server: az rest
--method delete --uri
https://management.azure.com/subscriptions/<subscription>/resourceGroups/<

resourcegroup>/providers/Microsoft.HybridCompute/machines/<arc enabled
server

name>/providers/Microsoft.HybridConnectivity/endpoints/default/serviceconf
igurations/SSH?api-version=2023-03-15 --body '{\"properties\":

{\"serviceName\": \"SSH\", \"port\": \"22\"}}'

 Delete the default connectivity endpoint: az rest --method delete --uri
https://management.azure.com/subscriptions/<subscription>/resourceGroups/<

resourcegroup>/providers/Microsoft.HybridCompute/machines/<arc enabled
server name>/providers/Microsoft.HybridConnectivity/endpoints/default?api-

version=2023-03-15

Next steps
Learn about SSH access to Azure Arc-enabled servers.
Learn about troubleshooting agent connection issues.
Prepare to deliver Extended Security
Updates for Windows Server 2012
Article • 06/26/2024

With Windows Server 2012 and Windows Server 2012 R2 having reached end of support
on October 10, 2023, Azure Arc-enabled servers lets you enroll your existing Windows
Server 2012/2012 R2 machines in Extended Security Updates (ESUs). Affording both cost
flexibility and an enhanced delivery experience, Azure Arc better positions you to
migrate to Azure.

The purpose of this article is to help you understand the benefits and how to prepare to
use Arc-enabled servers to enable delivery of ESUs.

７ Note

Azure VMware Solutions (AVS) machines are eligible for free ESUs and should not
enroll in ESUs enabled through Azure Arc.

Key benefits
Delivering ESUs to your Windows Server 2012/2012 R2 machines provides the following
key benefits:

Pay-as-you-go: Flexibility to sign up for a monthly subscription service with the

ability to migrate mid-year.

Azure billed: You can draw down from your existing Microsoft Azure Consumption
Commitment (MACC) and analyze your costs using Microsoft Cost Management
and Billing.

Built-in inventory: The coverage and enrollment status of Windows Server

2012/2012 R2 ESUs on eligible Arc-enabled servers are identified in the Azure
portal, highlighting gaps and status changes.

Keyless delivery: The enrollment of ESUs on Azure Arc-enabled Windows Server

2012/2012 R2 machines won't require the acquisition or activation of keys.

Access to Azure services

For Azure Arc-enabled servers enrolled in WS2012 ESUs enabled by Azure Arc, free
access is provided to these Azure services from October 10, 2023:

Azure Update Manager - Unified management and governance of update

compliance that includes not only Azure and hybrid machines, but also ESU update
compliance for all your Windows Server 2012/2012 R2 machines. Enrollment in
ESUs does not impact Azure Update Manager. After enrollment in ESUs through
Azure Arc, the server becomes eligible for ESU patches. These patches can be
delivered through Azure Update Manager or any other patching solution. You'll
still need to configure updates from Microsoft Updates or Windows Server Update
Services.
Azure Automation Change Tracking and Inventory - Track changes in virtual
machines hosted in Azure, on-premises, and other cloud environments.
Azure Policy Guest Configuration - Audit the configuration settings in a virtual
machine. Guest configuration supports Azure VMs natively and non-Azure physical
and virtual servers through Azure Arc-enabled servers.

Other Azure services through Azure Arc-enabled servers are available as well, with
offerings such as:

Microsoft Defender for Cloud - As part of the cloud security posture management
(CSPM) pillar, it provides server protections through Microsoft Defender for Servers
to help protect you from various cyber threats and vulnerabilities.
Microsoft Sentinel - Collect security-related events and correlate them with other
data sources.

Prepare delivery of ESUs

Plan and prepare to onboard your machines to Azure Arc-enabled servers through the
installation of the Azure Connected Machine agent (version 1.34 or higher) to establish a
connection to Azure. Windows Server 2012 Extended Security Updates supports
Windows Server 2012 and R2 Standard and Datacenter editions. Windows Server 2012
Storage is not supported.

We recommend you deploy your machines to Azure Arc in preparation for when the
related Azure services deliver supported functionality to manage ESU. Once these
machines are onboarded to Azure Arc-enabled servers, you'll have visibility into their
ESU coverage and enroll through the Azure portal or using Azure Policy. Billing for this
service starts from October 2023 (i.e., after Windows Server 2012 end of support).

７ Note
 In order to purchase ESUs, you must have Software Assurance through Volume
Licensing Programs such as an Enterprise Agreement (EA), Enterprise Agreement
Subscription (EAS), Enrollment for Education Solutions (EES), Server and Cloud
Enrollment (SCE), or through Microsoft Open Value Programs. Alternatively, if your
Windows Server 2012/2012 R2 machines are licensed through SPLA or with a
Server Subscription, Software Assurance is not required to purchase ESUs.

You must also download both the licensing package and servicing stack update (SSU)
for the Azure Arc-enabled server as documented at KB5031043: Procedure to continue
receiving security updates after extended support has ended on October 10, 2023 .

Deployment options
There are several at-scale onboarding options for Azure Arc-enabled servers, including
running a Custom Task Sequence through Configuration Manager and deploying a
Scheduled Task through Group Policy. There are also at-scale ESU delivery options for
VMware vCenter managed VMs and SCVMM managed VMs through Azure Arc.

７ Note

Delivery of ESUs through Azure Arc to virtual machines running on Virtual Desktop
Infrastructure (VDI) is not recommended. VDI systems should use Multiple
Activation Keys (MAK) to apply ESUs. See Access your Multiple Activation Key
from the Microsoft 365 Admin Center to learn more.

Networking
Connectivity options include public endpoint, proxy server, and private link or Azure
Express Route. Review the networking prerequisites to prepare non-Azure environments
for deployment to Azure Arc.

If you're using Azure Arc-enabled servers only for Extended Security Updates for either
or both of the following products:

Windows Server 2012

SQL Server 2012

You can enable the following subset of endpoints:

Azure Cloud
 ﾉ Expand table

Agent resource Description When required Endpoint used

with private
link

aka.ms Used to resolve At installation Public

the download time, only
script during
installation

download.microsoft.com Used to At installation Public

download the time, only
Windows
installation
package

login.windows.net Microsoft Entra Always Public

ID

*blob.core.windows.net Download Arc SQL Server ESUs Public

SQL Extension

login.microsoftonline.com Microsoft Entra Always Public

ID

management.azure.com Azure Resource When connecting Public, unless a

Manager - to or disconnecting resource
create or delete a server, only management
the Arc server private link is
resource also configured

*.his.arc.azure.com Metadata and Always Private

hybrid identity
services

*.guestconfiguration.azure.com Extension Always Private

management and
guest
configuration
services

www.microsoft.com/pkiops/certs Intermediate Always for Public

certificate automatic
updates for ESUs updates, or
(note: uses temporarily if
HTTP/TCP 80 and downloading
HTTPS/TCP 443) certificates
manually.
 Agent resource Description When required Endpoint used
with private
link

*.<region>.arcdataservices.com Azure Arc data SQL Server ESUs Public

processing
service and
service telemetry.

*.blob.core.windows.net Download Sql SQL Server ESUs Not required if

Server Extension using Private
package Link

 Tip

To take advantage of the full range of offerings for Arc-enabled servers, such as
extensions and remote connectivity, ensure that you allow the additional URLs that
apply to your scenario. For more information, see Connected machine agent
networking requirements.

Next steps
Find out more about planning for Windows Server and SQL Server end of
support and getting Extended Security Updates.

Learn about best practices and design patterns through the Azure Arc landing
zone accelerator for hybrid and multicloud.

Learn more about Arc-enabled servers and how they work with Azure through the
Azure Connected Machine agent.

Explore options for onboarding your machines to Azure Arc-enabled servers.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

License provisioning guidelines for
Extended Security Updates for Windows
Server 2012
Article • 04/11/2024

Flexibility is critical when enrolling end of support infrastructure in Extended Security

Updates (ESUs) through Azure Arc to receive critical patches. To give ease of options
across virtualization and disaster recovery scenarios, you must first provision Windows
Server 2012 Arc ESU licenses and then link those licenses to your Azure Arc-enabled
servers. The linking and provisioning of licenses can be done through the Azure portal.

When provisioning WS2012 ESU licenses, you need to specify:

Either virtual core or physical core license

Standard or Datacenter license

You also need to attest to the number of associated cores (broken down by the number
of 2-core and 16-core packs).

To assist with the license provisioning process, this article provides general guidance and
sample customer scenarios for planning your deployment of WS2012 ESUs through
Azure Arc.

General guidance: Standard vs. Datacenter,

Physical vs. Virtual Cores

Physical core licensing

If you choose to license based on physical cores, the licensing requires a minimum of 16
physical cores per machine. Most customers choose to license based on physical cores
and select Standard or Datacenter edition to match their original Windows Server
licensing. While Standard licensing can be applied to up to two virtual machines (VMs),
Datacenter licensing has no limit to the number of VMs it can be applied to. Depending
on the number of VMs covered, it may make sense to choose the Datacenter license
instead of the Standard license.

Virtual core licensing

If you choose to license based on virtual cores, the licensing requires a minimum of
eight virtual cores per Virtual Machine. There are two main scenarios where this model is
advisable:

1. If the VM is running on a third-party host or cloud service provider like AWS, GCP,
or OCI.

2. The Windows Server operating system was licensed on a virtualization basis.

Another scenario (scenario 1, below) is a candidate for VM/Virtual core licensing when
the WS2012 VMs are running on a newer Windows Server host (that is, Windows Server
2016 or later).

） Important

Virtual core licensing can't be used on physical servers. When creating a license
with virtual cores, always select the standard edition instead of datacenter, even if
the operating system is datacenter edition.

License limits
Each WS2012 ESU license can cover up to and including 10,000 cores. If you need ESUs
for more than 10,000 cores, split the total number of cores across multiple licenses.
Additionally, only 800 licenses can be created in a single resource group. Use more
resource groups if you need to create more than 800 license resources.

SA/SPLA conformance
In all cases, you're required to attest to conformance with SA or SPLA. There is no
exception for these requirements. Software Assurance or an equivalent Server
Subscription is required for you to purchase Extended Security Updates on-premises
and in hosted environments. You are able to purchase Extended Security Updates from
Enterprise Agreement (EA), Enterprise Subscription Agreement (EAS), a Server & Cloud
Enrollment (SCE), and Enrollment for Education Solutions (EES). On Azure, you do not
need Software Assurance to get free Extended Security Updates, but Software Assurance
or Server Subscription is required to take advantage of the Azure Hybrid Benefit.

Visual Studio subscription benefit for dev/test scenarios

Visual Studio subscriptions allow developers to get product keys for Windows Server at
no extra cost to help them develop and test their software. If a Windows Server 2012
server's operating system is licensed through a product key obtained from a Visual
Studio subscription, you can also get extended security updates for these servers at no
extra cost. To configure ESU licenses for these servers using Azure Arc, you must have at
least one server with paid ESU usage. You can't create an ESU license where all
associated servers are entitled to the Visual Studio subscription benefit. See additional
scenarios in the deployment article for more information on how to provision an ESU
license correctly for this scenario.

Development, test, and other non-production servers that have a paid operating system
license (from your organization's volume licensing key, for example) must use a paid
ESU license. The only dev/test servers entitled to ESU licenses at no extra cost are those
whose operating system licenses came from a Visual Studio subscription.

Cost savings with migration and modernization

of workloads
As you migrate and modernize your Windows Server 2012 and Windows 2012 R2
infrastructure through the end of 2023, you can utilize the flexibility of monthly billing
with Windows Server 2012 ESUs enabled by Azure Arc for cost savings benefits.

As servers no longer require ESUs because they've been migrated to Azure, Azure
VMware Solution (AVS), or Azure Stack HCI where they’re eligible for free ESUs, or
updated to Windows Server 2016 or higher, you can modify the number of cores
associated with a license or delete/deactivate licenses. You can also link the license to a
new scope of additional servers. See Programmatically deploy and manage Azure Arc
Extended Security Updates licenses to learn more. For information about no-cost ESUs
through Azure Stack HCI, see Free Extended Security Updates through Azure Stack HCI.

７ Note

This process is not automatic; billing is tied to the activated licenses and you are
responsible for modifying your provisioned licensing to take advantage of cost
savings.

Scenario based examples: Compliant and Cost

Effective Licensing
Scenario 1: Eight modern 32-core hosts (not Windows
Server 2012). While each of these hosts are running four
8-core VMs, only one VM on each host is running
Windows Server 2012 R2
In this scenario, you can use virtual core-based licensing to avoid covering the entire
host by provisioning eight Windows Server 2012 Standard licenses for eight virtual cores
each and link each of those licenses to the VMs running Windows Server 2012 R2.
Alternatively, you could consider consolidating your Windows Server 2012 R2 VMs into
two of the hosts to take advantage of physical core-based licensing options.

Scenario 2: A branch office with four VMs, each 8-cores,

on a 32-core Windows Server 2012 Standard host
In this case, you should provision two WS2012 Standard licenses for 16 physical cores
each and apply to the four Arc-enabled servers. Alternatively, you could provision four
WS2012 Standard licenses for eight virtual cores each and apply individually to the four
Arc-enabled servers.

Scenario 3: Eight physical servers in retail stores, each

server is standard with eight cores each and there's no
virtualization
In this scenario, you should apply eight WS2012 Standard licenses for 16 physical cores
each and link each license to a physical server. Note that the 16 physical core minimum
applies to the provisioned licenses.

Scenario 4: Multicloud environment with 12 AWS VMs,

each of which have 12 cores and are running Windows
Server 2012 R2 Standard
In this scenario, you should apply 12 Windows Server 2012 Standard licenses with 12
virtual cores each, and link individually to each AWS VM.

Scenario 5: You have already purchased the traditional

Windows Server 2012 ESUs through Volume Licensing
In this scenario, the Azure Arc-enabled servers that have been enrolled in Extended
Security Updates through an activated MAK Key are as enrolled in ESUs in the Azure
portal. You have the flexibility to switch from this key-based traditional ESU model to
WS2012 ESUs enabled by Azure Arc between Year one and Year two.

Scenario 6: Migrating or retiring your Azure Arc-enabled

servers enrolled in Windows Server 2012 ESUs
In this scenario, you can deactivate or decommission the ESU Licenses associated with
these servers. If only part of the server estate covered by a license no longer requires
ESUs, you can modify the ESU license details to reduce the number of associated cores.

Scenario 7: 128-core Windows Server 2012 Datacenter

server running between 10 and 15 Windows Server 2012
R2 VMs that get provisioned and deprovisioned regularly
In this scenario, you should provision a Windows Server 2012 Datacenter license
associated with 128 physical cores and link this license to the Arc-enabled Windows
Server 2012 R2 VMs running on it. The deletion of the underlying VM also deletes the
corresponding Arc-enabled server resource, enabling you to link another Arc-enabled
server.

Scenario 8: An insurance customer is running a 16 node

VMware cluster with 1024 physical cores on-premises. 44
of the VMs on the cluster are running Windows Server
2012 R2. Those 44 VMs consume 506 virtual cores, which
was calculated by summing up the maximum of 8 or the
actual number of cores assigned to each VM.
In this scenario, you could either license the entire cluster with 1024 Windows Server
2012 Datacenter ESU physical cores or license each VM individually with a total of 506
standard edition virtual cores. In this case, it's cheaper to purchase an Arc ESU Windows
Server 2012 Standard edition license associated with 506 virtual cores. You'll need to
onboard each of the 44 VMs to Azure Arc and then link the license to the Arc machines.

） Important

If you migrate the VMs to Azure VMware Solution (AVS), these servers become
eligible for free WS2012 ESUs and should not enroll in ESUs enabled through Azure
 Arc.

License operations
There are several limitations in the management scenarios for provisioned WS2012 Arc
ESU license resources:

License cores are a mutable property, and customers are able to increment or
decrement cores. This is subject to the mandatory minimums of both: (i) 16 cores
for Physical core based licenses and (ii) 8 cores for Virtual core based licenses.

License edition and type is not a mutable property. Standard licenses can't be
changed to Datacenter licenses, and vice versa. Similarly, Physical core licenses
can't be changed to Virtual core licenses, and vice versa. Note that there are three
valid licensing combinations: Standard Virtual Core, Standard Physical Core, and
Datacenter Physical Core. Datacenter Virtual cores aren't a viable licensing
combination. Erroneously provisioned Datacenter Virtual core licenses have been
translated to Datacenter Physical core licenses with core counts compliant with
licensing guidelines.

Licenses can be moved between resource groups and subscriptions. License are
modeled in Azure Resource Manager and can be queried using Azure Resource
Graph.

Licenses can be linked to servers in another subscription within the same tenant,
but licenses can't be linked to servers within subscriptions of other tenants.

Tagging a license under evaluation scenarios such as Dev Test or Disaster Recovery
doesn't impact billing. Billing is strictly tied to the number of cores associated with
the license regardless of tags. The cores used for evaluation or free scenarios
shouldn't be provisioned for the Azure Arc ESU license.

Next steps
Find out more about planning for Windows Server and SQL Server end of
support and getting Extended Security Updates.

Learn about best practices and design patterns through the Azure Arc landing
zone accelerator for hybrid and multicloud.

Learn more about Arc-enabled servers and how they work with Azure through the
Azure Connected Machine agent.
Explore options for onboarding your machines to Azure Arc-enabled servers.
Billing service for Extended Security
Updates for Windows Server 2012
enabled by Azure Arc
Article • 04/26/2024

Three factors impact billing for Extended Security Updates (ESUs):

The number of cores provisioned

The edition of the license (Standard vs. Datacenter)
The application of any eligible discounts

Billing is monthly. Decrementing, deactivating, or deleting a license results in charges for

up to five more calendar days from the time of decrement, deactivation, or deletion.
Reduction in billing isn't immediate. This is an Azure-billed service and can be used to
decrement a customer's Microsoft Azure Consumption Commitment (MACC) and be
eligible for Azure Consumption Discount (ACD).

７ Note

Licenses or additional cores provisioned after End of Support are subject to a one-
time back-billing charge during the month in which the license was provisioned.
This isn't reflective of the recurring monthly bill.

Back-billing for ESUs enabled by Azure Arc

Licenses that are provisioned after the End of Support (EOS) date of October 10, 2023
are charged a back bill for the time elapsed since the EOS date. For example, an ESU
license provisioned in December 2023 is back-billed for October and November upon
provisioning. Enrolling late in WS2012 ESUs makes you eligible for all the critical security
patches up to that point. The back-billing charge reflects the value of these critical
security patches.

If you deactivate and then later reactivate a license, you're billed for the window during
which the license was deactivated. It isn't possible to evade charges by deactivating a
license before a critical security patch and reactivating it shortly before.

If the region or the tenant of an ESU license is changed, this will be subject to back-
billing charges.
 ７ Note

The back-billing cost appears as a separate line item in invoicing. If you acquired a
discount for your core WS2012 ESUs enabled by Azure Arc, the same discount may
or may not apply to back-billing. You should verify that the same discounting, if
applicable, has been applied to back-billing charges as well.

Please note that estimates in the Azure Cost Management forecast may not accurately
project monthly costs. Due to the episodic nature of back-billing charges, the projection
of monthly costs may appear as overestimated during initial months.

Billing associated with modifications to an

Azure Arc ESU license
License type: License type (either Standard or Datacenter) is an immutable
property. The billing associated with a license is specific to the edition of the
provisioned license.

７ Note

If you previously provisioned a Datacenter Virtual Core license, it will be

charged with and offer the virtualization benefits associated with the pricing
of a Datacenter edition license.

Core modification: If cores are added to an existing ESU license, they're subject to
back-billing (that is, charges for the time elapsed since EOS) and regularly billed
from the calendar month in which they were added. If cores are reduced or
decremented to an existing ESU license, the billing rate will reflect the reduced
number of cores within 5 business days of the change.

Activation: Licenses are billed for their number and edition of cores from the point
at which they're activated. The activated license doesn't need to be linked to any
Azure Arc-enabled servers to initiate billing. Activation and reactivation are subject
to back-billing. Note that licenses that were activated but not linked to any servers
may be back-billed if they weren't billed upon creation. Customers are responsible
for deletion of any activated but unlinked ESU licenses.

Deactivation or deletion: Licenses that are deactivated or deleted will be billed

through up to five calendar days from the time of the change.
Services included with WS2012 ESUs enabled
by Azure Arc
Purchase of Windows Server 2012/R2 ESUs enabled by Azure Arc provides you with the
benefit of access to additional Azure management services at no additional cost for
enrolled servers. See Access to Azure services to learn more.

Azure Arc-enabled servers allow you the flexibility to evaluate and operationalize
Azure’s robust security, monitoring, and governance capabilities for your non-Azure
infrastructure, delivering key value beyond the observability, ease of enrollment, and
financial flexibility of WS2012 ESUs enabled by Azure Arc.

Additional notes
You'll be billed if you connect an activated Azure Arc ESU license to environments
like Azure Stack HCI or Azure VMware Solution. These environments are eligible for
free Windows Server 2012 ESUs enabled by Azure Arc and should not be activated
through Azure Arc.

You'll be billed for all of the cores provisioned in the license. If provision licenses
for free ESU usage like Visual Studio Development environments, you shouldn't
provision additional cores for the scope of licensing applied to non-paid ESU
coverage.

Migration and modernization of End-of-Life infrastructure to Azure, including

Azure VMware Solution and Azure Stack HCI, can reduce the need for paid
WS2012 ESUs. You must decrement the cores with their Azure Arc ESU licenses or
deactivate and delete ESU licenses to benefit from the cost savings associated with
Azure Arc’s flexible monthly billing model. This isn't an automatic process.

For customers seeking to transition from Volume Licensing based MAK Keys for
Year 1 of WS2012/R2 ESUs to WS2012/R2 ESUs enabled by Azure Arc for Year 2,
there's a transition process that is exempt from back-billing.
Deliver Extended Security Updates for
Windows Server 2012
Article • 02/20/2024

This article provides steps to enable delivery of Extended Security Updates (ESUs) to
Windows Server 2012 machines onboarded to Arc-enabled servers. You can enable ESUs
to these machines individually or at scale.

Before you begin

Plan and prepare to onboard your machines to Azure Arc-enabled servers. See Prepare
to deliver Extended Security Updates for Windows Server 2012 to learn more.

You'll also need the Contributor role in Azure RBAC to create and assign ESUs to Arc-
enabled servers.

Manage ESU licenses

1. From your browser, sign in to the Azure portal .

2. On the Azure Arc page, select Extended Security Updates in the left pane.

From here, you can view and create ESU Licenses and view Eligible resources for
ESUs.

７ Note
 When viewing all your Arc-enabled servers from the Servers page, a banner
specifies how many Windows 2012 machines are eligible for ESUs. You can then
select View servers in Extended Security Updates to view a list of resources that
are eligible for ESUs, together with machines already ESU enabled.

Create Azure Arc WS2012 licenses

The first step is to provision Windows Server 2012 and 2012 R2 Extended Security
Update licenses from Azure Arc. You link these licenses to one or more Arc-enabled
servers that you select in the next section.

After you provision an ESU license, you need to specify the SKU (Standard or
Datacenter), type of cores (Physical or vCore), and number of 16-core and 2-core packs
to provision an ESU license. You can also provision an Extended Security Update license
in a deactivated state so that it won’t initiate billing or be functional on creation.
Moreover, the cores associated with the license can be modified after provisioning.

７ Note

The provisioning of ESU licenses requires you to attest to their SA or SPLA

coverage.

The Licenses tab displays Azure Arc WS2012 licenses that are available. From here, you
can select an existing license to apply or create a new license.

1. To create a new WS2012 license, select Create, and then provide the information
required to configure the license on the page.
 For details on how to complete this step, see License provisioning guidelines for
Extended Security Updates for Windows Server 2012.

2. Review the information provided, and then select Create.

The license you created appears in the list and you can link it to one or more Arc-
enabled servers by following the steps in the next section.

Link ESU licenses to Arc-enabled servers

You can select one or more Arc-enabled servers to link to an Extended Security Update
license. Once you've linked a server to an activated ESU license, the server is eligible to
receive Windows Server 2012 and 2012 R2 ESUs.

７ Note

You have the flexibility to configure your patching solution of choice to receive
these updates – whether that’s Update Manager, Windows Server Update
Services, Microsoft Updates, Microsoft Endpoint Configuration Manager, or a
third-party patch management solution.

1. Select the Eligible Resources tab to view a list of all your Arc-enabled servers
running Windows Server 2012 and 2012 R2.
 

The ESUs status column indicates whether or not the machine is ESUs-enabled.

2. To enable ESUs for one or more machines, select them in the list, and then select
Enable ESUs.

3. On the Enable Extended Security Updates page, it shows the number of machines
selected to enable ESU and the WS2012 licenses available to apply. Select a license
to link to the selected machine(s) and then select Enable.

７ Note

You can also create a license from this page by selecting Create an ESU
license.
The status of the selected machines changes to Enabled.

If any problems occur during the enablement process, see Troubleshoot delivery of
Extended Security Updates for Windows Server 2012 for assistance.

At-scale Azure Policy

For at-scale linking of servers to an Azure Arc Extended Security Update license and
locking down license modification or creation, consider the usage of the following built-
in Azure policies:

Enable Extended Security Updates (ESUs) license to keep Windows 2012 machines
protected after their support lifecycle has ended (preview)

Deny Extended Security Updates (ESUs) license creation or modification (preview)

Azure policies can be specified to a targeted subscription or resource group for both
auditing and management scenarios.

Additional scenarios
There are some scenarios in which you may be eligible to receive Extended Security
Updates patches at no additional cost. Two of these scenarios supported by Azure Arc
are (1) Dev/Test (Visual Studio) and (2) Disaster Recovery (Entitled benefit DR instances
from Software Assurance or subscription only). Both of these scenarios require the
customer is already using Windows Server 2012/R2 ESUs enabled by Azure Arc for
billable, production machines.
 ２ Warning

Don't create a Windows Server 2012/R2 ESU License for only Dev/Test or Disaster
Recovery workloads. You shouldn't provision an ESU License only for non-billable
workloads. Moreover, you'll be billed fully for all of the cores provisioned with an
ESU license, and any dev/test cores on the license won't be billed as long as they're
tagged accordingly based on the following qualifications.

To qualify for these scenarios, you must already have:

Billable ESU License. You must already have provisioned and activated a WS2012
Arc ESU License intended to be linked to regular Azure Arc-enabled servers
running in production environments (i.e., normally billed ESU scenarios). This
license should be provisioned only for billable cores, not cores that are eligible for
free Extended Security Updates, for example, dev/test cores.

Arc-enabled servers. Onboarded your Windows Server 2012 and Windows Server
2012 R2 machines to Azure Arc-enabled servers for the purpose of Dev/Test with
Visual Studio subscriptions or Disaster Recovery.

To enroll Azure Arc-enabled servers eligible for ESUs at no additional cost, follow these
steps to tag and link:

1. Tag both the WS2012 Arc ESU License (created for the production environment
with cores for only the production environment servers) and the non-production
Azure Arc-enabled servers with one of the following name-value pairs,
corresponding to the appropriate exception:

a. Name: “ESU Usage”; Value: “WS2012 VISUAL STUDIO DEV TEST”

b. Name: “ESU Usage”; Value: “WS2012 DISASTER RECOVERY”

In the case that you're using the ESU License for multiple exception scenarios,
mark the license with the tag: Name: “ESU Usage”; Value: “WS2012
MULTIPURPOSE”

2. Link the tagged license (created for the production environment with cores only
for the production environment servers) to your tagged non-production Azure
Arc-enabled Windows Server 2012 and Windows Server 2012 R2 machines. Do not
license cores for these servers or create a new ESU license for only these servers.

This linking won't trigger a compliance violation or enforcement block, allowing you to
extend the application of a license beyond its provisioned cores. The expectation is that
the license only includes cores for production and billed servers. Any additional cores
will be charged and result in over-billing.

） Important

Adding these tags to your license will NOT make the license free or reduce the
number of license cores that are chargeable. These tags allow you to link your
Azure machines to existing licenses that are already configured with payable cores
without needing to create any new licenses or add additional cores to your free
machines.

Example:

You have 8 Windows Server 2012 R2 Standard instances, each with 8 physical
cores. Six of these Windows Server 2012 R2 Standard machines are for production,
and 2 of these Windows Server 2012 R2 Standard machines are eligible for free
ESUs through the Visual Studio Dev Test subscription.
You should first provision and activate a regular ESU License for Windows Server
2012/R2 that's Standard edition and has 48 physical cores to cover the 6
production machines. You should link this regular, production ESU license to
your 6 production servers.
Next, you should reuse this existing license, don't add any more cores or
provision a separate license, and link this license to your 2 non-production
Windows Server 2012 R2 standard machines. You should tag the ESU license
and the 2 non-production Windows Server 2012 R2 Standard machines with
Name: "ESU Usage" and Value: "WS2012 VISUAL STUDIO DEV TEST".
This will result in an ESU license for 48 cores, and you'll be billed for those 48
cores. You won't be charged for the additional 16 cores of the dev test servers
that you added to this license, as long as the ESU license and the dev test server
resources are tagged appropriately.

７ Note

You needed a regular production license to start with, and you'll be billed only for
the production cores.

Upgrading from Windows Server 2012/2012 R2

When upgrading a Windows Server 2012/2012R machine to Windows Server 2016 or
above, it's not necessary to remove the Connected Machine agent from the machine.
The new operating system will be visible for the machine in Azure within a few minutes
of upgrade completion. Upgraded machines no longer require ESUs and are no longer
eligible for them. Any ESU license associated with the machine isn't automatically
unlinked from the machine. See Unlink a license for instructions on doing so manually.

Assess WS2012 ESU patch Status

To detect whether your Azure Arc-enabled servers are patched with the most recent
Windows Server 2012/R2 Extended Security Updates, you can use the Azure Policy
Extended Security Updates should be installed on Windows Server 2012 Arc machines-
Microsoft Azure . This Azure Policy, powered by Machine Configuration, identifies if the
server has received the most recent ESU Patches. This is observable from the Guest
Assignment and Azure Policy Compliance views built into Azure portal.
Programmatically deploy and manage
Azure Arc Extended Security Updates
licenses
Article • 10/23/2023

This article provides instructions to programmatically provision and manage Windows

Server 2012 and Windows Server 2012 R2 Extended Security Updates lifecycle
operations through the Azure Arc WS2012 ESU ARM APIs.

For each of the API commands explained in this article, be sure to enter accurate
parameter information for location, state, edition, type, and processors depending on
your particular scenario

７ Note

You'll need to create a service principal to use the Azure API to manage ESUs. See
Connect hybrid machines to Azure at scale and Azure REST API reference for
more information.

Provision a license
To provision a license, execute the following commands:

PUT
https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RE
SOURCE_GROUP_NAME/providers/Microsoft.HybridCompute/licenses/LICENSE_NAME?
api-version=2023-06-20-preview
{
"location": "ENTER-REGION",
"properties": {
"licenseDetails": {
"state": "Activated",
"target": "Windows Server 2012",
"Edition": "Datacenter",
"Type": "pCore",
"Processors": 12
}
}
}
Link a license
To link a license, execute the following commands:

PUT
https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RE
SOURCE_GROUP_NAME/providers/Microsoft.HybridCompute/machines/MACHINE_NAME/li
censeProfiles/default?api-version=2023-06-20-preview
{
"location": "SAME_REGION_AS_MACHINE",
"properties": {
"esuProfile": {
"assignedLicense": "RESOURCE_ID_OF_LICENSE"
}
}
}

Unlink a license
To unlink a license, execute the following commands:

PUT
https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RE
SOURCE_GROUP_NAME/providers/Microsoft.HybridCompute/machines/MACHINE_NAME/li
censeProfiles/default?api-version=2023-06-20-preview
{
"location": "SAME_REGION_AS_MACHINE",
"properties": {
"esuProfile": {
}
}
}

Modify a license
To modify a license, execute the following commands:

PUT/PATCH
https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RE
SOURCE_GROUP_NAME/providers/Microsoft.HybridCompute/licenses/LICENSE_NAME?
api-version=2023-06-20-preview
 {
"location": "ENTER-REGION",
"properties": {
"licenseDetails": {
"state": "Activated",
"target": "Windows Server 2012",
"Edition": "Datacenter",
"Type": "pCore",
"Processors": 12
}
}
}

７ Note

For PUT, all of the properties must be provided. For PATCH, a subset may be
provided.

Delete a license
To delete a license, execute the following commands:

DELETE
https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RE
SOURCE_GROUP_NAME/providers/Microsoft.HybridCompute/licenses/LICENSE_NAME?
api-version=2023-06-20-preview
Troubleshoot delivery of Extended
Security Updates for Windows Server
2012
Article • 06/21/2024

This article provides information on troubleshooting and resolving issues that may occur
while enabling Extended Security Updates for Windows Server 2012 and Windows
Server 2012 R2 through Arc-enabled servers.

License provisioning issues

If you're unable to provision a Windows Server 2012 Extended Security Update license
for Azure Arc-enabled servers, check the following:

Permissions: Verify you have sufficient permissions (Contributor role or higher)

within the scope of ESU provisioning and linking.

Core minimums: Verify you have specified sufficient cores for the ESU License.
Physical core-based licenses require a minimum of 16 cores per machine, and
virtual core-based licenses require a minimum of 8 cores per virtual machine (VM).

Conventions: Verify you have selected an appropriate subscription and resource

group and provided a unique name for the ESU license.

ESU enrollment issues

If you're unable to successfully link your Azure Arc-enabled server to an activated
Extended Security Updates license, verify the following conditions are met:

Connectivity: Azure Arc-enabled server is Connected. For information about

viewing the status of Azure Arc-enabled machines, see Agent status.

Agent version: Connected Machine agent is version 1.34 or higher. If the agent
version is less than 1.34, you need to update it to this version or higher.

Operating system: Only Azure Arc-enabled servers running the Windows Server
2012 and 2012 R2 operating system are eligible to enroll in Extended Security
Updates.
 Environment: The connected machine should not be running on Azure Stack HCI,
Azure VMware solution (AVS), or as an Azure virtual machine. In these scenarios,
WS2012 ESUs are available for free. For information about no-cost ESUs through
Azure Stack HCI, see Free Extended Security Updates through Azure Stack HCI.

License properties: Verify the license is activated and has been allocated sufficient
physical or virtual cores to support the intended scope of servers.

Resource providers
If you're unable to enable this service offering, review the resource providers registered
on the subscription as noted below. If you receive an error while attempting to register
the resource providers, validate the role assignment/s on the subscription. Also review
any potential Azure policies that may be set with a Deny effect, preventing the
enablement of these resource providers.

Microsoft.HybridCompute: This resource provider is essential for Azure Arc-

enabled servers, allowing you to onboard and manage on-premises servers in the
Azure portal.

Microsoft.GuestConfiguration: Enables Guest Configuration policies, which are

used to assess and enforce configurations on your Arc-enabled servers for
compliance and security.

Microsoft.Compute: This resource provider is required for Azure Update

Management, which is used to manage updates and patches on your on-premises
servers, including ESU updates.

Microsoft.Security: Enabling this resource provider is crucial for implementing

security-related features and configurations for both Azure Arc and on-premises
servers.

Microsoft.OperationalInsights: This resource provider is associated with Azure

Monitor and Log Analytics, which are used for monitoring and collecting telemetry
data from your hybrid infrastructure, including on-premises servers.

Microsoft.Sql: If you're managing on-premises SQL Server instances and require

ESU for SQL Server, enabling this resource provider is necessary.

Microsoft.Storage: Enabling this resource provider is important for managing

storage resources, which may be relevant for hybrid and on-premises scenarios.
ESU patch issues

ESU patch status

To detect whether your Azure Arc-enabled servers are patched with the most recent
Windows Server 2012/R2 Extended Security Updates, use Azure Update Manager or the
Azure Policy Extended Security Updates should be installed on Windows Server 2012 Arc
machines-Microsoft Azure , which checks whether the most recent WS2012 ESU
patches have been received. Both of these options are available at no additional cost for
Azure Arc-enabled servers enrolled in WS2012 ESUs enabled by Azure Arc.

ESU prerequisites
Ensure that both the licensing package and servicing stack update (SSU) are
downloaded for the Azure Arc-enabled server as documented at KB5031043: Procedure
to continue receiving security updates after extended support has ended on October 10,
2023 . Ensure you are following all of the networking prerequisites as recorded at
Prepare to deliver Extended Security Updates for Windows Server 2012.

Error: Trying to check IMDS again (HRESULT 12002 or

12029)
If installing the Extended Security Update enabled by Azure Arc fails with errors such as
"ESU: Trying to Check IMDS Again LastError=HRESULT_FROM_WIN32(12029)" or "ESU:
Trying to Check IMDS Again LastError=HRESULT_FROM_WIN32(12002)", you may need
to update the intermediate certificate authorities trusted by your computer using one of
the following methods.

） Important

If you're running the latest version of the Azure Connected machine agent, it's not
necessary to install the intermediate CA certificates or allow access to the PKI URL.
However, if a license was already assigned before the agent was upgraded, it can
take up to 15 days for the older license to be replaced. During this time, the
intermediate cert will still be required. After upgrading the agent, you can delete
the license file %ProgramData%\AzureConnectedMachineAgent\certs\license.json to
force it to be refreshed.

Option 1: Allow access to the PKI URL

Configure your network firewall and/or proxy server to allow access from the Windows
Server 2012 (R2) machines to http://www.microsoft.com/pkiops/certs and
https://www.microsoft.com/pkiops/certs (both TCP 80 and 443). This will enable the

machines to automatically retrieve any missing intermediate CA certificates from

Microsoft.

Once the network changes are made to allow access to the PKI URL, try installing the
Windows updates again. You may need to reboot your computer for the automatic
installation of certificates and validation of the license to take effect.

Option 2: Manually download and install the intermediate CA

certificates

If you're unable to allow access to the PKI URL from your servers, you can manually
download and install the certificates on each machine.

1. On any computer with internet access, download these intermediate CA

certificates:
a. Microsoft Azure TLS Issuing CA 01
b. Microsoft Azure TLS Issuing CA 02
c. Microsoft Azure TLS Issuing CA 05
d. Microsoft Azure TLS Issuing CA 06
e. Microsoft Azure RSA TLS Issuing CA 04

2. Copy the certificate files to your Windows Server 2012 (R2) machines.

3. Run any one set of the following commands in an elevated command prompt or
PowerShell session to add the certificates to the "Intermediate Certificate
Authorities" store for the local computer. The command should be run from the
same directory as the certificate files. The commands are idempotent and won't
make any changes if you've already imported the certificate:

certutil -addstore CA "Microsoft Azure TLS Issuing CA 01 - xsign.crt"

certutil -addstore CA "Microsoft Azure TLS Issuing CA 02 - xsign.crt"
certutil -addstore CA "Microsoft Azure TLS Issuing CA 05 - xsign.crt"
certutil -addstore CA "Microsoft Azure TLS Issuing CA 06 - xsign.crt"
certutil -addstore CA "Microsoft Azure RSA TLS Issuing CA 04 -
xsign.crt"

4. Try installing the Windows updates again. You may need to reboot your computer
for the validation logic to recognize the newly imported intermediate CA
 certificates.

Error: Not eligible (HRESULT 1633)

If you encounter the error "ESU: not eligible HRESULT_FROM_WIN32(1633)", follow
these steps:

PowerShell

Remove-Item "$env:ProgramData\AzureConnectedMachineAgent\Certs\license.json"
-Force
Restart-Service himds

If you have other issues receiving ESUs after successfully enrolling the server through
Arc-enabled servers, or you need additional information related to issues affecting ESU
deployment, see Troubleshoot issues in ESU.

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Troubleshoot Azure Connected Machine agent connection
issues
Article • 11/03/2023

This article provides information for troubleshooting issues that might occur while configuring the Azure Connected Machine agent for
Windows or Linux. Both the interactive and at-scale installation methods when configuring connection to the service are included. For
general information, see Azure Arc-enabled servers overview.

Agent error codes

Use the following table to identify and resolve issues when configuring the Azure Connected Machine agent using the AZCM0000 ("0000"
can be any four digit number) error code printed to the console or script output.

Error code Probable cause Suggested remediation

AZCM0000 The action was successful N/A

AZCM0001 An unknown error occurred Contact Microsoft Support for assistance.

AZCM0011 The user canceled the action Retry the previous command.
(CTRL+C)

AZCM0012 The access token is invalid If authenticating via access token, obtain a new token and try again. If authenticating via service
principal or device logins, contact Microsoft Support for assistance.

AZCM0016 Missing a mandatory parameter Review the error message in the output to identify which parameters are missing. For the complete
syntax of the command, run azcmagent <command> --help .

AZCM0018 The command was executed Retry the command in an elevated user context (administrator/root).
without administrative privileges

AZCM0019 The path to the configuration file is Ensure the path to the configuration file is correct and try again.
incorrect

AZCM0023 The value provided for a parameter Review the error message for more specific information. Refer to the syntax of the command
(argument) is invalid ( azcmagent <command> --help ) for valid values or expected format for the arguments.

AZCM0026 There's an error in network Check if the required endpoints are reachable (for example, hostnames are resolvable, endpoints
configuration or some critical aren't blocked). If the network is configured for Private Link Scope, a Private Link Scope resource ID
services are temporarily unavailable must be provided for onboarding using the --private-link-scope parameter.

AZCM0041 The credentials supplied are invalid For device logins, verify that the user account specified has access to the tenant and subscription
where the server resource will be created. For service principal logins, check the client ID and secret
for correctness, the expiration date of the secret, and that the service principal is from the same
tenant where the server resource will be created.

AZCM0042 Creation of the Azure Arc-enabled Review the error message in the output to identify the cause of the failure to create resource and
server resource failed the suggested remediation. For more information, see Connected Machine agent prerequisites-
required permissions for more information.

AZCM0043 Deletion of the Azure Arc-enabled Verify that the user/service principal specified has permissions to delete Azure Arc-enabled
server resource failed server/resources in the specified group. For more information, see Connected Machine agent
prerequisites-required permissions. If the resource no longer exists in Azure, use the --force-local-
only flag to proceed.

AZCM0044 A resource with the same name Specify a different name for the --resource-name parameter or delete the existing Azure Arc-
already exists enabled server in Azure and try again.

AZCM0062 An error occurred while connecting Review the error message in the output for more specific information. If the error occurred after the
the server Azure resource was created, delete this resource before retrying.

AZCM0063 An error occurred while Review the error message in the output for more specific information. If this error persists, delete
disconnecting the server the resource in Azure, and then run azcmagent disconnect --force-local-only on the server.

AZCM0067 The machine is already connected Run azcmagent disconnect to remove the current connection, then try again.
to Azure

AZCM0068 Subscription name was provided, Retry the command with the subscription GUID instead of subscription name.
and an error occurred while looking
 Error code Probable cause Suggested remediation

up the corresponding subscription

GUID.

AZCM0061 The agent service isn't responding Verify the command is run in an elevated user context (administrator/root). Ensure that the HIMDS
AZCM0064 or unavailable service is running (start or restart HIMDS as needed) then try the command again.
AZCM0065
AZCM0066
AZCM0070

AZCM0081 An error occurred while If this message is encountered while attempting to connect the server to Azure, the agent won't be
downloading the Microsoft Entra able to communicate with the Azure Arc service. Delete the resource in Azure and try connecting
managed identity certificate again.

AZCM0101 The command wasn't parsed Run azcmagent <command> --help to review the command syntax.
successfully

AZCM0102 An error occurred while retrieving Retry the command and specify a resource name (with parameter --resource-name or –n). Use only
the computer hostname alphanumeric characters, hyphens and/or underscores; note that resource name can't end with a
hyphen or underscore.

AZCM0103 An error occurred while generating Contact Microsoft Support for assistance.
RSA keys

AZCM0105 An error occurred while Delete the resource created in Azure and try again.
downloading the Microsoft Entra ID
managed identify certificate

AZCM0147- An error occurred while installing Review the error message in the output for more specific information.
AZCM0152 Azcmagent on Windows

AZCM0127- An error occurred while installing Review the error message in the output for more specific information.
AZCM0146 Azcmagent on Linux

AZCM0150 Generic failure during installation Submit a support ticket to get assistance.

AZCM0153 The system platform isn't supported Review the prerequisites for supported platforms

AZCM0154 The version of PowerShell installed Upgrade to PowerShell 4 or later and try again.
on the system is too old

AZCM0155 The user running the installation Re-run the script as an administrator.
script doesn't have administrator
permissions

AZCM0156 Installation of the agent failed Confirm that the machine isn't running on Azure. Detailed errors might be found in the installation
log at %TEMP%\installationlog.txt .

AZCM0157 Unable to download repo metadata Check if a firewall is blocking access to packages.microsoft.com and try again.
for the Microsoft Linux software
repository

Agent verbose log

Before following the troubleshooting steps described later in this article, the minimum information you need is the verbose log. It
contains the output of the azcmagent tool commands, when the verbose (-v) argument is used. The log files are written to
%ProgramData%\AzureConnectedMachineAgent\Log\azcmagent.log for Windows, and Linux to /var/opt/azcmagent/log/azcmagent.log .

Windows
Following is an example of the command to enable verbose logging with the Connected Machine agent for Windows when performing
an interactive installation.

Console

& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect --resource-group "resourceGroupName" --tenant-id

"tenantID" --location "regionName" --subscription-id "subscriptionID" --verbose

Following is an example of the command to enable verbose logging with the Connected Machine agent for Windows when performing
an at-scale installation using a service principal.
 Console

& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect `

--service-principal-id "{serviceprincipalAppID}" `
--service-principal-secret "{serviceprincipalPassword}" `
--resource-group "{ResourceGroupName}" `
--tenant-id "{tenantID}" `
--location "{resourceLocation}" `
--subscription-id "{subscriptionID}"
--verbose

Linux
Following is an example of the command to enable verbose logging with the Connected Machine agent for Linux when performing an
interactive installation.

７ Note

You must have root access permissions on Linux machines to run azcmagent.

Bash

azcmagent connect --resource-group "resourceGroupName" --tenant-id "tenantID" --location "regionName" --subscription-id

"subscriptionID" --verbose

Following is an example of the command to enable verbose logging with the Connected Machine agent for Linux when performing an
at-scale installation using a service principal.

Bash

azcmagent connect \
--service-principal-id "{serviceprincipalAppID}" \
--service-principal-secret "{serviceprincipalPassword}" \
--resource-group "{ResourceGroupName}" \
--tenant-id "{tenantID}" \
--location "{resourceLocation}" \
--subscription-id "{subscriptionID}"
--verbose

Agent connection issues to service

The following table lists some of the known errors and suggestions on how to troubleshoot and resolve them.

Message Error Probable cause Solution

Failed to acquire Error occurred while sending request for Device Authorization Code: Post Can't reach Run
authorization https://login.windows.net/fb84ce97-b875-4d12-b031-ef5e7edf9c8e/oauth2/devicecode?api- login.windows.net azcmagent
token device flow version=1.0: dial tcp 40.126.9.7:443: connect: network is unreachable. endpoint check to see
if a firewall
is blocking
access to
Microsoft
Entra ID.

Failed to acquire Error occurred while sending request for Device Authorization Code: Post Proxy or firewall is Run
authorization https://login.windows.net/fb84ce97-b875-4d12-b031-ef5e7edf9c8e/oauth2/devicecode?api- blocking access to azcmagent
token device flow version=1.0: dial tcp 40.126.9.7:443: connect: network is Forbidden . login.windows.net check to see
endpoint. if a firewall
is blocking
access to
Microsoft
Entra ID.

Failed to acquire Error occurred while sending request for Device Authorization Code: Post Group Policy Object Verify the
authorization https://login.windows.net/fb84ce97-b875-4d12-b031-ef5e7edf9c8e/oauth2/devicecode?api- Computer GPO is
token device flow version=1.0: dial tcp lookup login.windows.net: no such host . Configuration\ enabled
Administrative and
Templates\ System\ targeting
 Message Error Probable cause Solution

User Profiles\ Delete the affected

user profiles older machine.
than a specified See
number of days on footnote 1
system restart is for further
enabled. details.

Failed to acquire Failed to execute the refresh request. Error = 'Post https://login.windows.net/fb84ce97-b875- Proxy or firewall is Run
authorization 4d12-b031-ef5e7edf9c8e/oauth2/token?api-version=1.0: Forbidden' blocking access to azcmagent
token from SPN login.windows.net check to see
endpoint. if a firewall
is blocking
access to
Microsoft
Entra ID.

Failed to acquire Invalid client secret is provided Wrong or invalid Verify the
authorization service principal service
token from SPN secret. principal
secret.

Failed to acquire Application with identifier 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' wasn't found in the Incorrect service Verify the
authorization directory 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'. This can happen if the application has not principal and/or service
token from SPN been installed by the administrator of the tenant or consented to by any user in the tenant Tenant ID. principal
and/or the
tenant ID.

Get ARM Resource The client '[email protected]' with object id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' does Wrong credentials Verify you
Response not have authorization to perform action 'Microsoft.HybridCompute/machines/read' over scope and/or permissions or the
'/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx- service
xxxxxxxxxxxx/resourcegroups/myResourceGroup/providers/Microsoft.HybridCompute/machines/MSJC01' principal is
or the scope is invalid. If access was recently granted, please refresh your credentials."}}" a member
Status Code=403 of the
Azure
Connected
Machine
Onboarding
role.

Failed to The subscription isn't registered to use namespace 'Microsoft.HybridCompute' Azure resource Register the
AzcmagentConnect providers aren't resource
ARM resource registered. providers.

Failed to Get https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx- Proxy server or Run

AzcmagentConnect xxxxxxxxxxxx/resourcegroups/myResourceGroup/providers/Microsoft.HybridCompute/machines/MSJC01? firewall is blocking azcmagent
ARM resource api-version=2019-03-18-preview: Forbidden access to check to see
management.azure.com if a firewall
endpoint. is blocking
access to
Azure
Resource
Manager.

1If this GPO is enabled and applies to machines with the Connected Machine agent, it deletes the user profile associated with the built-in
account specified for the himds service. As a result, it also deletes the authentication certificate used to communicate with the service
that is cached in the local certificate store for 30 days. Before the 30-day limit, an attempt is made to renew the certificate. To resolve this
issue, follow the steps to disconnect the agent and then re-register it with the service running azcmagent connect .

Next steps
If you don't see your problem here or you can't resolve your issue, try one of the following channels for more support:

Get answers from Azure experts through Microsoft Q&A.

Connect with @AzureSupport , the official Microsoft Azure account for improving customer experience. Azure Support connects
the Azure community to answers, support, and experts.

File an Azure support incident. Go to the Azure support site , and select Get Support.
Troubleshoot Azure Arc-enabled servers
VM extension issues
Article • 09/07/2021

This article provides information on troubleshooting and resolving issues that may occur
while attempting to deploy or remove Azure VM extensions on Azure Arc-enabled
servers. For general information, see Manage and use Azure VM extensions.

General troubleshooting
Data about the state of extension deployments can be retrieved from the Azure portal.

The following troubleshooting steps apply to all VM extensions.

1. To check the Guest agent log, look at the activity when your extension was being
provisioned in %SystemDrive%\ProgramData\GuestConfig\ext_mgr_logs for Windows,
and for Linux under /var/lib/GuestConfig/ext_mgr_logs .

2. Check the extension logs for the specific extension for more details in
%SystemDrive%\ProgramData\GuestConfig\extension_logs\<Extension> for Windows.
Extension output is logged to a file for each extension installed on Linux under
/var/lib/GuestConfig/extension_logs .

3. Check extension-specific documentation troubleshooting sections for error codes,

known issues etc. Additional troubleshooting information for each extension can
be found in the Troubleshoot and support section in the overview for the
extension. This includes the description of error codes written to the log. The
extension articles are linked in the extensions table.

4. Look at the system logs. Check for other operations that may have interfered with
the extension, such as a long running installation of another application that
required exclusive package manager access.

Troubleshooting specific extension scenarios

VM Insights
When enabling VM Insights for an Azure Arc-enabled server, it installs the
Dependency and Log Analytics agent. On a slow machine or one with a slow
 network connection, it is possible to see timeouts during the installation process.
Microsoft is taking steps to address this in the Connected Machine agent to help
improve this condition. In the interim, a retry of the installation may succeed.

Log Analytics agent for Linux

The Log Analytics agent version 1.13.9 (corresponding extension version is 1.13.15)
is not correctly marking uploaded data with the resource ID of the Azure Arc-
enabled server. Although logs are being sent to the service, when you try to view
the data from the selected enabled server after selecting Logs or Insights, no data
is returned. You can view its data by running queries from Azure Monitor Logs or
from Azure Monitor for VMs, which are scoped to the workspace.

Some distributions are not currently supported by the Log Analytics agent for
Linux. The agent requires additional dependencies to be installed, including Python
2. Review the support matrix and prerequisites here.

Error code 52 in the status message indicates a missing dependency. Check the
output and logs for more information about which dependency is missing.

If an installation fails, review the Troubleshoot and support section in the overview
for the extension. In most cases, there is an error code included in the status
message. For the Log Analytics agent for Linux, status messages are explained
here, along with general troubleshooting information for this VM extension.

Next steps
If you don't see your problem here or you can't resolve your issue, try one of the
following channels for additional support:

Get answers from Azure experts through Microsoft Q&A.

Connect with @AzureSupport , the official Microsoft Azure account for improving
customer experience. Azure Support connects the Azure community to answers,
support, and experts.

File an Azure support incident. Go to the Azure support site , and select Get
Support.
Security overview for Azure Arc-enabled
servers
Article • 06/13/2024

This article describes the security considerations and controls available when using
Azure Arc-enabled servers. Whether you’re a security practitioner or IT operator, the
information in this article let's you confidently configure Azure Arc in a way that meets
your organization’s security requirements.

Responsibilities
The security of your Azure Arc-enabled Servers deployment is a shared responsibility
between you and Microsoft. Microsoft is responsible for:

To secure the cloud service that stores system metadata and orchestrate
operations for the agents you connect to the service.
Securing and protecting the privacy of your system metadata stored in Azure.
Documenting optional security features so you understand the benefits and
drawbacks of deployment options.
Publishing regular agent updates with security, quality, performance, and feature
improvements.

You're responsible for:

Managing and monitoring RBAC access to your Azure Arc-enabled resources in

your Azure subscription.
Protecting and regularly rotating the credentials of any accounts used to manage
Azure Arc-enabled servers. This includes any service principal secrets or credentials
used to onboard new servers.
Determining if and how any security features described in this document (for
example, extension allowlists) should be applied to the Azure Connected Machine
agents you deploy.
Keeping the Azure Connected Machine agent and extensions up-to-date.
Determining Azure Arc’s compliance with your organization’s legal, and regulatory,
and internal policy obligations.
Securing the server itself, including the compute, storage, and networking
infrastructure used to run the server.

Architecture overview
Azure Arc-enabled servers is an agent-based service. Your interaction with Azure Arc is
primarily through Azure’s APIs, portal, and management experiences. The data you see
and actions you take in Azure are relayed via the Azure Connected Machine agent
installed on each managed server. Azure is the source of truth for the agent. The only
way to tell the agent to do something (for example, install an extension) is to take an
action on the Azure representation of the server. This helps ensure that your
organization’s RBAC and policy assignments can evaluate the request before any
changes are made.

The Azure Connected Machine agent is primarily an enablement platform for other
Azure and third-party services. Its core functionalities include:

Establishing a relationship between your machine and your Azure subscription

Providing a managed identity for the agent and other apps to use when
authenticating with Azure
Enabling other capabilities (agents, scripts) with extensions
Evaluating and enforcing settings on your server

Once the Azure Connected Machine agent is installed, you can enable other Azure
services on your server to meet your monitoring, patch management, remote access, or
other needs. Azure Arc’s role is to help enable those services to work outside of Azure’s
own datacenters.

You can use Azure Policy to limit what your organization’s users can do with Azure Arc.
Cloud-based restrictions like Azure Policy are a great way to apply security controls at-
scale while retaining flexibility to adjust the restrictions at any time. However, sometimes
you need even stronger controls to protect against a legitimately privileged account
being used to circumvent security measures (for example, disabling policies). To account
for this, the Azure Connected Machine agent also has security controls of its own that
take precedence over any restrictions set in the cloud.
 

Agent services
The Azure Connected Machine agent is a combination of four services/daemons that
run on your server and help connect it with Azure. They're installed together as a single
application and are managed centrally using the azcmagent command line interface.

Hybrid Instance Metadata Service

The Hybrid Instance Metadata Service (HIMDS) is the “core” service in the agent and is
responsible for registering the server with Azure, ongoing metadata synchronization
(heartbeats), managed identity operations, and hosting the local REST API which other
apps can query to learn about the device’s connection with Azure. This service is
unprivileged and runs as a virtual account (NT SERVICE\himds with SID S-1-5-80-
4215458991-2034252225-2287069555-1155419622-2701885083) on Windows or a
standard user account (himds) on Linux operating systems.

Extension manager
The extension manager is responsible for installing, configuring, upgrading, and
removing additional software on your machine. Out of the box, Azure Arc doesn’t know
how to do things like monitor or patch your machine. Instead, when you choose to use
those features, the extension manager downloads and enables those capabilities. The
extension manager runs as Local System on Windows and root on Linux because the
software it installs may require full system access. You can limit which extensions the
extension manager is allowed to install or disable it entirely if you don’t intend to use
extensions.

Guest configuration
The guest configuration service evaluates and enforces Azure machine (guest)
configuration policies on your server. These are special Azure policies written in
PowerShell Desired State Configuration to check software settings on a server. The guest
configuration service regularly evaluates and reports on compliance with these policies
and, if the policy is configured in enforce mode, will change settings on your system to
bring the machine back into compliance if necessary. The guest configuration service
runs as Local System on Windows and root on Linux to ensure it has access to all
settings on your system. You can disable the guest configuration feature if you don't
intend to use guest configuration policies.

Azure Arc proxy

The Azure Arc proxy service is responsible for aggregating network traffic from the
Azure Connected Machine agent services and any extensions you’ve installed and
deciding where to route that data. If you’re using the Azure Arc Gateway to simplify your
network endpoints, the Azure Arc Proxy service is the local component that forwards
network requests via the Azure Arc Gateway instead of the default route. The Azure Arc
proxy runs as Network Service on Windows and a standard user account (arcproxy) on
Linux. It's disabled by default until you configure the agent to use the Azure Arc
Gateway.

Security considerations for Tier 0 assets

Tier 0 assets such as an Active Directory Domain Controller, Certificate Authority server,
or highly sensitive business application server can be connected to Azure Arc with extra
care to ensure only the desired management functions and authorized users can
manage the servers. These recommendations are not required but are strongly
recommended to maintain the security posture of your Tier 0 assets.

Dedicated Azure subscription

Access to Azure Arc-enabled servers is often determined by the organizational hierarchy
to which it belongs in Azure. You should treat any subscription or management group
admin as equivalent to a local administrator on Tier 0 assets because they could use
their permissions to add new role assignments to the Azure Arc resource. Additionally,
policies applied at the subscription or management group level may also have
permission to make changes to the server.

To minimize the number of accounts and policies with access to your Tier 0 assets,
consider using a dedicated Azure subscription that can be closely monitored and
configured with as few persistent administrators as possible. Review Azure policies in
any parent management groups to ensure they are aligned with your intent for these
servers.

Disable unnecessary management features

For a Tier 0 asset, you should use the local agent security controls to disable any unused
functionality in the agent to prevent any intentional—or accidental—use of those
features to make changes to the server. This includes:

Disabling remote access capabilities

Setting an extension allowlist for the extensions you intend to use, or disabling the
extension manager if you are not using extensions
Disabling the machine configuration agent if you don’t intend to use machine
configuration policies

The following example shows how to lock down the Azure Connected Machine agent
for a domain controller that needs to use the Azure Monitor Agent to collect security
logs for Microsoft Sentinel and Microsoft Defender for Servers to protect against
malware threats:

azcmagent config set incomingconnections.enabled false

azcmagent config set guestconfiguration.enabled false

azcmagent config set extensions.allowlist

“Microsoft.Azure.Monitor/AzureMonitorWindowsAgent,Microsoft.Azure.AzureDefen
derForServers/MDE.Windows”

Feedback
Was this page helpful?  Yes  No

Provide product feedback

Planning and deployment guidance
Article • 06/13/2024

The Azure Arc Landing Zone Accelerator for Hybrid and Multicloud has a complete set
of guidance for you to consider as you plan an Azure Arc-enabled servers deployment.
This section contains a selection of that content with security relevance.

Resource hierarchy and inherited access

The subscription and resource group where you choose to connect your machine will
influence which users and accounts in your organization can see and manage the
machine from Azure. Generally, you should organize your servers based on the groups
of accounts that need to access them. If you have two teams managing two separate
sets of servers who shouldn't be able to manage each other’s machines, you should use
two resource groups and control access to the servers at the resource group.

Onboarding credential
When you connect a server to Azure Arc, you need to use an onboarding credential to
authorize the machine to create a resource in your Azure subscription. There are three
ways to provide credentials:

1. Interactive logons, either using the local web browser (Windows-only) or a device
login code that can be entered on any computer with internet access.

2. Service principals, which are dedicated accounts that can be used for scripted
installations of the agent. Service principals consist of a unique application ID and
either a plain text secret or a certificate. If you choose to use a service principal,
you should use certificates instead of secrets because they can be controlled with
Microsoft Entra conditional access policies. Remember to protect access to and
regularly rotate the service principal secrets/certificates to minimize the risk of a
compromised credential.

3. Access tokens, which are short-lived and obtained from another credential.

No matter the type of credential you choose to use, the most important part is to
ensure that it has only the required permissions to onboard machines to Azure Arc and
nothing extra. The Azure Connected Machine Onboarding role is designed specifically
for onboarding credentials and only includes the necessary permissions to create and
read Azure Arc-enabled server resources in Azure. You should also limit the scope of the
role assignment to only the resource groups or subscriptions necessary to onboard your
servers.

The onboarding credential is only needed at the time the azcmagent connect step is run
on a server. It's not needed once a server is connected. If the onboarding credential
expires or is deleted, the server continues to be connected to Azure.

If a malicious actor gains access to your onboarding credential, they could use the
credential to onboard servers outside of your organization to Azure Arc within your
subscription/resource group. You can use private endpoints to protect against such
attacks by restricting access to Azure Arc within your network.

Protecting secrets in onboarding script

The onboarding script contains all the information needed to connect your server to
Azure. This includes steps to download, install, and configure the Azure Connected
Machine agent on your server. It also includes the onboarding credential used to non-
interactively connect that server to Azure. It’s important to protect the onboarding
credential so it isn't accidentally captured in logs and end up in the wrong hands.

For production deployments, it’s common to orchestrate the onboarding script using an
automation tool such as Microsoft Configuration Manager, Red Hat Ansible, or Group
Policy. Check with your automation tool to see if it has a way to protect secrets used in
the installation script. If it doesn’t, consider moving the onboarding script parameters to
a dedicated configuration file. This prevents secrets from being parsed and potentially
logged directly on the command line. The Group Policy onboarding guidance includes
extra steps to encrypt the configuration file so that only computer accounts can decrypt
it, not users or others outside your organization.

If your automation tool copies the configuration file to the server, make sure it also
cleans up the file after it's done so the secrets don’t persist longer than necessary.

Additionally, as with all Azure resources, tags for Azure Arc-enabled servers are stored
as plain text. Don't put sensitive information in tags.

Agent updates
A new version of the Azure Connected Machine agent is typically released every month.
There isn’t an exact schedule of when the updates are available, but you should check
for and apply updates on a monthly basis. Refer to the list of all the new releases,
including what specific changes are included in them. Most updates include security,
performance. and quality fixes. Some also include new features and functionality. When
a hotfix is required to address an issue with a release, it's released as a new agent
version and available via the same means as a regular agent release.

The Azure Connected Machine agent doesn't update itself. You must update it using
your preferred update management tool. For Windows machines, updates are delivered
through Microsoft Update. Standalone servers should opt-in to Microsoft Updates
(using the receive updates for other Microsoft products option). If your organization uses
Windows Server Update Services to cache and approve updates locally, your WSUS
admin must synchronize and approve updates for the Azure Connected Machine agent
product.

Linux updates are published to packages.microsoft.com . Your package management

software (apt, yum, dnf, zypper, etc.) should show “azcmagent” updates alongside your
other system packages. Learn more about upgrading Linux agents.

Microsoft recommends staying up to date with the latest agent version whenever
possible. If your maintenance windows are less frequent, Microsoft supports all agent
versions released within the last 12 months. However, since the agent updates include
security fixes, you should update as frequently as possible.

If you're looking for a patch management tool to orchestrate updates of the Azure
Connected Machine agent on both Windows and Linux, consider Azure Update
Manager.

Extension updates

Automatic extension updates

By default, every extension you deploy to an Azure Arc-enabled server has automatic
extension upgrades enabled. If the extension publisher supports this feature, new
versions of the extension are automatically installed within 60 days of the new version
becoming available. Automatic extension upgrades follow a safe deployment practice,
meaning that only a small number of extensions are updated at a time. Rollouts
continue slowly across regions and subscriptions until every extension is updated.

There are no granular controls over automatic extension upgrades. You'll always be
upgraded to the most recent version of the extension and can’t choose when the
upgrade happens. The extension manager has built-in resource governance to ensure
an extension upgrade doesn't consume too much of the system’s CPU and interfere with
your workloads during the upgrade.
If you don't want to use automatic upgrades for extensions, you can disable them on a
per-extension, per-server basis using the Azure portal, CLI, or PowerShell.

Manual extension updates

For extensions that don’t support automatic upgrades or have automatic upgrades
disabled, you can use the Azure portal, CLI, or PowerShell to upgrade extensions to the
newest version. The CLI and PowerShell commands also support downgrading an
extension, in case you need to revert to an earlier version.

Using disk encryption

The Azure Connected Machine agent uses public key authentication to communicate
with the Azure service. After you onboard a server to Azure Arc, a private key is saved to
the disk and used whenever the agent communicates with Azure. If stolen, the private
key can be used on another server to communicate with the service and act as if it were
the original server. This includes getting access to the system assigned identity and any
resources that identity has access to. The private key file is protected to only allow the
himds account access to read it. To prevent offline attacks, we strongly recommend the
use of full disk encryption (for example, BitLocker, dm-crypt, etc.) on the operating
system volume of your server.
Network security
Article • 06/13/2024

This article describes the networking requirements and options for Azure Arc-enabled
servers.

General networking
Azure Arc-enabled servers is a software-as-a-service offering with a combination of
global and regional endpoints shared by all customers. All network communication from
the Azure Connected Machine agent is outbound to Azure. Azure will never reach "into"
your network to manage your machines. These connections are always encrypted using
TLS certificates. The list of endpoints and IP addresses accessed by the agent are
documented in the network requirements.

Extensions you install may require extra endpoints not included in the Azure Arc
network requirements. Consult the extension documentation for further information on
network requirements for that solution.

If your organization uses TLS inspection, the Azure Connected Machine agent doesn't
use certificate pinning and will continue to work, so long as your machine trusts the
certificate presented by the TLS inspection service. Some Azure Arc extensions use
certificate pinning and need to be excluded from TLS inspection. Consult the
documentation for any extensions you deploy to determine if they support TLS
inspection.

Private endpoints
Private endpoints are an optional Azure networking technology that allows network
traffic to be sent over Express Route or a site-to-site VPN and more granularly control
which machines can use Azure Arc. With private endpoints, you can use private IP
addresses in your organization’s network address space to access the Azure Arc cloud
services. Additionally, only servers you authorize are able to send data through these
endpoints, which protects against unauthorized use of the Azure Connected Machine
agent in your network.

It’s important to note that not all endpoints and not all scenarios are supported with
private endpoints. You'll still need to make firewall exceptions for some endpoints like
Microsoft Entra ID, which doesn't offer a private endpoint solution. Any extensions you
install may require other private endpoints (if supported) or access to the public
endpoints for their services. Additionally, you can’t use SSH or Windows Admin Center
to access your server over a private endpoint.

Regardless of whether you use private or public endpoints, data transferred between the
Azure Connected Machine agent and Azure is always encrypted. You can always start
with public endpoints and later switch to private endpoints (or vice versa) as your
business needs change.
Extensions security
Article • 06/13/2024

This article describes the fundamentals of VM extensions for Azure Arc-enabled servers
and details how extension settings can be customized.

Extension basics
VM extensions for Azure Arc-enabled servers are optional add-ons that enable other
functionality, such as monitoring, patch management, and script execution. Extensions
are published by Microsoft and select third parties from the Azure Marketplace and
stored in Microsoft-managed storage accounts. All extensions are scanned for malware
as part of the publishing process. The extensions for Azure Arc-enabled servers are
identical to those available for Azure VMs, ensuring consistency across your operating
environments.

Extensions are downloaded directly from Azure Storage ( *.blob.core.windows.net ) at

the time they are installed or upgraded, unless you have configured private endpoints.
The storage accounts regularly change and can’t be predicted in advance. When private
endpoints are used, extensions are proxied via the regional URL for the Azure Arc
service instead.

A digitally signed catalog file is downloaded separately from the extension package and
used to verify the integrity of each extension before the extension manager opens or
executes the extension package. If the downloaded ZIP file for the extension doesn’t
match the contents in the catalog file, the extension operation will be aborted.

Extensions may take settings to customize or configure the installation, such as proxy
URLs or API keys to connect a monitoring agent to its cloud service. Extension settings
come in two flavors: regular settings and protected settings. Protected settings aren’t
persisted in Azure and are encrypted at rest on your local machine.

All extension operations originate from Azure through an API call, CLI, PowerShell, or
Portal action. This design ensures that any action to install, update, or upgrade an
extension on a server gets logged in the Azure Activity Log. The Azure Connected
Machine agent does allow extensions to be removed locally for troubleshooting and
cleanup purposes. However, if the extension is removed locally and the service still
expects the machine to have the extension installed, it will be reinstalled the next time
the extension manager syncs with Azure.
Script execution
The extension manager can be used to run scripts on machines using the Custom Script
Extension or Run Command. By default, these scripts will run in the extension manager’s
user context – Local System on Windows or root on Linux – meaning these scripts will
have unrestricted access to the machine. If you do not intend to use these features, you
can block them using an allowlist or blocklist. An example is provided in the next
section.

Local agent security controls

Starting with agent version 1.16, you can optionally limit the extensions that can be
installed on your server and disable Guest Configuration. These controls can be useful
when connecting servers to Azure for a single purpose, such as collecting event logs,
without allowing other management capabilities to be used on the server.

These security controls can only be configured by running a command on the server
itself and cannot be modified from Azure. This approach preserves the server admin's
intent when enabling remote management scenarios with Azure Arc, but also means
that changing the setting is more difficult if you later decide to change them. This
feature is intended for sensitive servers (for example, Active Directory Domain
Controllers, servers that handle payment data, and servers subject to strict change
control measures). In most other cases, it's not necessary to modify these settings.

Allowlists and blocklists

The Azure Connected Machine agent supports an allowlist and blocklist to restrict which
extensions can be installed on your machine. Allowlists are exclusive, meaning that only
the specific extensions you include in the list can be installed. Blocklists are exclusive,
meaning anything except those extensions can be installed. Allowlists are preferable to
blocklists because they inherently block any new extensions that become available in
the future. Allowlists and blocklists are configured locally on a per-server basis. This
ensures that nobody, not even a user with Owner or Global Administrator permissions in
Azure, can override your security rules by trying to install an unauthorized extension. If
someone tries to install an unauthorized extension, the extension manager will refuse to
install it and mark the extension installation report a failure to Azure. Allowlists and
blocklists can be configured any time after the agent is installed, including before the
agent is connected to Azure.

If no allowlist or blocklist is configured on the agent, all extensions are allowed.

The most secure option is to explicitly allow the extensions you expect to be installed.
Any extension not in the allowlist is automatically blocked. To configure the Azure
Connected Machine agent to allow only the Azure Monitor Agent for Linux, run the
following command on each server:

Bash

azcmagent config set extensions.allowlist

"Microsoft.Azure.Monitor/AzureMonitorLinuxAgent"

Here is an example blocklist that blocks all extensions with the capability of running
arbitrary scripts:

azcmagent config set extensions.blocklist

“Microsoft.Cplat.Core/RunCommandHandlerWindows,
Microsoft.Cplat.Core/RunCommandHandlerLinux,Microsoft.Compute/CustomScriptEx
tension,Microsoft.Azure.Extensions/CustomScript,Microsoft.Azure.Automation.H
ybridWorker/HybridWorkerForWindows,Microsoft.Azure.Automation.HybridWorkerFo
rLinux,Microsoft.EnterpriseCloud.Monitoring/MicrosoftMonitoringAgent,
Microsoft.EnterpriseCloud.Monitoring/OMSAgentForLinux”

Specify extensions with their publisher and type, separated by a forward slash / . See the
list of the most common extensions in the docs or list the VM extensions already
installed on your server in the portal, Azure PowerShell, or Azure CLI.

The table describes the behavior when performing an extension operation against an
agent that has the allowlist or blocklist configured.

ﾉ Expand table

Operation In the In the In both the Not in any list, but an

allowlist blocklist allowlist and allowlist is configured
blocklist

Install extension Allowed Blocked Blocked Blocked

Update Allowed Blocked Blocked Blocked

(reconfigure)
extension

Upgrade extension Allowed Blocked Blocked Blocked

Delete extension Allowed Allowed Allowed Allowed

 ） Important

If an extension is already installed on your server before you configure an allowlist

or blocklist, it won't automatically be removed. It's your responsibility to delete the
extension from Azure to fully remove it from the machine. Delete requests are
always accepted to accommodate this scenario. Once deleted, the allowlist and
blocklist determine whether or not to allow future install attempts.

Starting with agent version 1.35, there is a special allowlist value Allow/None , which
instructs the extension manager to run, but not allow any extensions to be installed. This
is the recommended configuration when using Azure Arc to deliver Windows Server
2012 Extended Security Updates (ESU) without intending to use any other extensions.

Bash

azcmagent config set extensions.allowlist "Allow/None"

Azure Policies can also be used to restrict which extensions can be installed. Azure
Policies have the advantage of being configurable in the cloud and not requiring a
change on each individual server if you need to change the list of approved extensions.
However, anyone with permission to modify policy assignments could override or
remove this protection. If you choose to use Azure Policies to restrict extensions, make
sure you review which accounts in your organization have permission to edit policy
assignments and that appropriate change control measures are in place.

Locked down machine best practices

When configuring the Azure Connected Machine agent with a reduced set of
capabilities, it's important to consider the mechanisms that someone could use to
remove those restrictions and implement appropriate controls. Anybody capable of
running commands as an administrator or root user on the server can change the Azure
Connected Machine agent configuration. Extensions and guest configuration policies
execute in privileged contexts on your server, and as such might be able to change the
agent configuration. If you apply local agent security controls to lock down the agent,
Microsoft recommends the following best practices to ensure only local server admins
can update the agent configuration:

Use allowlists for extensions instead of blocklists whenever possible.

Don't include the Custom Script Extension in the extension allowlist to prevent
execution of arbitrary scripts that could change the agent configuration.
 Disable Guest Configuration to prevent the use of custom Guest Configuration
policies that could change the agent configuration.

Example configuration for monitoring and security

scenarios
It's common to use Azure Arc to monitor your servers with Azure Monitor and Microsoft
Sentinel and secure them with Microsoft Defender for Cloud. This section contains
examples for how to lock down the agent to only support monitoring and security
scenarios.

Azure Monitor Agent only

On your Windows servers, run the following commands in an elevated command

console:

PowerShell

azcmagent config set extensions.allowlist

"Microsoft.Azure.Monitor/AzureMonitorWindowsAgent"
azcmagent config set guestconfiguration.enabled false

On your Linux servers, run the following commands:

Bash

sudo azcmagent config set extensions.allowlist

"Microsoft.Azure.Monitor/AzureMonitorLinuxAgent"
sudo azcmagent config set guestconfiguration.enabled false

Log Analytics and dependency (Azure Monitor VM Insights) only

This configuration is for the legacy Log Analytics agents and the dependency agent.

On your Windows servers, run the following commands in an elevated console:

PowerShell

azcmagent config set extensions.allowlist

"Microsoft.EnterpriseCloud.Monitoring/MicrosoftMonitoringAgent,Microsoft.Azu
re.Monitoring.DependencyAgent/DependencyAgentWindows"
azcmagent config set guestconfiguration.enabled false
On your Linux servers, run the following commands:

Bash

sudo azcmagent config set extensions.allowlist

"Microsoft.EnterpriseCloud.Monitoring/OMSAgentForLinux,Microsoft.Azure.Monit
oring.DependencyAgent/DependencyAgentLinux"
sudo azcmagent config set guestconfiguration.enabled false

Monitoring and security

Microsoft Defender for Cloud deploys extensions on your server to identify vulnerable
software on your server and enable Microsoft Defender for Endpoint (if configured).
Microsoft Defender for Cloud also uses Guest Configuration for its regulatory
compliance feature. Since a custom Guest Configuration assignment could be used to
undo the agent limitations, you should carefully evaluate whether or not you need the
regulatory compliance feature and, as a result, Guest Configuration to be enabled on the
machine.

On your Windows servers, run the following commands in an elevated command

console:

PowerShell

azcmagent config set extensions.allowlist

"Microsoft.EnterpriseCloud.Monitoring/MicrosoftMonitoringAgent,Qualys/Window
sAgent.AzureSecurityCenter,Microsoft.Azure.AzureDefenderForServers/MDE.Windo
ws,Microsoft.Azure.AzureDefenderForSQL/AdvancedThreatProtection.Windows"
azcmagent config set guestconfiguration.enabled true

On your Linux servers, run the following commands:

Bash

sudo azcmagent config set extensions.allowlist

"Microsoft.EnterpriseCloud.Monitoring/OMSAgentForLinux,Qualys/LinuxAgent.Azu
reSecurityCenter,Microsoft.Azure.AzureDefenderForServers/MDE.Linux"
sudo azcmagent config set guestconfiguration.enabled true

Agent modes
A simpler way to configure local security controls for monitoring and security scenarios
is to use the monitor mode, available with agent version 1.18 and newer. Modes are pre-
defined configurations of the extension allowlist and guest configuration agent
maintained by Microsoft. As new extensions become available that enable monitoring
scenarios, Microsoft will update the allowlist and agent configuration to include or
exclude the new functionality, as appropriate.

There are two modes to choose from:

1. full - the default mode. This allows all agent functionality.

2. monitor - a restricted mode that disables the guest configuration policy agent and
only allows the use of extensions related to monitoring and security.

To enable monitor mode, run the following command:

Bash

azcmagent config set config.mode monitor

You can check the current mode of the agent and allowed extensions with the following
command:

Bash

azcmagent config list

While in monitor mode, you cannot modify the extension allowlist or blocklist. If you
need to change either list, change the agent back to full mode and specify your own
allowlist and blocklist.

To change the agent back to full mode, run the following command:

Bash

azcmagent config set config.mode full

Disabling the extension manager

If you don’t need to use extensions with Azure Arc, you can also disable the extension
manager entirely. You can disable the extension manager with the following command
(run locally on each machine):

azcmagent config set extensions.enabled false

Disabling the extension manager won't remove any extensions already installed on your
server. Extensions that are hosted in their own Windows or Linux services, such as the
Log Analytics Agent, might continue to run even if the extension manager is disabled.
Other extensions that are hosted by the extension manager itself, like the Azure Monitor
Agent, don't run if the extension manger is disabled. You should remove any extensions
before disabling the extension manager to ensure no extensions continue to run on the
server.
Configuration and remote access
Article • 06/13/2024

This article describes the basics of Azure Machine Configuration, a compliance reporting
and configuration tool that can check and optionally remediate security and other
settings on machines at scale. This article also describes the Azure Arc connectivity
platform, used for communication between the Azure Connected Machine agent and
Azure.

Machine configuration basics

Azure Machine Configuration is a PowerShell Desired State Configuration-based
compliance reporting and configuration tool. It can help you check security and other
settings on your machines at-scale and optionally remediate them if they drift from the
approved state. Microsoft provides its own built-in Machine Configuration policies for
your use, or you can author your own policies to check any condition on your machine.

Machine Configuration policies run in the Local System context on Windows or root on
Linux, and therefore can access any system settings or resources. You should review
which accounts in your organization have permission to assign Azure Policies or Azure
Guest Assignments (the Azure resource representing a machine configuration) and
ensure all those accounts are trusted.

Disabling the machine configuration agent

If you don’t intend to use machine configuration policies, you can disable the machine
configuration agent with the following command (run locally on each machine):

azcmagent config set guestconfiguration.enabled false

Agent modes
The Azure Connected Machine agent has two possible modes:

Full mode, the default mode which allows all use of agent functionality.

Monitor mode, which applies a Microsoft-managed extension allowlist, disables

remote connectivity, and disables the machine configuration agent.

If you’re using Arc solely for monitoring purposes, setting the agent to Monitor mode
makes it easy to restrict the agent to just the functionality required to use Azure
Monitor. You can configure the agent mode with the following command (run locally on
each machine):

azcmagent config set config.mode monitor

Azure Arc connectivity platform

The Azure Arc connectivity platform is a web sockets-based experience to allow real-
time communication between the Azure Connected Machine agent and Azure. This
enables interactive remote access scenarios to your server without requiring direct line
of sight from the management client to the server.

The connectivity platform supports two scenarios:

SSH access to Azure Arc-enabled servers

Windows Admin Center for Azure Arc-enabled servers

For both scenarios, the management client (SSH client or web browser) talks to the
Azure Arc connectivity service that then relays the information to and from the Azure
Connected Machine agent.

Connectivity access is disabled by default and is enabled using a three step process:

1. Create a connectivity endpoint in Azure for the Azure Arc-enabled server. The
connectivity endpoint isn’t a real endpoint with an IP address. It’s just a way of
saying that access to this server via Azure is allowed and provides an API to
retrieve the connection details for management clients.

2. Configure the connectivity endpoint to allow your specific intended scenarios.

Having an endpoint created doesn’t allow any traffic through. Instead, you need to
configure it to say, “we allow traffic to this local port on the target server.” For SSH,
that’s commonly TCP port 22. For WAC, TCP port 6516.

3. Assign the appropriate RBAC roles to the accounts that will use this feature.
Remote access to servers requires other role assignments. Common roles like
Azure Connected Machine Resource Administrator, Contributor, and Owner don't
grant access to use SSH or WAC via the Azure Arc Connectivity Platform. Roles that
allow remote access include:

Virtual Machine Local User Login (SSH with local credentials)

Virtual Machine User Login (SSH with Microsoft Entra ID, standard user
access)
 Virtual Machine Administrator Login (SSH with Microsoft Entra ID, full admin
access)
Windows Admin Center Administrator Login (WAC with Microsoft Entra ID
authentication)

 Tip

Consider using Microsoft Entra Privileged Identity Management to provide your IT

operators with just-in-time access to these roles. This enables a least privilege
approach to remote access.

There's a local agent configuration control as well to block remote access, regardless of
the configuration in Azure.

Disabling remote access

To disable all remote access to your machine, run the following command on each
machine:

azcmagent config set incomingconnections.enabled false

SSH access to Azure Arc-enabled servers

SSH access via the Azure Arc connectivity platform can help you avoid opening SSH
ports directly through a firewall or requiring your IT operators to use a VPN. It also
allows you to grant access to Linux servers using Entra IDs and Azure RBAC, reducing
the management overhead of distributing and protecting SSH keys.

When a user connects using SSH and Microsoft Entra ID authentication, a temporary
account is created on the server to manage it on their behalf. The account is named
after the user’s UPN in Azure to help you audit actions taken on the machine. If the user
has the "Virtual Machine Administrator Login" role, the temporary account is created as
a member of the sudoers group so that it can elevate to perform administrative tasks on
the server. Otherwise, the account is just a standard user on the machine. If you change
the role assignment from user to administrator or vice versa, it can take up to 10
minutes for the change to take effect. Users must disconnect any active SSH sessions
and reconnect to see the changes reflected on the local user account.

When a user connects using local credentials (SSH key or password), they get the
permissions and group memberships of the account information they provided.
Windows Admin Center
WAC in the Azure portal allows Windows users to see and manage their Windows Server
without connecting over Remote Desktop Connection. The “Windows Admin Center
Administrator Login” role is required to use the WAC experience in the Azure portal.
When the user opens the WAC experience, a virtual account is created on the Windows
Server using the UPN of the Azure user to identify them. This virtual account is a
member of the administrators group and can make changes to the system. Actions the
user takes in WAC are then executed locally on the server using this virtual account.

Interactive access to the machine with the PowerShell or Remote Desktop experiences in
WAC don't currently support Microsoft Entra ID authentication and will prompt the user
to provide local user credentials. These credentials aren't stored in Azure and are only
used to establish the PowerShell or Remote Desktop session.
Identity and authorization
Article • 06/13/2024

This article describes the Microsoft Entra ID managed identity for Azure Arc-enabled
servers, which is used for authentication when communicating with Azure and details
two built-in RBAC roles.

Microsoft Entra ID managed identity

Every Azure Arc-enabled server has a system-assigned Microsoft Entra ID managed
identity associated with it. This identity is used by the agent to authenticate itself with
Azure. It can also be used by extensions or other authorized apps on your system to
access resources that understand OAuth tokens. The managed identity appears in the
Microsoft Entra ID portal with the same name as the Azure Arc-enabled server resource.
For example, if your Azure Arc-enabled server is named prodsvr01, an enterprise app in
Microsoft Entra ID with the same name appears.

Each Microsoft Entra ID directory has a finite limit for the number of objects it can store.
A managed identity counts as one object in the directory. If you're planning a large
deployment of Azure Arc-enabled servers, check the available quota in your Microsoft
Entra ID directory first and submit a support request for more quota if necessary. You
can see the available and used quota in the List Organizations API response under the
“directorySizeLimit” section.

The managed identity is fully managed by the agent. As long as the agent stays
connected to Azure, it handles rotating the credential automatically. The certificate
backing the managed identity is valid for 90 days. The agent attempts to renew the
certificate when it has 45 or fewer days of validity remaining. If the agent is offline long
enough to expire, the agent becomes “expired” as well and won't connect to Azure. In
this situation, automatic reconnection isn't possible and requires you to disconnect and
reconnect the agent to Azure using an onboarding credential.

The managed identity certificate is stored on the local disk of the system. It’s important
that you protect this file, because anyone in possession of this certificate can request a
token from Microsoft Entra ID. The agent stores the certificate in
C:\ProgramData\AzureConnectedMachineAgent\Certs\ on Windows and
/var/opt/azcmagent/certs on Linux. The agent automatically applies an access control
list to this directory, restricting access to local administrators and the "himds" account.
Don't modify access to the certificate files or modify the certificates on your own. If you
think the credential for a system-assigned managed identity has been compromised,
disconnect the agent from Azure and connect it again to generate a new identity and
credential. Disconnecting the agent removes the resource in Azure, including its
managed identity.

When an application on your system wants to get a token for the managed identity, it
issues a request to the REST identity endpoint at http://localhost:40342/identity. There
are slight differences in how Azure Arc handles this request compared to Azure VM. The
first response from the API includes a path to a challenge token located on disk. The
challenge token is stored in C:\ProgramData\AzureConnectedMachineAgent\tokens on
Windows or /var/opt/azcmagent/tokens on Linux. The caller must prove they have access
to this folder by reading the contents of the file and reissuing the request with this
information in the authorization header. The tokens directory is configured to allow
administrators and any identity belonging to the "Hybrid agent extension applications"
(Windows) or the "himds" (Linux) group to read the challenge tokens. If you're
authorizing a custom application to use the system-assigned managed identity, you
should add its user account to the appropriate group to grant it access.

To learn more about using a managed identity with Arc-enabled servers to authenticate
and access Azure resources, see the following video.
https://www.youtube-nocookie.com/embed/4hfwxwhWcP4

RBAC roles
There are two built-in roles in Azure that you can use to control access to an Azure Arc-
enabled server:

Azure Connected Machine Onboarding, intended for accounts used to connect

new machines to Azure Arc. This role allows accounts to see and create new Arc
servers but disallows extension management.

Azure Connected Machine Resource Administrator, intended for accounts that

will manage servers once they’re connected. This role allows accounts to read,
create, and delete Arc servers, VM extensions, licenses, and private link scopes.

Generic RBAC roles in Azure also apply to Azure Arc-enabled servers, including Reader,
Contributor, and Owner.

Identity and access control

Azure role-based access control is used to control which accounts can see and manage
your Azure Arc-enabled server. From the Access Control (IAM) page in the Azure portal,
you can verify who has access to your Azure Arc-enabled server.
Users and applications granted contributor or administrator role access to the resource
can make changes to the resource, including deploying or deleting extensions on the
machine. Extensions can include arbitrary scripts that run in a privileged context, so
consider any contributor on the Azure resource to be an indirect administrator of the
server.

The Azure Connected Machine Onboarding role is available for at-scale onboarding,
and is only able to read or create new Azure Arc-enabled servers in Azure. It cannot be
used to delete servers already registered or manage extensions. As a best practice, we
recommend only assigning this role to the Microsoft Entra service principal used to
onboard machines at scale.

Users as a member of the Azure Connected Machine Resource Administrator role can
read, modify, reonboard, and delete a machine. This role is designed to support
management of Azure Arc-enabled servers, but not other resources in the resource
group or subscription.
Data and privacy for Arc-enabled
servers
Article • 06/13/2024

This article explains the data collection process by the Azure Connected Machine agent
for Azure Arc-enabled servers, detailing how system metadata is gathered and sent to
Azure. This article also describes the logging mechanisms available for Azure Arc-
enabled servers, including the Azure Activity log for tracking server actions.

Information collected by Azure Arc

As part of its normal operation, the Azure Connected Machine agent collects system
metadata and sends it to Azure as part of its regular heartbeat. This metadata is
populated in the Azure Arc-enabled server resource so you can identify and query your
servers as part of your Azure inventory. Azure Arc collects no end user-identifiable data.

See instance metadata for a complete list of metadata collected by Azure Arc. This list is
regularly updated to reflect the data collected by the most recent release of the Azure
Connected Machine agent. It's not possible to opt out of this data collection because it's
used across Azure experiences to help filter and identify your servers.

To collect cloud metadata, the Azure Connected Machine agent queries the instance
metadata endpoints for AWS, GCP, Oracle Cloud, Azure Stack HCI and Azure. The agent
checks if it’s in a cloud once, each time the "himds" service is started. Your security
software may notice the agent reaching out to the following endpoints as part of that
process: 169.254.169.254, 169.254.169.253, and metadata.google.internal.

All data is handled according to Microsoft’s privacy standards .

Data replication and disaster recovery

Azure Arc-enabled servers is a software-as-a-service offering and handles data
replication and disaster recovery preparation on your behalf. When you select the
region to store your data, that data is automatically replicated to another region in that
same geography to protect against a regional outage. In the event a region becomes
unavailable, DNS records are automatically changed to point to the failover region. No
action is required from you and your agents will automatically reconnect when the
failover is complete.
In some geographies, only one region supports Azure Arc-enabled servers. In these
situations, data is still replicated for backup purposes to another region in that
geography but won't be able to fail over to another region during an outage. You
continue to see metadata in Azure from the last time your servers sent a heartbeat but
can't make changes or connect new servers until region functionality is restored. The
Azure Arc team regularly considers region expansion opportunities to minimize the
number of geographies in this configuration.

Compliance with regulatory standards

Azure Arc is regularly audited for compliance with many global, regional, and industry-
specific regulatory standards. A summary table of the compliance offerings is available
at https://aka.ms/AzureCompliance .

For more information on a particular standard and to download audit documents, see
Azure and other Microsoft cloud services compliance offerings.

Azure Activity log

You can use the Azure Activity log to track actions taken on an Azure Arc-enabled
server. Actions like installing extensions on an Arc server have unique operation
identifiers (all starting with “Microsoft.HybridCompute”) that you can use to filter the
log. Learn more about the Azure Activity Log and how to retain activity logs for more
than 30 days by sending activity log data to Log Analytics.

Local logs
The Azure Connected Machine agent keeps a set of local logs on each server that may
be useful for troubleshooting or auditing when the Arc agent made a change to the
system. The fastest way to get a copy of all logs from a server is to run azcmagent logs,
which generates a compressed folder of all the latest logs for you.

HIMDS log
The HIMDS log file contains all log data from the HIMDS service. This data includes
heartbeat information, connection and disconnection attempts, and a history of REST
API requests for IMDS metadata and managed identity tokens from other apps on the
system.
 ﾉ Expand table

OS Log location

Windows %PROGRAMDATA%\AzureConnectedMachineAgent\Log\himds.log

Linux /var/opt/azcmagent/log/himds.log

azcmagent CLI log

The azcmagent log file contains a history of commands run using the local “azcmagent”
command line interface. This log provides the parameters used when connecting,
disconnecting, or modifying the configuration of the agent.

ﾉ Expand table

OS Log location

Windows %PROGRAMDATA%\AzureConnectedMachineAgent\Log\azcmagent.log

Linux /var/opt/azcmagent/log/azcmagent.log

Extension Manager log

The extension manager log contains information about attempts to install, upgrade,
reconfigure, and uninstall extensions on the machine.

ﾉ Expand table

OS Log location

Windows %PROGRAMDATA%\GuestConfig\ext_mgr_logs\gc_ext.log

Linux /var/lib/GuestConfig/ext_mgr_logs/gc_ext.log

Other logs may be generated by individual extensions. Logs for individual extensions
aren't guaranteed to follow any standard log format.

ﾉ Expand table

OS Log location

Windows %PROGRAMDATA%\GuestConfig\extension_logs*
 OS Log location

Linux /var/lib/GuestConfig/extension_logs/*

Machine Configuration log

The machine configuration policy engine generates logs for the audit and enforcement
of settings on the system.

ﾉ Expand table

OS Log location

Windows %PROGRAMDATA%\GuestConfig\arc_policy_logs\gc_agent.log

Linux /var/lib/GuestConfig/arc_policy_logs/gc_agent.log
Azure security baseline for Azure Arc-
enabled servers
Article • 09/20/2023

This security baseline applies guidance from the Microsoft cloud security benchmark
version 1.0 to Azure Arc-enabled servers. The Microsoft cloud security benchmark
provides recommendations on how you can secure your cloud solutions on Azure. The
content is grouped by the security controls defined by the Microsoft cloud security
benchmark and the related guidance applicable to Azure Arc-enabled servers.

You can monitor this security baseline and its recommendations using Microsoft
Defender for Cloud. Azure Policy definitions will be listed in the Regulatory Compliance
section of the Microsoft Defender for Cloud portal page.

When a feature has relevant Azure Policy Definitions, they are listed in this baseline to
help you measure compliance with the Microsoft cloud security benchmark controls and
recommendations. Some recommendations may require a paid Microsoft Defender plan
to enable certain security scenarios.

７ Note

Features not applicable to Azure Arc-enabled servers have been excluded. To see
how Azure Arc-enabled servers completely maps to the Microsoft cloud security
benchmark, see the full Azure Arc-enabled servers security baseline mapping
file .

Security profile
The security profile summarizes high-impact behaviors of Azure Arc-enabled servers,
which may result in increased security considerations.

Service Behavior Attribute Value

Product Category Hybrid/Multi-Cloud,

MGMT/Governance

Customer can access HOST / OS No Access

Service can be deployed into customer's virtual False

network
 Service Behavior Attribute Value

Stores customer content at rest False

Network security
For more information, see the Microsoft cloud security benchmark: Network security.

NS-1: Establish network segmentation boundaries

Features

Virtual Network Integration

Description: Service supports deployment into customer's private Virtual Network

(VNet). Learn more.

Supported Enabled By Default Configuration Responsibility

False Not Applicable Not Applicable

Configuration Guidance: This feature is not supported to secure this service.

NS-2: Secure cloud services with network controls

Features

Azure Private Link

Description: Service native IP filtering capability for filtering network traffic (not to be
confused with NSG or Azure Firewall). Learn more.

Supported Enabled By Default Configuration Responsibility

True False Customer

Configuration Guidance: Deploy private endpoints for all Azure resources that support
the Private Link feature to establish a private access point for the resources.

Reference: Use Azure Private Link to securely connect servers to Azure Arc
Disable Public Network Access

Description: Service supports disabling public network access either through using
service-level IP ACL filtering rule (not NSG or Azure Firewall) or using a 'Disable Public
Network Access' toggle switch. Learn more.

Supported Enabled By Default Configuration Responsibility

True False Customer

Configuration Guidance: Disable public network access either using the service-level IP
ACL filtering rule or a toggling switch for public network access.

Reference: Use Azure Private Link to securely connect servers to Azure Arc

Identity management
For more information, see the Microsoft cloud security benchmark: Identity management.

IM-1: Use centralized identity and authentication system

Features

Azure AD Authentication Required for Data Plane Access

Description: Service supports using Azure AD authentication for data plane access.
Learn more.

Supported Enabled By Default Configuration Responsibility

True True Microsoft

Feature notes: There is no customer-facing data plane API.

Configuration Guidance: No additional configurations are required as this is enabled on

a default deployment.

Reference: Identity and access control for Azure Arc-enabled servers

Local Authentication Methods for Data Plane Access

Description: Local authentications methods supported for data plane access, such as a
local username and password. Learn more.

Supported Enabled By Default Configuration Responsibility

True False Customer

Feature notes: Local authentication is only used when connecting to the server using
SSH or Windows Admin Center. Avoid the usage of local authentication methods or
accounts, these should be disabled wherever possible. Instead use Azure AD to
authenticate where possible.

Configuration Guidance: Restrict the use of local authentication methods for data plane
access. Instead, use Azure Active Directory (Azure AD) as the default authentication
method to control your data plane access.

Reference: SSH access to Azure Arc-enabled servers

IM-3: Manage application identities securely and

automatically

Features

Managed Identities

Description: Data plane actions support authentication using managed identities. Learn
more.

Supported Enabled By Default Configuration Responsibility

True True Microsoft

Configuration Guidance: No additional configurations are required as this is enabled on

a default deployment.

Reference: Authenticate against Azure resources with Azure Arc-enabled servers

Service Principals

Description: Data plane supports authentication using service principals. Learn more.
 Supported Enabled By Default Configuration Responsibility

True False Customer

Configuration Guidance: There is no current Microsoft guidance for this feature

configuration. Please review and determine if your organization wants to configure this
security feature.

Reference: Create a service principal for onboarding at scale

IM-8: Restrict the exposure of credential and secrets

Features

Service Credential and Secrets Support Integration and Storage in

Azure Key Vault

Description: Data plane supports native use of Azure Key Vault for credential and secrets
store. Learn more.

Supported Enabled By Default Configuration Responsibility

False Not Applicable Not Applicable

Configuration Guidance: This feature is not supported to secure this service.

Privileged access
For more information, see the Microsoft cloud security benchmark: Privileged access.

PA-1: Separate and limit highly privileged/administrative

users

Features

Local Admin Accounts

Description: Service has the concept of a local administrative account. Learn more.
 Supported Enabled By Default Configuration Responsibility

True False Customer

Feature notes: Avoid the usage of local authentication methods or accounts, these
should be disabled wherever possible. Instead use Azure AD to authenticate where
possible.

Configuration Guidance: If not required for routine administrative operations, disable or

restrict any local admin accounts for only emergency use.

Reference: SSH access to Azure Arc-enabled servers

PA-7: Follow just enough administration (least privilege)

principle

Features

Azure RBAC for Data Plane

Description: Azure Role-Based Access Control (Azure RBAC) can be used to managed
access to service's data plane actions. Learn more.

Supported Enabled By Default Configuration Responsibility

True True Microsoft

Configuration Guidance: No additional configurations are required as this is enabled on

a default deployment.

Reference: Identity and access control for Azure Arc-enabled servers

Data protection
For more information, see the Microsoft cloud security benchmark: Data protection.

DP-1: Discover, classify, and label sensitive data

Features
Sensitive Data Discovery and Classification

Description: Tools (such as Azure Purview or Azure Information Protection) can be used
for data discovery and classification in the service. Learn more.

Supported Enabled By Default Configuration Responsibility

False Not Applicable Not Applicable

Configuration Guidance: This feature is not supported to secure this service.

DP-3: Encrypt sensitive data in transit

Features

Data in Transit Encryption

Description: Service supports data in-transit encryption for data plane. Learn more.

Supported Enabled By Default Configuration Responsibility

True True Microsoft

Configuration Guidance: No additional configurations are required as this is enabled on

a default deployment.

Reference: Network topology and connectivity for Azure Arc-enabled servers

Microsoft Defender for Cloud monitoring

Azure Policy built-in definitions - Microsoft.HybridCompute:

Name Description Effect(s) Version

(Azure portal) (GitHub)

Windows web servers To protect the privacy of information AuditIfNotExists, 4.1.0

should be configured communicated over the Internet, your web Disabled
to use secure servers should use the latest version of the
communication industry-standard cryptographic protocol,
protocols Transport Layer Security (TLS). TLS secures
communications over a network by using
security certificates to encrypt a
connection between machines.
DP-4: Enable data at rest encryption by default

Features

Data at Rest Encryption Using Platform Keys

Description: Data at-rest encryption using platform keys is supported, any customer
content at rest is encrypted with these Microsoft managed keys. Learn more.

Supported Enabled By Default Configuration Responsibility

True True Microsoft

Configuration Guidance: No additional configurations are required as this is enabled on

a default deployment.

Asset management
For more information, see the Microsoft cloud security benchmark: Asset management.

AM-2: Use only approved services

Features

Azure Policy Support

Description: Service configurations can be monitored and enforced via Azure Policy.
Learn more.

Supported Enabled By Default Configuration Responsibility

True False Customer

Configuration Guidance: Use Microsoft Defender for Cloud to configure Azure Policy to
audit and enforce configurations of your Azure resources. Use Azure Monitor to create
alerts when there is a configuration deviation detected on the resources. Use Azure
Policy [deny] and [deploy if not exists] effects to enforce secure configuration across
Azure resources.

Reference: Azure Policy built-in definitions for Azure Arc-enabled servers

Logging and threat detection
For more information, see the Microsoft cloud security benchmark: Logging and threat
detection.

LT-1: Enable threat detection capabilities

Features

Microsoft Defender for Service / Product Offering

Description: Service has an offering-specific Microsoft Defender solution to monitor and

alert on security issues. Learn more.

Supported Enabled By Default Configuration Responsibility

True False Customer

Configuration Guidance: Use Azure Active Directory (Azure AD) as the default
authentication method to control your management plane access. When you get an
alert from Microsoft Defender for Key Vault, investigate and respond to the alert.

Reference: Introduction to Microsoft Defender for Servers

Microsoft Defender for Cloud monitoring

Azure Policy built-in definitions - Microsoft.HybridCompute:

Name Description Effect(s) Version

(Azure portal) (GitHub)

Windows Windows Defender Exploit Guard uses the AuditIfNotExists, 2.0.0

Defender Exploit Azure Policy Guest Configuration agent. Exploit Disabled
Guard should be Guard has four components that are designed
enabled on your to lock down devices against a wide variety of
machines attack vectors and block behaviors commonly
used in malware attacks while enabling
enterprises to balance their security risk and
productivity requirements (Windows only).

LT-4: Enable logging for security investigation

Features

Azure Resource Logs

Description: Service produces resource logs that can provide enhanced service-specific
metrics and logging. The customer can configure these resource logs and send them to
their own data sink like a storage account or log analytics workspace. Learn more.

Supported Enabled By Default Configuration Responsibility

False Not Applicable Not Applicable

Configuration Guidance: This feature is not supported to secure this service.

Backup and recovery

For more information, see the Microsoft cloud security benchmark: Backup and recovery.

BR-1: Ensure regular automated backups

Features

Azure Backup

Description: The service can be backed up by the Azure Backup service. Learn more.

Supported Enabled By Default Configuration Responsibility

False Not Applicable Not Applicable

Configuration Guidance: This feature is not supported to secure this service.

Service Native Backup Capability

Description: Service supports its own native backup capability (if not using Azure
Backup). Learn more.

Supported Enabled By Default Configuration Responsibility

False Not Applicable Not Applicable

Configuration Guidance: This feature is not supported to secure this service.

Next steps
See the Microsoft cloud security benchmark overview
Learn more about Azure security baselines
Azure Policy Regulatory Compliance
controls for Azure Arc-enabled servers
Article • 02/06/2024

Regulatory Compliance in Azure Policy provides Microsoft created and managed initiative
definitions, known as built-ins, for the compliance domains and security controls related to
different compliance standards. This page lists the compliance domains and security controls
for Azure Arc-enabled servers. You can assign the built-ins for a security control individually to
help make your Azure resources compliant with the specific standard.

The title of each built-in policy definition links to the policy definition in the Azure portal. Use
the link in the Policy Version column to view the source on the Azure Policy GitHub repo .

） Important

Each control is associated with one or more Azure Policy definitions. These policies might
help you assess compliance with the control. However, there often isn't a one-to-one or
complete match between a control and one or more policies. As such, Compliant in Azure
Policy refers only to the policies themselves. This doesn't ensure that you're fully
compliant with all requirements of a control. In addition, the compliance standard includes
controls that aren't addressed by any Azure Policy definitions at this time. Therefore,
compliance in Azure Policy is only a partial view of your overall compliance status. The
associations between controls and Azure Policy Regulatory Compliance definitions for
these compliance standards can change over time.

Australian Government ISM PROTECTED

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - Australian Government ISM PROTECTED.
For more information about this compliance standard, see Australian Government ISM
PROTECTED .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Guidelines for Personnel 415 User identification - 415 Audit Windows machines 2.0.0
Security - Access to that have the specified
systems and their members in the
resources Administrators group
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Guidelines for System 421 Single-factor Windows machines should 3.0.0

Hardening - authentication - 421 meet requirements for
Authentication 'Security Settings - Account
hardening Policies'

Guidelines for Personnel 445 Privileged access to Audit Windows machines 2.0.0
Security - Access to systems - 445 that have the specified
systems and their members in the
resources Administrators group

Guidelines for 1139 Using Transport Layer Windows machines should 4.1.1
Cryptography - Security - 1139 be configured to use secure
Transport Layer Security communication protocols

Guidelines for Database 1277 Communications Windows machines should 4.1.1

Systems - Database between database be configured to use secure
servers servers and web servers - communication protocols
1277

Guidelines for Personnel 1503 Standard access to Audit Windows machines 2.0.0
Security - Access to systems - 1503 that have the specified
systems and their members in the
resources Administrators group

Guidelines for Personnel 1507 Privileged access to Audit Windows machines 2.0.0
Security - Access to systems - 1507 that have the specified
systems and their members in the
resources Administrators group

Guidelines for Personnel 1508 Privileged access to Audit Windows machines 2.0.0
Security - Access to systems - 1508 that have the specified
systems and their members in the
resources Administrators group

Guidelines for System 1546 Authenticating to Audit Linux machines that 3.1.0
Hardening - systems - 1546 allow remote connections
Authentication from accounts without
hardening passwords

Guidelines for System 1546 Authenticating to Audit Linux machines that 3.1.0
Hardening - systems - 1546 have accounts without
Authentication passwords
hardening

Canada Federal PBMM

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - Canada Federal PBMM. For more
information about this compliance standard, see Canada Federal PBMM .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Access Control AC-5 Separation of Duties Audit Windows machines 2.0.0

missing any of specified
members in the Administrators
group

Access Control AC-5 Separation of Duties Audit Windows machines that 2.0.0
have the specified members in
the Administrators group

Access Control AC-6 Least Privilege Audit Windows machines 2.0.0

missing any of specified
members in the Administrators
group

Access Control AC-6 Least Privilege Audit Windows machines that 2.0.0
have the specified members in
the Administrators group

Access Control AC- Remote Access | Audit Linux machines that 3.1.0
17(1) Automated Monitoring / allow remote connections
Control from accounts without
passwords

Identification and IA-5 Authenticator Audit Linux machines that do 3.1.0

Authentication Management not have the passwd file
permissions set to 0644

Identification and IA-5 Authenticator Audit Linux machines that 3.1.0

Authentication Management have accounts without
passwords

Identification and IA-5(1) Authenticator Audit Windows machines that 2.1.0

Authentication Management | Password- allow re-use of the passwords
Based Authentication after the specified number of
unique passwords

Identification and IA-5(1) Authenticator Audit Windows machines that 2.1.0

Authentication Management | Password- do not have the maximum
Based Authentication password age set to specified
number of days

Identification and IA-5(1) Authenticator Audit Windows machines that 2.1.0

Authentication Management | Password- do not have the minimum
Based Authentication password age set to specified
number of days
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Identification and IA-5(1) Authenticator Audit Windows machines that 2.0.0

Authentication Management | Password- do not have the password
Based Authentication complexity setting enabled

Identification and IA-5(1) Authenticator Audit Windows machines that 2.1.0

Authentication Management | Password- do not restrict the minimum
Based Authentication password length to specified
number of characters

System and SC-8(1) Transmission Windows machines should be 4.1.1

Communications Confidentiality and configured to use secure
Protection Integrity | Cryptographic communication protocols
or Alternate Physical
Protection

CIS Microsoft Azure Foundations Benchmark 2.0.0

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance details for CIS v2.0.0. For more information
about this compliance standard, see CIS Microsoft Azure Foundations Benchmark .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

2.1 2.1.13 Ensure that Microsoft Defender Machines should be 3.5.0

Recommendation for 'Apply system configured to periodically
updates' status is 'Completed' check for missing system
updates

7 7.6 Ensure that Endpoint Protection for all Endpoint protection should 1.0.0
Virtual Machines is installed be installed on your machines

CMMC Level 3
To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - CMMC Level 3. For more information
about this compliance standard, see Cybersecurity Maturity Model Certification (CMMC) .

ﾉ Expand table
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Access Control AC.1.001 Limit information system access to Audit Linux machines 3.1.0
authorized users, processes acting that allow remote
on behalf of authorized users, and connections from
devices (including other accounts without
information systems). passwords

Access Control AC.1.001 Limit information system access to Windows machines 3.0.0
authorized users, processes acting should meet
on behalf of authorized users, and requirements for
devices (including other 'Security Options -
information systems). Network Access'

Access Control AC.1.001 Limit information system access to Windows machines 3.0.0
authorized users, processes acting should meet
on behalf of authorized users, and requirements for
devices (including other 'Security Options -
information systems). Network Security'

Access Control AC.1.002 Limit information system access to Audit Linux machines 3.1.0
the types of transactions and that allow remote
functions that authorized users are connections from
permitted to execute. accounts without
passwords

Access Control AC.1.002 Limit information system access to Windows machines 4.1.1
the types of transactions and should be configured
functions that authorized users are to use secure
permitted to execute. communication
protocols

Access Control AC.1.002 Limit information system access to Windows machines 3.0.0
the types of transactions and should meet
functions that authorized users are requirements for
permitted to execute. 'Security Options -
Network Access'

Access Control AC.2.008 Use non-privileged accounts or Windows machines 3.0.0

roles when accessing nonsecurity should meet
functions. requirements for
'Security Options - User
Account Control'

Access Control AC.2.008 Use non-privileged accounts or Windows machines 3.0.0

roles when accessing nonsecurity should meet
functions. requirements for 'User
Rights Assignment'

Access Control AC.2.013 Monitor and control remote Audit Linux machines 3.1.0
access sessions. that allow remote
connections from
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

accounts without
passwords

Access Control AC.2.013 Monitor and control remote Windows machines 3.0.0
access sessions. should meet
requirements for
'Security Options -
Network Security'

Access Control AC.2.016 Control the flow of CUI in Windows machines 3.0.0
accordance with approved should meet
authorizations. requirements for
'Security Options -
Network Access'

Access Control AC.3.017 Separate the duties of individuals Audit Windows 2.0.0
to reduce the risk of malevolent machines missing any
activity without collusion. of specified members in
the Administrators
group

Access Control AC.3.017 Separate the duties of individuals Audit Windows 2.0.0
to reduce the risk of malevolent machines that have the
activity without collusion. specified members in
the Administrators
group

Access Control AC.3.018 Prevent non-privileged users from Windows machines 3.0.0
executing privileged functions and should meet
capture the execution of such requirements for
functions in audit logs. 'System Audit Policies -
Privilege Use'

Access Control AC.3.021 Authorize remote execution of Windows machines 3.0.0

privileged commands and remote should meet
access to security-relevant requirements for
information. 'Security Options - User
Account Control'

Access Control AC.3.021 Authorize remote execution of Windows machines 3.0.0

privileged commands and remote should meet
access to security-relevant requirements for 'User
information. Rights Assignment'

Configuration CM.2.061 Establish and maintain baseline Linux machines should 2.2.0
Management configurations and inventories of meet requirements for
organizational systems (including the Azure compute
hardware, software, firmware, and security baseline
documentation) throughout the
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

respective system development

life cycles.

Configuration CM.2.062 Employ the principle of least Windows machines 3.0.0

Management functionality by configuring should meet
organizational systems to provide requirements for
only essential capabilities. 'System Audit Policies -
Privilege Use'

Configuration CM.2.063 Control and monitor user-installed Windows machines 3.0.0

Management software. should meet
requirements for
'Security Options - User
Account Control'

Configuration CM.2.064 Establish and enforce security Windows machines 3.0.0

Management configuration settings for should meet
information technology products requirements for
employed in organizational 'Security Options -
systems. Network Security'

Configuration CM.2.065 Track, review, approve or Windows machines 3.0.0

Management disapprove, and log changes to should meet
organizational systems. requirements for
'System Audit Policies -
Policy Change'

Identification and IA.1.077 Authenticate (or verify) the Audit Linux machines 3.1.0
Authentication identities of those users, that do not have the
processes, or devices, as a passwd file permissions
prerequisite to allowing access to set to 0644
organizational information
systems.

Identification and IA.1.077 Authenticate (or verify) the Audit Linux machines 3.1.0
Authentication identities of those users, that have accounts
processes, or devices, as a without passwords
prerequisite to allowing access to
organizational information
systems.

Identification and IA.1.077 Authenticate (or verify) the Windows machines 3.0.0
Authentication identities of those users, should meet
processes, or devices, as a requirements for
prerequisite to allowing access to 'Security Options -
organizational information Network Security'
systems.

Identification and IA.2.078 Enforce a minimum password Audit Linux machines 3.1.0
Authentication complexity and change of that have accounts
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

characters when new passwords without passwords

are created.

Identification and IA.2.078 Enforce a minimum password Audit Windows 2.0.0

Authentication complexity and change of machines that do not
characters when new passwords have the password
are created. complexity setting
enabled

Identification and IA.2.078 Enforce a minimum password Audit Windows 2.1.0

Authentication complexity and change of machines that do not
characters when new passwords restrict the minimum
are created. password length to
specified number of
characters

Identification and IA.2.078 Enforce a minimum password Windows machines 3.0.0

Authentication complexity and change of should meet
characters when new passwords requirements for
are created. 'Security Options -
Network Security'

Identification and IA.2.079 Prohibit password reuse for a Audit Windows 2.1.0
Authentication specified number of generations. machines that allow re-
use of the passwords
after the specified
number of unique
passwords

Identification and IA.2.079 Prohibit password reuse for a Windows machines 3.0.0
Authentication specified number of generations. should meet
requirements for
'Security Options -
Network Security'

Identification and IA.2.081 Store and transmit only Audit Windows 2.0.0
Authentication cryptographically-protected machines that do not
passwords. store passwords using
reversible encryption

Identification and IA.2.081 Store and transmit only Windows machines 3.0.0
Authentication cryptographically-protected should meet
passwords. requirements for
'Security Options -
Network Security'

Identification and IA.3.084 Employ replay-resistant Windows machines 4.1.1

Authentication authentication mechanisms for should be configured
network access to privileged and to use secure
nonprivileged accounts.
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

communication
protocols

System and SC.1.175 Monitor, control, and protect Windows machines 4.1.1
Communications communications (i.e., information should be configured
Protection transmitted or received by to use secure
organizational systems) at the communication
external boundaries and key protocols
internal boundaries of
organizational systems.

System and SC.1.175 Monitor, control, and protect Windows machines 3.0.0
Communications communications (i.e., information should meet
Protection transmitted or received by requirements for
organizational systems) at the 'Security Options -
external boundaries and key Network Access'
internal boundaries of
organizational systems.

System and SC.1.175 Monitor, control, and protect Windows machines 3.0.0
Communications communications (i.e., information should meet
Protection transmitted or received by requirements for
organizational systems) at the 'Security Options -
external boundaries and key Network Security'
internal boundaries of
organizational systems.

System and SC.3.177 Employ FIPS-validated Audit Windows 2.0.0

Communications cryptography when used to machines that do not
Protection protect the confidentiality of CUI. store passwords using
reversible encryption

System and SC.3.181 Separate user functionality from Audit Windows 2.0.0
Communications system management functionality. machines that have the
Protection specified members in
the Administrators
group

System and SC.3.183 Deny network communications Windows machines 3.0.0

Communications traffic by default and allow should meet
Protection network communications traffic by requirements for
exception (i.e., deny all, permit by 'Security Options -
exception). Network Access'

System and SC.3.183 Deny network communications Windows machines 3.0.0

Communications traffic by default and allow should meet
Protection network communications traffic by requirements for
exception (i.e., deny all, permit by 'Security Options -
exception). Network Security'
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

System and SC.3.185 Implement cryptographic Windows machines 4.1.1

Communications mechanisms to prevent should be configured
Protection unauthorized disclosure of CUI to use secure
during transmission unless communication
otherwise protected by alternative protocols
physical safeguards.

System and SC.3.190 Protect the authenticity of Windows machines 4.1.1

Communications communications sessions. should be configured
Protection to use secure
communication
protocols

FedRAMP High
To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - FedRAMP High. For more information
about this compliance standard, see FedRAMP High .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Access Control AC-3 Access Enforcement Audit Linux machines that have 3.1.0
accounts without passwords

Access Control AC-3 Access Enforcement Authentication to Linux machines 3.2.0

should require SSH keys

Access Control AC-17 Remote Access Audit Linux machines that allow 3.1.0
remote connections from
accounts without passwords

Access Control AC-17 Automated Audit Linux machines that allow 3.1.0
(1) Monitoring / Control remote connections from
accounts without passwords

Audit And AU-6 (4) Central Review And [Preview]: Log Analytics 1.0.1-
Accountability Analysis extension should be installed on preview
your Linux Azure Arc machines

Audit And AU-6 (4) Central Review And [Preview]: Log Analytics 1.0.1-
Accountability Analysis extension should be installed on preview
your Windows Azure Arc
machines
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Audit And AU-6 (5) Integration / [Preview]: Log Analytics 1.0.1-

Accountability Scanning And extension should be installed on preview
Monitoring your Linux Azure Arc machines
Capabilities

Audit And AU-6 (5) Integration / [Preview]: Log Analytics 1.0.1-

Accountability Scanning And extension should be installed on preview
Monitoring your Windows Azure Arc
Capabilities machines

Audit And AU-12 Audit Generation [Preview]: Log Analytics 1.0.1-

Accountability extension should be installed on preview
your Linux Azure Arc machines

Audit And AU-12 Audit Generation [Preview]: Log Analytics 1.0.1-

Accountability extension should be installed on preview
your Windows Azure Arc
machines

Audit And AU-12 System-Wide / Time- [Preview]: Log Analytics 1.0.1-

Accountability (1) Correlated Audit Trail extension should be installed on preview
your Linux Azure Arc machines

Audit And AU-12 System-Wide / Time- [Preview]: Log Analytics 1.0.1-

Accountability (1) Correlated Audit Trail extension should be installed on preview
your Windows Azure Arc
machines

Configuration CM-6 Configuration Linux machines should meet 2.2.0

Management Settings requirements for the Azure
compute security baseline

Configuration CM-6 Configuration Windows machines should meet 2.0.0

Management Settings requirements of the Azure
compute security baseline

Identification And IA-5 Authenticator Audit Linux machines that do not 3.1.0
Authentication Management have the passwd file permissions
set to 0644

Identification And IA-5 Authenticator Audit Windows machines that do 2.0.0

Authentication Management not store passwords using
reversible encryption

Identification And IA-5 Authenticator Authentication to Linux machines 3.2.0

Authentication Management should require SSH keys

Identification And IA-5 (1) Password-Based Audit Linux machines that do not 3.1.0
Authentication Authentication have the passwd file permissions
set to 0644
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Identification And IA-5 (1) Password-Based Audit Windows machines that 2.1.0
Authentication Authentication allow re-use of the passwords
after the specified number of
unique passwords

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.1.0
Authentication Authentication not have the maximum password
age set to specified number of
days

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.1.0
Authentication Authentication not have the minimum password
age set to specified number of
days

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.0.0
Authentication Authentication not have the password
complexity setting enabled

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.1.0
Authentication Authentication not restrict the minimum
password length to specified
number of characters

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.0.0
Authentication Authentication not store passwords using
reversible encryption

Risk Assessment RA-5 Vulnerability SQL servers on machines should 1.0.0

Scanning have vulnerability findings
resolved

System And SC-3 Security Function Windows Defender Exploit Guard 2.0.0
Communications Isolation should be enabled on your
Protection machines

System And SC-8 Transmission Windows machines should be 4.1.1

Communications Confidentiality And configured to use secure
Protection Integrity communication protocols

System And SC-8 (1) Cryptographic Or Windows machines should be 4.1.1

Communications Alternate Physical configured to use secure
Protection Protection communication protocols

System And SI-3 Malicious Code Windows Defender Exploit Guard 2.0.0
Information Integrity Protection should be enabled on your
machines

System And SI-3 (1) Central Management Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

machines

System And SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Linux Azure Arc machines

System And SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Windows Azure Arc
machines

System And SI-16 Memory Protection Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

FedRAMP Moderate
To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - FedRAMP Moderate. For more information
about this compliance standard, see FedRAMP Moderate .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Access Control AC-3 Access Enforcement Audit Linux machines that have 3.1.0
accounts without passwords

Access Control AC-3 Access Enforcement Authentication to Linux machines 3.2.0

should require SSH keys

Access Control AC-17 Remote Access Audit Linux machines that allow 3.1.0
remote connections from
accounts without passwords

Access Control AC-17 Automated Audit Linux machines that allow 3.1.0
(1) Monitoring / remote connections from
Control accounts without passwords

Audit And AU-12 Audit Generation [Preview]: Log Analytics extension 1.0.1-
Accountability should be installed on your Linux preview
Azure Arc machines

Audit And AU-12 Audit Generation [Preview]: Log Analytics extension 1.0.1-
Accountability should be installed on your preview
Windows Azure Arc machines
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Configuration CM-6 Configuration Linux machines should meet 2.2.0

Management Settings requirements for the Azure
compute security baseline

Configuration CM-6 Configuration Windows machines should meet 2.0.0

Management Settings requirements of the Azure
compute security baseline

Identification And IA-5 Authenticator Audit Linux machines that do not 3.1.0
Authentication Management have the passwd file permissions
set to 0644

Identification And IA-5 Authenticator Audit Windows machines that do 2.0.0

Authentication Management not store passwords using
reversible encryption

Identification And IA-5 Authenticator Authentication to Linux machines 3.2.0

Authentication Management should require SSH keys

Identification And IA-5 (1) Password-Based Audit Linux machines that do not 3.1.0
Authentication Authentication have the passwd file permissions
set to 0644

Identification And IA-5 (1) Password-Based Audit Windows machines that 2.1.0
Authentication Authentication allow re-use of the passwords
after the specified number of
unique passwords

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.1.0
Authentication Authentication not have the maximum password
age set to specified number of
days

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.1.0
Authentication Authentication not have the minimum password
age set to specified number of
days

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.0.0
Authentication Authentication not have the password
complexity setting enabled

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.1.0
Authentication Authentication not restrict the minimum
password length to specified
number of characters

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.0.0
Authentication Authentication not store passwords using
reversible encryption
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Risk Assessment RA-5 Vulnerability SQL servers on machines should 1.0.0

Scanning have vulnerability findings
resolved

System And SC-8 Transmission Windows machines should be 4.1.1

Communications Confidentiality And configured to use secure
Protection Integrity communication protocols

System And SC-8 (1) Cryptographic Or Windows machines should be 4.1.1

Communications Alternate Physical configured to use secure
Protection Protection communication protocols

System And SI-3 Malicious Code Windows Defender Exploit Guard 2.0.0
Information Integrity Protection should be enabled on your
machines

System And SI-3 (1) Central Windows Defender Exploit Guard 2.0.0
Information Integrity Management should be enabled on your
machines

System And SI-4 Information System [Preview]: Log Analytics extension 1.0.1-
Information Integrity Monitoring should be installed on your Linux preview
Azure Arc machines

System And SI-4 Information System [Preview]: Log Analytics extension 1.0.1-
Information Integrity Monitoring should be installed on your preview
Windows Azure Arc machines

System And SI-16 Memory Protection Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

HIPAA HITRUST 9.2

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - HIPAA HITRUST 9.2. For more information
about this compliance standard, see HIPAA HITRUST 9.2 .

ﾉ Expand table

Domain Control ID Control title Policy Policy

(Azure portal) version
(GitHub)

User 11210.01q2Organizational.10 - Electronic signatures and Audit Windows 2.0.0

Identification 01.q handwritten signatures machines that
executed to electronic records have the
Domain Control ID Control title Policy Policy
(Azure portal) version
(GitHub)

and shall be linked to their specified

Authentication respective electronic records. members in the
Administrators
group

User 11211.01q2Organizational.11 - Signed electronic records shall Audit Windows 2.0.0

Identification 01.q contain information associated machines
and with the signing in human- missing any of
Authentication readable format. specified
members in the
Administrators
group

06 0605.10h1System.12-10.h 0605.10h1System.12-10.h 10.04 Windows 3.0.0

Configuration Security of System Files machines
Management should meet
requirements
for 'Security
Options - Audit'

06 0605.10h1System.12-10.h 0605.10h1System.12-10.h 10.04 Windows 3.0.0

Configuration Security of System Files machines
Management should meet
requirements
for 'System
Audit Policies -
Account
Management'

06 0635.10k1Organizational.12- 0635.10k1Organizational.12- Windows 3.0.0

Configuration 10.k 10.k 10.05 Security In machines
Management Development and Support should meet
Processes requirements
for 'System
Audit Policies -
Detailed
Tracking'

06 0636.10k2Organizational.1-10.k 0636.10k2Organizational.1-10.k Windows 3.0.0

Configuration 10.05 Security In Development machines
Management and Support Processes should meet
requirements
for 'System
Audit Policies -
Detailed
Tracking'

06 0637.10k2Organizational.2-10.k 0637.10k2Organizational.2-10.k Windows 3.0.0

Configuration 10.05 Security In Development machines
Management and Support Processes should meet
Domain Control ID Control title Policy Policy
(Azure portal) version
(GitHub)

requirements
for 'System
Audit Policies -
Detailed
Tracking'

06 0638.10k2Organizational.34569- 0638.10k2Organizational.34569- Windows 3.0.0

Configuration 10.k 10.k 10.05 Security In machines
Management Development and Support should meet
Processes requirements
for 'System
Audit Policies -
Detailed
Tracking'

06 0639.10k2Organizational.78- 0639.10k2Organizational.78- Windows 3.0.0

Configuration 10.k 10.k 10.05 Security In machines
Management Development and Support should meet
Processes requirements
for 'System
Audit Policies -
Detailed
Tracking'

06 0640.10k2Organizational.1012- 0640.10k2Organizational.1012- Windows 3.0.0

Configuration 10.k 10.k 10.05 Security In machines
Management Development and Support should meet
Processes requirements
for 'System
Audit Policies -
Detailed
Tracking'

06 0641.10k2Organizational.11- 0641.10k2Organizational.11- Windows 3.0.0

Configuration 10.k 10.k 10.05 Security In machines
Management Development and Support should meet
Processes requirements
for 'System
Audit Policies -
Detailed
Tracking'

06 0642.10k3Organizational.12- 0642.10k3Organizational.12- Windows 3.0.0

Configuration 10.k 10.k 10.05 Security In machines
Management Development and Support should meet
Processes requirements
for 'System
Audit Policies -
Detailed
Tracking'
Domain Control ID Control title Policy Policy
(Azure portal) version
(GitHub)

06 0643.10k3Organizational.3-10.k 0643.10k3Organizational.3-10.k Windows 3.0.0

Configuration 10.05 Security In Development machines
Management and Support Processes should meet
requirements
for 'System
Audit Policies -
Detailed
Tracking'

06 0644.10k3Organizational.4-10.k 0644.10k3Organizational.4-10.k Windows 3.0.0

Configuration 10.05 Security In Development machines
Management and Support Processes should meet
requirements
for 'System
Audit Policies -
Detailed
Tracking'

07 0709.10m1Organizational.1- 0709.10m1Organizational.1- Windows 3.0.0

Vulnerability 10.m 10.m 10.06 Technical machines
Management Vulnerability Management should meet
requirements
for 'Security
Options -
Microsoft
Network Server'

08 Network 0858.09m1Organizational.4- 0858.09m1Organizational.4- Windows 3.0.0

Protection 09.m 09.m 09.06 Network Security machines
Management should meet
requirements
for 'Windows
Firewall
Properties'

08 Network 0861.09m2Organizational.67- 0861.09m2Organizational.67- Windows 3.0.0

Protection 09.m 09.m 09.06 Network Security machines
Management should meet
requirements
for 'Security
Options -
Network
Access'

09 0945.09y1Organizational.3-09.y 0945.09y1Organizational.3-09.y Audit Windows 3.0.0

Transmission 09.09 Electronic Commerce machines that
Protection Services do not contain
the specified
Domain Control ID Control title Policy Policy
(Azure portal) version
(GitHub)

certificates in
Trusted Root

11 Access 1123.01q1System.2-01.q 1123.01q1System.2-01.q 01.05 Audit Windows 2.0.0

Control Operating System Access machines that
Control have extra
accounts in the
Administrators
group

11 Access 1125.01q2System.1-01.q 1125.01q2System.1-01.q 01.05 Audit Windows 2.0.0

Control Operating System Access machines that
Control have the
specified
members in the
Administrators
group

11 Access 1127.01q2System.3-01.q 1127.01q2System.3-01.q 01.05 Audit Windows 2.0.0

Control Operating System Access machines
Control missing any of
specified
members in the
Administrators
group

11 Access 1148.01c2System.78-01.c 1148.01c2System.78-01.c 01.02 Windows 3.0.0

Control Authorized Access to machines
Information Systems should meet
requirements
for 'Security
Options -
Accounts'

12 Audit 12102.09ab1Organizational.4- 12102.09ab1Organizational.4- Audit Windows 2.0.0

Logging & 09.ab 09.ab 09.10 Monitoring machines on
Monitoring which the Log
Analytics agent
is not
connected as
expected

12 Audit 1217.09ab3System.3-09.ab 1217.09ab3System.3-09.ab Audit Windows 2.0.0

Logging & 09.10 Monitoring machines on
Monitoring which the Log
Analytics agent
is not
connected as
expected
 Domain Control ID Control title Policy Policy
(Azure portal) version
(GitHub)

12 Audit 1232.09c3Organizational.12- 1232.09c3Organizational.12- Windows 3.0.0

Logging & 09.c 09.c 09.01 Documented machines
Monitoring Operating Procedures should meet
requirements
for 'User Rights
Assignment'

12 Audit 1277.09c2Organizational.4-09.c 1277.09c2Organizational.4-09.c Windows 3.0.0

Logging & 09.01 Documented Operating machines
Monitoring Procedures should meet
requirements
for 'Security
Options - User
Account
Control'

16 Business 1637.12b2Organizational.2-12.b 1637.12b2Organizational.2-12.b Windows 3.0.0

Continuity & 12.01 Information Security machines
Disaster Aspects of Business Continuity should meet
Recovery Management requirements
for 'Security
Options -
Recovery
console'

IRS 1075 September 2016

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - IRS 1075 September 2016. For more
information about this compliance standard, see IRS 1075 September 2016 .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Access Control 9.3.1.12 Remote Access (AC- Audit Linux machines that allow 3.1.0
17) remote connections from accounts
without passwords

Access Control 9.3.1.5 Separation of Duties Audit Windows machines missing 2.0.0
(AC-5) any of specified members in the
Administrators group

Access Control 9.3.1.5 Separation of Duties Audit Windows machines that 2.0.0
(AC-5) have the specified members in the
 Administrators group
Domain Control Control title Policy Policy
ID (Azure version
Access Control 9.3.1.6 Least Privilege (AC-6) Audit portal)
Windows machines missing 2.0.0
any of specified members in the (GitHub)

Administrators group

Access Control 9.3.1.6 Least Privilege (AC-6) Audit Windows machines that 2.0.0
have the specified members in the
Administrators group

System and 9.3.16.6 Transmission Windows machines should be 4.1.1

Communications Confidentiality and configured to use secure
Protection Integrity (SC-8) communication protocols

Identification and 9.3.7.5 Authenticator Audit Linux machines that do not 3.1.0
Authentication Management (IA-5) have the passwd file permissions
set to 0644

Identification and 9.3.7.5 Authenticator Audit Linux machines that have 3.1.0
Authentication Management (IA-5) accounts without passwords

Identification and 9.3.7.5 Authenticator Audit Windows machines that 2.1.0

Authentication Management (IA-5) allow re-use of the passwords after
the specified number of unique
passwords

Identification and 9.3.7.5 Authenticator Audit Windows machines that do 2.1.0

Authentication Management (IA-5) not have the maximum password
age set to specified number of
days

Identification and 9.3.7.5 Authenticator Audit Windows machines that do 2.1.0

Authentication Management (IA-5) not have the minimum password
age set to specified number of
days

Identification and 9.3.7.5 Authenticator Audit Windows machines that do 2.0.0

Authentication Management (IA-5) not have the password complexity
setting enabled

Identification and 9.3.7.5 Authenticator Audit Windows machines that do 2.1.0

Authentication Management (IA-5) not restrict the minimum password
length to specified number of
characters

Identification and 9.3.7.5 Authenticator Audit Windows machines that do 2.0.0

Authentication Management (IA-5) not store passwords using
reversible encryption

ISO 27001:2013
To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - ISO 27001:2013. For more information
about this compliance standard, see ISO 27001:2013 .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Cryptography 10.1.1 Policy on the use of Audit Windows machines that do not 2.0.0
cryptographic controls store passwords using reversible
encryption

Access 9.1.2 Access to networks and Audit Linux machines that allow 3.1.0
Control network services remote connections from accounts
without passwords

Access 9.1.2 Access to networks and Audit Linux machines that have 3.1.0
Control network services accounts without passwords

Access 9.2.4 Management of secret Audit Linux machines that do not 3.1.0
Control authentication have the passwd file permissions set
information of users to 0644

Access 9.4.3 Password management Audit Windows machines that allow 2.1.0
Control system re-use of the passwords after the
specified number of unique
passwords

Access 9.4.3 Password management Audit Windows machines that do not 2.1.0
Control system have the maximum password age set
to specified number of days

Access 9.4.3 Password management Audit Windows machines that do not 2.1.0
Control system have the minimum password age set
to specified number of days

Access 9.4.3 Password management Audit Windows machines that do not 2.0.0
Control system have the password complexity setting
enabled

Access 9.4.3 Password management Audit Windows machines that do not 2.1.0
Control system restrict the minimum password
length to specified number of
characters

Microsoft cloud security benchmark

The Microsoft cloud security benchmark provides recommendations on how you can secure
your cloud solutions on Azure. To see how this service completely maps to the Microsoft cloud
security benchmark, see the Azure Security Benchmark mapping files .
To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - Microsoft cloud security benchmark.

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Identity IM-6 Use strong Authentication to Linux 3.2.0

Management authentication controls machines should require SSH
keys

Data Protection DP-3 Encrypt sensitive data in Windows machines should be 4.1.1
transit configured to use secure
communication protocols

Logging and LT-1 Enable threat detection Windows Defender Exploit 2.0.0
Threat Detection capabilities Guard should be enabled on
your machines

Logging and LT-2 Enable threat detection Windows Defender Exploit 2.0.0
Threat Detection for identity and access Guard should be enabled on
management your machines

Logging and LT-5 Centralize security log [Preview]: Log Analytics 1.0.1-
Threat Detection management and extension should be installed on preview
analysis your Linux Azure Arc machines

Logging and LT-5 Centralize security log [Preview]: Log Analytics 1.0.1-
Threat Detection management and extension should be installed on preview
analysis your Windows Azure Arc
machines

Logging and LT-5 Centralize security log Linux machines should have 1.1.0
Threat Detection management and Log Analytics agent installed on
analysis Azure Arc

Logging and LT-5 Centralize security log Windows machines should have 2.0.0
Threat Detection management and Log Analytics agent installed on
analysis Azure Arc

Posture and PV-4 Audit and enforce Linux machines should meet 2.2.0
Vulnerability secure configurations requirements for the Azure
Management for compute resources compute security baseline

Posture and PV-4 Audit and enforce Windows machines should 2.0.0
Vulnerability secure configurations meet requirements of the Azure
Management for compute resources compute security baseline

Posture and PV-6 Rapidly and [Preview]: System updates 1.0.0-

Vulnerability automatically remediate should be installed on your preview
Management vulnerabilities machines (powered by Update
Center)
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Posture and PV-6 Rapidly and Machines should be configured 3.5.0

Vulnerability automatically remediate to periodically check for missing
Management vulnerabilities system updates

Posture and PV-6 Rapidly and SQL servers on machines should 1.0.0
Vulnerability automatically remediate have vulnerability findings
Management vulnerabilities resolved

Endpoint Security ES-2 Use modern anti- Endpoint protection health 1.0.0
malware software issues should be resolved on
your machines

Endpoint Security ES-2 Use modern anti- Endpoint protection should be 1.0.0
malware software installed on your machines

Endpoint Security ES-2 Use modern anti- Windows Defender Exploit 2.0.0
malware software Guard should be enabled on
your machines

Endpoint Security ES-3 Ensure anti-malware Endpoint protection health 1.0.0

software and signatures issues should be resolved on
are updated your machines

NIST SP 800-171 R2
To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - NIST SP 800-171 R2. For more information
about this compliance standard, see NIST SP 800-171 R2 .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Access Control 3.1.1 Limit system access to authorized Audit Linux machines 3.1.0
users, processes acting on behalf that allow remote
of authorized users, and devices connections from
(including other systems). accounts without
passwords

Access Control 3.1.1 Limit system access to authorized Audit Linux machines 3.1.0
users, processes acting on behalf that have accounts
of authorized users, and devices without passwords
(including other systems).
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Access Control 3.1.1 Limit system access to authorized Authentication to Linux 3.2.0
users, processes acting on behalf machines should
of authorized users, and devices require SSH keys
(including other systems).

Access Control 3.1.12 Monitor and control remote Audit Linux machines 3.1.0
access sessions. that allow remote
connections from
accounts without
passwords

Access Control 3.1.4 Separate the duties of individuals Audit Windows 2.0.0
to reduce the risk of malevolent machines missing any
activity without collusion. of specified members
in the Administrators
group

Access Control 3.1.4 Separate the duties of individuals Audit Windows 2.0.0
to reduce the risk of malevolent machines that have the
activity without collusion. specified members in
the Administrators
group

Risk Assessment 3.11.2 Scan for vulnerabilities in SQL servers on 1.0.0

organizational systems and machines should have
applications periodically and vulnerability findings
when new vulnerabilities affecting resolved
those systems and applications
are identified.

Risk Assessment 3.11.3 Remediate vulnerabilities in SQL servers on 1.0.0

accordance with risk assessments. machines should have
vulnerability findings
resolved

System and 3.13.8 Implement cryptographic Windows machines 4.1.1

Communications mechanisms to prevent should be configured
Protection unauthorized disclosure of CUI to use secure
during transmission unless communication
otherwise protected by alternative protocols
physical safeguards.

System and 3.14.1 Identify, report, and correct Windows Defender 2.0.0
Information system flaws in a timely manner. Exploit Guard should
Integrity be enabled on your
machines

System and 3.14.2 Provide protection from malicious Windows Defender 2.0.0
Information code at designated locations Exploit Guard should
Integrity within organizational systems.
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

be enabled on your
machines

System and 3.14.4 Update malicious code protection Windows Defender 2.0.0
Information mechanisms when new releases Exploit Guard should
Integrity are available. be enabled on your
machines

System and 3.14.5 Perform periodic scans of Windows Defender 2.0.0

Information organizational systems and real- Exploit Guard should
Integrity time scans of files from external be enabled on your
sources as files are downloaded, machines
opened, or executed.

System and 3.14.6 Monitor organizational systems, [Preview]: Log Analytics 1.0.1-
Information including inbound and outbound extension should be preview
Integrity communications traffic, to detect installed on your Linux
attacks and indicators of potential Azure Arc machines
attacks.

System and 3.14.6 Monitor organizational systems, [Preview]: Log Analytics 1.0.1-
Information including inbound and outbound extension should be preview
Integrity communications traffic, to detect installed on your
attacks and indicators of potential Windows Azure Arc
attacks. machines

System and 3.14.7 Identify unauthorized use of [Preview]: Log Analytics 1.0.1-
Information organizational systems. extension should be preview
Integrity installed on your Linux
Azure Arc machines

System and 3.14.7 Identify unauthorized use of [Preview]: Log Analytics 1.0.1-
Information organizational systems. extension should be preview
Integrity installed on your
Windows Azure Arc
machines

Audit and 3.3.1 Create and retain system audit [Preview]: Log Analytics 1.0.1-
Accountability logs and records to the extent extension should be preview
needed to enable the monitoring, installed on your Linux
analysis, investigation, and Azure Arc machines
reporting of unlawful or
unauthorized system activity

Audit and 3.3.1 Create and retain system audit [Preview]: Log Analytics 1.0.1-
Accountability logs and records to the extent extension should be preview
needed to enable the monitoring, installed on your
analysis, investigation, and Windows Azure Arc
reporting of unlawful or machines
unauthorized system activity
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Audit and 3.3.2 Ensure that the actions of [Preview]: Log Analytics 1.0.1-
Accountability individual system users can be extension should be preview
uniquely traced to those users, so installed on your Linux
they can be held accountable for Azure Arc machines
their actions.

Audit and 3.3.2 Ensure that the actions of [Preview]: Log Analytics 1.0.1-
Accountability individual system users can be extension should be preview
uniquely traced to those users, so installed on your
they can be held accountable for Windows Azure Arc
their actions. machines

Configuration 3.4.1 Establish and maintain baseline Linux machines should 2.2.0
Management configurations and inventories of meet requirements for
organizational systems (including the Azure compute
hardware, software, firmware, and security baseline
documentation) throughout the
respective system development
life cycles.

Configuration 3.4.1 Establish and maintain baseline Windows machines 2.0.0

Management configurations and inventories of should meet
organizational systems (including requirements of the
hardware, software, firmware, and Azure compute security
documentation) throughout the baseline
respective system development
life cycles.

Configuration 3.4.2 Establish and enforce security Linux machines should 2.2.0
Management configuration settings for meet requirements for
information technology products the Azure compute
employed in organizational security baseline
systems.

Configuration 3.4.2 Establish and enforce security Windows machines 2.0.0

Management configuration settings for should meet
information technology products requirements of the
employed in organizational Azure compute security
systems. baseline

Identification and 3.5.10 Store and transmit only Audit Linux machines 3.1.0
Authentication cryptographically-protected that do not have the
passwords. passwd file permissions
set to 0644

Identification and 3.5.10 Store and transmit only Audit Windows 2.0.0
Authentication cryptographically-protected machines that do not
passwords. store passwords using
reversible encryption
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Identification and 3.5.10 Store and transmit only Windows machines 3.0.0
Authentication cryptographically-protected should meet
passwords. requirements for
'Security Options -
Network Security'

Identification and 3.5.2 Authenticate (or verify) the Audit Linux machines 3.1.0
Authentication identities of users, processes, or that do not have the
devices, as a prerequisite to passwd file permissions
allowing access to organizational set to 0644
systems.

Identification and 3.5.2 Authenticate (or verify) the Audit Windows 2.0.0
Authentication identities of users, processes, or machines that do not
devices, as a prerequisite to store passwords using
allowing access to organizational reversible encryption
systems.

Identification and 3.5.2 Authenticate (or verify) the Authentication to Linux 3.2.0
Authentication identities of users, processes, or machines should
devices, as a prerequisite to require SSH keys
allowing access to organizational
systems.

Identification and 3.5.4 Employ replay-resistant Windows machines 3.0.0

Authentication authentication mechanisms for should meet
network access to privileged and requirements for
non-privileged accounts. 'Security Options -
Network Security'

Identification and 3.5.7 Enforce a minimum password Audit Windows 2.0.0

Authentication complexity and change of machines that do not
characters when new passwords have the password
are created. complexity setting
enabled

Identification and 3.5.7 Enforce a minimum password Audit Windows 2.1.0

Authentication complexity and change of machines that do not
characters when new passwords restrict the minimum
are created. password length to
specified number of
characters

Identification and 3.5.8 Prohibit password reuse for a Audit Windows 2.1.0
Authentication specified number of generations. machines that allow re-
use of the passwords
after the specified
number of unique
passwords
NIST SP 800-53 Rev. 4
To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - NIST SP 800-53 Rev. 4. For more
information about this compliance standard, see NIST SP 800-53 Rev. 4 .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Access Control AC-3 Access Enforcement Audit Linux machines that have 3.1.0
accounts without passwords

Access Control AC-3 Access Enforcement Authentication to Linux machines 3.2.0

should require SSH keys

Access Control AC-17 Remote Access Audit Linux machines that allow 3.1.0
remote connections from
accounts without passwords

Access Control AC-17 Automated Audit Linux machines that allow 3.1.0
(1) Monitoring / Control remote connections from
accounts without passwords

Audit And AU-6 (4) Central Review And [Preview]: Log Analytics 1.0.1-
Accountability Analysis extension should be installed on preview
your Linux Azure Arc machines

Audit And AU-6 (4) Central Review And [Preview]: Log Analytics 1.0.1-
Accountability Analysis extension should be installed on preview
your Windows Azure Arc
machines

Audit And AU-6 (5) Integration / [Preview]: Log Analytics 1.0.1-

Accountability Scanning And extension should be installed on preview
Monitoring your Linux Azure Arc machines
Capabilities

Audit And AU-6 (5) Integration / [Preview]: Log Analytics 1.0.1-

Accountability Scanning And extension should be installed on preview
Monitoring your Windows Azure Arc
Capabilities machines

Audit And AU-12 Audit Generation [Preview]: Log Analytics 1.0.1-

Accountability extension should be installed on preview
your Linux Azure Arc machines

Audit And AU-12 Audit Generation [Preview]: Log Analytics 1.0.1-

Accountability extension should be installed on preview
your Windows Azure Arc
machines
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Audit And AU-12 System-Wide / Time- [Preview]: Log Analytics 1.0.1-

Accountability (1) Correlated Audit Trail extension should be installed on preview
your Linux Azure Arc machines

Audit And AU-12 System-Wide / Time- [Preview]: Log Analytics 1.0.1-

Accountability (1) Correlated Audit Trail extension should be installed on preview
your Windows Azure Arc
machines

Configuration CM-6 Configuration Linux machines should meet 2.2.0

Management Settings requirements for the Azure
compute security baseline

Configuration CM-6 Configuration Windows machines should meet 2.0.0

Management Settings requirements of the Azure
compute security baseline

Identification And IA-5 Authenticator Audit Linux machines that do not 3.1.0
Authentication Management have the passwd file permissions
set to 0644

Identification And IA-5 Authenticator Audit Windows machines that do 2.0.0

Authentication Management not store passwords using
reversible encryption

Identification And IA-5 Authenticator Authentication to Linux machines 3.2.0

Authentication Management should require SSH keys

Identification And IA-5 (1) Password-Based Audit Linux machines that do not 3.1.0
Authentication Authentication have the passwd file permissions
set to 0644

Identification And IA-5 (1) Password-Based Audit Windows machines that 2.1.0
Authentication Authentication allow re-use of the passwords
after the specified number of
unique passwords

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.1.0
Authentication Authentication not have the maximum password
age set to specified number of
days

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.1.0
Authentication Authentication not have the minimum password
age set to specified number of
days

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.0.0
Authentication Authentication not have the password
complexity setting enabled
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.1.0
Authentication Authentication not restrict the minimum
password length to specified
number of characters

Identification And IA-5 (1) Password-Based Audit Windows machines that do 2.0.0
Authentication Authentication not store passwords using
reversible encryption

Risk Assessment RA-5 Vulnerability SQL servers on machines should 1.0.0

Scanning have vulnerability findings
resolved

System And SC-3 Security Function Windows Defender Exploit Guard 2.0.0
Communications Isolation should be enabled on your
Protection machines

System And SC-8 Transmission Windows machines should be 4.1.1

Communications Confidentiality And configured to use secure
Protection Integrity communication protocols

System And SC-8 (1) Cryptographic Or Windows machines should be 4.1.1

Communications Alternate Physical configured to use secure
Protection Protection communication protocols

System And SI-3 Malicious Code Windows Defender Exploit Guard 2.0.0
Information Integrity Protection should be enabled on your
machines

System And SI-3 Malicious Code Windows Defender Exploit Guard 2.0.0
Information Integrity Protection should be enabled on your
machines

System and SI-3 Malicious Code Windows Defender Exploit Guard 2.0.0
Information Integrity Protection should be enabled on your
machines

System and SI-3 Malicious Code Windows Defender Exploit Guard 2.0.0
Information Integrity Protection should be enabled on your
machines

System And SI-3 Malicious Code Windows Defender Exploit Guard 2.0.0
Information Integrity Protection should be enabled on your
machines

System And SI-3 (1) Central Management Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

System and SI-3 (1) Central Management Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
 machines
Domain Control Control title Policy Policy
ID (Azure portal) version
System And SI-3 (1) Central Management Windows Defender Exploit Guard 2.0.0
(GitHub)
Information Integrity should be enabled on your
machines

System And SI-3 (1) Central Management Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

System and SI-3 (1) Central Management Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

System and SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Linux Azure Arc machines

System and SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Linux Azure Arc machines

System And SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Linux Azure Arc machines

System And SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Linux Azure Arc machines

System And SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Linux Azure Arc machines

System and SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Windows Azure Arc
machines

System and SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Windows Azure Arc
machines

System And SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Windows Azure Arc
machines

System And SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Windows Azure Arc
machines
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

System And SI-4 Information System [Preview]: Log Analytics 1.0.1-

Information Integrity Monitoring extension should be installed on preview
your Windows Azure Arc
machines

System And SI-16 Memory Protection Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

System And SI-16 Memory Protection Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

System and SI-16 Memory Protection Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

System and SI-16 Memory Protection Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

System And SI-16 Memory Protection Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

NIST SP 800-53 Rev. 5

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - NIST SP 800-53 Rev. 5. For more
information about this compliance standard, see NIST SP 800-53 Rev. 5 .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Access Control AC-3 Access Enforcement Audit Linux machines that have 3.1.0
accounts without passwords

Access Control AC-3 Access Enforcement Authentication to Linux machines 3.2.0

should require SSH keys

Access Control AC-17 Remote Access Audit Linux machines that allow 3.1.0
remote connections from
accounts without passwords
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Access Control AC-17 Monitoring and Audit Linux machines that allow 3.1.0
(1) Control remote connections from
accounts without passwords

Audit and AU-6 (4) Central Review and [Preview]: Log Analytics extension 1.0.1-
Accountability Analysis should be installed on your Linux preview
Azure Arc machines

Audit and AU-6 (4) Central Review and [Preview]: Log Analytics extension 1.0.1-
Accountability Analysis should be installed on your preview
Windows Azure Arc machines

Audit and AU-6 (5) Integrated Analysis [Preview]: Log Analytics extension 1.0.1-
Accountability of Audit Records should be installed on your Linux preview
Azure Arc machines

Audit and AU-6 (5) Integrated Analysis [Preview]: Log Analytics extension 1.0.1-
Accountability of Audit Records should be installed on your preview
Windows Azure Arc machines

Audit and AU-12 Audit Record [Preview]: Log Analytics extension 1.0.1-
Accountability Generation should be installed on your Linux preview
Azure Arc machines

Audit and AU-12 Audit Record [Preview]: Log Analytics extension 1.0.1-
Accountability Generation should be installed on your preview
Windows Azure Arc machines

Audit and AU-12 System-wide and [Preview]: Log Analytics extension 1.0.1-
Accountability (1) Time-correlated should be installed on your Linux preview
Audit Trail Azure Arc machines

Audit and AU-12 System-wide and [Preview]: Log Analytics extension 1.0.1-
Accountability (1) Time-correlated should be installed on your preview
Audit Trail Windows Azure Arc machines

Configuration CM-6 Configuration Linux machines should meet 2.2.0

Management Settings requirements for the Azure
compute security baseline

Configuration CM-6 Configuration Windows machines should meet 2.0.0

Management Settings requirements of the Azure
compute security baseline

Identification and IA-5 Authenticator Audit Linux machines that do not 3.1.0
Authentication Management have the passwd file permissions
set to 0644

Identification and IA-5 Authenticator Audit Windows machines that do 2.0.0

Authentication Management not store passwords using
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

reversible encryption

Identification and IA-5 Authenticator Authentication to Linux machines 3.2.0

Authentication Management should require SSH keys

Identification and IA-5 (1) Password-based Audit Linux machines that do not 3.1.0
Authentication Authentication have the passwd file permissions
set to 0644

Identification and IA-5 (1) Password-based Audit Windows machines that 2.1.0
Authentication Authentication allow re-use of the passwords
after the specified number of
unique passwords

Identification and IA-5 (1) Password-based Audit Windows machines that do 2.1.0
Authentication Authentication not have the maximum password
age set to specified number of
days

Identification and IA-5 (1) Password-based Audit Windows machines that do 2.1.0
Authentication Authentication not have the minimum password
age set to specified number of
days

Identification and IA-5 (1) Password-based Audit Windows machines that do 2.0.0
Authentication Authentication not have the password
complexity setting enabled

Identification and IA-5 (1) Password-based Audit Windows machines that do 2.1.0
Authentication Authentication not restrict the minimum
password length to specified
number of characters

Identification and IA-5 (1) Password-based Audit Windows machines that do 2.0.0
Authentication Authentication not store passwords using
reversible encryption

Risk Assessment RA-5 Vulnerability SQL servers on machines should 1.0.0

Monitoring and have vulnerability findings
Scanning resolved

System and SC-3 Security Function Windows Defender Exploit Guard 2.0.0
Communications Isolation should be enabled on your
Protection machines

System and SC-8 Transmission Windows machines should be 4.1.1

Communications Confidentiality and configured to use secure
Protection Integrity communication protocols

System and SC-8 (1) Cryptographic Windows machines should be 4.1.1

Communications Protection configured to use secure
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Protection communication protocols

System and SI-3 Malicious Code Windows Defender Exploit Guard 2.0.0
Information Integrity Protection should be enabled on your
machines

System and SI-4 System Monitoring [Preview]: Log Analytics extension 1.0.1-
Information Integrity should be installed on your Linux preview
Azure Arc machines

System and SI-4 System Monitoring [Preview]: Log Analytics extension 1.0.1-
Information Integrity should be installed on your preview
Windows Azure Arc machines

System and SI-16 Memory Protection Windows Defender Exploit Guard 2.0.0
Information Integrity should be enabled on your
machines

NL BIO Cloud Theme

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance details for NL BIO Cloud Theme. For more
information about this compliance standard, see Baseline Information Security Government
Cybersecurity - Digital Government (digitaleoverheid.nl) .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

C.04.3 Technical C.04.3 If the probability of abuse and SQL servers on machines 1.0.0
vulnerability the expected damage are should have vulnerability
management - both high, patches are findings resolved
Timelines installed no later than within a
week.

C.04.3 Technical C.04.3 If the probability of abuse and Windows Defender 2.0.0
vulnerability the expected damage are Exploit Guard should be
management - both high, patches are enabled on your
Timelines installed no later than within a machines
week.

C.04.6 Technical C.04.6 Technical weaknesses can be SQL servers on machines 1.0.0
vulnerability remedied by performing patch should have vulnerability
management - management in a timely findings resolved
Timelines manner.
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

C.04.6 Technical C.04.6 Technical weaknesses can be Windows Defender 2.0.0

vulnerability remedied by performing patch Exploit Guard should be
management - management in a timely enabled on your
Timelines manner. machines

C.04.7 Technical C.04.7 Evaluations of technical SQL servers on machines 1.0.0

vulnerability vulnerabilities are recorded should have vulnerability
management - and reported. findings resolved
Evaluated

C.04.7 Technical C.04.7 Evaluations of technical Windows Defender 2.0.0

vulnerability vulnerabilities are recorded Exploit Guard should be
management - and reported. enabled on your
Evaluated machines

C.04.8 Technical C.04.8 The evaluation reports contain SQL servers on machines 1.0.0
vulnerability suggestions for improvement should have vulnerability
management - and are communicated with findings resolved
Evaluated managers/owners.

U.05.1 Data U.05.1 Data transport is secured with Windows machines 4.1.1
protection - cryptography where key should be configured to
Cryptographic management is carried out by use secure
measures the CSC itself if possible. communication
protocols

U.09.3 Malware U.09.3 The malware protection runs SQL servers on machines 1.0.0
Protection - on different environments. should have vulnerability
Detection, findings resolved
prevention and
recovery

U.09.3 Malware U.09.3 The malware protection runs Windows Defender 2.0.0
Protection - on different environments. Exploit Guard should be
Detection, enabled on your
prevention and machines
recovery

U.10.2 Access to IT U.10.2 Under the responsibility of the Audit Linux machines 3.1.0
services and data - CSP, access is granted to that allow remote
Users administrators. connections from
accounts without
passwords

U.10.2 Access to IT U.10.2 Under the responsibility of the Audit Linux machines 3.1.0
services and data - CSP, access is granted to that have accounts
Users administrators. without passwords

U.10.3 Access to IT U.10.3 Only users with authenticated Audit Linux machines 3.1.0
services and data - equipment can access IT that allow remote
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Users services and data. connections from

accounts without
passwords

U.10.3 Access to IT U.10.3 Only users with authenticated Audit Linux machines 3.1.0
services and data - equipment can access IT that have accounts
Users services and data. without passwords

U.10.5 Access to IT U.10.5 Access to IT services and data Audit Linux machines 3.1.0
services and data - is limited by technical that allow remote
Competent measures and has been connections from
implemented. accounts without
passwords

U.10.5 Access to IT U.10.5 Access to IT services and data Audit Linux machines 3.1.0
services and data - is limited by technical that have accounts
Competent measures and has been without passwords
implemented.

U.11.1 U.11.1 In the cryptography policy, at Audit Windows 2.0.0

Cryptoservices - least the subjects in machines that do not
Policy accordance with BIO have store passwords using
been elaborated. reversible encryption

U.11.1 U.11.1 In the cryptography policy, at Windows machines 4.1.1

Cryptoservices - least the subjects in should be configured to
Policy accordance with BIO have use secure
been elaborated. communication
protocols

U.11.2 U.11.2 In case of PKIoverheid Audit Windows 2.0.0

Cryptoservices - certificates use PKIoverheid machines that do not
Cryptographic requirements for key store passwords using
measures management. In other reversible encryption
situations use ISO11770.

U.11.2 U.11.2 In case of PKIoverheid Windows machines 4.1.1

Cryptoservices - certificates use PKIoverheid should be configured to
Cryptographic requirements for key use secure
measures management. In other communication
situations use ISO11770. protocols

U.15.1 Logging and U.15.1 The violation of the policy [Preview]: Log Analytics 1.0.1-
monitoring - Events rules is recorded by the CSP extension should be preview
logged and the CSC. installed on your Linux
Azure Arc machines

U.15.1 Logging and U.15.1 The violation of the policy [Preview]: Log Analytics 1.0.1-
monitoring - Events rules is recorded by the CSP extension should be preview
logged and the CSC. installed on your
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Windows Azure Arc

machines

PCI DSS 3.2.1

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see PCI DSS 3.2.1. For more information about this compliance standard, see PCI DSS
3.2.1 .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Requirement 8.2.3 PCI DSS Audit Windows machines that allow re-use of 2.1.0
8 requirement the passwords after the specified number of
8.2.3 unique passwords

Requirement 8.2.3 PCI DSS Audit Windows machines that do not have 2.1.0
8 requirement the maximum password age set to specified
8.2.3 number of days

Requirement 8.2.3 PCI DSS Audit Windows machines that do not restrict 2.1.0
8 requirement the minimum password length to specified
8.2.3 number of characters

Requirement 8.2.5 PCI DSS Audit Windows machines that allow re-use of 2.1.0
8 requirement the passwords after the specified number of
8.2.5 unique passwords

Requirement 8.2.5 PCI DSS Audit Windows machines that do not have 2.1.0
8 requirement the maximum password age set to specified
8.2.5 number of days

Requirement 8.2.5 PCI DSS Audit Windows machines that do not restrict 2.1.0
8 requirement the minimum password length to specified
8.2.5 number of characters

PCI DSS v4.0

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance details for PCI DSS v4.0. For more
information about this compliance standard, see PCI DSS v4.0 .
 ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Requirement 08: 8.3.6 Strong authentication Audit Windows machines 2.1.0

Identify Users and for users and that allow re-use of the
Authenticate Access to administrators is passwords after the specified
System Components established and number of unique passwords
managed

Requirement 08: 8.3.6 Strong authentication Audit Windows machines 2.1.0

Identify Users and for users and that do not have the
Authenticate Access to administrators is maximum password age set
System Components established and to specified number of days
managed

Requirement 08: 8.3.6 Strong authentication Audit Windows machines 2.1.0

Identify Users and for users and that do not restrict the
Authenticate Access to administrators is minimum password length
System Components established and to specified number of
managed characters

Reserve Bank of India - IT Framework for NBFC

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - Reserve Bank of India - IT Framework for
NBFC. For more information about this compliance standard, see Reserve Bank of India - IT
Framework for NBFC .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

IT Governance 1 IT Governance-1 SQL servers on machines should 1.0.0

have vulnerability findings resolved

Information and 3.3 Vulnerability SQL servers on machines should 1.0.0

Cyber Security Management-3.3 have vulnerability findings resolved

Reserve Bank of India IT Framework for Banks

v2016
To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - RBI ITF Banks v2016. For more information
about this compliance standard, see RBI ITF Banks v2016 (PDF) .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Maintenance, Maintenance, Monitoring, [Preview]: Log Analytics 1.0.1-

Monitoring, And Analysis And Analysis Of Audit extension should be preview
Of Audit Logs Logs-16.2 installed on your Linux
Azure Arc machines

Maintenance, Maintenance, Monitoring, [Preview]: Log Analytics 1.0.1-

Monitoring, And Analysis And Analysis Of Audit extension should be preview
Of Audit Logs Logs-16.2 installed on your Linux
Azure Arc machines

Maintenance, Maintenance, Monitoring, [Preview]: Log Analytics 1.0.1-

Monitoring, And Analysis And Analysis Of Audit extension should be preview
Of Audit Logs Logs-16.2 installed on your Linux
Azure Arc machines

Maintenance, Maintenance, Monitoring, [Preview]: Log Analytics 1.0.1-

Monitoring, And Analysis And Analysis Of Audit extension should be preview
Of Audit Logs Logs-16.2 installed on your
Windows Azure Arc
machines

Maintenance, Maintenance, Monitoring, [Preview]: Log Analytics 1.0.1-

Monitoring, And Analysis And Analysis Of Audit extension should be preview
Of Audit Logs Logs-16.2 installed on your
Windows Azure Arc
machines

Maintenance, Maintenance, Monitoring, [Preview]: Log Analytics 1.0.1-

Monitoring, And Analysis And Analysis Of Audit extension should be preview
Of Audit Logs Logs-16.2 installed on your
Windows Azure Arc
machines

Authentication Authentication Authentication to Linux 3.2.0

Framework For Framework For machines should require
Customers Customers-9.1 SSH keys

Authentication Authentication Authentication to Linux 3.2.0

Framework For Framework For machines should require
Customers Customers-9.3 SSH keys

Authentication Authentication Authentication to Linux 3.2.0

Framework For Framework For machines should require
Customers Customers-9.3 SSH keys
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Authentication Authentication Authentication to Linux 3.2.0

Framework For Framework For machines should require
Customers Customers-9.1 SSH keys

Patch/Vulnerability & Patch/Vulnerability & Authentication to Linux 3.2.0

Change Management Change Management-7.7 machines should require
SSH keys

Advanced Real- Advanced Real- Authentication to Linux 3.2.0

Timethreat Defenceand Timethreat Defenceand machines should require
Management Management-13.4 SSH keys

Patch/Vulnerability & Patch/Vulnerability & Authentication to Linux 3.2.0

Change Management Change Management-7.7 machines should require
SSH keys

Advanced Real- Advanced Real- Endpoint protection 1.0.0

Timethreat Defenceand Timethreat Defenceand health issues should be
Management Management-13.2 resolved on your
machines

Advanced Real- Advanced Real- Endpoint protection 1.0.0

Timethreat Defenceand Timethreat Defenceand health issues should be
Management Management-13.1 resolved on your
machines

Data Leak Prevention Data Leak Prevention Endpoint protection 1.0.0

Strategy Strategy-15.1 health issues should be
resolved on your
machines

Data Leak Prevention Data Leak Prevention Endpoint protection 1.0.0

Strategy Strategy-15.3 health issues should be
resolved on your
machines

Data Leak Prevention Data Leak Prevention Endpoint protection 1.0.0

Strategy Strategy-15.1 health issues should be
resolved on your
machines

Data Leak Prevention Data Leak Prevention Endpoint protection 1.0.0

Strategy Strategy-15.3 health issues should be
resolved on your
machines

Data Leak Prevention Data Leak Prevention Endpoint protection 1.0.0

Strategy Strategy-15.3 should be installed on
your machines
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Data Leak Prevention Data Leak Prevention Endpoint protection 1.0.0

Strategy Strategy-15.1 should be installed on
your machines

Data Leak Prevention Data Leak Prevention Endpoint protection 1.0.0

Strategy Strategy-15.3 should be installed on
your machines

Advanced Real- Advanced Real- Endpoint protection 1.0.0

Timethreat Defenceand Timethreat Defenceand should be installed on
Management Management-13.2 your machines

Advanced Real- Advanced Real- Endpoint protection 1.0.0

Timethreat Defenceand Timethreat Defenceand should be installed on
Management Management-13.1 your machines

Data Leak Prevention Data Leak Prevention Endpoint protection 1.0.0

Strategy Strategy-15.1 should be installed on
your machines

Audit Log Settings Audit Log Settings-17.1 Linux machines should 2.2.0
meet requirements for
the Azure compute
security baseline

Advanced Real- Advanced Real- Linux machines should 2.2.0

Timethreat Defenceand Timethreat Defenceand meet requirements for
Management Management-13.1 the Azure compute
security baseline

Vulnerability Assessment Vulnerability Assessment SQL servers on machines 1.0.0

And Penetration Test And Penetration Test And should have vulnerability
And Red Team Exercises Red Team Exercises-18.4 findings resolved

Preventing Execution Of Security Update SQL servers on machines 1.0.0

Unauthorised Software Management-2.3 should have vulnerability
findings resolved

Vulnerability Assessment Vulnerability Assessment SQL servers on machines 1.0.0

And Penetration Test And Penetration Test And should have vulnerability
And Red Team Exercises Red Team Exercises-18.4 findings resolved

Patch/Vulnerability & Patch/Vulnerability & SQL servers on machines 1.0.0

Change Management Change Management-7.1 should have vulnerability
findings resolved

Vulnerability Assessment Vulnerability Assessment SQL servers on machines 1.0.0

And Penetration Test And Penetration Test And should have vulnerability
And Red Team Exercises Red Team Exercises-18.4 findings resolved
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Patch/Vulnerability & Patch/Vulnerability & SQL servers on machines 1.0.0

Change Management Change Management-7.2 should have vulnerability
findings resolved

Patch/Vulnerability & Patch/Vulnerability & SQL servers on machines 1.0.0

Change Management Change Management-7.6 should have vulnerability
findings resolved

Patch/Vulnerability & Patch/Vulnerability & SQL servers on machines 1.0.0

Change Management Change Management-7.6 should have vulnerability
findings resolved

Patch/Vulnerability & Patch/Vulnerability & SQL servers on machines 1.0.0

Change Management Change Management-7.1 should have vulnerability
findings resolved

Patch/Vulnerability & Patch/Vulnerability & SQL servers on machines 1.0.0

Change Management Change Management-7.2 should have vulnerability
findings resolved

Data Leak Prevention Data Leak Prevention Windows Defender 2.0.0

Strategy Strategy-15.3 Exploit Guard should be
enabled on your
machines

Data Leak Prevention Data Leak Prevention Windows Defender 2.0.0

Strategy Strategy-15.1 Exploit Guard should be
enabled on your
machines

Data Leak Prevention Data Leak Prevention Windows Defender 2.0.0

Strategy Strategy-15.3 Exploit Guard should be
enabled on your
machines

Data Leak Prevention Data Leak Prevention Windows Defender 2.0.0

Strategy Strategy-15.1 Exploit Guard should be
enabled on your
machines

Secure Configuration Secure Configuration-5.1 Windows Defender 2.0.0

Exploit Guard should be
enabled on your
machines

Advanced Real- Advanced Real- Windows Defender 2.0.0

Timethreat Defenceand Timethreat Defenceand Exploit Guard should be
Management Management-13.2 enabled on your
machines
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Advanced Real- Advanced Real- Windows Defender 2.0.0

Timethreat Defenceand Timethreat Defenceand Exploit Guard should be
Management Management-13.1 enabled on your
machines

Secure Mail And Secure Mail And Windows machines 4.1.1

Messaging Systems Messaging Systems-10.1 should be configured to
use secure
communication
protocols

Secure Mail And Secure Mail And Windows machines 4.1.1

Messaging Systems Messaging Systems-10.2 should be configured to
use secure
communication
protocols

Advanced Real- Advanced Real- Windows machines 4.1.1

Timethreat Defenceand Timethreat Defenceand should be configured to
Management Management-13.4 use secure
communication
protocols

Audit Log Settings Audit Log Settings-17.1 Windows machines 2.0.0

should meet
requirements of the
Azure compute security
baseline

Advanced Real- Advanced Real- Windows machines 2.0.0

Timethreat Defenceand Timethreat Defenceand should meet
Management Management-13.1 requirements of the
Azure compute security
baseline

SWIFT CSP-CSCF v2021

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance details for SWIFT CSP-CSCF v2021. For more
information about this compliance standard, see SWIFT CSP CSCF v2021 .

ﾉ Expand table
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Reduce Attack 2.1 Internal Data Flow Authentication to Linux machines 3.2.0
Surface and Security should require SSH keys
Vulnerabilities

Reduce Attack 2.1 Internal Data Flow Windows machines should be 4.1.1
Surface and Security configured to use secure
Vulnerabilities communication protocols

Reduce Attack 2.2 Security Updates Audit Windows VMs with a pending 2.0.0
Surface and reboot
Vulnerabilities

Reduce Attack 2.3 System Hardening Audit Linux machines that do not 3.1.0
Surface and have the passwd file permissions set
Vulnerabilities to 0644

Reduce Attack 2.3 System Hardening Audit Windows machines that 2.0.0
Surface and contain certificates expiring within
Vulnerabilities the specified number of days

Reduce Attack 2.3 System Hardening Audit Windows machines that do 2.0.0
Surface and not store passwords using
Vulnerabilities reversible encryption

Reduce Attack 2.4A Back-office Data Authentication to Linux machines 3.2.0

Surface and Flow Security should require SSH keys
Vulnerabilities

Reduce Attack 2.4A Back-office Data Windows machines should be 4.1.1

Surface and Flow Security configured to use secure
Vulnerabilities communication protocols

Reduce Attack 2.6 Operator Session Windows machines should be 4.1.1

Surface and Confidentiality and configured to use secure
Vulnerabilities Integrity communication protocols

Prevent 4.1 Password Policy Audit Linux machines that allow 3.1.0
Compromise of remote connections from accounts
Credentials without passwords

Prevent 4.1 Password Policy Audit Linux machines that have 3.1.0
Compromise of accounts without passwords
Credentials

Prevent 4.1 Password Policy Audit Windows machines that allow 2.1.0
Compromise of re-use of the passwords after the
Credentials specified number of unique
passwords

Prevent 4.1 Password Policy Audit Windows machines that do 2.1.0

Compromise of not have the maximum password
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Credentials age set to specified number of days

Prevent 4.1 Password Policy Audit Windows machines that do 2.1.0

Compromise of not have the minimum password
Credentials age set to specified number of days

Prevent 4.1 Password Policy Audit Windows machines that do 2.0.0

Compromise of not have the password complexity
Credentials setting enabled

Prevent 4.1 Password Policy Audit Windows machines that do 2.1.0

Compromise of not restrict the minimum password
Credentials length to specified number of
characters

Manage Identities 5.4 Physical and Logical Audit Windows machines that do 2.0.0
and Segregate Password Storage not store passwords using
Privileges reversible encryption

SWIFT CSP-CSCF v2022

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance details for SWIFT CSP-CSCF v2022. For more
information about this compliance standard, see SWIFT CSP CSCF v2022 .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

2. Reduce Attack 2.1 Ensure the confidentiality, integrity, Authentication to Linux 3.2.0
Surface and and authenticity of application data machines should require
Vulnerabilities flows between local SWIFT-related SSH keys
components.

2. Reduce Attack 2.1 Ensure the confidentiality, integrity, Windows machines 4.1.1
Surface and and authenticity of application data should be configured to
Vulnerabilities flows between local SWIFT-related use secure
components. communication
protocols

2. Reduce Attack 2.2 Minimise the occurrence of known Audit Windows VMs 2.0.0
Surface and technical vulnerabilities on operator with a pending reboot
Vulnerabilities PCs and within the local SWIFT
infrastructure by ensuring vendor
support, applying mandatory
software updates, and applying
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

timely security updates aligned to

the assessed risk.

2. Reduce Attack 2.3 Reduce the cyber-attack surface of Audit Linux machines 3.1.0
Surface and SWIFT-related components by that do not have the
Vulnerabilities performing system hardening. passwd file permissions
set to 0644

2. Reduce Attack 2.3 Reduce the cyber-attack surface of Audit Windows 2.0.0
Surface and SWIFT-related components by machines that contain
Vulnerabilities performing system hardening. certificates expiring
within the specified
number of days

2. Reduce Attack 2.3 Reduce the cyber-attack surface of Audit Windows 2.0.0
Surface and SWIFT-related components by machines that do not
Vulnerabilities performing system hardening. store passwords using
reversible encryption

2. Reduce Attack 2.4A Back-office Data Flow Security Authentication to Linux 3.2.0
Surface and machines should require
Vulnerabilities SSH keys

2. Reduce Attack 2.4A Back-office Data Flow Security Windows machines 4.1.1
Surface and should be configured to
Vulnerabilities use secure
communication
protocols

2. Reduce Attack 2.6 Protect the confidentiality and Windows machines 4.1.1
Surface and integrity of interactive operator should be configured to
Vulnerabilities sessions that connect to the local or use secure
remote (operated by a service communication
provider) SWIFT infrastructure or protocols
service provider SWIFT-related
applications

2. Reduce Attack 2.6 Protect the confidentiality and Windows machines 3.0.0
Surface and integrity of interactive operator should meet
Vulnerabilities sessions that connect to the local or requirements for
remote (operated by a service 'Security Options -
provider) SWIFT infrastructure or Interactive Logon'
service provider SWIFT-related
applications

4. Prevent 4.1 Ensure passwords are sufficiently Audit Linux machines 3.1.0
Compromise of resistant against common password that allow remote
Credentials attacks by implementing and connections from
enforcing an effective password accounts without
policy. passwords
Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

4. Prevent 4.1 Ensure passwords are sufficiently Audit Linux machines 3.1.0
Compromise of resistant against common password that have accounts
Credentials attacks by implementing and without passwords
enforcing an effective password
policy.

4. Prevent 4.1 Ensure passwords are sufficiently Audit Windows 2.1.0

Compromise of resistant against common password machines that allow re-
Credentials attacks by implementing and use of the passwords
enforcing an effective password after the specified
policy. number of unique
passwords

4. Prevent 4.1 Ensure passwords are sufficiently Audit Windows 2.1.0

Compromise of resistant against common password machines that do not
Credentials attacks by implementing and have the maximum
enforcing an effective password password age set to
policy. specified number of
days

4. Prevent 4.1 Ensure passwords are sufficiently Audit Windows 2.1.0

Compromise of resistant against common password machines that do not
Credentials attacks by implementing and have the minimum
enforcing an effective password password age set to
policy. specified number of
days

4. Prevent 4.1 Ensure passwords are sufficiently Audit Windows 2.0.0

Compromise of resistant against common password machines that do not
Credentials attacks by implementing and have the password
enforcing an effective password complexity setting
policy. enabled

4. Prevent 4.1 Ensure passwords are sufficiently Audit Windows 2.1.0

Compromise of resistant against common password machines that do not
Credentials attacks by implementing and restrict the minimum
enforcing an effective password password length to
policy. specified number of
characters

5. Manage 5.1 Enforce the security principles of Audit Windows 2.0.0

Identities and need-to-know access, least privilege, machines that contain
Segregate and separation of duties for operator certificates expiring
Privileges accounts. within the specified
number of days

5. Manage 5.4 Protect physically and logically the Audit Windows 2.0.0
Identities and repository of recorded passwords. machines that do not
 Domain Control Control title Policy Policy
ID (Azure portal) version
(GitHub)

Segregate store passwords using

Privileges reversible encryption

UK OFFICIAL and UK NHS

To review how the available Azure Policy built-ins for all Azure services map to this compliance
standard, see Azure Policy Regulatory Compliance - UK OFFICIAL and UK NHS. For more
information about this compliance standard, see UK OFFICIAL .

ﾉ Expand table

Domain Control Control title Policy Policy

ID (Azure portal) version
(GitHub)

Data in transit 1 Data in transit Windows machines should be configured 4.1.1

protection protection to use secure communication protocols

Identity and 10 Identity and Audit Linux machines that allow remote 3.1.0
authentication authentication connections from accounts without
passwords

Identity and 10 Identity and Audit Linux machines that do not have 3.1.0
authentication authentication the passwd file permissions set to 0644

Identity and 10 Identity and Audit Linux machines that have accounts 3.1.0
authentication authentication without passwords

Identity and 10 Identity and Audit Windows machines that allow re- 2.1.0
authentication authentication use of the passwords after the specified
number of unique passwords

Identity and 10 Identity and Audit Windows machines that do not 2.1.0
authentication authentication have the maximum password age set to
specified number of days

Identity and 10 Identity and Audit Windows machines that do not 2.1.0
authentication authentication have the minimum password age set to
specified number of days

Identity and 10 Identity and Audit Windows machines that do not 2.0.0
authentication authentication have the password complexity setting
enabled

Identity and 10 Identity and Audit Windows machines that do not 2.1.0
authentication authentication restrict the minimum password length to
specified number of characters
Next steps
Learn more about Azure Policy Regulatory Compliance.
See the built-ins on the Azure Policy GitHub repo .
azcmagent CLI reference
Article • 04/25/2023

The Azure Connected Machine agent command line tool, azcmagent, helps you
configure, manage, and troubleshoot a server's connection with Azure Arc. The
azcmagent CLI is installed with the Azure Connected Machine agent and controls
actions specific to the server where it's running. Once the server is connected to Azure
Arc, you can use the Azure CLI or Azure PowerShell module to enable extensions,
manage tags, and perform other operations on the server resource.

Unless otherwise specified, the command syntax and flags represent available options in
the most recent release of the Azure Connected Machine agent. For more information,
see What's new with the Azure Connected Machine agent.

Commands
Command Purpose

azcmagent check Run network connectivity checks for Azure Arc endpoints

azcmagent config Manage agent settings

azcmagent connect Connect the server to Azure Arc

azcmagent disconnect Disconnect the server from Azure Arc

azcmagent genkey Generate a public-private key pair for asynchronous onboarding

azcmagent help Get help for commands

azcmagent license Display the end-user license agreement

azcmagent logs Collect logs to troubleshoot agent issues

azcmagent show Display the agent status

azcmagent version Display the agent version

Frequently asked questions

How can I install the azcmagent CLI?

The azcmagent CLI is bundled with the Azure Connected Machine agent. Review your
deployment options for Azure Arc to learn how to install and configure the agent.

Where is the CLI installed?

On Windows operating systems, the CLI is installed at
%PROGRAMFILES%\AzureConnectedMachineAgent\azcmagent.exe . This path is automatically
added to the system PATH variable during the installation process. You may need to
close and reopen your console to refresh the PATH variable and be able to run
azcmagent without specifying the full path.

On Linux operating systems, the CLI is installed at /opt/azcmagent/bin/azcmagent

What's the difference between the azcmagent CLI and the

Azure CLI for Azure Arc-enabled servers?
The azcmagent CLI is used to configure the local agent. It's responsible for connecting
the agent to Azure, disconnecting it, and configuring local settings like proxy URLs and
security features.

The Azure CLI and other management experiences are used to interact with the Azure
Arc resource in Azure once the agent is connected. These tools help you manage
extensions, move the resource to another subscription or resource group, and change
certain settings of the Arc server remotely.
azcmagent check
Article • 05/22/2024

Run a series of network connectivity checks to see if the agent can successfully
communicate with required network endpoints. The command outputs a table showing
connectivity test results for each required endpoint, including whether the agent used a
private endpoint and/or proxy server.

Usage

azcmagent check [flags]

Examples
Check connectivity with the agent's configured cloud and region.

azcmagent check

Check connectivity with the East US region using public endpoints.

azcmagent check --location "eastus"

Check connectivity for supported extensions (SQL Server enabled by Azure Arc) using
public endpoints:

azcmagent check --extensions all

Check connectivity with the Central India region using private endpoints.

azcmagent check --location "centralindia" --enable-pls-check

Flags
--cloud

Specifies the Azure cloud instance. Must be used with the --location flag. If the
machine is already connected to Azure Arc, the default value is the cloud to which the
agent is already connected. Otherwise, the default value is AzureCloud.

Supported values:

AzureCloud (public regions)

AzureUSGovernment (Azure US Government regions)
AzureChinaCloud (Microsoft Azure operated by 21Vianet regions)

-e , --extensions

Includes extra checks for extension endpoints to help validate end-to-end scenario
readiness. This flag is available in agent version 1.41 and later.

Supported values:

all (checks all supported extension endpoints)

sql (SQL Server enabled by Azure Arc)

-l , --location

The Azure region to check connectivity with. If the machine is already connected to
Azure Arc, the current region is selected as the default.

Sample value: westeurope

-p , --enable-pls-check

Checks if supported Azure Arc endpoints resolve to private IP addresses. This flag
should be used when you intend to connect the server to Azure using an Azure Arc
private link scope.

Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:
 JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent config
Article • 04/25/2023

Configure settings for the Azure connected machine agent. Configurations are stored
locally and are unique to each machine. Available configuration properties vary by agent
version. Use azcmagent config info to see all available configuration properties and
supported values for the currently installed agent.

Commands
Command Purpose

azcmagent config clear Clear a configuration property's value

azcmagent config get Gets a configuration property's value

azcmagent config info Describes all available configuration properties and supported values

azcmagent config list Lists all configuration properties and values

azcmagent config set Set a value for a configuration property

azcmagent config clear

Clear a configuration property's value and reset it to its default state.

Usage

azcmagent config clear [property] [flags]

Examples
Clear the proxy server URL property.

azcmagent config clear proxy.url

Flags
Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.

azcmagent config get

Get a configuration property's value.
Usage

azcmagent config get [property] [flags]

Examples
Get the agent mode.

azcmagent config get config.mode

Flags
Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr
Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.

azcmagent config info

Describes available configuration properties and supported values. When run without
specifying a specific property, the command describes all available properties their
supported values.

Usage

azcmagent config info [property] [flags]

Examples
Describe all available configuration properties and supported values.

azcmagent config info

Learn more about the extensions allowlist property and its supported values.

azcmagent config info extensions.allowlist

Flags
Common flags available for all commands
--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.

azcmagent config list

Lists all configuration properties and their current values

Usage
 azcmagent config list [flags]

Examples
List the current agent configuration.

azcmagent config list

Flags
Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.
--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.

azcmagent config set

Set a value for a configuration property.

Usage

azcmagent config set [property] [value] [flags]

Examples
Configure the agent to use a proxy server.

azcmagent config set proxy.url "http://proxy.contoso.corp:8080"

Append an extension to the extension allowlist.

azcmagent config set extensions.allowlist

"Microsoft.Azure.Monitor/AzureMonitorWindowsAgent" --add

Flags
-a , --add

Append the value to the list of existing values. If not specified, the default behavior is to
replace the list of existing values. This flag is only supported for configuration properties
that support more than one value. Can't be used with the --remove flag.
-r , --remove

Remove the specified value from the list, retaining all other values. If not specified, the
default behavior is to replace the list of existing values. This flag is only supported for
configuration properties that support more than one value. Can't be used in conjunction
with the --add flag.

Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent connect
Article • 05/22/2024

Connects the server to Azure Arc by creating a metadata representation of the server in
Azure and associating the Azure connected machine agent with it. The command
requires information about the tenant, subscription, and resource group where you want
to represent the server in Azure and valid credentials with permissions to create Azure
Arc-enabled server resources in that location.

Usage

azcmagent connect [authentication] --subscription-id [subscription] --

resource-group [resourcegroup] --location [region] [flags]

Examples
Connect a server using the default login method (interactive browser or device code).

azcmagent connect --subscription-id "Production" --resource-group

"HybridServers" --location "eastus"

azcmagent connect --subscription-id "Production" --resource-group

"HybridServers" --location "eastus" --use-device-code

Connect a server using a service principal.

azcmagent connect --subscription-id "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" -

-resource-group "HybridServers" --location "australiaeast" --service-
principal-id "ID" --service-principal-secret "SECRET" --tenant-id "TENANT"

Connect a server using a private endpoint and device code login method.
 azcmagent connect --subscription-id "Production" --resource-group
"HybridServers" --location "koreacentral" --use-device-code --private-link-
scope
"/subscriptions/.../Microsoft.HybridCompute/privateLinkScopes/ScopeName"

Authentication options
There are four ways to provide authentication credentials to the Azure connected
machine agent. Choose one authentication option and replace the [authentication]
section in the usage syntax with the recommended flags.

Interactive browser login (Windows-only)

This option is the default on Windows operating systems with a desktop experience. It
login page opens in your default web browser. This option might be required if your
organization configured conditional access policies that require you to log in from
trusted machines.

No flag is required to use the interactive browser login.

Device code login

This option generates a code that you can use to log in on a web browser on another
device. This is the default option on Windows Server core editions and all Linux
distributions. When you execute the connect command, you have 5 minutes to open the
specified login URL on an internet-connected device and complete the login flow.

To authenticate with a device code, use the --use-device-code flag. If the account you're
logging in with and the subscription where you're registering the server aren't in the
same tenant, you must also provide the tenant ID for the subscription with --tenant-id
[tenant] .

Service principal with secret

Service principals allow you to authenticate non-interactively and are often used for at-
scale deployments where the same script is run across multiple servers. Microsoft
recommends providing service principal information via a configuration file (see --
config ) to avoid exposing the secret in any console logs. The service principal should

also be dedicated for Arc onboarding and have as few permissions as possible, to limit
the impact of a stolen credential.
To authenticate with a service principal using a secret, provide the service principal's
application ID, secret, and tenant ID: --service-principal-id [appid] --service-
principal-secret [secret] --tenant-id [tenantid]

Service principal with certificate

Certificate-based authentication is a more secure way to authenticate using service
principals. The agent accepts both PCKS #12 (.PFX) files and ASCII-encoded files (such as
.PEM) that contain both the private and public keys. The certificate must be available on
the local disk and the user running the azcmagent command needs read access to the
file. Password-protected PFX files are not supported.

To authenticate with a service principal using a certificate, provide the service principal's
application ID, tenant ID, and path to the certificate file: --service-principal-id [appId]
--service-principal-cert [pathToPEMorPFXfile] --tenant-id [tenantid]

For more information, see create a service principal for RBAC with certificate-based
authentication.

Access token
Access tokens can also be used for non-interactive authentication, but are short-lived
and typically used by automation solutions onboarding several servers over a short
period of time. You can get an access token with Get-AzAccessToken or any other
Microsoft Entra client.

To authenticate with an access token, use the --access-token [token] flag. If the
account you're logging in with and the subscription where you're registering the server
aren't in the same tenant, you must also provide the tenant ID for the subscription with
--tenant-id [tenant] .

Flags
--access-token

Specifies the Microsoft Entra access token used to create the Azure Arc-enabled server
resource in Azure. For more information, see authentication options.

--automanage-profile

Resource ID of an Azure Automanage best practices profile that will be applied to the
server once it's connected to Azure.
Sample value:
/providers/Microsoft.Automanage/bestPractices/AzureBestPracticesProduction

--cloud

Specifies the Azure cloud instance. Must be used with the --location flag. If the
machine is already connected to Azure Arc, the default value is the cloud to which the
agent is already connected. Otherwise, the default value is "AzureCloud".

Supported values:

AzureCloud (public regions)

AzureUSGovernment (Azure US Government regions)
AzureChinaCloud (Microsoft Azure operated by 21Vianet regions)

--correlation-id

Identifies the mechanism being used to connect the server to Azure Arc. For example,
scripts generated in the Azure portal include a GUID that helps Microsoft track usage of
that experience. This flag is optional and only used for telemetry purposes to improve
your experience.

--ignore-network-check

Instructs the agent to continue onboarding even if the network check for required
endpoints fails. You should only use this option if you're sure that the network check
results are incorrect. In most cases, a failed network check indicates that the Azure
Connected Machine agent won't function correctly on the server.

-l , --location

The Azure region to check connectivity with. If the machine is already connected to
Azure Arc, the current region is selected as the default.

Sample value: westeurope

--private-link-scope

Specifies the resource ID of the Azure Arc private link scope to associate with the server.
This flag is required if you're using private endpoints to connect the server to Azure.

-g , --resource-group

Name of the Azure resource group where you want to create the Azure Arc-enabled
server resource.
Sample value: HybridServers

-n , --resource-name

Name for the Azure Arc-enabled server resource. By default, the resource name is:

The AWS instance ID, if the server is on AWS

The hostname for all other machines

You can override the default name with a name of your own choosing to avoid naming
conflicts. Once chosen, the name of the Azure resource can't be changed without
disconnecting and re-connecting the agent.

If you want to force AWS servers to use the hostname instead of the instance ID, pass in
$(hostname) to have the shell evaluate the current hostname and pass that in as the new

resource name.

Sample value: FileServer01

-i , --service-principal-id

Specifies the application ID of the service principal used to create the Azure Arc-enabled
server resource in Azure. Must be used with the --tenant-id and either the --service-
principal-secret or --service-principal-cert flags. For more information, see

authentication options.

--service-principal-cert

Specifies the path to a service principal certificate file. Must be used with the --service-
principal-id and --tenant-id flags. The certificate must include a private key and can

be in a PKCS #12 (.PFX) or ASCII-encoded text (.PEM, .CRT) format. Password-protected

PFX files are not supported. For more information, see authentication options.

-p , --service-principal-secret

Specifies the service principal secret. Must be used with the --service-principal-id and
--tenant-id flags. To avoid exposing the secret in console logs, Microsoft

recommended providing the service principal secret in a configuration file. For more
information, see authentication options.

-s , --subscription-id

The subscription name or ID where you want to create the Azure Arc-enabled server
resource.
Sample values: Production, aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

--tags

Comma-delimited list of tags to apply to the Azure Arc-enabled server resource. Each
tag should be specified in the format: TagName=TagValue. If the tag name or value
contains a space, use single quotes around the name or value.

Sample value: Datacenter=NY3,Application=SharePoint,Owner='Shared Infrastructure

Services'

-t , --tenant-id

The tenant ID for the subscription where you want to create the Azure Arc-enabled
server resource. This flag is required when authenticating with a service principal. For all
other authentication methods, the home tenant of the account used to authenticate
with Azure is used for the resource as well. If the tenants for the account and
subscription are different (guest accounts, Lighthouse), you must specify the tenant ID
to clarify the tenant where the subscription is located.

--use-device-code

Generate a Microsoft Entra device login code that can be entered in a web browser on
another computer to authenticate the agent with Azure. For more information, see
authentication options.

--user-tenant-id

The tenant ID for the account used to connect the server to Azure. This field is required
when the tenant of the onboarding account isn't the same as the desired tenant for the
Azure Arc-enabled server resource.

Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
 }

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent disconnect
Article • 05/22/2024

Deletes the Azure Arc-enabled server resource in the cloud and resets the configuration
of the local agent. For detailed information on removing extensions and disconnecting
and uninstalling the agent, see uninstall the agent.

Usage

azcmagent disconnect [authentication] [flags]

Examples
Disconnect a server using the default login method (interactive browser or device code).

azcmagent disconnect

Disconnect a server using a service principal.

azcmagent disconnect --service-principal-id "ID" --service-principal-secret

"SECRET"

Disconnect a server if the corresponding resource in Azure has already been deleted.

azcmagent disconnect --force-local-only

Authentication options
There are four ways to provide authentication credentials to the Azure connected
machine agent. Choose one authentication option and replace the [authentication]
section in the usage syntax with the recommended flags.
 ７ Note

The account used to disconnect a server must be from the same tenant as the
subscription where the server is registered.

Interactive browser login (Windows-only)

This option is the default on Windows operating systems with a desktop experience. The
login page opens in your default web browser. This option might be required if your
organization configured conditional access policies that require you to log in from
trusted machines.

No flag is required to use the interactive browser login.

Device code login

This option generates a code that you can use to log in on a web browser on another
device. This is the default option on Windows Server core editions and all Linux
distributions. When you execute the connect command, you have 5 minutes to open the
specified login URL on an internet-connected device and complete the login flow.

To authenticate with a device code, use the --use-device-code flag.

Service principal with secret

Service principals allow you to authenticate non-interactively and are often used for at-
scale operations where the same script is run across multiple servers. It's recommended
that you provide service principal information via a configuration file (see --config ) to
avoid exposing the secret in any console logs. The service principal should also be
dedicated for Arc onboarding and have as few permissions as possible, to limit the
impact of a stolen credential.

To authenticate with a service principal using a secret, provide the service principal's
application ID, secret, and tenant ID: --service-principal-id [appid] --service-
principal-secret [secret] --tenant-id [tenantid]

Service principal with certificate

Certificate-based authentication is a more secure way to authenticate using service
principals. The agent accepts both PCKS #12 (.PFX) files and ASCII-encoded files (such as
.PEM) that contain both the private and public keys. The certificate must be available on
the local disk and the user running the azcmagent command needs read access to the
file. Password-protected PFX files are not supported.

To authenticate with a service principal using a certificate, provide the service principal's
application ID, tenant ID, and path to the certificate file: --service-principal-id [appId]
--service-principal-cert [pathToPEMorPFXfile] --tenant-id [tenantid]

For more information, see create a service principal for RBAC with certificate-based
authentication.

Access token
Access tokens can also be used for non-interactive authentication, but are short-lived
and typically used by automation solutions operating on several servers over a short
period of time. You can get an access token with Get-AzAccessToken or any other
Microsoft Entra client.

To authenticate with an access token, use the --access-token [token] flag.

Flags
--access-token

Specifies the Microsoft Entra access token used to create the Azure Arc-enabled server
resource in Azure. For more information, see authentication options.

-f , --force-local-only

Disconnects the server without deleting the resource in Azure. Primarily used if the
Azure resource was deleted and the local agent configuration needs to be cleaned up.

-i , --service-principal-id

Specifies the application ID of the service principal used to create the Azure Arc-enabled
server resource in Azure. Must be used with the --tenant-id and either the --service-
principal-secret or --service-principal-cert flags. For more information, see

authentication options.

--service-principal-cert

Specifies the path to a service principal certificate file. Must be used with the --service-
principal-id and --tenant-id flags. The certificate must include a private key and can
be in a PKCS #12 (.PFX) or ASCII-encoded text (.PEM, .CRT) format. Password-protected
PFX files are not supported. For more information, see authentication options.

-p , --service-principal-secret

Specifies the service principal secret. Must be used with the --service-principal-id and
--tenant-id flags. To avoid exposing the secret in console logs, Microsoft recommends

providing the service principal secret in a configuration file. For more information, see
authentication options.

--use-device-code

Generate a Microsoft Entra device login code that can be entered in a web browser on
another computer to authenticate the agent with Azure. For more information, see
authentication options.

--user-tenant-id

The tenant ID for the account used to connect the server to Azure. This field is required
when the tenant of the onboarding account isn't the same as the desired tenant for the
Azure Arc-enabled server resource.

Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json
Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent extension
Article • 03/19/2024

Local management of Azure Arc extensions installed on the machine. These commands
can be run even when a machine is in a disconnected state.

The extension manager must be stopped before running any of these commands.
Stopping the extension manager interrupts any in-progress extension installs, upgrades,
and removals. To disable the extension manager, run Stop-Service ExtensionService on
Windows or systemctl stop extd . When you're done managing extensions locally, start
the extension manager again with Start-Service ExtensionService on Windows or
systemctl start extd on Linux.

Commands
ﾉ Expand table

Command Purpose

azcmagent extension list Lists extensions installed on the machine

azcmagent extension remove Uninstalls extensions on the machine

azcmagent extension list

Lists extensions installed on the machine.

Usage

azcmagent extension list [flags]

Examples
See which extensions are installed on your machine.
 azcmagent extension list

Flags
Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent extension remove
Uninstalls extensions on the machine.

Usage

azcmagent extension remove [flags]

Examples
Remove the "AzureMonitorWindowsAgent" extension from the local machine.

azcmagent extension remove --name AzureMonitorWindowsAgent

Remove all extensions from the local machine.

azcmagent extension remove --all

Flags
--all , -a

Removes all extensions from the machine.

--name , -n

Removes the specified extension from the machine. Use azcmagent extension list to get
the name of the extension.

Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent genkey
Article • 04/25/2023

Generates a private-public key pair that can be used to onboard a machine

asynchronously. This command is used when connecting a server to an Azure Arc-
enabled virtual machine offering (for example, Azure Arc-enabled VMware vSphere
VMs). You should normally use azcmagent connect to configure the agent.

Usage

azcmagent genkey [flags]

Examples
Generate a key pair and print the public key to the console.

azcmagent genkey

Flags
Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}
If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent help
Article • 04/25/2023

Prints usage information and a list of all available commands for the Azure Connected
Machine agent CLI. For help with a particular command, use azcmagent COMMANDNAME --
help .

Usage

azcmagent help [flags]

Examples
Show all available commands for the command line interface.

azcmagent help

Flags
Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}
If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent license
Article • 04/25/2023

Show the license agreement for the Azure Connected Machine agent.

Usage

azcmagent license [flags]

Examples
Show the license agreement.

azcmagent license

Flags
Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help
Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent logs
Article • 04/25/2023

Collects log files for the Azure connected machine agent and extensions into a ZIP
archive.

Usage

azcmagent logs [flags]

Examples
Collect the most recent log files and store them in a ZIP archive in the current directory.

azcmagent logs

Collect all log files and store them in a specific location.

azcmagent logs --full --output "/tmp/azcmagent-logs.zip"

Flags
-f , --full

Collect all log files on the system instead of just the most recent. Useful when
troubleshooting older problems.

-o , --output

Specifies the path and name for the ZIP file. If this flag isn't specified, the ZIP is saved to
the console's current directory with the name "azcmagent-TIMESTAMP-
COMPUTERNAME.zip"

Sample value: custom-logname.zip

Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent show
Article • 06/07/2023

Displays the current state of the Azure Connected Machine agent, including whether or
not it's connected to Azure, the Azure resource information, and the status of
dependent services.

７ Note

azcmagent show does not require administrator privileges

Usage

azcmagent show [property1] [property2] ... [propertyN] [flags]

Examples
Check the status of the agent.

azcmagent show

Check the status of the agent and save it in a JSON file in the current directory.

azcmagent show -j > "agent-status.json"

Show only the agent status and last heartbeat time (using display names)

azcmagent show "Agent Status" "Agent Last Heartbeat"

Show only the agent status and last heartbeat time (using JSON keys)
 azcmagent show status lastHeartbeat

Flags
[property]

The name of a property to include in the output. If you want to show more than one
property, separate them by spaces. You can use either the display name or the JSON key
name to specify a property. For display names with spaces, enclose the property in
quotes.

--os

Outputs additional information about the operating system.

Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help

Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr
Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
azcmagent version
Article • 04/25/2023

Shows the version of the currently installed agent.

Usage

azcmagent version [flags]

Examples
Show the agent version.

azcmagent version

Flags
Common flags available for all commands

--config

Takes in a path to a JSON or YAML file containing inputs to the command. The
configuration file should contain a series of key-value pairs where the key matches an
available command line option. For example, to pass in the --verbose flag, the
configuration file would look like:

JSON

{
"verbose": true
}

If a command line option is found in both the command invocation and a configuration
file, the value specified on the command line will take precedence.

-h , --help
Get help for the current command, including its syntax and command line options.

-j , --json

Output the command result in the JSON format.

--log-stderr

Redirect error and verbose messages to the standard error (stderr) stream. By default, all
output is sent to the standard output (stdout) stream.

--no-color

Disable color output for terminals that do not support ANSI colors.

-v , --verbose

Show more detailed logging information while the command executes. Useful for
troubleshooting issues when running a command.
az connectedmachine
Reference

７ Note

This reference is part of the connectedmachine extension for the Azure CLI (version
2.57.0 or higher). The extension will automatically install the first time you run an az
connectedmachine command. Learn more about extensions.

Manage an Azure Arc-Enabled Server.

Commands
ﾉ Expand table

Name Description Type Status

az connectedmachine assess- Assess patches on an Azure Arc-Enabled Extension GA

patches Server.

az connectedmachine delete Delete operation to delete an Azure Arc- Extension GA

Enabled Server.

az connectedmachine Manage a VM extension on an Azure Extension GA

extension Arc-Enabled Server.

az connectedmachine The operation to create the extension. Extension GA

extension create

az connectedmachine The operation to delete the extension. Extension GA

extension delete

az connectedmachine Manage VM extension metadata Extension GA

extension image available for Azure Arc-Enabled Servers.

az connectedmachine List all Extension versions based on Extension GA

extension image list location, publisher, extensionType.

az connectedmachine Get an Extension Metadata based on Extension GA

extension image show location, publisher, extensionType and
version.

az connectedmachine The operation to get all extensions of a Extension GA

extension list Non-Azure machine.
Name Description Type Status

az connectedmachine The operation to create or update the Extension GA

extension show extension.

az connectedmachine Update operation to update the Extension GA

extension update extension.

az connectedmachine Place the CLI in a waiting state until a Extension GA

extension wait condition is met.

az connectedmachine install- Install patches on an Azure Arc-Enabled Extension GA

patches Server.

az connectedmachine license The operations on ESU license. Extension Preview

az connectedmachine license Create operation to create a license. Extension Preview

create

az connectedmachine license Delete operation to delete a license. Extension Preview

delete

az connectedmachine license List operation to get all licenses of a Extension Preview

list non-Azure machine.

az connectedmachine license Get information about the view of a Extension Preview

show license.

az connectedmachine license Update operation to create or update a Extension Preview

update license.

az connectedmachine license Place the CLI in a waiting state until a Extension Preview
wait condition is met.

az connectedmachine list List all the Azure Arc-Enabled Servers in Extension GA

the specified resource group.

az connectedmachine private- Manage private endpoint connection Extension GA

endpoint-connection with an Azure Arc-Enabled Server.

az connectedmachine private- Delete a private endpoint connection Extension GA

endpoint-connection delete with a given name.

az connectedmachine private- List all private endpoint connections on a Extension GA

endpoint-connection list private link scope.

az connectedmachine private- Get a private endpoint connection. Extension GA

endpoint-connection show

az connectedmachine private- Update a private endpoint connection Extension GA

endpoint-connection update with a given name.
Name Description Type Status

az connectedmachine private- Place the CLI in a waiting state until a Extension GA

endpoint-connection wait condition is met.

az connectedmachine private- Manage private link resource of an Azure Extension GA

link-resource Arc-Enabled Server.

az connectedmachine private- List the private link resources that need Extension GA
link-resource list to be created for an Azure Monitor
PrivateLinkScope.

az connectedmachine private- Get the private link resources that need Extension GA
link-resource show to be created for an Azure Monitor
PrivateLinkScope.

az connectedmachine private- Private link scope. Extension GA

link-scope

az connectedmachine private- Create an Azure Arc PrivateLinkScope. Extension GA

link-scope create Note: You cannot specify a different
value for InstrumentationKey nor AppId
in the Put operation.

az connectedmachine private- Delete an Azure Arc PrivateLinkScope. Extension GA

link-scope delete

az connectedmachine private- Get a list of Azure Arc PrivateLinkScopes Extension GA

link-scope list within a resource group and get a list of
all Azure Arc PrivateLinkScopes within a
subscription.

az connectedmachine private- Network-security-perimeter- Extension GA

link-scope network-security- configuration.
perimeter-configuration

az connectedmachine private- List the network security perimeter Extension GA

link-scope network-security- configurations for a private link scope.
perimeter-configuration list

az connectedmachine private- Get the network security perimeter Extension GA

link-scope network-security- configuration for a private link scope.
perimeter-configuration show

az connectedmachine private- Return an Azure Arc PrivateLinkScope. Extension GA

link-scope show

az connectedmachine private- Update an Azure Arc PrivateLinkScope. Extension GA

link-scope update Note: You cannot specify a different
value for InstrumentationKey nor AppId
in the Put operation.
 Name Description Type Status

az connectedmachine private- Update an existing PrivateLinkScope's Extension GA

link-scope update-tag tags. To update other fields use the
CreateOrUpdate method.

az connectedmachine private- Place the CLI in a waiting state until a Extension GA

link-scope wait condition is met.

az connectedmachine run- Manage run commands on an Azure Arc- Extension Preview

command Enabled Server.

az connectedmachine run- Create operation to create or update a Extension Preview

command create run command.

az connectedmachine run- Delete operation to delete a run Extension Preview

command delete command.

az connectedmachine run- List operation to get all the run Extension Preview
command list commands of a non-Azure machine.

az connectedmachine run- Get operation to get a run command. Extension Preview

command show

az connectedmachine run- Update operation to create or update a Extension Preview

command update run command.

az connectedmachine run- Place the CLI in a waiting state until a Extension Preview
command wait condition is met.

az connectedmachine show Get information about the model view or Extension GA

the instance view of an Azure Arc-
Enabled Server.

az connectedmachine update Update an Azure Arc-Enabled Server. Extension GA

Please note some properties can be set
only during machine creation.

az connectedmachine upgrade- The operation to upgrade Machine Extension GA

extension Extensions.

az connectedmachine assess-patches

Assess patches on an Azure Arc-Enabled Server.

Azure CLI
 az connectedmachine assess-patches [--ids]
[--name]
[--no-wait {0, 1, f, false, n, no, t,
true, y, yes}]
[--resource-group]
[--subscription]

Examples
Sample command for assess-patches

Azure CLI

az connectedmachine assess-patches --resource-group MyResourceGroup --name

MyMachine

Optional Parameters

--ids

One or more resource IDs (space-delimited). It should be a complete resource ID

containing all information of 'Resource Id' arguments. You should provide either --
ids or other 'Resource Id' arguments.

--name -n

The name of the hybrid machine.

--no-wait

Do not wait for the long-running operation to finish.

Accepted values: 0, 1, f, false, n, no, t, true, y, yes

--resource-group -g

Name of resource group. You can configure the default group using az configure --
defaults group=<name> .

--subscription
 Name or ID of subscription. You can configure the default subscription using az
account set -s NAME_OR_ID .

Global Parameters

--debug

Increase logging verbosity to show all debug logs.

--help -h

Show this help message and exit.

--only-show-errors

Only show errors, suppressing warnings.

--output -o

Output format.
Accepted values: json, jsonc, none, table, tsv, yaml, yamlc
Default value: json

--query

JMESPath query string. See http://jmespath.org/ for more information and

examples.

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--verbose

Increase logging verbosity. Use --debug for full debug logs.

az connectedmachine delete

Delete operation to delete an Azure Arc-Enabled Server.

 Azure CLI

az connectedmachine delete [--ids]

[--machine-name]
[--resource-group]
[--subscription]
[--yes]

Examples
Sample command for delete

Azure CLI

az connectedmachine delete --name myMachine --resource-group myResourceGroup

Optional Parameters

--ids

One or more resource IDs (space-delimited). It should be a complete resource ID

containing all information of 'Resource Id' arguments. You should provide either --
ids or other 'Resource Id' arguments.

--machine-name --name -n

The name of the hybrid machine.

--resource-group -g

Name of resource group. You can configure the default group using az configure --
defaults group=<name> .

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--yes -y

Do not prompt for confirmation.

Default value: False
 Global Parameters

--debug

Increase logging verbosity to show all debug logs.

--help -h

Show this help message and exit.

--only-show-errors

Only show errors, suppressing warnings.

--output -o

Output format.
Accepted values: json, jsonc, none, table, tsv, yaml, yamlc
Default value: json

--query

JMESPath query string. See http://jmespath.org/ for more information and

examples.

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--verbose

Increase logging verbosity. Use --debug for full debug logs.

az connectedmachine install-patches

Install patches on an Azure Arc-Enabled Server.

Azure CLI

az connectedmachine install-patches --maximum-duration

--reboot-setting {Always, IfRequired,
 Never}
[--ids]
[--linux-parameters]
[--name]
[--no-wait {0, 1, f, false, n, no, t,
true, y, yes}]
[--resource-group]
[--subscription]
[--windows-parameters]

Examples
Sample command for install-patches

Azure CLI

az connectedmachine install-patches --resource-group MyResourceGroup --name

MyMachine --maximum-duration PT4H --reboot-setting IfRequired --windows-
parameters "{"classificationsToInclude": ["Critical", "Security"]}"

Required Parameters

--maximum-duration

Specifies the maximum amount of time that the operation will run. It must be an ISO
8601-compliant duration string such as PT4H (4 hours).

--reboot-setting

Defines when it is acceptable to reboot a VM during a software update operation.

Accepted values: Always, IfRequired, Never

Optional Parameters

--ids

One or more resource IDs (space-delimited). It should be a complete resource ID

containing all information of 'Resource Id' arguments. You should provide either --
ids or other 'Resource Id' arguments.

--linux-parameters
 Input for InstallPatches on a Linux VM, as directly received by the API Support
shorthand-syntax, json-file and yaml-file. Try "??" to show more.

--name -n

The name of the hybrid machine.

--no-wait

Do not wait for the long-running operation to finish.

Accepted values: 0, 1, f, false, n, no, t, true, y, yes

--resource-group -g

Name of resource group. You can configure the default group using az configure --
defaults group=<name> .

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--windows-parameters

Input for InstallPatches on a Windows VM, as directly received by the API Support
shorthand-syntax, json-file and yaml-file. Try "??" to show more.

Global Parameters

--debug

Increase logging verbosity to show all debug logs.

--help -h

Show this help message and exit.

--only-show-errors

Only show errors, suppressing warnings.

--output -o

Output format.
 Accepted values: json, jsonc, none, table, tsv, yaml, yamlc
Default value: json

--query

JMESPath query string. See http://jmespath.org/ for more information and

examples.

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--verbose

Increase logging verbosity. Use --debug for full debug logs.

az connectedmachine list

List all the Azure Arc-Enabled Servers in the specified resource group.

Azure CLI

az connectedmachine list --resource-group

[--expand]
[--max-items]
[--next-token]

Examples
Sample command for list

Azure CLI

az connectedmachine list --resource-group myResourceGroup

az connectedmachine list

Required Parameters
--resource-group -g

Name of resource group. You can configure the default group using az configure --
defaults group=<name> .

Optional Parameters

--expand

Expands referenced resources.

--max-items

Total number of items to return in the command's output. If the total number of
items available is more than the value specified, a token is provided in the
command's output. To resume pagination, provide the token value in --next-token
argument of a subsequent command.

--next-token

Token to specify where to start paginating. This is the token value from a previously
truncated response.

Global Parameters

--debug

Increase logging verbosity to show all debug logs.

--help -h

Show this help message and exit.

--only-show-errors

Only show errors, suppressing warnings.

--output -o

Output format.
Accepted values: json, jsonc, none, table, tsv, yaml, yamlc
Default value: json
--query

JMESPath query string. See http://jmespath.org/ for more information and

examples.

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--verbose

Increase logging verbosity. Use --debug for full debug logs.

az connectedmachine show

Get information about the model view or the instance view of an Azure Arc-Enabled
Server.

Azure CLI

az connectedmachine show [--expand {instanceView}]

[--ids]
[--machine-name]
[--resource-group]
[--subscription]

Examples
Sample command for show

Azure CLI

az connectedmachine show --name myMachine --resource-group myResourceGroup

Optional Parameters

--expand
 The expand expression to apply on the operation.
Accepted values: instanceView

--ids

One or more resource IDs (space-delimited). It should be a complete resource ID

containing all information of 'Resource Id' arguments. You should provide either --
ids or other 'Resource Id' arguments.

--machine-name --name -n

The name of the hybrid machine.

--resource-group -g

Name of resource group. You can configure the default group using az configure --
defaults group=<name> .

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

Global Parameters

--debug

Increase logging verbosity to show all debug logs.

--help -h

Show this help message and exit.

--only-show-errors

Only show errors, suppressing warnings.

--output -o

Output format.
Accepted values: json, jsonc, none, table, tsv, yaml, yamlc
Default value: json
--query

JMESPath query string. See http://jmespath.org/ for more information and

examples.

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--verbose

Increase logging verbosity. Use --debug for full debug logs.

az connectedmachine update

Update an Azure Arc-Enabled Server. Please note some properties can be set only
during machine creation.

Azure CLI

az connectedmachine update [--add]

[--agent-upgrade]
[--client-public-key]
[--expand {instanceView}]
[--extensions]
[--force-string {0, 1, f, false, n, no, t, true,
y, yes}]
[--identity]
[--ids]
[--kind {AVS, AWS, EPS, GCP, HCI, SCVMM, VMware}]
[--license-profile]
[--location-data]
[--machine-name]
[--mssql-discovered]
[--os-profile]
[--os-type]
[--parent-cluster-id]
[--private-link-scope-resource-id]
[--remove]
[--resource-group]
[--service-statuses]
[--set]
[--subscription]
[--tags]
Examples
Sample command for update

Azure CLI

az connectedmachine update --name myMachine --resource-group myResourceGroup

--location eastus2euap

Optional Parameters

--add

Add an object to a list of objects by specifying a path and key value pairs. Example: -
-add property.listProperty <key=value, string or JSON string>.

--agent-upgrade

The info of the machine w.r.t Agent Upgrade Support shorthand-syntax, json-file and
yaml-file. Try "??" to show more.

--client-public-key

Public Key that the client provides to be used during initial resource onboarding.

--expand

The expand expression to apply on the operation.

Accepted values: instanceView

--extensions

Machine Extensions information (deprecated field) Support shorthand-syntax, json-

file and yaml-file. Try "??" to show more.

--force-string

When using 'set' or 'add', preserve string literals instead of attempting to convert to
JSON.
Accepted values: 0, 1, f, false, n, no, t, true, y, yes

--identity
 Identity for the resource. Support shorthand-syntax, json-file and yaml-file. Try "??"
to show more.

--ids

One or more resource IDs (space-delimited). It should be a complete resource ID

containing all information of 'Resource Id' arguments. You should provide either --
ids or other 'Resource Id' arguments.

--kind

Indicates which kind of Arc machine placement on-premises, such as HCI, SCVMM or
VMware etc.
Accepted values: AVS, AWS, EPS, GCP, HCI, SCVMM, VMware

--license-profile

Specifies the License related properties for a machine. Support shorthand-syntax,

json-file and yaml-file. Try "??" to show more.

--location-data

Metadata pertaining to the geographic location of the resource. Support shorthand-

syntax, json-file and yaml-file. Try "??" to show more.

--machine-name --name -n

The name of the hybrid machine.

--mssql-discovered

Specifies whether any MS SQL instance is discovered on the machine.

--os-profile

Specifies the operating system settings for the hybrid machine. Support shorthand-
syntax, json-file and yaml-file. Try "??" to show more.

--os-type

The type of Operating System (windows/linux).

--parent-cluster-id --parent-cluster-resource-id
 The resource id of the parent cluster (Azure HCI) this machine is assigned to, if any.

--private-link-scope-resource-id --scope-id

The resource id of the private link scope this machine is assigned to, if any.

--remove

Remove a property or an element from a list. Example: --remove property.list OR --

remove propertyToRemove.

--resource-group -g

Name of resource group. You can configure the default group using az configure --
defaults group=<name> .

--service-statuses

Statuses of dependent services that are reported back to ARM. Support shorthand-
syntax, json-file and yaml-file. Try "??" to show more.

--set

Update an object by specifying a property path and value to set. Example: --set
property1.property2=.

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--tags

Resource tags. Support shorthand-syntax, json-file and yaml-file. Try "??" to show
more.

Global Parameters

--debug

Increase logging verbosity to show all debug logs.

--help -h
 Show this help message and exit.

--only-show-errors

Only show errors, suppressing warnings.

--output -o

Output format.
Accepted values: json, jsonc, none, table, tsv, yaml, yamlc
Default value: json

--query

JMESPath query string. See http://jmespath.org/ for more information and

examples.

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--verbose

Increase logging verbosity. Use --debug for full debug logs.

az connectedmachine upgrade-extension

The operation to upgrade Machine Extensions.

Azure CLI

az connectedmachine upgrade-extension [--extension-targets]

[--ids]
[--machine-name]
[--no-wait {0, 1, f, false, n, no, t,
true, y, yes}]
[--resource-group]
[--subscription]

Examples
Sample command for extension upgrade

Azure CLI

az connectedmachine extension upgrade --machine-name "myMachineName" --

resource-group "myResourceGroup" --subscription "mySubscription" --targets "
{"Microsoft.Compute.CustomScriptExtension": "{"targetVersion": "1.10"}",
"Microsoft.Azure.Monitoring": "{"targetVersion": "2.0"}"}"

Optional Parameters

--extension-targets

Describes the Extension Target Properties. Support shorthand-syntax, json-file and

yaml-file. Try "??" to show more.

--ids

One or more resource IDs (space-delimited). It should be a complete resource ID

containing all information of 'Resource Id' arguments. You should provide either --
ids or other 'Resource Id' arguments.

--machine-name

The name of the hybrid machine.

--no-wait

Do not wait for the long-running operation to finish.

Accepted values: 0, 1, f, false, n, no, t, true, y, yes

--resource-group -g

Name of resource group. You can configure the default group using az configure --
defaults group=<name> .

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

Global Parameters
--debug

Increase logging verbosity to show all debug logs.

--help -h

Show this help message and exit.

--only-show-errors

Only show errors, suppressing warnings.

--output -o

Output format.
Accepted values: json, jsonc, none, table, tsv, yaml, yamlc
Default value: json

--query

JMESPath query string. See http://jmespath.org/ for more information and

examples.

--subscription

Name or ID of subscription. You can configure the default subscription using az

account set -s NAME_OR_ID .

--verbose

Increase logging verbosity. Use --debug for full debug logs.

６ Collaborate with us on
GitHub Azure CLI feedback
Azure CLI is an open source project.
The source for this content can
Select a link to provide feedback:
be found on GitHub, where you
can also create and review
 Open a documentation issue
issues and pull requests. For
more information, see our
 Provide product feedback
contributor guide.
Az.ConnectedMachine
Reference

Microsoft Azure PowerShell: ConnectedMachine cmdlets

Connected Machine
ﾉ Expand table

Connect-AzConnectedMachine API to register a new machine and

thereby create a tracked resource in ARM

Get-AzConnectedExtensionMetadata Gets an Extension Metadata based on

location, publisher, extensionType and
version

Get-AzConnectedLicense Retrieves information about the view of a

license.

Get-AzConnectedMachine Retrieves information about the model

view or the instance view of a hybrid
machine.

Get-AzConnectedMachineExtension The operation to get the extension.

Get-AzConnectedMachineRunCommand The operation to get a run command.

Get- Gets the network security perimeter

AzConnectedNetworkSecurityPerimeterConfiguration configuration for a private link scope.

Get-AzConnectedPrivateLinkScope Returns a Azure Arc PrivateLinkScope.

Install-AzConnectedMachinePatch The operation to install patches on a

hybrid machine identity in Azure.

Invoke-AzConnectedAssessMachinePatch The operation to assess patches on a

hybrid machine identity in Azure.

New-AzConnectedLicense The operation to create or update a

license.

New-AzConnectedLicenseDetail Create an in-memory object for

LicenseDetails.

New-AzConnectedMachineExtension The operation to create or update the

extension.
New-AzConnectedMachineRunCommand The operation to create or update a run
command.

New-AzConnectedPrivateLinkScope Create (or updates) a Azure Arc

PrivateLinkScope. Note: You cannot
specify a different value for
InstrumentationKey nor AppId in the Put
operation.

Remove-AzConnectedLicense The operation to delete a license.

Remove-AzConnectedMachine The operation to delete a hybrid

machine.

Remove-AzConnectedMachineExtension The operation to delete the extension.

Remove-AzConnectedMachineRunCommand The operation to delete a run command.

Remove-AzConnectedPrivateLinkScope Deletes a Azure Arc PrivateLinkScope.

Set-AzConnectedLicense The operation to create or update a

license.

Set-AzConnectedMachineExtension The operation to create or update the

extension.

Set-AzConnectedPrivateLinkScope Update (or updates) a Azure Arc

PrivateLinkScope. Note: You cannot
specify a different value for
InstrumentationKey nor AppId in the Put
operation.

Update-AzConnectedExtension The operation to Upgrade Machine

Extensions.

Update-AzConnectedMachine The operation to update a hybrid

machine.

Update-AzConnectedMachineExtension The operation to create or update the

extension.

Update-AzConnectedMachineRunCommand The operation to create or update a run

command.

Update-AzConnectedPrivateLinkScopeTag Update an existing PrivateLinkScope's

tags. To update other fields use the
CreateOrUpdate method.
６ Collaborate with us on Azure PowerShell feedback
GitHub
Azure PowerShell is an open source
The source for this content can project. Select a link to provide
be found on GitHub, where you feedback:
can also create and review
issues and pull requests. For  Open a documentation issue
more information, see our
contributor guide.  Provide product feedback
HybridComputeManagementClient.Api
Version Property
Reference

Definition
Namespace: Microsoft.Azure.Management.HybridCompute
Assembly: Microsoft.Azure.Management.HybridCompute.dll
Package: Microsoft.Azure.Management.HybridCompute v0.1.0-preview.2

Client Api Version.

C#

public string ApiVersion { get; }

Property Value
String

Applies to
Product Versions

Azure SDK for .NET Legacy

６ Collaborate with us on Azure SDK for .NET

GitHub feedback
The source for this content can Azure SDK for .NET is an open
be found on GitHub, where you source project. Select a link to
can also create and review provide feedback:
issues and pull requests. For
more information, see our  Open a documentation issue
contributor guide.
 Provide product feedback
Azure Stack HCI REST API reference
Article • 10/31/2023

Azure Stack HCI is a hyperconverged cluster that uses validated hardware to run
virtualized workloads on-premises, making it easy for customers to consolidate aging
infrastructure and connect to Azure for cloud services. For a more detailed overview, see
the Azure Stack HCI product page .

See Also
Azure Stack HCI documentation
Hybrid Compute
Article • 10/31/2023

Azure Arc enables you to manage servers running outside of Azure using Azure
Resource Manager. Each server is represented in Azure as a hybrid compute machine
resource. Once a server is managed with Azure Arc, you can deploy agents, scripts, or
configurations to the machine using extensions. The Hybrid Compute API allows you to
create, list, update and delete your Azure Arc enabled servers and any extensions
associated with them.

See Also
Azure Arc enabled servers documentation
com.azure.resourcemanager.compute
Reference
Package: com.azure.resourcemanager.compute
Maven Artifact: com.azure.resourcemanager:azure-resourcemanager-compute:2.40.0

Package containing the classes for ComputeManagementClient. Compute Client.

Classes
ﾉ Expand table

ComputeManager Entry point to Azure compute resource management.

Interfaces
ﾉ Expand table

ComputeManager.Configurable The interface allowing configurations to be set.

６ Collaborate with us on
Azure SDK for Java feedback
GitHub
Azure SDK for Java is an open source
The source for this content can project. Select a link to provide
be found on GitHub, where you feedback:
can also create and review
issues and pull requests. For  Open a documentation issue
more information, see our
contributor guide.  Provide product feedback
@azure/arm-hybridcompute package
Reference

Classes
ﾉ Expand table

HybridComputeManagementClient

Interfaces
ﾉ Expand table

ConnectionDetail

ErrorAdditionalInfo The resource management error additional info.

ErrorDetail The error detail.

ErrorResponse Common error response for all Azure Resource Manager APIs to
return error details for failed operations. (This also follows the
OData error response format.).

ExtensionTargetProperties Describes the Machine Extension Target Version Properties

HybridComputeManagement Optional parameters.

ClientOptionalParams

HybridComputePrivateLink Describes the list of Azure Arc PrivateLinkScope resources.

ScopeListResult

HybridComputePrivateLink Properties that define a Azure Arc PrivateLinkScope resource.

ScopeProperties

Identity Identity for the resource.

LocationData Metadata pertaining to the geographic location of the resource.

MachineExtensionInstance Describes the Machine Extension Instance View.

View

MachineExtensionInstance Instance view status.

ViewStatus

MachineExtensionProperties Describes the properties of a Machine Extension.

MachineExtensionUpdate Describes the properties of a Machine Extension.
Properties

MachineExtensionUpgrade Describes the Machine Extension Upgrade Properties

MachineExtensions Interface representing a MachineExtensions.

MachineExtensionsCreate Optional parameters.

OrUpdateOptionalParams

MachineExtensionsDelete Optional parameters.

OptionalParams

MachineExtensionsGet Optional parameters.

OptionalParams

MachineExtensionsListNext Optional parameters.

OptionalParams

MachineExtensionsList Optional parameters.

OptionalParams

MachineExtensionsListResult Describes the Machine Extensions List Result.

MachineExtensionsUpdate Optional parameters.

OptionalParams

MachineListResult The List hybrid machine operation response.

MachineProperties Describes the properties of a hybrid machine.

MachineUpdateProperties Describes the ARM updatable properties of a hybrid machine.

Machines Interface representing a Machines.

MachinesDeleteOptional Optional parameters.

Params

MachinesGetOptionalParams Optional parameters.

MachinesListByResourceGroup Optional parameters.

NextOptionalParams

MachinesListByResourceGroup Optional parameters.

OptionalParams

MachinesListBySubscription Optional parameters.

NextOptionalParams

MachinesListBySubscription Optional parameters.

OptionalParams

OSProfile Specifies the operating system settings for the hybrid machine.
OperationListResult The List Compute Operation operation response.

OperationValue Describes the properties of a Compute Operation value.

OperationValueDisplay Describes the properties of a Hybrid Compute Operation Value

Display.

Operations Interface representing a Operations.

OperationsListOptionalParams Optional parameters.

PrivateEndpointConnectionList A list of private endpoint connections.

Result

PrivateEndpointConnection Properties of a private endpoint connection.

Properties

PrivateEndpointConnections Interface representing a PrivateEndpointConnections.

PrivateEndpointConnections Optional parameters.

CreateOrUpdateOptional
Params

PrivateEndpointConnections Optional parameters.

DeleteOptionalParams

PrivateEndpointConnections Optional parameters.

GetOptionalParams

PrivateEndpointConnections Optional parameters.

ListByPrivateLinkScopeNext
OptionalParams

PrivateEndpointConnections Optional parameters.

ListByPrivateLinkScope
OptionalParams

PrivateEndpointProperty Private endpoint which the connection belongs to.

PrivateLinkResourceListResult A list of private link resources

PrivateLinkResourceProperties Properties of a private link resource.

PrivateLinkResources Interface representing a PrivateLinkResources.

PrivateLinkResourcesGet Optional parameters.

OptionalParams

PrivateLinkResourcesList Optional parameters.

ByPrivateLinkScopeNext
OptionalParams
PrivateLinkResourcesList Optional parameters.
ByPrivateLinkScopeOptional
Params

PrivateLinkScopeValidationDetails

PrivateLinkScopes Interface representing a PrivateLinkScopes.

PrivateLinkScopesCreate Optional parameters.

OrUpdateOptionalParams

PrivateLinkScopesDelete Optional parameters.

OptionalParams

PrivateLinkScopesGetOptional Optional parameters.

Params

PrivateLinkScopesGet Optional parameters.

ValidationDetailsForMachine
OptionalParams

PrivateLinkScopesGet Optional parameters.

ValidationDetailsOptional
Params

PrivateLinkScopesList Optional parameters.

ByResourceGroupNext
OptionalParams

PrivateLinkScopesList Optional parameters.

ByResourceGroupOptional
Params

PrivateLinkScopesListNext Optional parameters.

OptionalParams

PrivateLinkScopesListOptional Optional parameters.

Params

PrivateLinkScopesResource An azure resource object

PrivateLinkScopesUpdateTags Optional parameters.

OptionalParams

PrivateLinkServiceConnection State of the private endpoint connection.

StateProperty

Resource Common fields that are returned in the response for all Azure
Resource Manager resources

ResourceUpdate The Update Resource model definition.

SystemData Metadata pertaining to creation and last modification of the
resource.

TagsResource A container holding only the Tags for a resource, allowing the
user to update the tags on a PrivateLinkScope instance.

UpgradeExtensionsOptional Optional parameters.

Params

Type Aliases
ﾉ Expand table

CreatedByType Defines values for CreatedByType.

KnownCreatedByType can be used interchangeably with
CreatedByType, this enum contains the known values that the
service supports.

Known values supported by the

service
User
Application
ManagedIdentity
Key

HybridComputePrivateLink An Azure Arc PrivateLinkScope definition.

Scope

InstanceViewTypes Defines values for InstanceViewTypes.

KnownInstanceViewTypes can be used interchangeably with
InstanceViewTypes, this enum contains the known values that the
service supports.

Known values supported by the

service
instanceView

Machine Describes a hybrid machine.

MachineExtension Describes a Machine Extension.

MachineExtensionUpdate Describes a Machine Extension Update.

MachineExtensionsCreate Contains response data for the createOrUpdate operation.
OrUpdateResponse

MachineExtensionsGet Contains response data for the get operation.

Response

MachineExtensionsListNext Contains response data for the listNext operation.

Response

MachineExtensionsList Contains response data for the list operation.

Response

MachineExtensionsUpdate Contains response data for the update operation.

Response

MachineUpdate Describes a hybrid machine Update.

MachinesGetResponse Contains response data for the get operation.

MachinesListByResource Contains response data for the listByResourceGroupNext

GroupNextResponse operation.

MachinesListByResource Contains response data for the listByResourceGroup operation.

GroupResponse

MachinesListBySubscription Contains response data for the listBySubscriptionNext operation.

NextResponse

MachinesListBySubscription Contains response data for the listBySubscription operation.

Response

OperationsListResponse Contains response data for the list operation.

PrivateEndpointConnection A private endpoint connection

PrivateEndpointConnections Contains response data for the createOrUpdate operation.

CreateOrUpdateResponse

PrivateEndpointConnections Contains response data for the get operation.

GetResponse

PrivateEndpointConnections Contains response data for the listByPrivateLinkScopeNext

ListByPrivateLinkScopeNext operation.
Response

PrivateEndpointConnections Contains response data for the listByPrivateLinkScope operation.

ListByPrivateLinkScope
Response

PrivateLinkResource A private link resource

PrivateLinkResourcesGet Contains response data for the get operation.

Response

PrivateLinkResourcesList Contains response data for the listByPrivateLinkScopeNext

ByPrivateLinkScopeNext operation.
Response

PrivateLinkResourcesList Contains response data for the listByPrivateLinkScope operation.

ByPrivateLinkScope
Response

PrivateLinkScopesCreate Contains response data for the createOrUpdate operation.

OrUpdateResponse

PrivateLinkScopesGet Contains response data for the get operation.

Response

PrivateLinkScopesGet Contains response data for the getValidationDetailsForMachine

ValidationDetailsForMachine operation.
Response

PrivateLinkScopesGet Contains response data for the getValidationDetails operation.

ValidationDetailsResponse

PrivateLinkScopesList Contains response data for the listByResourceGroupNext

ByResourceGroupNext operation.
Response

PrivateLinkScopesList Contains response data for the listByResourceGroup operation.

ByResourceGroupResponse

PrivateLinkScopesListNext Contains response data for the listNext operation.

Response

PrivateLinkScopesList Contains response data for the list operation.

Response

PrivateLinkScopesUpdate Contains response data for the updateTags operation.

TagsResponse

ProxyResource The resource model definition for a Azure Resource Manager

proxy resource. It will not have tags and a location

PublicNetworkAccessType Defines values for PublicNetworkAccessType.

KnownPublicNetworkAccessType can be used interchangeably with
PublicNetworkAccessType, this enum contains the known values
that the service supports.

Known values supported by the

service
 Enabled: Allows Azure Arc agents to communicate with Azure Arc
services over both public (internet) and private endpoints.
Disabled: Does not allow Azure Arc agents to communicate with
Azure Arc services over public (internet) endpoints. The agents
must use the private link.

StatusLevelTypes Defines values for StatusLevelTypes.

KnownStatusLevelTypes can be used interchangeably with
StatusLevelTypes, this enum contains the known values that the
service supports.

Known values supported by the

service
Info
Warning
Error

StatusTypes Defines values for StatusTypes.

KnownStatusTypes can be used interchangeably with StatusTypes,
this enum contains the known values that the service supports.

Known values supported by the

service
Connected
Disconnected
Error

TrackedResource The resource model definition for an Azure Resource Manager

tracked top level resource which has 'tags' and a 'location'

Enums
ﾉ Expand table

KnownCreatedByType Known values of CreatedByType that the service accepts.

KnownInstanceViewTypes Known values of InstanceViewTypes that the service accepts.

KnownPublicNetworkAccess Known values of PublicNetworkAccessType that the service

Type accepts.

KnownStatusLevelTypes Known values of StatusLevelTypes that the service accepts.

KnownStatusTypes Known values of StatusTypes that the service accepts.

Azure Policy built-in definitions for Azure Arc-
enabled servers
Article • 02/06/2024

This page is an index of Azure Policy built-in policy definitions for Azure Arc-enabled servers. For additional
Azure Policy built-ins for other services, see Azure Policy built-in definitions.

The name of each built-in policy definition links to the policy definition in the Azure portal. Use the link in the
Version column to view the source on the Azure Policy GitHub repo .

Azure Arc-enabled servers

ﾉ Expand table

Name Description Effect(s) Version

(Azure portal) (GitHub)

[Preview]: A Resources managed by Automanage should have a managed identity. Audit, Disabled 1.0.0-
managed preview
identity should
be enabled on
your machines

[Preview]: Resources managed by Automanage should have a status of Conformant or AuditIfNotExists, 1.0.0-
Automanage ConformantCorrected. Disabled preview
Configuration
Profile
Assignment
should be
Conformant

[Preview]: Azure Install the Azure Security agent on your Linux Arc machines in order to monitor AuditIfNotExists, 1.0.0-
Security agent your machines for security configurations and vulnerabilities. Results of the Disabled preview
should be assessments can seen and managed in Azure Security Center.
installed on
your Linux Arc
machines

[Preview]: Azure Install the Azure Security agent on your Windows Arc machines in order to AuditIfNotExists, 1.0.0-
Security agent monitor your machines for security configurations and vulnerabilities. Results of Disabled preview
should be the assessments can seen and managed in Azure Security Center.
installed on
your Windows
Arc machines

[Preview]: Install ChangeTracking Extension on Linux Arc machines to enable File Integrity AuditIfNotExists, 1.0.0-
ChangeTracking Monitoring(FIM) in Azure Security Center. FIM examines operating system files, Disabled preview
extension Windows registries, application software, Linux system files, and more, for
should be changes that might indicate an attack. The extension can be installed in virtual
installed on machines and locations supported by Azure Monitoring Agent.
your Linux Arc
machine

[Preview]: Install ChangeTracking Extension on Windows Arc machines to enable File AuditIfNotExists, 1.0.0-
ChangeTracking Integrity Monitoring(FIM) in Azure Security Center. FIM examines operating Disabled preview
extension system files, Windows registries, application software, Linux system files, and
Name Description Effect(s) Version
(Azure portal) (GitHub)

should be more, for changes that might indicate an attack. The extension can be installed
installed on in virtual machines and locations supported by Azure Monitoring Agent.
your Windows
Arc machine

[Preview]: Protect your Azure Arc-enabled Linux machines with Microsoft Defender for DeployIfNotExists, 1.0.0-
Configure Cloud capabilities, by installing Log Analytics agents that send data to a default Disabled preview
Azure Arc- Log Analytics workspace created by Microsoft Defender for Cloud.
enabled Linux
machines with
Log Analytics
agents
connected to
default Log
Analytics
workspace

[Preview]: Protect your Azure Arc-enabled Windows machines with Microsoft Defender for DeployIfNotExists, 1.1.0-
Configure Cloud capabilities, by installing Log Analytics agents that send data to a default Disabled preview
Azure Arc- Log Analytics workspace created by Microsoft Defender for Cloud.
enabled
Windows
machines with
Log Analytics
agents
connected to
default Log
Analytics
workspace

[Preview]: Configure Linux Arc machines to automatically install the ChangeTracking DeployIfNotExists, 2.0.0-
Configure Extension to enable File Integrity Monitoring(FIM) in Azure Security Center. FIM Disabled preview
ChangeTracking examines operating system files, Windows registries, application software, Linux
Extension for system files, and more, for changes that might indicate an attack. The extension
Linux Arc can be installed in virtual machines and locations supported by Azure Monitor
machines Agent.

[Preview]: Configure Windows Arc machines to automatically install the ChangeTracking DeployIfNotExists, 2.0.0-
Configure Extension to enable File Integrity Monitoring(FIM) in Azure Security Center. FIM Disabled preview
ChangeTracking examines operating system files, Windows registries, application software, Linux
Extension for system files, and more, for changes that might indicate an attack. The extension
Windows Arc can be installed in virtual machines and locations supported by Azure Monitor
machines Agent.

[Preview]: Deploy Association to link Linux Arc-enabled machines to specified Data DeployIfNotExists, 1.0.0-
Configure Linux Collection Rule to enable ChangeTracking and Inventory. The list of locations Disabled preview
Arc-enabled are updated over time as support is increased.
machines to be
associated with
a Data
Collection Rule
for
ChangeTracking
and Inventory

[Preview]: Automate the deployment of Azure Monitor Agent extension on your Linux DeployIfNotExists, 1.2.0-
Configure Linux Arc-enabled machines for enabling ChangeTracking and Inventory. This policy Disabled preview
Arc-enabled will install the extension if the region is supported. Learn more:
machines to https://aka.ms/AMAOverview .
Name Description Effect(s) Version
(Azure portal) (GitHub)

install AMA for

ChangeTracking
and Inventory

[Preview]: Configure supported Linux Arc machines to automatically install the Azure DeployIfNotExists, 1.0.0-
Configure Security agent. Security Center collects events from the agent and uses them to Disabled preview
supported Linux provide security alerts and tailored hardening tasks (recommendations). Target
Arc machines to Linux Arc machines must be in a supported location.
automatically
install the Azure
Security agent

[Preview]: Configure supported Windows Arc machines to automatically install the Azure DeployIfNotExists, 1.0.0-
Configure Security agent. Security Center collects events from the agent and uses them to Disabled preview
supported provide security alerts and tailored hardening tasks (recommendations). Target
Windows Arc Windows Arc machines must be in a supported location.
machines to
automatically
install the Azure
Security agent

[Preview]: Deploy Association to link Windows Arc-enabled machines to specified Data DeployIfNotExists, 1.0.0-
Configure Collection Rule to enable ChangeTracking and Inventory. The list of locations Disabled preview
Windows Arc- are updated over time as support is increased.
enabled
machines to be
associated with
a Data
Collection Rule
for
ChangeTracking
and Inventory

[Preview]: Automate the deployment of Azure Monitor Agent extension on your Windows DeployIfNotExists, 1.0.0-
Configure Arc-enabled machines for enabling ChangeTracking and Inventory. This policy Disabled preview
Windows Arc- will install the extension if the OS and region are supported and system-
enabled assigned managed identity is enabled, and skip install otherwise. Learn more:
machines to https://aka.ms/AMAOverview .
install AMA for
ChangeTracking
and Inventory

[Preview]: Creates a Guest Configuration assignment to configure disabling local users on DeployIfNotExists, 1.2.0-
Configure Windows Server. This ensures that Windows Servers can only be accessed by Disabled preview
Windows Server AAD (Azure Active Directory) account or a list of explicitly allowed users by this
to disable local policy, improving overall security posture.
users.

[Preview]: Deny This policy enables you to restrict the creation or modification of ESU licenses Deny, Disabled 1.0.0-
Extended for Windows Server 2012 Arc machines. For more details on pricing please visit preview
Security https://aka.ms/ArcWS2012ESUPricing
Updates (ESUs)
license creation
or modification.

[Preview]: Deploys Microsoft Defender for Endpoint agent on Linux hybrid machines DeployIfNotExists, 2.0.1-
Deploy AuditIfNotExists, preview
Microsoft Disabled
Defender for
Name Description Effect(s) Version
(Azure portal) (GitHub)

Endpoint agent
on Linux hybrid
machines

[Preview]: Deploys Microsoft Defender for Endpoint on Windows Azure Arc machines. DeployIfNotExists, 2.0.1-
Deploy AuditIfNotExists, preview
Microsoft Disabled
Defender for
Endpoint agent
on Windows
Azure Arc
machines

[Preview]: Enable Extended Security Updates (ESUs) license to keep Windows 2012 DeployIfNotExists, 1.0.0-
Enable machines protected even after their support lifecycle has ended. Learn How to Disabled preview
Extended prepare to deliver Extended Security Updates for Windows Server 2012 through
Security AzureArc please visit https://learn.microsoft.com/en-us/azure/azure-
Updates (ESUs) arc/servers/prepare-extended-security-updates. For more details on pricing
license to keep please visit https://aka.ms/ArcWS2012ESUPricing
Windows 2012
machines
protected after
their support
lifecycle has
ended.

[Preview]: Windows Server 2012 Arc machines should have installed all the Extended AuditIfNotExists, 1.0.0-
Extended Security Updates released by Microsoft. This policy requires that the Guest Disabled preview
Security Configuration prerequisites have been deployed to the policy assignment
Updates should scope. For details, visit https://aka.ms/gcpol
be installed on
Windows Server
2012 Arc
machines.

[Preview]: Linux Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 1.2.0-
machines details, visit https://aka.ms/gcpol . The machine is not configured correctly for Disabled preview
should meet one of the recommendations in the Azure security baseline for Docker hosts.
requirements
for the Azure
security
baseline for
Docker hosts

[Preview]: Linux Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 1.2.0-
machines details, visit https://aka.ms/gcpol . Machines are non-compliant if the machine Disabled preview
should meet is not configured correctly for one of the recommendations in STIG compliance
STIG requirement for Azure compute. DISA (Defense Information Systems Agency)
compliance provides technical guides STIG (Security Technical Implementation Guide) to
requirement for secure compute OS as required by Department of Defense (DoD). For more
Azure compute details, https://public.cyber.mil/stigs/ .

[Preview]: Linux Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 1.2.0-
machines with details, visit https://aka.ms/gcpol . Due to a security fix included in version Disabled preview
OMI installed 1.6.8-1 of the OMI package for Linux, all machines should be updated to the
should have latest release. Upgrade apps/packages that use OMI to resolve the issue. For
version 1.6.8-1 more information, see https://aka.ms/omiguidance .
or later
Name Description Effect(s) Version
(Azure portal) (GitHub)

[Preview]: Log This policy audits Linux Azure Arc machines if the Log Analytics extension is not AuditIfNotExists, 1.0.1-
Analytics installed. Disabled preview
extension
should be
installed on
your Linux
Azure Arc
machines

[Preview]: Log This policy audits Windows Azure Arc machines if the Log Analytics extension is AuditIfNotExists, 1.0.1-
Analytics not installed. Disabled preview
extension
should be
installed on
your Windows
Azure Arc
machines

[Preview]: Utilizes the Azure Policy Guest Configuration agent for auditing. This policy AuditIfNotExists, 1.1.0-
Nexus Compute ensures that machines adhere to the Nexus compute security baseline, Disabled preview
Machines encompassing various recommendations designed to fortify machines against a
should meet range of vulnerabilities and unsafe configurations (Linux only).
Security
Baseline

[Preview]: Your machines are missing system, security, and critical updates. Software AuditIfNotExists, 1.0.0-
System updates updates often include critical patches to security holes. Such holes are Disabled preview
should be frequently exploited in malware attacks so it's vital to keep your software
installed on updated. To install all outstanding patches and secure your machines, follow
your machines the remediation steps.
(powered by
Update Center)

[Preview]: Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 1.0.0-
Windows details, visit https://aka.ms/gcpol . Machines are non-compliant if the machine Disabled preview
machines is not configured correctly for one of the recommendations in STIG compliance
should meet requirements for Azure compute. DISA (Defense Information Systems Agency)
STIG provides technical guides STIG (Security Technical Implementation Guide) to
compliance secure compute OS as required by Department of Defense (DoD). For more
requirements details, https://public.cyber.mil/stigs/ .
for Azure
compute

Audit Linux Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 3.1.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if Linux Disabled
allow remote machines that allow remote connections from accounts without passwords
connections
from accounts
without
passwords

Audit Linux Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 3.1.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if Linux Disabled
do not have the machines that do not have the passwd file permissions set to 0644
passwd file
permissions set
to 0644
Name Description Effect(s) Version
(Azure portal) (GitHub)

Audit Linux Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 4.2.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the Chef Disabled
don't have the InSpec resource indicates that one or more of the packages provided by the
specified parameter are not installed.
applications
installed

Audit Linux Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 3.1.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if Linux Disabled
have accounts machines that have accounts without passwords
without
passwords

Audit Linux Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 4.2.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the Chef Disabled
have the InSpec resource indicates that one or more of the packages provided by the
specified parameter are installed.
applications
installed

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines details, visit https://aka.ms/gcpol . Machines are non-compliant if the local
missing any of Administrators group does not contain one or more members that are listed in
specified the policy parameter.
members in the
Administrators
group

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines details, visit https://aka.ms/gcpol . Machines are non-compliant if a network
network connection status to an IP and TCP port does not match the policy parameter.
connectivity

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 3.0.0
machines on details, visit https://aka.ms/gcpol . Machines are non-compliant if the
which the DSC Windows PowerShell command Get-DSCConfigurationStatus returns that the
configuration is DSC configuration for the machine is not compliant.
not compliant

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines on details, visit https://aka.ms/gcpol . Machines are non-compliant if the agent is
which the Log not installed, or if it is installed but the COM object
Analytics agent AgentConfigManager.MgmtSvcCfg returns that it is registered to a workspace
is not other than the ID specified in the policy parameter.
connected as
expected

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 3.0.0
machines on details, visit https://aka.ms/gcpol . Machines are non-compliant if result of the
which the Windows PowerShell command Get-Service do not include the service name
specified with matching status as specified by the policy parameter.
services are not
installed and
'Running'

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 3.0.0
machines on details, visit https://aka.ms/gcpol . Machines are non-compliant if the machine
which Windows does not have the Serial Console software installed or if the EMS port number
or baud rate are not configured with the same values as the policy parameters.
Serial Console
Name Description Effect(s) Version
is not enabled
(Azure portal) (GitHub)

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.1.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if Windows Disabled
allow re-use of machines that allow re-use of the passwords after the specified number of
the passwords unique passwords. Default value for unique passwords is 24
after the
specified
number of
unique
passwords

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the value of
are not joined the Domain property in WMI class win32_computersystem does not match the
to the specified value in the policy parameter.
domain

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 3.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the value of
are not set to the property StandardName in WMI class Win32_TimeZone does not match the
the specified selected time zone for the policy parameter.
time zone

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if certificates
contain in the specified store have an expiration date out of range for the number of
certificates days given as parameter. The policy also provides the option to only check for
expiring within specific certificates or exclude specific certificates, and whether to report on
the specified expired certificates.
number of days

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 3.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the machine
do not contain Trusted Root certificate store (Cert:\LocalMachine\Root) does not contain one
the specified or more of the certificates listed by the policy parameter.
certificates in
Trusted Root

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.1.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if Windows Disabled
do not have the machines that do not have the maximum password age set to specified number
maximum of days. Default value for maximum password age is 70 days
password age
set to specified
number of days

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.1.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if Windows Disabled
do not have the machines that do not have the minimum password age set to specified number
minimum of days. Default value for minimum password age is 1 day
password age
set to specified
number of days

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if Windows Disabled
do not have the machines that do not have the password complexity setting enabled
password
complexity
setting enabled
Name Description Effect(s) Version
(Azure portal) (GitHub)

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 3.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the Disabled
do not have the Windows PowerShell command Get-ExecutionPolicy returns a value other than
specified what was selected in the policy parameter.
Windows
PowerShell
execution policy

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 3.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if a module Disabled
do not have the isn't available in a location specified by the environment variable
specified PSModulePath.
Windows
PowerShell
modules
installed

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.1.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if Windows Disabled
do not restrict machines that do not restrict the minimum password length to specified
the minimum number of characters. Default value for minimum password length is 14
password characters
length to
specified
number of
characters

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if Windows Disabled
do not store machines that do not store passwords using reversible encryption
passwords
using reversible
encryption

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the
don't have the application name is not found in any of the following registry paths:
specified HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall,
applications HKLM:SOFTWARE\Wow6432node\Microsoft\Windows\CurrentVersion\Uninstall,
installed HKCU:Software\Microsoft\Windows\CurrentVersion\Uninstall.

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the local
have extra Administrators group contains members that are not listed in the policy
accounts in the parameter.
Administrators
group

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the WMI
have not property LastBootUpTime in class Win32_Operatingsystem is outside the range
restarted within of days provided by the policy parameter.
the specified
number of days

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the
have the application name is found in any of the following registry paths:
specified HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall,
Name Description Effect(s) Version
(Azure portal) (GitHub)

applications HKLM:SOFTWARE\Wow6432node\Microsoft\Windows\CurrentVersion\Uninstall,
installed HKCU:Software\Microsoft\Windows\CurrentVersion\Uninstall.

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
machines that details, visit https://aka.ms/gcpol . Machines are non-compliant if the local
have the Administrators group contains one or more of the members listed in the policy
specified parameter.
members in the
Administrators
group

Audit Windows Requires that prerequisites are deployed to the policy assignment scope. For auditIfNotExists 2.0.0
VMs with a details, visit https://aka.ms/gcpol . Machines are non-compliant if the machine
pending reboot is pending reboot for any of the following reasons: component based servicing,
Windows Update, pending file rename, pending computer rename,
configuration manager pending reboot. Each detection has a unique registry
path.

Authentication Although SSH itself provides an encrypted connection, using passwords with AuditIfNotExists, 3.2.0
to Linux SSH still leaves the VM vulnerable to brute-force attacks. The most secure Disabled
machines option for authenticating to an Azure Linux virtual machine over SSH is with a
should require public-private key pair, also known as SSH keys. Learn more:
SSH keys https://docs.microsoft.com/azure/virtual-machines/linux/create-ssh-keys-
detailed.

Azure Arc Azure Private Link lets you connect your virtual networks to Azure services Audit, Disabled 1.0.0
Private Link without a public IP address at the source or destination. The Private Link
Scopes should platform handles the connectivity between the consumer and services over the
be configured Azure backbone network. By mapping private endpoints to Azure Arc Private
with a private Link Scopes, data leakage risks are reduced. Learn more about private links at:
endpoint https://aka.ms/arc/privatelink .

Azure Arc Disabling public network access improves security by ensuring that Azure Arc Audit, Deny, 1.0.0
Private Link resources cannot connect via the public internet. Creating private endpoints can Disabled
Scopes should limit exposure of Azure Arc resources. Learn more at:
disable public https://aka.ms/arc/privatelink .
network access

Azure Arc- Azure Private Link lets you connect your virtual networks to Azure services Audit, Deny, 1.0.0
enabled servers without a public IP address at the source or destination. The Private Link Disabled
should be platform handles the connectivity between the consumer and services over the
configured with Azure backbone network. By mapping Azure Arc-enabled servers to an Azure
an Azure Arc Arc Private Link Scope that is configured with a private endpoint, data leakage
Private Link risks are reduced. Learn more about private links at:
Scope https://aka.ms/arc/privatelink .

Configure Arc- To ensure that SQL Server - Azure Arc resources are created by default when DeployIfNotExists, 3.4.0
enabled SQL Server instance is found on Azure Arc enabled Windows/Linux Server, the Disabled
machines latter should have SQL Server extension installed
running SQL
Server to have
SQL Server
extension
installed.

Configure Arc- Enable or disable SQL best practices assessment on the SQL server instances on DeployIfNotExists, 1.0.1
enabled Servers your Arc-enabled servers to evaluate best practices. Learn more at Disabled
with SQL Server https://aka.ms/azureArcBestPracticesAssessment .
extension
Name Description Effect(s) Version
(Azure portal) (GitHub)

installed to
enable or
disable SQL
best practices
assessment.

Configure Arc- Automate the deployment of Azure Monitor Agent extension on your Windows DeployIfNotExists, 1.3.0
enabled SQL Arc-enabled SQL Servers. Learn more: https://aka.ms/AMAOverview . Disabled
Servers to
automatically
install Azure
Monitor Agent

Configure Arc- Configure Windows Arc-enabled SQL Servers to automatically install the DeployIfNotExists, 1.2.0
enabled SQL Microsoft Defender for SQL agent. Microsoft Defender for SQL collects events Disabled
Servers to from the agent and uses them to provide security alerts and tailored hardening
automatically tasks (recommendations).
install Microsoft
Defender for
SQL

Configure Arc- Microsoft Defender for SQL collects events from the agent and uses them to DeployIfNotExists, 1.3.0
enabled SQL provide security alerts and tailored hardening tasks (recommendations). Create Disabled
Servers to a resource group, a Data Collection Rule and Log Analytics workspace in the
automatically same region as the machine.
install Microsoft
Defender for
SQL and DCR
with a Log
Analytics
workspace

Configure Arc- Microsoft Defender for SQL collects events from the agent and uses them to DeployIfNotExists, 1.4.0
enabled SQL provide security alerts and tailored hardening tasks (recommendations). Create Disabled
Servers to a resource group and a Data Collection Rule in the same region as the user-
automatically defined Log Analytics workspace.
install Microsoft
Defender for
SQL and DCR
with a user-
defined LA
workspace

Configure Arc- Configure association between Arc-enabled SQL Servers and the Microsoft DeployIfNotExists, 1.1.0
enabled SQL Defender for SQL DCR. Deleting this association will break the detection of Disabled
Servers with security vulnerabilities for this Arc-enabled SQL Servers.
Data Collection
Rule
Association to
Microsoft
Defender for
SQL DCR

Configure Arc- Configure association between Arc-enabled SQL Servers and the Microsoft DeployIfNotExists, 1.2.0
enabled SQL Defender for SQL user-defined DCR. Deleting this association will break the Disabled
Servers with detection of security vulnerabilities for this Arc-enabled SQL Servers.
Data Collection
Rule
Association to
Name Description Effect(s) Version
(Azure portal) (GitHub)

Microsoft
Defender for
SQL user-
defined DCR

Configure Disable public network access for your Azure Arc Private Link Scope so that Modify, Disabled 1.0.0
Azure Arc associated Azure Arc resources cannot connect to Azure Arc services over the
Private Link public internet. This can reduce data leakage risks. Learn more at:
Scopes to https://aka.ms/arc/privatelink .
disable public
network access

Configure Private endpoints connect your virtual networks to Azure services without a DeployIfNotExists, 2.0.0
Azure Arc public IP address at the source or destination. By mapping private endpoints to Disabled
Private Link Azure Arc Private Link Scopes, you can reduce data leakage risks. Learn more
Scopes with about private links at: https://aka.ms/arc/privatelink .
private
endpoints

Configure Azure Private Link lets you connect your virtual networks to Azure services Modify, Disabled 1.0.0
Azure Arc- without a public IP address at the source or destination. The Private Link
enabled servers platform handles the connectivity between the consumer and services over the
to use an Azure Azure backbone network. By mapping Azure Arc-enabled servers to an Azure
Arc Private Link Arc Private Link Scope that is configured with a private endpoint, data leakage
Scope risks are reduced. Learn more about private links at:
https://aka.ms/arc/privatelink .

Configure Azure Defender for Servers provides real-time threat protection for server DeployIfNotExists, 1.0.0
Azure Defender workloads and generates hardening recommendations as well as alerts about Disabled
for Servers to suspicious activities. This policy will disable the Defender for Servers plan for all
be disabled for resources (VMs, VMSSs and ARC Machines) in the selected scope (subscription
all resources or resource group).
(resource level)

Configure Azure Defender for Servers provides real-time threat protection for server DeployIfNotExists, 1.0.0
Azure Defender workloads and generates hardening recommendations as well as alerts about Disabled
for Servers to suspicious activities. This policy will disable the Defender for Servers plan for all
be disabled for resources (VMs, VMSSs and ARC Machines) that have the selected tag name
resources and tag value(s).
(resource level)
with the
selected tag

Configure Azure Defender for Servers provides real-time threat protection for server DeployIfNotExists, 1.0.0
Azure Defender workloads and generates hardening recommendations as well as alerts about Disabled
for Servers to suspicious activities. This policy will enable the Defender for Servers plan (with
be enabled ('P1' 'P1' subplan) for all resources (VMs and ARC Machines) that have the selected
subplan) for all tag name and tag value(s).
resources
(resource level)
with the
selected tag

Configure Azure Defender for Servers provides real-time threat protection for server DeployIfNotExists, 1.0.0
Azure Defender workloads and generates hardening recommendations as well as alerts about Disabled
for Servers to suspicious activities. This policy will enable the Defender for Servers plan (with
be enabled 'P1' subplan) for all resources (VMs and ARC Machines) in the selected scope
(with 'P1' (subscription or resource group).
subplan) for all
Name Description Effect(s) Version
(Azure portal) (GitHub)

resources
(resource level)

Configure Enable VM insights on servers and machines connected to Azure through Arc DeployIfNotExists, 2.0.0
Dependency enabled servers by installing the Dependency agent virtual machine extension. Disabled
agent on Azure VM insights uses the Dependency agent to collect network metrics and
Arc enabled discovered data about processes running on the machine and external process
Linux servers dependencies. See more - https://aka.ms/vminsightsdocs .

Configure Enable VM insights on servers and machines connected to Azure through Arc DeployIfNotExists, 1.1.2
Dependency enabled servers by installing the Dependency agent virtual machine extension Disabled
agent on Azure with Azure Monitoring Agent settings. VM insights uses the Dependency agent
Arc enabled to collect network metrics and discovered data about processes running on the
Linux servers machine and external process dependencies. See more -
with Azure https://aka.ms/vminsightsdocs .
Monitoring
Agent settings

Configure Enable VM insights on servers and machines connected to Azure through Arc DeployIfNotExists, 2.0.0
Dependency enabled servers by installing the Dependency agent virtual machine extension. Disabled
agent on Azure VM insights uses the Dependency agent to collect network metrics and
Arc enabled discovered data about processes running on the machine and external process
Windows dependencies. See more - https://aka.ms/vminsightsdocs .
servers

Configure Enable VM insights on servers and machines connected to Azure through Arc DeployIfNotExists, 1.1.2
Dependency enabled servers by installing the Dependency agent virtual machine extension Disabled
agent on Azure with Azure Monitoring Agent settings. VM insights uses the Dependency agent
Arc enabled to collect network metrics and discovered data about processes running on the
Windows machine and external process dependencies. See more -
servers with https://aka.ms/vminsightsdocs .
Azure
Monitoring
Agent settings

Configure Linux Deploy Association to link Linux Arc machines to the specified Data Collection DeployIfNotExists, 2.1.0
Arc Machines to Rule or the specified Data Collection Endpoint. The list of locations are updated Disabled
be associated over time as support is increased.
with a Data
Collection Rule
or a Data
Collection
Endpoint

Configure Linux Automate the deployment of Azure Monitor Agent extension on your Linux DeployIfNotExists, 2.3.0
Arc-enabled Arc-enabled machines for collecting telemetry data from the guest OS. This Disabled
machines to run policy will install the extension if the region is supported. Learn more:
Azure Monitor https://aka.ms/AMAOverview .
Agent

Configure Linux Deploy Association to link Linux virtual machines, virtual machine scale sets, DeployIfNotExists, 6.1.0
Machines to be and Arc machines to the specified Data Collection Rule or the specified Data Disabled
associated with Collection Endpoint. The list of locations and OS images are updated over time
a Data as support is increased.
Collection Rule
or a Data
Collection
Endpoint
Name Description Effect(s) Version
(Azure portal) (GitHub)

Configure Linux Creates a Guest Configuration assignment to configure disabling local users on DeployIfNotExists, 1.3.0-
Server to Linux Server. This ensures that Linux Servers can only be accessed by AAD Disabled preview
disable local (Azure Active Directory) account or a list of explicitly allowed users by this
users. policy, improving overall security posture.

Configure Log Enable VM insights on servers and machines connected to Azure through Arc DeployIfNotExists, 2.1.1
Analytics enabled servers by installing the Log Analytics virtual machine extension. VM Disabled
extension on insights uses the Log Analytics agent to collect the guest OS performance data,
Azure Arc and provides insights into their performance. See more -
enabled Linux https://aka.ms/vminsightsdocs . Deprecation notice: The Log Analytics agent
servers. See is on a deprecation path and won't be supported after August 31, 2024. You
deprecation must migrate to the replacement 'Azure Monitor agent' prior to that date
notice below

Configure Log Enable VM insights on servers and machines connected to Azure through Arc DeployIfNotExists, 2.1.1
Analytics enabled servers by installing the Log Analytics virtual machine extension. VM Disabled
extension on insights uses the Log Analytics agent to collect the guest OS performance data,
Azure Arc and provides insights into their performance. See more -
enabled https://aka.ms/vminsightsdocs . Deprecation notice: The Log Analytics agent
Windows is on a deprecation path and won't be supported after August 31, 2024. You
servers must migrate to the replacement 'Azure Monitor agent' prior to that date.

Configure Azure Defender includes vulnerability scanning for your machines at no extra DeployIfNotExists, 4.0.0
machines to cost. You don't need a Qualys license or even a Qualys account - everything's Disabled
receive a handled seamlessly inside Security Center. When you enable this policy, Azure
vulnerability Defender automatically deploys the Qualys vulnerability assessment provider to
assessment all supported machines that don't already have it installed.
provider

Configure Configure auto-assessment (every 24 hours) for OS updates on Azure Arc- modify 2.2.1
periodic enabled servers. You can control the scope of assignment according to machine
checking for subscription, resource group, location or tag. Learn more about this for
missing system Windows: https://aka.ms/computevm-windowspatchassessmentmode, for
updates on Linux: https://aka.ms/computevm-linuxpatchassessmentmode .
azure Arc-
enabled servers

Configure Creates a Guest Configuration assignment to configure specified secure DeployIfNotExists, 1.0.1
secure protocol version(TLS 1.1 or TLS 1.2) on Windows machine. Disabled
communication
protocols(TLS
1.1 or TLS 1.2)
on Windows
machines

Configure the Microsoft Defender for SQL collects events from the agent and uses them to DeployIfNotExists, 1.2.0
Microsoft provide security alerts and tailored hardening tasks (recommendations). Create Disabled
Defender for a resource group and Log Analytics workspace in the same region as the
SQL Log machine.
Analytics
workspace

Configure time This policy creates a Guest Configuration assignment to set specified time zone deployIfNotExists 2.1.0
zone on on Windows virtual machines.
Windows
machines.

Configure Azure Automanage enrolls, configures, and monitors virtual machines with best AuditIfNotExists, 2.4.0
virtual practice as defined in the Microsoft Cloud Adoption Framework for Azure. Use DeployIfNotExists,
Name Description Effect(s) Version
(Azure portal) (GitHub)

machines to be this policy to apply Automanage to your selected scope. Disabled

onboarded to
Azure
Automanage

Configure Azure Automanage enrolls, configures, and monitors virtual machines with best AuditIfNotExists, 1.4.0
virtual practice as defined in the Microsoft Cloud Adoption Framework for Azure. Use DeployIfNotExists,
machines to be this policy to apply Automanage with your own customized Configuration Disabled
onboarded to Profile to your selected scope.
Azure
Automanage
with Custom
Configuration
Profile

Configure Deploy Association to link Windows Arc machines to the specified Data DeployIfNotExists, 2.1.0
Windows Arc Collection Rule or the specified Data Collection Endpoint. The list of locations Disabled
Machines to be are updated over time as support is increased.
associated with
a Data
Collection Rule
or a Data
Collection
Endpoint

Configure Automate the deployment of Azure Monitor Agent extension on your Windows DeployIfNotExists, 2.3.0
Windows Arc- Arc-enabled machines for collecting telemetry data from the guest OS. This Disabled
enabled policy will install the extension if the OS and region are supported and system-
machines to run assigned managed identity is enabled, and skip install otherwise. Learn more:
Azure Monitor https://aka.ms/AMAOverview .
Agent

Configure Deploy Association to link Windows virtual machines, virtual machine scale sets, DeployIfNotExists, 4.2.0
Windows and Arc machines to the specified Data Collection Rule or the specified Data Disabled
Machines to be Collection Endpoint. The list of locations and OS images are updated over time
associated with as support is increased.
a Data
Collection Rule
or a Data
Collection
Endpoint

Endpoint Resolve endpoint protection health issues on your virtual machines to protect AuditIfNotExists, 1.0.0
protection them from latest threats and vulnerabilities. Azure Security Center supported Disabled
health issues endpoint protection solutions are documented here -
should be https://docs.microsoft.com/azure/security-center/security-center-services?
resolved on tabs=features-windows#supported-endpoint-protection-solutions. Endpoint
your machines protection assessment is documented here -
https://docs.microsoft.com/azure/security-center/security-center-endpoint-
protection.

Endpoint To protect your machines from threats and vulnerabilities, install a supported AuditIfNotExists, 1.0.0
protection endpoint protection solution. Disabled
should be
installed on
your machines

Linux Arc- Linux Arc-enabled machines should be monitored and secured through the AuditIfNotExists, 1.1.0
enabled deployed Azure Monitor Agent. The Azure Monitor Agent collects telemetry Disabled
Name Description Effect(s) Version
(Azure portal) (GitHub)

machines data from the guest OS. This policy will audit Arc-enabled machines in
should have supported regions. Learn more: https://aka.ms/AMAOverview .
Azure Monitor
Agent installed

Linux machines Machines are non-compliant if Log Analytics agent is not installed on Azure Arc AuditIfNotExists, 1.1.0
should have enabled Linux server. Disabled
Log Analytics
agent installed
on Azure Arc

Linux machines Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.2.0
should meet details, visit https://aka.ms/gcpol . Machines are non-compliant if the machine Disabled
requirements is not configured correctly for one of the recommendations in the Azure
for the Azure compute security baseline.
compute
security
baseline

Linux machines Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.2.0
should only details, visit https://aka.ms/gcpol . Managing user accounts using Azure Disabled
have local Active Directory is a best practice for management of identities. Reducing local
accounts that machine accounts helps prevent the proliferation of identities managed outside
are allowed a central system. Machines are non-compliant if local user accounts exist that
are enabled and not listed in the policy parameter.

Local Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 1.2.0-
authentication details, visit https://aka.ms/gcpol . Machines are non-compliant if Linux Disabled preview
methods should servers don't have local authentication methods disabled. This is to validate that
be disabled on Linux Servers can only be accessed by AAD (Azure Active Directory) account or
Linux machines a list of explicitly allowed users by this policy, improving overall security
posture.

Local Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 1.0.0-
authentication details, visit https://aka.ms/gcpol . Machines are non-compliant if Windows Disabled preview
methods should servers don't have local authentication methods disabled. This is to validate that
be disabled on Windows Servers can only be accessed by AAD (Azure Active Directory) account
Windows or a list of explicitly allowed users by this policy, improving overall security
Servers posture.

Machines To ensure periodic assessments for missing system updates are triggered Audit, Deny, 3.5.0
should be automatically every 24 hours, the AssessmentMode property should be set to Disabled
configured to 'AutomaticByPlatform'. Learn more about AssessmentMode property for
periodically Windows: https://aka.ms/computevm-windowspatchassessmentmode, for
check for Linux: https://aka.ms/computevm-linuxpatchassessmentmode .
missing system
updates

Schedule You can use Azure Update Manager in Azure to save recurring deployment DeployIfNotExists, 3.10.0
recurring schedules to install operating system updates for your Windows Server and Disabled
updates using Linux machines in Azure, in on-premises environments, and in other cloud
Azure Update environments connected using Azure Arc-enabled servers. This policy will also
Manager change the patch mode for the Azure Virtual Machine to
'AutomaticByPlatform'. See more: https://aka.ms/umc-scheduled-patching

SQL servers on SQL vulnerability assessment scans your database for security vulnerabilities, AuditIfNotExists, 1.0.0
machines and exposes any deviations from best practices such as misconfigurations, Disabled
should have excessive permissions, and unprotected sensitive data. Resolving the
vulnerability vulnerabilities found can greatly improve your database security posture.
Name Description Effect(s) Version
(Azure portal) (GitHub)

findings
resolved

Subscribe Subscribe eligible Arc-enabled SQL Servers instances with License Type set to DeployIfNotExists, 1.0.0
eligible Arc- Paid or PAYG to Extended Security Updates. More on extended security updates Disabled
enabled SQL https://go.microsoft.com/fwlink/?linkid=2239401 .
Servers
instances to
Extended
Security
Updates.

The legacy Log Automatically prevent installation of the legacy Log Analytics Agent as the final Deny, Audit, 1.0.0
Analytics step of migrating from legacy agents to Azure Monitor Agent. After you have Disabled
extension uninstalled existing legacy extensions, this policy will deny all future
should not be installations of the legacy agent extension on Azure Arc enabled Linux servers.
installed on Learn more: https://aka.ms/migratetoAMA
Azure Arc
enabled Linux
servers

The legacy Log Automatically prevent installation of the legacy Log Analytics Agent as the final Deny, Audit, 1.0.0
Analytics step of migrating from legacy agents to Azure Monitor Agent. After you have Disabled
extension uninstalled existing legacy extensions, this policy will deny all future
should not be installations of the legacy agent extension on Azure Arc enabled Windows
installed on servers. Learn more: https://aka.ms/migratetoAMA
Azure Arc
enabled
Windows
servers

Windows Arc- Windows Arc-enabled machines should be monitored and secured through the AuditIfNotExists, 1.1.0
enabled deployed Azure Monitor Agent. The Azure Monitor Agent collects telemetry Disabled
machines data from the guest OS. Windows Arc-enabled machines in supported regions
should have are monitored for Azure Monitor Agent deployment. Learn more:
Azure Monitor https://aka.ms/AMAOverview .
Agent installed

Windows Windows Defender Exploit Guard uses the Azure Policy Guest Configuration AuditIfNotExists, 2.0.0
Defender agent. Exploit Guard has four components that are designed to lock down Disabled
Exploit Guard devices against a wide variety of attack vectors and block behaviors commonly
should be used in malware attacks while enabling enterprises to balance their security risk
enabled on and productivity requirements (Windows only).
your machines

Windows To protect the privacy of information communicated over the Internet, your AuditIfNotExists, 4.1.1
machines machines should use the latest version of the industry-standard cryptographic Disabled
should be protocol, Transport Layer Security (TLS). TLS secures communications over a
configured to network by encrypting a connection between machines.
use secure
communication
protocols

Windows To provide adequate protection against newly released malware, Windows AuditIfNotExists, 1.0.0
machines Defender protection signatures need to be updated regularly to account for Disabled
should newly released malware. This policy requires that the Guest Configuration
configure prerequisites have been deployed to the policy assignment scope. For more
Windows information on Guest Configuration, visit https://aka.ms/gcpol .
Defender to
Name Description Effect(s) Version
(Azure portal) (GitHub)

update
protection
signatures
within one day

Windows Windows machines should enable the Real-time protection in the Windows AuditIfNotExists, 1.0.0
machines Defender to provide adequate protection against newly released malware. This Disabled
should enable policy requires that the Guest Configuration prerequisites have been deployed
Windows to the policy assignment scope. For more information on Guest Configuration,
Defender Real- visit https://aka.ms/gcpol .
time protection

Windows Machines are non-compliant if Log Analytics agent is not installed on Azure Arc AuditIfNotExists, 2.0.0
machines enabled windows server. Disabled
should have
Log Analytics
agent installed
on Azure Arc

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Administrative Templates - Control Panel' for input personalization Disabled
should meet and prevention of enabling lock screens. This policy requires that the Guest
requirements Configuration prerequisites have been deployed to the policy assignment
for scope. For details, visit https://aka.ms/gcpol .
'Administrative
Templates -
Control Panel'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Administrative Templates - MSS (Legacy)' for automatic logon, screen Disabled
should meet saver, network behavior, safe DLL, and event log. This policy requires that the
requirements Guest Configuration prerequisites have been deployed to the policy assignment
for scope. For details, visit https://aka.ms/gcpol .
'Administrative
Templates -
MSS (Legacy)'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Administrative Templates - Network' for guest logons, simultaneous Disabled
should meet connections, network bridge, ICS, and multicast name resolution. This policy
requirements requires that the Guest Configuration prerequisites have been deployed to the
for policy assignment scope. For details, visit https://aka.ms/gcpol .
'Administrative
Templates -
Network'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Administrative Templates - System' for settings that control the Disabled
should meet administrative experience and Remote Assistance. This policy requires that the
requirements Guest Configuration prerequisites have been deployed to the policy assignment
for scope. For details, visit https://aka.ms/gcpol .
'Administrative
Templates -
System'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Accounts' for limiting local account use of blank Disabled
should meet passwords and guest account status. This policy requires that the Guest
requirements
Name Description Effect(s) Version
(Azure portal) (GitHub)

for 'Security Configuration prerequisites have been deployed to the policy assignment
Options - scope. For details, visit https://aka.ms/gcpol .
Accounts'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Audit' for forcing audit policy subcategory and Disabled
should meet shutting down if unable to log security audits. This policy requires that the
requirements Guest Configuration prerequisites have been deployed to the policy assignment
for 'Security scope. For details, visit https://aka.ms/gcpol .
Options - Audit'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Devices' for undocking without logging on, Disabled
should meet installing print drivers, and formatting/ejecting media. This policy requires that
requirements the Guest Configuration prerequisites have been deployed to the policy
for 'Security assignment scope. For details, visit https://aka.ms/gcpol .
Options -
Devices'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Interactive Logon' for displaying last user name Disabled
should meet and requiring ctrl-alt-del. This policy requires that the Guest Configuration
requirements prerequisites have been deployed to the policy assignment scope. For details,
for 'Security visit https://aka.ms/gcpol .
Options -
Interactive
Logon'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Microsoft Network Client' for Microsoft network Disabled
should meet client/server and SMB v1. This policy requires that the Guest Configuration
requirements prerequisites have been deployed to the policy assignment scope. For details,
for 'Security visit https://aka.ms/gcpol .
Options -
Microsoft
Network Client'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Microsoft Network Server' for disabling SMB v1 Disabled
should meet server. This policy requires that the Guest Configuration prerequisites have
requirements been deployed to the policy assignment scope. For details, visit
for 'Security https://aka.ms/gcpol .
Options -
Microsoft
Network Server'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Network Access' for including access for Disabled
should meet anonymous users, local accounts, and remote access to the registry. This policy
requirements requires that the Guest Configuration prerequisites have been deployed to the
for 'Security policy assignment scope. For details, visit https://aka.ms/gcpol .
Options -
Network
Access'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Network Security' for including Local System Disabled
should meet behavior, PKU2U, LAN Manager, LDAP client, and NTLM SSP. This policy
requirements
Name Description Effect(s) Version
(Azure portal) (GitHub)

for 'Security requires that the Guest Configuration prerequisites have been deployed to the
Options - policy assignment scope. For details, visit https://aka.ms/gcpol .
Network
Security'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Recovery console' for allowing floppy copy and Disabled
should meet access to all drives and folders. This policy requires that the Guest
requirements Configuration prerequisites have been deployed to the policy assignment
for 'Security scope. For details, visit https://aka.ms/gcpol .
Options -
Recovery
console'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - Shutdown' for allowing shutdown without logon Disabled
should meet and clearing the virtual memory pagefile. This policy requires that the Guest
requirements Configuration prerequisites have been deployed to the policy assignment
for 'Security scope. For details, visit https://aka.ms/gcpol .
Options -
Shutdown'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - System objects' for case insensitivity for non- Disabled
should meet Windows subsystems and permissions of internal system objects. This policy
requirements requires that the Guest Configuration prerequisites have been deployed to the
for 'Security policy assignment scope. For details, visit https://aka.ms/gcpol .
Options -
System objects'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - System settings' for certificate rules on executables Disabled
should meet for SRP and optional subsystems. This policy requires that the Guest
requirements Configuration prerequisites have been deployed to the policy assignment
for 'Security scope. For details, visit https://aka.ms/gcpol .
Options -
System settings'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Options - User Account Control' for mode for admins, Disabled
should meet behavior of elevation prompt, and virtualizing file and registry write failures.
requirements This policy requires that the Guest Configuration prerequisites have been
for 'Security deployed to the policy assignment scope. For details, visit
Options - User https://aka.ms/gcpol .
Account
Control'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Security Settings - Account Policies' for password history, age, length, Disabled
should meet complexity, and storing passwords using reversible encryption. This policy
requirements requires that the Guest Configuration prerequisites have been deployed to the
for 'Security policy assignment scope. For details, visit https://aka.ms/gcpol .
Settings -
Account
Policies'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'System Audit Policies - Account Logon' for auditing credential Disabled
should meet validation and other account logon events. This policy requires that the Guest
Name Description Effect(s) Version
(Azure portal) (GitHub)

requirements Configuration prerequisites have been deployed to the policy assignment

for 'System scope. For details, visit https://aka.ms/gcpol .
Audit Policies -
Account Logon'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'System Audit Policies - Account Management' for auditing Disabled
should meet application, security, and user group management, and other management
requirements events. This policy requires that the Guest Configuration prerequisites have
for 'System been deployed to the policy assignment scope. For details, visit
Audit Policies - https://aka.ms/gcpol .
Account
Management'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'System Audit Policies - Detailed Tracking' for auditing DPAPI, process Disabled
should meet creation/termination, RPC events, and PNP activity. This policy requires that the
requirements Guest Configuration prerequisites have been deployed to the policy assignment
for 'System scope. For details, visit https://aka.ms/gcpol .
Audit Policies -
Detailed
Tracking'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'System Audit Policies - Logon-Logoff' for auditing IPSec, network Disabled
should meet policy, claims, account lockout, group membership, and logon/logoff events.
requirements This policy requires that the Guest Configuration prerequisites have been
for 'System deployed to the policy assignment scope. For details, visit
Audit Policies - https://aka.ms/gcpol .
Logon-Logoff'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'System Audit Policies - Object Access' for auditing file, registry, SAM, Disabled
should meet storage, filtering, kernel, and other system types. This policy requires that the
requirements Guest Configuration prerequisites have been deployed to the policy assignment
for 'System scope. For details, visit https://aka.ms/gcpol .
Audit Policies -
Object Access'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'System Audit Policies - Policy Change' for auditing changes to system Disabled
should meet audit policies. This policy requires that the Guest Configuration prerequisites
requirements have been deployed to the policy assignment scope. For details, visit
for 'System https://aka.ms/gcpol .
Audit Policies -
Policy Change'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'System Audit Policies - Privilege Use' for auditing nonsensitive and Disabled
should meet other privilege use. This policy requires that the Guest Configuration
requirements prerequisites have been deployed to the policy assignment scope. For details,
for 'System visit https://aka.ms/gcpol .
Audit Policies -
Privilege Use'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'System Audit Policies - System' for auditing IPsec driver, system Disabled
should meet integrity, system extension, state change, and other system events. This policy
requirements
Name Description Effect(s) Version
(Azure portal) (GitHub)

for 'System requires that the Guest Configuration prerequisites have been deployed to the
Audit Policies - policy assignment scope. For details, visit https://aka.ms/gcpol .
System'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'User Rights Assignment' for allowing log on locally, RDP, access from Disabled
should meet the network, and many other user activities. This policy requires that the Guest
requirements Configuration prerequisites have been deployed to the policy assignment
for 'User Rights scope. For details, visit https://aka.ms/gcpol .
Assignment'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Windows Components' for basic authentication, unencrypted traffic, Disabled
should meet Microsoft accounts, telemetry, Cortana, and other Windows behaviors. This
requirements policy requires that the Guest Configuration prerequisites have been deployed
for 'Windows to the policy assignment scope. For details, visit https://aka.ms/gcpol .
Components'

Windows Windows machines should have the specified Group Policy settings in the AuditIfNotExists, 3.0.0
machines category 'Windows Firewall Properties' for firewall state, connections, rule Disabled
should meet management, and notifications. This policy requires that the Guest
requirements Configuration prerequisites have been deployed to the policy assignment
for 'Windows scope. For details, visit https://aka.ms/gcpol .
Firewall
Properties'

Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.0.0
machines details, visit https://aka.ms/gcpol . Machines are non-compliant if the machine Disabled
should meet is not configured correctly for one of the recommendations in the Azure
requirements of compute security baseline.
the Azure
compute
security
baseline

Windows Requires that prerequisites are deployed to the policy assignment scope. For AuditIfNotExists, 2.0.0
machines details, visit https://aka.ms/gcpol . This definition is not supported on Disabled
should only Windows Server 2012 or 2012 R2. Managing user accounts using Azure Active
have local Directory is a best practice for management of identities. Reducing local
accounts that machine accounts helps prevent the proliferation of identities managed outside
are allowed a central system. Machines are non-compliant if local user accounts exist that
are enabled and not listed in the policy parameter.

Windows To ensure prompt detection of malware and minimize its impact on your AuditIfNotExists, 1.2.0
machines system, it is recommended that Windows machines with Windows Defender Disabled
should schedule schedule a daily scan. Please make sure Windows Defender is supported,
Windows preinstalled on the device, and Guest Configuration prerequisites are deployed.
Defender to Failure to meet these requirements may lead to inaccurate evaluation results.
perform a Learn more about Guest Configuration at https://aka.ms/gcpol .
scheduled scan
every day

Windows Setup the 'time.windows.com' as the default NTP Server for all Windows AuditIfNotExists, 1.0.0
machines machines to ensure logs across all systems have system clocks that are all in Disabled
should use the sync. This policy requires that the Guest Configuration prerequisites have been
default NTP deployed to the policy assignment scope. For more information on Guest
server Configuration, visit https://aka.ms/gcpol .
Next steps
See the built-ins on the Azure Policy GitHub repo .
Review the Azure Policy definition structure.
Review Understanding policy effects.
Azure Arc Platform software component
license terms
Article • 09/07/2023

Microsoft Legal Notice

Microsoft Azure Arc Platform Software

Azure Arc Platform Software components may consist of agents, virtual machine images,
and other software (collectively “Arc Platform Software”) which may be deployed outside
of Azure to enable connectivity to and use of Azure Services. Arc Platform Software is
licensed to you as part of your Azure subscription
(https://azure.microsoft.com/support/legal/ ) and is subject to the "Use of Software
with the Online Service" section of the Product Terms
(https://www.microsoft.com/licensing/terms ). If you do not have an Azure
subscription, you may not use Arc Platform Software. Your Azure subscription will be
billed for fees and applicable taxes associated with use of Azure Services enabled by Arc
Platform Software.

Previews. Certain Arc Platform Software may be designated as a “Preview” version and is
therefore subject to terms applicable to "Previews" as detailed in the “Universal License
Terms for Online Services” section of the Product Terms and the Products and Services
Data Protection Addendum.