[ARC 3.1] Build Sheet: A Machine Configuration Baseline

Take a built-in baseline from audit to enforcement: make the drift-visibility decision, remediate machines already adrift, check the meter, and prove it with a deliberately broken setting.

Take a built-in baseline from audit to enforcement: make the drift-visibility decision, remediate machines already adrift, check the meter, and prove it with a deliberately broken setting.

Machine configuration is the closest thing the cloud has to a GPO. It genuinely enforces state, but it is machine-scope only, it lags, one mode costs you the drift interval, and it meters. Here is where the analogy stops.

The build companion to the onboarding article: the low-power onboarding identity, the connectivity choice, agent hardening, and the verification that proves a server is genuinely managed.

Onboarding a server to Arc looks like an install step. It is really a grant of code execution and a network-path decision, and the defaults do not make either choice for you.

Arc extends Azure’s management plane onto servers Azure does not host. The control plane is free, the management meters, and your Windows Server licensing decides which.

The build for standing up the identity sensor estate, both generations, from an empty tenant to a fabric that audits itself and is proven to deliver a detection into the queue.

The cheapest identity attack to survive is the one your configuration never left open. The standing assessments, the honest account of what became of lateral movement paths, and an order that reflects the attacker.

A detection is only half a control. The other half is what you can do the moment it fires, which on this product is two different surfaces people run together at their peril.