Every capability Arc brings to a server is now on the table, and the honest question at the end of a series like this is not whether the platform works but where it belongs. Arc is not a replacement for Active Directory, and treating it as one leads to disappointment in both directions: expecting it to do things the domain still owns, or leaving machines on the domain that would be better off managed from the cloud. The useful skill is not adopting Arc but sorting your estate with a clear head, knowing what moves, what stays, and how to tell the difference. That sorting is the decision this whole series has been building toward.
What the domain still owns
Start with an honest inventory of what Arc does not touch, because that list is the boundary of the whole conversation. The domain is still the identity provider for on-premises authentication, still the source of Kerberos tickets, still what a file server or a print server leans on to know who a user is. Machine configuration governs the machine and has no user-side story, so everything Group Policy did for the logged-on user sits outside Arc entirely. A server whose reason for existing is to be a domain controller, or to serve files to domain-authenticated users, or to run an application that expects integrated Windows authentication against the local directory, is not a candidate to be cut loose from the domain simply because Arc can manage its operating system. Arc can manage that server’s patches and settings perfectly well while it remains domain-joined, but Arc does not replace the role the domain plays for it. Confusing the management plane with the identity plane is the single most common error in this space, and naming the difference is most of the work.
What Arc does that the domain never could
The other side is just as real. The domain could only ever manage a machine it could reach on a network it controlled, and the moment a server sat in a branch office, a colocation rack, or someone else’s cloud, the domain’s reach frayed and you reached for a patchwork of VPNs, jump boxes, and one-off scripts. Arc does not require inbound reachability, a routable management network, or line of sight to a domain controller. It still depends on working outbound connectivity to its approved Azure endpoints over 443, with DNS, proxy, and certificate validation intact. Grant it that much and a server in another cloud is governed through the same Azure control plane as one in your own datacenter, with the caveat that feature coverage varies by operating system, connector, region, and licensing. Same policy, same patching, same remote access, no inbound port and no bastion. For an estate that has spread beyond a single well-connected site, that is not a marginal improvement, it is a different category of capability. If your servers have outgrown the network your domain assumes, Arc is the management plane that was actually built for where they are now.
The domain manages machines it can reach. Arc manages machines wherever they are. That difference, not any single feature, is the reason to adopt it.
The cost inversion, one more time
The economics deserve a final restatement because they quietly decide more than any feature comparison. Arc’s control plane is free, and its management services meter, but for a Windows estate that already carries Software Assurance or subscription licensing, the attestation benefit makes that management stack free as well. So for a large and well-licensed environment, moving server management onto Arc does not add a line item, it activates capability that was already paid for. The meter mostly bites the machines that were never licensed the way their owners assumed, and discovering that is often more valuable than the management itself, because it surfaces a licensing gap that existed whether or not you adopted Arc. The lesson that has run under every chapter holds at the end: establish the licensing posture first, because it decides both what Arc costs and, frequently, whether the decision is close at all.
How to sort the fleet
With those three facts in hand, the sorting becomes tractable. A server that has already left the domain, or never joined it, or lives somewhere the domain cannot cleanly reach, is a clear candidate to manage through Arc, and the only real question is which management services it needs. A server that remains a genuine participant in the domain’s identity fabric stays domain-joined and can still be Arc-managed for its operating system, gaining cloud patching and configuration without giving up the role it plays. The machines that need the most thought are the ones in between, the ones still domain-joined out of habit rather than need, because those are the population a shrinking-AD strategy actually moves, one dependency at a time, and Arc is what receives them on the server side as the domain’s footprint contracts. The goal is not to Arc-enable everything or to preserve the domain out of caution, but to match each machine to the plane that fits what it actually does.
The larger story this sits inside
That last population points at something bigger than this series. Sorting servers onto Arc is one move in a longer strategy of reducing what pins you to on-premises Active Directory, and Arc is specifically the server half of that story: it is how you keep managing the servers while you retire the domain machinery around them. The identity side, the migration of authentication and the eventual decommissioning of the last domain controller, is a separate and substantial undertaking with its own dependencies and its own sequencing, and it deserves its own treatment rather than a paragraph here. That treatment is the AD to Azure series, which takes the same estate to zero domain controllers in stages. This series has done its job if you now see Arc clearly for what it is: not a replacement for the domain, but the management plane that lets a server outlive its dependence on one. Where and whether you take that all the way to turning off the last domain controller is the next, larger question, and it builds directly on the ground this series has covered.
Sorting the fleet, in one table
The sorting above is a judgment, not a formula, but most estates contain the same handful of server shapes and it is worth naming where each one usually lands. Read the third column as the honest verdict rather than the ambitious one: almost everything is a candidate for Arc management, and far less is a candidate for leaving the domain.
| Server characteristic | Remain domain-joined? | Arc-manage it? | Candidate to leave the domain? |
|---|---|---|---|
| Domain controller | Yes, it is the domain | Yes, for patching and configuration reporting | No. This is the last thing to move, and moving it is the identity project, not this one |
| File server using Active Directory ACLs | Yes | Yes | No, not while the permissions model depends on domain principals |
| IIS application using Windows Integrated Authentication | Yes | Yes | Not until the application’s authentication is rebuilt. The application decides this, not the server team |
| SQL Server with domain service accounts | Yes | Yes, and mind the separate SQL licensing consequences of onboarding | No, until the service accounts are re-platformed onto managed identities or equivalent |
| Standalone web server with application-native identity | No real need | Yes | Yes. This is the clearest case in the table |
| Branch or utility server, domain-joined out of habit | Probably not needed | Yes, and Arc is usually better at reaching it than the domain ever was | Yes, after you check what actually authenticates against it. This is the population a shrinking-AD strategy really moves |
| Internet-facing Linux server | Not applicable | Yes, and Entra SSH gives it the identity story the domain never did | Already outside. Arc is how it stops being unmanaged rather than how it leaves |
| Legacy 2012 R2 workload on Extended Security Updates | Usually yes, and usually for reasons nobody has revisited | Yes, and ESU delivery through Arc is often why it gets onboarded at all | No. Do not stack an identity migration on top of a machine whose support clock is already expiring; migrate or replace the workload instead |
Notice the shape of the third column against the fourth. Arc-manage is nearly always yes, because managing a server from the cloud costs it nothing it was relying on. Leaving the domain is nearly always a question about what authenticates against the machine, not about the machine itself. Keeping those two decisions separate is the single most useful discipline in this article, because conflating them is what turns a straightforward management improvement into a stalled identity project.
Where this leaves you
Arc extends the Azure management plane to servers that have left the domain or never joined it. The control plane is free, the management meters unless your licensing waives it, the authority moves from the domain to the tenant, and the honest work is matching each server to the plane that fits its role rather than adopting the platform wholesale. Understand that, and Arc stops being a product you evaluate and becomes a tool you place deliberately, which is exactly what a management plane should be.
Azure Arc
‹ Previous: [ARC 7] Defender for Servers via Arc: Enabling the Security Attach
