Three prospective engagements this quarter opened with the same slide: onboard the server estate to Azure Arc, flip on Microsoft Defender for Cloud, and call the hybrid story solved. Two of those clients had never opened Azure Policy's compliance blade. One did not know a Log Analytics workspace bills by the gigabyte ingested, not by the server count.
Arc earned real capability in 2022, and by September the roadmap had mostly caught up with the pitch decks. Azure Arc-enabled data services went generally available earlier this year, SQL Server enabled by Azure Arc followed this spring, and Azure Arc-enabled VMware vSphere is far enough along in preview that partners are already selling it as though the GA button has been pressed. The most useful development this year, though, had nothing to do with dashboards: when SQL Server 2012's extended support lapsed on July 12, Arc-enabled servers became the delivery path for another year of security updates on those boxes, billed through the Azure subscription instead of a separate Extended Security Updates agreement. That is a genuinely good reason to Arc-enable a server. A steering-committee slide with the word "modernization" on it is not.
This note is our answer to that pitch, worked out with the people who inherit the decision after the statement of work closes: the on-call rotation, the network team that owns the firewall change the agent needs, and whoever gets the Log Analytics bill in January.
What Arc-enabling a server actually changes
Azure Arc does one structural thing: it projects a resource that is not natively an Azure resource — a physical server, a VM on VMware or Hyper-V or another cloud, a Kubernetes cluster running anywhere, a SQL Server instance running on Windows — into Azure Resource Manager. Once that resource has an Arc identity, Azure Policy can evaluate it, Microsoft Defender for Cloud can protect it, Azure Monitor can collect from it, and RBAC and tags apply the same way they do to a native Azure VM. Nothing about the underlying workload moves. The server still runs where it runs, on whoever's hardware already runs it.
For Arc-enabled servers, that means the Connected Machine agent (azcmagent) registers the box and starts reporting hardware and OS facts, then extensions — the Log Analytics agent, the Dependency agent, Microsoft Defender for Endpoint, a custom script extension — install through the same Azure extension model used for native VMs. For Arc-enabled Kubernetes, any CNCF-conformant cluster gets a comparable identity and can pull GitOps configuration through a Flux v2 extension. Arc-enabled data services puts SQL Managed Instance or PostgreSQL Hyperscale on top of a data controller that itself needs a Kubernetes cluster as substrate — direct or indirect connectivity mode, depending on how much you trust your egress path. SQL Server enabled by Azure Arc is the odd one out: it does not touch the database engine at all. It projects the instance for Defender for SQL, Azure Hybrid Benefit visibility, and Extended Security Updates delivery, and nothing else.
Four different products under one umbrella term, one control plane underneath. The part of the pitch that is true: this is a real single pane of glass, not a marketing coinage. The part that is not automatically true: turning it on does not mean anyone is looking through the glass afterward.
Where Azure Arc governance and Defender earned the project
The clearest yes we gave this year came from a state agency running roughly 700 servers across a dozen county facilities, none of it in Azure, most of it inventoried on a spreadsheet three people still trusted more than they should have. Arc gave us one thing SCCM and a pile of RDP sessions could not: a single Azure Policy assignment enforcing CIS-aligned guest configuration across every site, with compliance state visible in one blade instead of a dozen local Group Policy results nobody was comparing against each other. Microsoft Defender for Cloud's Plan 2 on top of that gave the security team Defender for Endpoint coverage and file integrity monitoring on servers that had never carried EDR, because nobody had ever gotten budget approved for a standalone agent rollout project. Arc was the vehicle for a security program the agency already needed and had never been able to fund as its own line item.
A regional bank got a narrower but sharper win. Their SQL Server 2012 estate — a dozen instances nobody wanted to touch ahead of a core-banking migration still two years out — needed to survive past July 12 without an unpatched CVE turning into an exam finding. Arc-enabling those instances bought Extended Security Updates through the existing Azure subscription and Defender for SQL's vulnerability assessment, which gave the compliance team something concrete to hand examiners instead of a migration timeline nobody in the room believed.
A third case involved Kubernetes rather than servers. An insurer running OpenShift on-prem across two datacenters — deliberately not in Azure, for latency reasons tied to a claims-processing system — wanted policy parity with their AKS clusters. Arc-enabled Kubernetes plus Flux v2 GitOps gave them one policy source for both environments instead of maintaining duplicate admission-controller configuration by hand in two places that drifted every quarter. That is centralization solving a problem they already had, which is the pattern behind every yes on this list: Arc did not create the requirement. It gave an existing requirement a cheaper way to get met.
Where we've told clients to leave it alone
The most common no this year involved Azure Arc-enabled data services pitched at a scale that did not need it. A manufacturer wanted "cloud-consistent" Postgres on-prem and asked for Arc data services with SQL Managed Instance running alongside it. Their actual requirement was four databases and a wish to stop paying an Oracle support bill. Arc data services would have required standing up a Kubernetes cluster purely to host the data controller — new expertise, new failure modes, new patching surface — to manage four databases a competent DBA already ran fine on plain PostgreSQL. We talked them out of it. The Kubernetes-as-substrate requirement is the part of the data services pitch that decks tend to leave off the slide, and it is the single biggest reason we say no to that specific product.
The second common no: a single-region estate already disciplined on ConfigMgr, with current Group Policy baselines and a patch cadence nobody was complaining about. Arc does not replace that. It duplicates it with a second inventory and a second policy engine pointed at the same servers, and somebody has to reconcile drift between the two indefinitely. If ConfigMgr already answers "is this server compliant," adding Arc answers the same question twice for the price of the second answer.
The third: air-gapped and OT-adjacent segments at another manufacturer, where the Connected Machine agent's outbound connectivity requirement collided directly with the change-control process protecting a live production line. Arc wants a persistent HTTPS path out to Microsoft; a segmented plant network wants nothing persistent crossing that boundary at all. We scoped Arc out of those subnets entirely and left the argument for a future network redesign project — not this one.
The agent tax nobody puts in the SOW
Every Arc conversation eventually reaches the agent question, and the honest answer is that Arc adds one more process to servers that frequently already run five: antivirus, a backup agent, the SCCM client, a monitoring agent, and now azcmagent plus whatever extensions ride on top of it. None of that is a reason to skip Arc on its own. It is a reason to put agent inventory on the discovery checklist instead of discovering it during the pilot's first incident call.
The Connected Machine agent needs outbound HTTPS to a specific set of endpoints, and this is where onboarding projects actually stall — not on licensing, on firewall change requests that sit in a queue for three weeks.
Outbound only, port 443, no inbound listener required:
*.his.arc.azure.com hybrid instance metadata service
*.guestconfiguration.azure.com Azure Policy guest configuration
*.servicebus.windows.net extension and policy delivery channel
login.windows.net
login.microsoftonline.com
management.azure.com
aka.ms
download.microsoft.com installer and agent updates
Miss one of those through a proxy or an egress firewall and the symptom is not a clean failure. It is a server that shows Connected in the portal with policy compliance stuck on "not registered," which reads exactly like a misconfiguration nobody can isolate until someone runs azcmagent show and azcmagent check on the box directly.
At onboarding scale we script this rather than click through the portal wizard one server at a time:
# Ring-0 onboarding batch, service principal auth, no interactive az login
$servers = Get-Content .\ring0-hostnames.txt
foreach ($server in $servers) {
Invoke-Command -ComputerName $server -ScriptBlock {
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect `
--service-principal-id $using:spnId `
--service-principal-secret $using:spnSecret `
--resource-group "rg-arc-ring0" `
--tenant-id $using:tenantId `
--location "eastus2" `
--cloud "AzureCloud"
}
}
That batch runs once. The Log Analytics ingestion bill, the extension update cadence, and the quarterly review of disconnected or stale Arc resources run forever, and none of them show up in the line item a client approved at kickoff.
The stay/skip test we run before signing
Before we let Arc onto a statement of work, we ask the same four questions regardless of which of the four Arc products is on the table.
| Question | Lean toward Arc | Lean toward skip |
|---|---|---|
| Does this estate already own a policy or Defender requirement it can't meet today? | Yes — Arc is a cheaper delivery path to an existing goal | No — Arc would be the first requirement, not a better answer to one that exists |
| Does the resource already have a working control plane (ConfigMgr, native Azure, an existing Kubernetes admission setup)? | No, or the estate is genuinely multi-cloud | Yes, and it isn't broken |
| Can the network path support persistent outbound HTTPS without a change-control fight? | Yes | No — air-gapped, OT-adjacent, or heavily segmented |
| Is there a named owner for the ongoing agent, extension, and ingestion cost after we leave? | Yes, in writing | No — "IT will figure it out" |
Two or more answers in the skip column is a no, or at minimum a much smaller pilot than whatever was on the original slide. We virtualized more than 400 servers onto Hyper-V with System Center for a manufacturer years ago on exactly this discipline: prove the platform earns the operational cost before it touches production. Arc gets held to the same bar System Center Virtual Machine Manager did, umbrella term or not.
If you're facing this
If someone has proposed Arc-enabling your estate this quarter, ask them to name the policy, Defender, or licensing problem it solves before you ask what it costs — the cost conversation is easy once the requirement is real, and painful when it isn't. We help Microsoft-centric estates run that test before the pilot starts, not after the invoice arrives. Bring the network diagram and the firewall change process; that is usually where the real answer lives.