Azure Arc adds a management plane, not a migration
Azure Arc-enabled Servers registers an on-premises or other-cloud Windows or Linux physical server or virtual machine as an Azure resource. The server keeps its hypervisor, storage, IP address and applications. The Connected Machine agent creates a managed identity and sends metadata required by the management plane.
Value comes from using that representation to standardize resource groups, tags, access control, inventory queries, policies and updates. Arc alone does not replace backup, monitoring, EDR, WSUS or operating processes. It provides a control point to which those services can be attached.
What stays local and what appears in Azure
Choose the region with metadata residency in mind. Before the pilot, document what the agent collects, including name, FQDN, AD domain, hardware, network interfaces, versions and compliance state when those features are used.
| Element | Stays on the server | Becomes an Azure resource or data |
|---|---|---|
| Workload | VM, applications, files and databases | No automatic movement |
| Management identity | Agent services and certificate | Managed identity and Azure Resource ID |
| Inventory | Operating system and hardware | Name, FQDN, OS, agent version, CPU, memory, network and tags |
| Configuration | Windows or Linux settings | Compliance state when Machine Configuration is enabled |
| Logs | Local events and counters | Only data configured through Azure Monitor or another service |
1. Design governance before installation
An agent deployed without a target model quickly creates another inconsistent inventory. Define subscriptions, resource groups, regions, naming and tags first. Grouping should support delegation and operations rather than simply mirror Active Directory OUs.
A pragmatic structure separates production, non-production and lab. Tags add site, owner, application, criticality, maintenance window and backup policy. Use Azure Policy to require key fields and prevent drift.
| Tag | Example | Use |
|---|---|---|
| Environment | Production | Policy and report scope |
| Site | Montreal-DC1 | Location and maintenance window |
| ServiceOwner | Infrastructure | Operational owner |
| Application | ERP | Dependencies and prioritization |
| Criticality | Tier-1 | Remediation and escalation order |
| PatchRing | Wave-2 | Dynamic update targeting |
2. Prepare identity and network access
The agent communicates outbound to Azure over HTTPS on TCP 443; no public inbound connection is required. Validate required URLs, TLS inspection, proxy and egress rules for the agent and every planned extension. Log Analytics Gateway is not a proxy for the Connected Machine agent, although Azure Monitor Agent can use it.
For at-scale deployment, use a dedicated service principal with the Azure Connected Machine Onboarding role scoped to the target resource group. It registers the machine, after which the server's managed identity takes over. Never distribute Contributor rights or a personal administrator credential in a deployment script.
- Register Microsoft.HybridCompute, Microsoft.GuestConfiguration and Microsoft.HybridConnectivity.
- Create a pilot resource group and dedicated onboarding identity.
- Allow TCP 443 to documented endpoints or use a supported proxy.
- Evaluate Private Link where a private path is required.
- Test TLS inspection and certificate revocation lists before broad deployment.
3. Start with a representative pilot
Select representative servers: Windows and Linux, virtual and physical, different sites, proxy users, a business application and a lower-risk system. Do not start with domain controllers or systems whose change window is difficult to obtain.
Generate the onboarding script from Azure Arc > Machines to obtain the right tenant, subscription, resource group and region values. Keep the service-principal secret in the secure mechanism of the deployment tool and rotate it after the onboarding wave.
azcmagent connect `
--service-principal-id '<application-id>' `
--service-principal-secret '<securely-supplied-secret>' `
--tenant-id '<tenant-id>' `
--subscription-id '<subscription-id>' `
--resource-group 'rg-arc-prod-canadacentral' `
--location 'canadacentral' `
--tags 'Environment=Production,Site=Montreal-DC1,PatchRing=Wave-1'Watch for automatic SQL Server discovery
When a connected Windows or Linux server hosts SQL Server, Azure Arc can automatically connect the SQL instances and deploy the related extension. This adds detailed inventory and management capabilities, but belongs in the security, licensing and cost review.
If the pilot must not connect SQL Server, add the ArcSQLServerExtensionDeployment=Disabled tag before connection. Do not discover this consequence after onboarding hundreds of servers.
--tags 'Environment=Pilot,ArcSQLServerExtensionDeployment=Disabled'4. Validate the agent on every platform
Successful onboarding means more than seeing a portal row. Confirm local state, service connectivity, tags, identity, agent version and services. On Windows, primary logs are under ProgramData\AzureConnectedMachineAgent; on Linux, under /var/opt/azcmagent.
The agent normally sends a heartbeat every five minutes. A server generally becomes Disconnected after 15 to 30 minutes without one. Create a Resource Health alert and a procedure that distinguishes an outage, stopped service, blocked proxy and intentional retirement.
azcmagent show
azcmagent check
azcmagent config list
azcmagent version
azcmagent logs --full5. Query inventory with Azure Resource Graph
Every connected server receives an Azure Resource ID and becomes queryable through Azure Resource Graph. It answers questions that are simple but expensive to consolidate: which servers are disconnected, which operating systems remain, which agents are aging and which tags are missing.
Resource Graph queries Azure metadata, not the server's full contents. Add Change Tracking, Azure Monitor Agent or another appropriate tool explicitly for detailed software, changes, logs and performance.
Resources
| where type =~ 'microsoft.hybridcompute/machines'
| extend status = tostring(properties.status),
os = tostring(properties.osName),
osVersion = tostring(properties.osVersion),
agentVersion = tostring(properties.agentVersion)
| project name, resourceGroup, subscriptionId, location,
status, os, osVersion, agentVersion, tags
| order by resourceGroup asc, name asc$query = @"
Resources
| where type =~ 'microsoft.hybridcompute/machines'
| project name, resourceGroup, location, properties.status,
properties.osName, properties.agentVersion, tags
"@
Search-AzGraph -Query $query -First 10006. Manage updates with Azure Update Manager
Azure Update Manager can assess and patch Arc-connected Windows and Linux servers without the previous Azure Automation account or Log Analytics dependency. Periodic assessment checks for updates about every 24 hours; installations can run immediately or through a maintenance configuration.
Keep existing update sources: Windows Update, Microsoft Update or WSUS for Windows, and configured Linux repositories. Arc orchestrates assessment and installation but does not make an incompatible package safe. Use rings, maintenance windows, restart behavior and stop criteria.
| Ring | Targets | Suggested delay | Exit criterion |
|---|---|---|---|
| 0 — Lab | Disposable or non-critical servers | At availability | Install and restart validated |
| 1 — Pilot | Representative IT services | A few days | No application incident |
| 2 — Production | Standard workloads | After pilot | Compliance and backup confirmed |
| 3 — Critical | Tier-1 and clusters | Approved window | Failover and functional testing |
7. Apply Azure Policy without fighting GPO
Azure Policy can check tags, allowed regions, expected extensions and management-service state. Machine Configuration goes inside Windows or Linux to audit or enforce settings. Start with Audit and DeployIfNotExists before Deny or automatic remediation.
Azure Policy and GPO can target the same setting on different schedules. Establish an authority matrix for Defender, Windows Update, services, certificates and logging. Use Arc to measure compliance before moving configuration authority.
- Audit Azure structure and tags.
- Controlled deployment of Azure Monitor Agent or approved extensions.
- Machine Configuration in audit for in-guest settings.
- Documented exemptions for legacy systems.
- Automatic remediation only after a pilot and rollback plan.
8. Restrict RBAC, extensions and remote execution
Arc extends the Azure control plane to servers. Someone who can install an extension, execute a command or assign an identity can have significant local impact. Separate onboarding, read, patch and administration roles, and protect privileged roles with PIM and Conditional Access.
Allow only required extensions. Log changes in Azure Activity Log, monitor extension installations, and limit groups allowed to use Run Command or SSH Arc. Give the server managed identity only the Azure access its workload needs.
9. Plan maintenance and cost
The Arc control plane, inventory, tags and Resource Graph queries are free. Added services can be billed: Azure Update Manager for an Arc server is listed at about US$5 per server per month, and Machine Configuration with Change Tracking at US$6. Azure Monitor and Sentinel add ingestion and retention charges.
Some Windows Server licences with active Software Assurance or subscription, and Defender for Servers Plan 2, can include capabilities otherwise billed separately. Estimate real server counts, ingestion and selected options. Connecting Arc does not make the entire Azure management portfolio free.
Microsoft officially supports Connected Machine agent releases from the preceding year. Automatic agent upgrade is in preview starting with agent 1.57; otherwise include updates in your deployment tool and track Azure Advisor.
A five-wave rollout
Azure Arc works best when it simplifies disciplined operations. Make inventory trustworthy first, then add governance and patching with clear ownership. This creates a common management plane without turning an administration project into a rushed Azure migration.
- Document transmitted data and selected region.
- Keep a least-privileged onboarding identity.
- Test proxy, TLS inspection, extensions and disconnection.
- Handle cloned servers and templates before connection.
- Monitor disconnected, expired and outdated agents.
- Deploy Policy and Update Manager in audit or rings.
- Estimate costs before enabling Monitor, Sentinel or Defender broadly.
- Plan clean removal of retired servers.
| Wave | Scope | Expected result |
|---|---|---|
| 0 — Design | Region, RBAC, groups, tags, network and cost | Approved model |
| 1 — Connect | Representative servers | Stable agent and accurate inventory |
| 2 — Visibility | Resource Graph, alerts and dashboards | Disconnections and drift detected |
| 3 — Governance | Policy and Machine Configuration in audit | Compliance measured without disruption |
| 4 — Operations | Patch rings and approved extensions | Windows, recovery and delegation tested |
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →