Once an Azure environment takes governance seriously, Azure machine configuration soon becomes a tool you can't do without. I see this in almost every enterprise tenant I work in. Whether it's Azure VMs or Arc-enabled servers running on-prem or in another cloud, people now simply expect OS-level settings to be audited and enforced. Clean VM builds alone don't cut it anymore. Organizations want to monitor and fix local admin accounts, password policies, audit settings and a lot more. Over the past couple of years, what began as Guest Configuration for heavily regulated workloads has turned into a standard part of daily operations.

Built-in baselines deliver security and compliance out of the box

Most teams begin with Microsoft's built-in policy initiatives, mainly the Windows and Linux security baselines. Azure Policy offers them as policy sets with effects like "AuditIfNotExists" or "DeployIfNotExists", and underneath they depend on the Azure machine configuration extension. That gives you auditing at the level of the individual VM or Arc server: local accounts, password standards, firewall configuration, security log retention and plenty more. You'd normally assign them at management group or subscription level, often as part of a landing zone deployment. I've written up some practical notes on scoping these policies in Azure landing zone governance: Foundations without overkill.

Many people assume machine configuration can only audit. That's not true, because some policies can enforce settings (the "ApplyAndMonitor" effect). From what I've seen, pushing enforcement out too widely can backfire, particularly in Arc-enabled environments where legacy workloads or custom apps conflict with the baseline settings.

Each machine needs the extension, a managed identity and the initiative

Setup is where a lot of teams run into trouble. On Azure VMs the machine configuration extension usually gets deployed automatically. On Arc servers you have to install it yourself, normally with a script or through the "Deploy prerequisites to enable guest configuration policies" initiative. Every machine also needs a system-assigned managed identity, otherwise the extension can't report compliance back to Azure Policy. Microsoft documents all of this in the official prerequisites documentation and the assignment how-to.

One thing people tend to miss is that Azure machine configuration costs money on Arc-connected servers (on-premises or in other clouds). As of late 2025 the price is roughly $6 per server per month. Because of that, most organizations limit full compliance monitoring and enforcement to their most critical servers.

Pro tip from the field: Build the deploy-prerequisites initiative into your server onboarding, whether that means Arc registration or imaging new Azure VMs. Adding the requirements to a large fleet after the fact is a lot messier.

You decide how far to go with audit or apply and monitor

An important choice with Azure machine configuration is whether you only audit settings (and report noncompliance) or actually enforce them. Most built-in policies use "AuditIfNotExists" by default, which gives you compliance visibility without breaking anything. Where it makes sense, you can switch individual policies to "ApplyAndMonitor". The extension then corrects drift and keeps the required state in place. Be careful here, though. On production or legacy servers in particular, automatic remediation can cause side effects nobody planned for, so test it before any broad rollout.

Compliance status lives in the Azure portal under Policy → Compliance. The "Machine Configuration" tab narrows the view to which VMs and Arc servers comply with which initiatives. Security and governance teams get a lot out of this central dashboard, both for a quick status check and for digging into the places that need remediation.

This simple mermaid diagram shows how a policy assignment ends up as a compliance report:

flowchart TD
A["Policy assignment"] --> B["Initiative deploy prerequisites"]
B --> C["Extension & managed identity"]
C --> D["Machine configuration evaluates settings"]
D --> E["Compliance status to Azure Policy"]
E --> F["Compliance view in Azure portal"]

Figure: From policy assignment to compliance reporting with Azure machine configuration.

Custom packages build on PowerShell DSC

Sometimes the built-in policies aren't enough, for example when you have your own security standards, specific registry keys or more involved logic. For those cases Azure machine configuration lets you write custom packages. You build them with PowerShell Desired State Configuration (DSC), then package and upload them as Custom Guest Configuration Packages in Azure. Assignment still happens through Azure Policy.

Microsoft's sample for Windows baselines is a useful reference. My standing advice is to version your custom packages and assign them only to the resources they're meant for. In mixed Arc environments especially, targeting too broadly fills your compliance results with noise and makes them hard to read.

Below is a working PowerShell snippet for registering a custom package (run it in PowerShell 7 with the 'Az.GuestConfiguration' module; you need contributor rights):

# Prereqs: Az.GuestConfiguration, contributor on subscription
gcPackage = New-GuestConfigurationPackage -Path .\MyDSC -Name "CustomBaseline" -Type Audit
Publish-GuestConfigurationPackage -ResourceGroupName "my-rg" -PackagePath $gcPackage.Path
New-AzPolicyAssignment -Name "CustomBaselineAssignment" -PolicyDefinition "<policy id>" -Scope "/subscriptions/<sub>/resourceGroups/my-rg"

The portal tracks compliance while careful scoping keeps costs down

In day-to-day work, I appreciate that compliance and drift status is always there in the Azure portal, under Policy → Compliance and in the Machine Configuration section. You see right away which servers comply and where remediation should start. Filtering and reporting by resource tags works too. My post on Azure Policy tag inheritance has practical tagging tips that support both compliance reporting and cost allocation.

With bigger Arc deployments, the budget becomes a real issue. I usually suggest turning on machine configuration only for critical systems (DMZ, domain controllers, management servers, databases) instead of covering every server. That keeps the costs under control and the compliance dashboards readable.

Field experience shows where machine configuration pays off

Azure machine configuration has become a core part of how I approach security and governance today. What you gain is verifiable policies, visible compliance and automatic correction, no matter whether your servers run in Azure or connect through Arc from somewhere else. Putting the prerequisites into your landing zone or server onboarding saves a lot of effort later. And good OS compliance does more than keep the auditors satisfied. It makes life noticeably easier for the admin team as well.