Guest Configuration extension should be installed on machines

What does the recommendation "Guest Configuration extension should be installed on machines" check?

Flags virtual machines and Azure Arc-connected servers that do not have the Guest Configuration extension installed. The extension is now called the Azure Machine Configuration extension and was previously known as Azure Policy guest configuration, so older docs still refer to it under the latter name. Its publisher is Microsoft.GuestConfiguration and its extension type is ConfigurationForLinux or ConfigurationforWindows; the names AzurePolicyforLinux and AzurePolicyforWindows are the extension instance names you give the deployment, not the publisher. It is the in-guest agent that reads operating system state such as security baseline settings, installed applications, running services and registry or file values so Azure Policy can audit them against an assigned baseline. The control only verifies that the extension is present. It does not by itself confirm the VM also carries the system-assigned managed identity the extension needs to authenticate, it does not check the extension is healthy and reporting, and it does not assess whether any particular baseline actually passes.

Why does "Guest Configuration extension should be installed on machines" matter?

Without the extension, Azure has no eyes inside the operating system. Every guest-level policy, including the OS security baseline checks, the password and account-lockout audits and your own custom configuration assignments, silently returns no data rather than a failure, so a drifted machine or one that was hardened and then quietly reverted still looks fine on the dashboard. That blind spot defeats the point of continuous compliance: you cannot prove a fleet meets a baseline you are no longer measuring, and an auditor treats an unmeasured host as non-compliant by default. The business consequence is twofold. You inherit unseen attack surface, since unpatched services and weakened settings go unflagged, and you risk failing the evidence gate of frameworks that mandate documented OS hardening. Installing the extension restores in-guest visibility so misconfigurations surface and can be remediated before they are exploited.

How do I fix "Guest Configuration extension should be installed on machines"?

1. Confirm the VM has a system-assigned managed identity first, because the extension cannot authenticate to the Guest Configuration service without one; remediate the companion recommendation 'Virtual machines' Guest Configuration extension should be deployed with system-assigned managed identity' if it is missing.
2. Assign the built-in policy initiative 'Deploy prerequisites to enable Guest Configuration policies on virtual machines', a four-policy set whose two Modify-effect policies add the system-assigned managed identity and whose two DeployIfNotExists-effect policies deploy the Linux and Windows extensions, then run a remediation task to backfill existing machines.
3. For per-VM fixes use 'az vm extension set' with --publisher Microsoft.GuestConfiguration, --name ConfigurationForLinux or ConfigurationforWindows and --extension-instance-name AzurePolicyforLinux or AzurePolicyforWindows, or add a Microsoft.Compute/virtualMachines/extensions resource in your Bicep modules so every new VM ships the extension by default.

# Bring machines into Azure Update Manager: switch on periodic assessment
# and platform-orchestrated patching, then deploy the audit agent.
for vm in $(az vm list -g rg-workloads --query "[].name" -o tsv); do
  az vm update -g rg-workloads -n "$vm" \
    --set osProfile.windowsConfiguration.patchSettings.assessmentMode=AutomaticByPlatform \
    --set osProfile.windowsConfiguration.patchSettings.patchMode=AutomaticByPlatform
  # Guest Configuration extension requires a system-assigned identity.
  az vm identity assign -g rg-workloads -n "$vm"
  az vm extension set -g rg-workloads --vm-name "$vm" \
    --name AzurePolicyforWindows \
    --publisher Microsoft.GuestConfiguration
  echo "$vm: periodic assessment on, auto-patch on, config extension deployed"
done

# Ratchet it shut: assign the built-in policy that enables periodic
# assessment on every machine in the subscription.
az policy assignment create \
  --name enable-periodic-assessment \
  --policy 59efceea-0c96-497e-a4a1-4eb2290dac15 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000" \
  --location uksouth --mi-system-assigned