The first question a server team asks about Arc is whether it replaces Group Policy, and the answer deserves more honesty than the marketing gives it. Azure Policy with machine configuration is the closest thing the cloud has produced to a GPO. It genuinely audits and genuinely enforces state inside the guest. But it is machine-scope only, it reports more slowly than a policy refresh, one of its modes will quietly repair drift before the compliance record can show how long it lasted, and unlike Group Policy it is a service you pay for. Call it the settings engine for servers that have left the domain, understand exactly where the analogy stops, and you will design with it well instead of being surprised by it later.
Audit, enforce, or enforce and lose the drift interval
Machine configuration can relate to a setting in one of three ways, and the choice between them is the most consequential decision in the whole feature. It can audit, reporting a machine compliant or not and changing nothing. It can apply and monitor, setting the state once and then reporting when it drifts but not correcting it. Or it can apply and auto-correct, re-asserting the desired state at every evaluation so the machine reports compliant continuously. That third mode sounds like the ideal, and operationally it often is, but it carries a consequence worth stating precisely. Auto-correct may return the setting to its enforced value before the compliance record captures the drift’s duration, so what you lose is not the existence of a compliance history but the timestamped interval during which the machine was actually wrong. The assignment still reports compliance and still keeps its assignment records; what it will not reliably give you is how long the gap lasted. In an environment where an auditor expects to see that something changed, for how long, and that it was remediated, continuous auto-correction narrows your evidence, and you have to decide per baseline whether you want the state enforced or the drift interval visible, because this feature does not easily give you both.
Auto-correction does not just fix drift. It can close the gap before the record shows how long the gap was open, and that is a design decision, not a detail.
How the enforcement actually reaches the machine
The delivery model is worth understanding because it explains both the power and the lag. Policies that change state use a deploy-if-not-exists effect, assigned at a scope, management group, subscription, or resource group, and inherited by the machines beneath it. A newly onboarded machine picks up its assignments automatically. An existing machine that was already out of compliance when you assigned the policy needs a remediation task run once to bring it into line, after which the in-guest agent maintains the state on its own. On an Arc server this capability is built directly into the Connected Machine agent, so there is no separate extension to deploy, which is one of the quieter conveniences of the platform. The assignment scope is the whole game here, and it is where the authority conversation lives, because a policy assigned at a management group reaches every server under it.
The authoring reality
For a great many baselines you will never author anything, because the built-in configuration packages cover the common hardening and compliance ground and you simply assign them. When you do need something bespoke, the authoring path is more involved than editing a Group Policy object. A custom package is built with PowerShell Desired State Configuration under PowerShell 7, compiled, signed, and published to a storage location the agent can reach. It is not difficult, but it is a small software-delivery pipeline rather than a console you click through, and that friction is the honest cost of the model. It buys you something real in return: the configuration is code, versioned and testable in a way a GPO never was. But if your mental model is right-click, edit, done, adjust it before you promise a timeline, because the first custom package always takes longer than the estimate.
One point of currency worth getting right, because the documentation itself is muddled on it: custom authoring today targets the second-generation PowerShell DSC resources running under PowerShell 7. The newer standalone configuration engine is not the supported authoring path for machine configuration, whatever an aspirational sentence in a doc might imply. Author to what the current tooling actually supports, not to where the platform is going, or you will build a package that will not deploy.
Where the analogy breaks
Now the seams, because this is where designs go wrong. Machine configuration governs the machine and has no user-side story at all. Everything Group Policy did for the logged-on user, the entire user half of the GPO world, is simply outside its scope, and for a server that is usually fine, but you should know the boundary is hard rather than assume parity. The compliance picture also lags. The in-guest evaluation runs on a short cycle, but the rollup you see in the portal can trail the real state of the fleet by a noticeable margin, so machine configuration is a poor tool for anything that needs a fast, authoritative answer about right now. There is a ceiling on how many configurations a single machine can carry, which is generous but real and forces you to consolidate rather than sprawl. And unlike Group Policy, which was simply part of owning Active Directory, this is a metered service that bills per server per month unless your Windows Server licensing waives it. The GPO replacement, in other words, has a line item, and that changes the calculus for a large fleet.
The authority has moved, not disappeared
The most important thing to carry out of this is that the locus of control has shifted, and your governance has to shift with it. In the domain, the question that mattered was who could link a Group Policy object at the root, because that person could touch every machine. In Arc, the equivalent question is who can assign a deploy-if-not-exists policy at a management group, because that assignment reaches every server beneath it and, through auto-correction, enforces itself continuously. The blast radius did not shrink when you moved to the cloud, it moved from the domain to the tenant, and if your role assignments at management-group and subscription scope are loose, you have recreated the unrestricted-GPO problem in a new console. Treat policy-assignment rights at high scopes as the privileged operation they are, and machine configuration becomes a disciplined settings engine. Leave them loose and it becomes the same footgun the domain always was, pointed at a bigger foot.
To the build
That is the honest shape of the GPO question: a real settings engine with a hard machine-only boundary, a slower and more expensive compliance model, a drift-interval trade you have to make deliberately, and an authority model that rewards tight scoping. The companion build sheet takes a built-in baseline from assignment through a deliberate move to enforcement, shows where the remediation task fits for machines that were already adrift, and puts the meter and its waivers in front of you before you scale it. After that we turn to the other half of what the domain did for a server, patching, and the service Microsoft has positioned to replace WSUS.
Azure Arc
‹ Previous: [ARC 2.1] Build Sheet: Onboarding at Scale
Next: [ARC 3.1] Build Sheet: A Machine Configuration Baseline ›
