Start with the outcome
| Goal | Arc capability |
|---|---|
| One inventory of all servers | Arc resources in Resource Graph with tags |
| Patch compliance everywhere | Azure Update Manager |
| Central logs and metrics | Azure Monitor Agent + DCRs |
| Security posture and EDR | Defender for Servers |
| Config compliance (baselines) | Azure Policy machine configuration |
| Run scripts without RDP/SSH | Run Command, Custom Script extension |
| Extended Security Updates for older Windows/SQL | ESU licences delivered through Arc (check eligibility) |
Pick the first two or three. Onboarding thousands of servers "because Arc is good" without a goal leads to agents nobody uses.
Resource organisation
- Dedicated subscription(s) for hybrid servers, or align to your landing zones by business unit.
- Resource groups by site/data centre or by owning team, with consistent tags:
site,environment,owner,os,patchGroup. - Region for the metadata: pick one that meets your residency needs (metadata, not workload data, is stored there).
Onboarding at scale
| Method | When |
|---|---|
| Onboarding script run with a dedicated service principal, in batches | Most estates |
| Configuration Manager / Group Policy | Windows estates with existing tooling |
| Ansible / Terraform | Linux-heavy, automation-first teams |
| AWS/GCP connectors (multicloud) | Discover and onboard cloud VMs automatically |
Use a dedicated onboarding identity with only the Azure Connected Machine Onboarding role, scoped to the target resource group, and rotate/expire its credential after the onboarding wave.
Network
The Connected Machine agent needs outbound HTTPS to Azure endpoints:
| Option | Notes |
|---|---|
| Direct internet (via proxy) | Simplest; configure proxy with azcmagent config set proxy.url |
| Azure Arc gateway | Fewer endpoints to allow-list (check availability/limits) |
| Private Link Scope | Traffic over ExpressRoute/VPN to private endpoints; more DNS work |
Check connectivity before installing at scale:
azcmagent check --location centralindia
Extensions and policy
Deploy extensions through Azure Policy (DeployIfNotExists) by tag or scope, not by hand:
- Azure Monitor Agent + DCR association
- Defender for Servers (MDE) integration
- Machine configuration for baselines
- Update Manager periodic assessment
Allow-list or block extensions on the agent (azcmagent config set extensions.allowlist) to keep servers from running unexpected extensions, especially in sensitive environments.
Identity and access
- RBAC on Arc resources controls who can run commands and deploy extensions. Treat Run Command rights like admin access to the server.
- The machine's managed identity can access Azure resources (e.g. Key Vault). Grant narrowly.
What Arc doesn't do
- It doesn't move or back up the server (use Azure Backup MARS/MABS or your existing backup).
- It doesn't replace your hypervisor/hardware monitoring.
- Disconnected servers can't be managed until they reconnect; the agent has limits on extended offline periods.
Tip
Onboard in waves by site with a success metric (agent connected, AMA reporting, patch assessment visible). A pilot of 20 servers flushes out proxy, firewall and certificate-inspection issues before they hit 2,000.
Checklist
- Goals chosen (inventory, patching, monitoring, security…)
- Subscriptions, RGs and tags designed
- Onboarding method and least-privilege identity
- Network path tested with azcmagent check
- Extensions via policy; extension allow-list
- Run Command and managed identity access controlled