Azure Windows baseline, simply

Expected values are raw policy or registry values; 0 does not always mean “off”.

Microsoft source snapshot, retrieved 7 September 2026.

Use a PowerShell DSC resource with three operations:

The custom WindowsPasswordPolicy resource leaves stronger existing values unchanged. Compile the DSC configuration into a MOF and build an AuditAndSet ZIP. The package contains that compiled configuration, resource modules and metadata. It is a specific package format, not an arbitrary zipped script. The Windows workflow uses PowerShell 7 with pinned GuestConfiguration 4.12.0 and PSDesiredStateConfiguration 2.0.7. Package authoring.

Before deployment, test the package on a disposable Windows machine:

Get-GuestConfigurationPackageComplianceStatus -Path ./WindowsPasswordMinimum_v1_0_0.zip
Start-GuestConfigurationPackageRemediation -Path ./WindowsPasswordMinimum_v1_0_0.zip
Get-GuestConfigurationPackageComplianceStatus -Path ./WindowsPasswordMinimum_v1_0_0.zip

The Windows package tests passed: 8 changed to 14, the string parameter "14" worked, and a value of 14 stayed unchanged when the required minimum was 12. The middle command changes that disposable runner; it does not test Azure Policy deployment. Package testing.

The implementation uses this folder:

platform/vm-guest-configuration/
  packages/WindowsPasswordMinimum/  # DSC configuration and resource
  parameters/windows-password.json # Required value and package version
  parameters/hosting.tfvars         # Package storage settings
  scripts/                         # Build, test, publish, generate policy
  main.tf                          # Azure package storage

The JSON setting is "minimumPasswordLength": 14. A Windows GitHub Actions workflow builds, tests and publishes the versioned ZIP. Terraform creates its storage. Definition and assignment JSON files stay in the existing platform/policy-management/ folders. Each assignment folder's _scope.json selects the scope.

Publish the tested ZIP at a versioned address, then generate a custom DeployIfNotExists definition with New-GuestConfigurationPolicy. Use ApplyAndAutoCorrect. The generated definition contains the package address, content hash and guest-assignment deployment. Deploy that JSON through the policy IaC pipeline. Policy generation.

This example uses a dedicated Blob container with anonymous blob reads for the generic package only. Anonymous listing and writes are disabled. Uploads require Microsoft Entra authentication; shared-key access is disabled. The ZIP contains no tenant details, credentials or secrets. The VM downloads it without a SAS token or storage role, and the policy pins its SHA-256 hash. A private repository's release download would not provide this anonymous access.

Keep these policy assignments separate:

Deploy the custom definition at your organisation's root management group and initially assign it to a test subscription. IaC also creates the assignment's managed identity and grants Guest Configuration Resource Contributor at the target scope. The definition's roleDefinitionIds describe the permissions; writing those IDs does not grant the roles. Remediation permissions.

For the initial audit-then-remediate test, use this assignment-parameters fragment:

{
  "MinimumPasswordLength": { "value": "14" },
  "EnableAutoRemediation": { "value": "false" }
}

Both values are strings. EnableAutoRemediation: "false" controls the service's metadata-driven automatic application; it does not disable DeployIfNotExists. Creating or updating the VM resource in Azure can still deploy ApplyAndAutoCorrect. For this audit-first test, avoid VM resource updates until the explicit remediation task. Once deployed, the guest assignment's mode controls later drift correction. Generator parameters · Remediation behavior.

First confirm the existing Windows value and the custom Audit guest report. In this test, both showed 8 against a required 14, and the report was NonCompliant before remediation. The built-in baseline's password check also reported NonCompliant.

Create an Azure Policy remediation task for the custom password policy. This deploys the guest assignment as ApplyAndAutoCorrect. Here, $VM_ID is the target VM's Azure resource ID and $POLICY_ASSIGNMENT_ID is the custom Azure Policy assignment ID:

az policy remediation create \
  --resource "$VM_ID" \
  --name remediate-password \
  --policy-assignment "$POLICY_ASSIGNMENT_ID" \
  --resource-discovery-mode ExistingNonCompliant

ExistingNonCompliant uses the policy's recorded noncompliant state. Confirm that state before running it. Azure Policy remediation · Machine Configuration apply modes.

The agent inside Windows then checks the value, applies the correction and reports its result. Later changes below the required minimum are corrected by the agent's next evaluation; they do not need another Azure Policy remediation task.

The Azure Policy remediation completed with one successful deployment and no failures. The custom guest assignment changed from Audit to ApplyAndAutoCorrect.

The custom report and a read-only secedit export both confirmed 14. No command manually set 14 on the Azure VM; the package applied it after policy remediation. The next built-in baseline report also marked Minimum password length as Compliant.

Reporting intervals are package-specific. In this lab, the custom package used 15 minutes and the built-in baseline used 60 minutes. After recording the corrected value, we requested a fresh baseline audit with one agent-service restart on the isolated test VM. This was a lab verification step; the package had already corrected the setting.

A successful remediation deployment alone does not prove that Windows changed. Guest reports and Azure Policy compliance can arrive at different times. The full Windows baseline remained NonCompliant because other checks still failed. This remediation fixed the minimum-password-length check.

This resource refuses to run on domain controllers. Test it on standalone Windows machines first; domain policy can override local settings on domain-joined machines. Removing the Azure Policy assignment does not restore the old Windows value; use a separate rollback configuration if needed.