Unable to install built-in guest configurations in Azure Windows VM

Question

Unable to install built-in guest configurations in Azure Windows VM

Seelam, Bharath 0

I am using bicep to install some built-in guest configurations in my windows machine. But they are in pending state as in the below screenshot. I suspect I am missing source(ContentUri) in the bicep for those guest configuration assignments. Can anyone help me what should be contentUri here for built-in guest configurations ?

The bicep is as below:


param location string

param vm_configuration object
param vnet_externalid string
param minimumPasswordLength string = '14'   
param enforcePasswordHistory string = '24'  
param maximumPasswordAge string = '70'      

module nic 'networkInterfaces/hubutil-nic.bicep' = {
  name: 'nic_deployment'
  params: {
    location: location
    nic_name: vm_configuration.nic_name
    vnet_externalid: vnet_externalid
  }
}

module osDisk 'osDisks/hubutil-disk.bicep' = {
  name: 'OSDisk_deployment'
  params: {
    location: location
    osDisk_name: vm_configuration.osDisk.name
  }
}

resource datadog_uami 'Microsoft.ManagedIdentity/userAssignedIdentities@2025-01-31-preview' = {
  name: vm_configuration.datadog_uami_name
  location: location
}

resource virtualMachine_hubutil 'Microsoft.Compute/virtualMachines@2024-11-01' = {
  name: vm_configuration.vmName
  location: location
  tags: {
    'managed-by': 'bicep'
  }
  identity: {
    type: 'SystemAssigned, UserAssigned' // SystemAssigned is required for Guest Configuration
    userAssignedIdentities: {
      '${datadog_uami.id}': {}
    }
  }
  properties: {
    hardwareProfile: {
      vmSize: vm_configuration.vmSize
    }
    additionalCapabilities: {
      hibernationEnabled: false
    }
    storageProfile: {
      imageReference: {
        publisher: 'MicrosoftWindowsServer'
        offer: 'WindowsServer'
        sku: '2022-datacenter-azure-edition-hotpatch'
        version: 'latest'
      }
      osDisk: {
        osType: 'Windows'
        name: vm_configuration.osDisk.name
        createOption: 'FromImage'
        caching: 'ReadWrite'
        managedDisk: {
          storageAccountType: 'Premium_LRS'
          id: osDisk.outputs.osDisk_id
        }
        deleteOption: 'Delete'
        diskSizeGB: 127
      }
      dataDisks: []
      diskControllerType: 'SCSI'
    }
    osProfile: {
      computerName: vm_configuration.vmName
      adminUsername: vm_configuration.adminUsername
      windowsConfiguration: {
        provisionVMAgent: true
        enableAutomaticUpdates: true
        patchSettings: {
          patchMode: 'AutomaticByPlatform'
          automaticByPlatformSettings: {
            rebootSetting: 'IfRequired'
          }
          assessmentMode: 'ImageDefault'
          enableHotpatching: true
        }
      }
      secrets: []
      allowExtensionOperations: true
      requireGuestProvisionSignal: true
    }
    securityProfile: {
      uefiSettings: {
        secureBootEnabled: true
        vTpmEnabled: true
      }
      securityType: 'TrustedLaunch'
    }
    networkProfile: {
      networkInterfaces: [
        {
          id: nic.outputs.nic_id
          properties: {
            deleteOption: 'Delete'
          }
        }
      ]
    }
    diagnosticsProfile: {
      bootDiagnostics: {
        enabled: true
      }
    }
  }
}

// --------------------------------------------------------
// Guest Configuration Extension
// One extension serves all assignments below
// --------------------------------------------------------
resource guestConfigExtension 'Microsoft.Compute/virtualMachines/extensions@2024-11-01' = {
  parent: virtualMachine_hubutil
  name: 'AzurePolicyforWindows'
  location: location
  properties: {
    publisher: 'Microsoft.GuestConfiguration'
    type: 'ConfigurationforWindows'
    typeHandlerVersion: '1.1'
    autoUpgradeMinorVersion: true
    enableAutomaticUpgrade: true
    settings: {}
    protectedSettings: {}
  }
}

// --------------------------------------------------------
// Assignment 1: Minimum Password Length
// Policy ID: a2d0e922-65d0-40c4-8f87-ea6da2d307a2
// Default: 14 characters
// --------------------------------------------------------
resource guestConfig_minPasswordLength 'Microsoft.GuestConfiguration/guestConfigurationAssignments@2020-06-25' = {
  name: 'MinimumPasswordLength'
  scope: virtualMachine_hubutil
  location: location
  dependsOn: [
    guestConfigExtension
  ]
  properties: {
    guestConfiguration: {
      name: 'MinimumPasswordLength'
      version: '1.*'
      assignmentType: 'ApplyAndAutoCorrect' // Auto-fixes if password policy drifts
      configurationParameter: [
        {
          name: '[AccountPolicy]MinimumPasswordLength;Minimum_Password_Length'
          value: minimumPasswordLength
        }
      ]
    }
  }
}

// --------------------------------------------------------
// Assignment 2: Password History
// Policy ID: 5b054a0d-39e2-4d53-bea3-9734cad2c69b
// Default: 24 unique passwords before reuse
// --------------------------------------------------------
resource guestConfig_passwordHistory 'Microsoft.GuestConfiguration/guestConfigurationAssignments@2020-06-25' = {
  name: 'EnforcePasswordHistory'
  scope: virtualMachine_hubutil
  location: location
  dependsOn: [
    guestConfigExtension
  ]
  properties: {
    guestConfiguration: {
      name: 'EnforcePasswordHistory'
      version: '1.*'
      assignmentType: 'ApplyAndAutoCorrect' // Auto-fixes if password policy drifts
      configurationParameter: [
        {
          name: '[AccountPolicy]EnforcePasswordHistory;Enforce_password_history'
          value: enforcePasswordHistory
        }
      ]
    }
  }
}

// --------------------------------------------------------
// Assignment 3: Maximum Password Age
// Policy ID: 4ceb8dc2-559c-478b-a15b-733fbf1e3738
// Default: 70 days before password must be changed
// --------------------------------------------------------
resource guestConfig_maximumPasswordAge 'Microsoft.GuestConfiguration/guestConfigurationAssignments@2020-06-25' = {
  name: 'MaximumPasswordAge'
  scope: virtualMachine_hubutil
  location: location
  dependsOn: [
    guestConfigExtension
  ]
  properties: {
    guestConfiguration: {
      name: 'MaximumPasswordAge'
      version: '1.*'
      assignmentType: 'ApplyAndAutoCorrect' // Auto-fixes if password policy drifts
      configurationParameter: [
        {
          name: '[AccountPolicy]MaximumPasswordAge;Maximum_Password_Age'
          value: maximumPasswordAge
        }
      ]
    }
  }
}

User's image

Bharath Y P 10,450 Reputation points Microsoft External Staff Moderator

2026-05-20T18:59:00.5833333+00:00
Hello Bharath, Guest Configuration assignments created via Bicep are stuck in Pending state.

You are using built-in Guest Configuration policies (password policies) and trying to determine whether missing contentUri is the cause.

Why this is happening

When using Azure Policy, the policy definition contains metadata such as contentUri and contentHash. Azure Policy automatically creates Guest Configuration assignments with the correct package references.

When creating a manual guestConfigurationAssignments resource, contentUri and contentHash are required only for custom configurations (where you host the package externally).

Built-in configurations behavior

Built-in configurations do NOT require you to manually provide contentUri

Their metadata is embedded within Azure Policy definitions

When assigning built-in configurations:

Only name, version, and parameters are specified

contentUri is not required in the template

However:

Built-in password policies are policy-backed Guest Configurations

When you directly create:

Microsoft.GuestConfiguration/guestConfigurationAssignments

Azure does not inject the required metadata

As a result, the Guest Configuration agent cannot resolve the package, and the assignment remains in a Pending state

Built-in configurations behavior

Built-in configurations do NOT require you to manually provide contentUri

Their metadata is embedded within Azure Policy definitions

When assigning built-in configurations:

Only name, version, and parameters are specified

contentUri is not required in the template

However:

Built-in password policies are policy-backed Guest Configurations

When you directly create:

Microsoft.GuestConfiguration/guestConfigurationAssignments

Azure does not inject the required metadata

As a result, the Guest Configuration agent cannot resolve the package, and the assignment remains in a Pending state

To resolve this:

Use Azure Policy (Best Practice)

Assign built-in policies to the VM or resource group:

resource passwordHistoryPolicy 'Microsoft.Authorization/policyAssignments@2023-03-01' = { name: 'enforce-password-history-on-${virtualMachine_hubutil.name}' properties: { displayName: 'Enforce Password History' policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/5b054a0d-39e2-4d53-bea3-9734cad2c69b' scope: virtualMachine_hubutil.id } }

Azure Policy will:

Create Guest Configuration assignments automatically

Inject required metadata (contentUri, contentHash)

Handle lifecycle and compliance

Use custom Guest Configuration (Advanced)

Only if you are creating your own configuration package requires:

contentUri

contentHash

Reference docs

Install the Azure machine configuration extension https://learn.microsoft.com/azure/defender-for-cloud/security-baseline-guest-configuration?wt.mc_id=azure-cxp-community

Azure Machine Configuration extension overview & ARM/Bicep samples https://learn.microsoft.com/azure/virtual-machines/extensions/guest-configuration?wt.mc_id=azure-cxp-community

Azure Policy built-in packages for guest configuration https://learn.microsoft.com/azure/governance/policy/samples/built-in-packages?wt.mc_id=azure-cxp-community

Guest Configuration REST API reference (create/update details) https://learn.microsoft.com/rest/api/guestconfiguration/guestconfigurationassignments?wt.mc_id=azure-cxp-community

Hope this helps. If the information was useful, please consider accepting the answer and upvoting. Feel free to reach out if you need any further assistance. Thank you.
Seelam, Bharath 0 Reputation points

2026-05-21T15:19:43.16+00:00

@Bharath Y P
I have updated the bicep to use policy assignment to enforce some policies onto my VM.
But I am seeing the policies are still non-compliant as in the below screenshot. Am I missing anything here ?

And I have a built-in initiave named PCI DSS v4 which is assigned at the subscription scope. And it contains these policies which I manually added to the bicep at the VM Scope. Why could not it automatically remediate those policies non-compliancy. And how would my present bicep change adding policy assignment at the VM level remeditate that ?
Bharath Y P 10,450 Reputation points Microsoft External Staff Moderator

2026-05-22T23:26:15.2133333+00:00
Thank you for the update. I can see you've moved to using Azure Policy assignments.

By design the PCI DSS v4 initiative is a Regulatory Compliance initiative. The vast majority of its 269 policies use either the AuditIfNotExists or Manual effect not DeployIfNotExists.

AuditIfNotExists: Only reports non-compliance. It will never make changes or deploy anything.

Manual: Requires manual attestation. No automated evaluation or remediation.

DeployIfNotExists: Can deploy a configuration, but only for new/updated resources automatically. Existing resources require a remediation task.

The PCI DSS v4 initiative is designed for compliance reporting, not enforcement/remediation. It tells you what is wrong but does not fix it. This is intentional regulatory compliance initiatives are meant to give you a compliance dashboard, not auto-change your infrastructure.

https://learn.microsoft.com/en-us/azure/governance/policy/samples/pci-dss-4-0

Even though you've now created proper DeployIfNotExists policy assignments via Bicep, there's a critical behavior to understand:

DeployIfNotExists does NOT automatically remediate existing resources. It only auto-deploys for NEW or UPDATED resources. For resources that already existed before the policy assignment was created, Azure Policy marks them as non-compliant but takes no action. You must explicitly create a Remediation Task.

This is documented behavior: "During an evaluation cycle, policy definitions with a DeployIfNotExists effect that match resources are marked as non-compliant, but no action is taken on that resource. Existing non-compliant resources can be remediated with a remediation task."

https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effect-deploy-if-not-exists

Since your VM already existed when you created the policy assignment, the policy evaluates it > finds non-compliance > marks it non-compliant > but does nothing to fix it.

You can try by creating a remediation task for each of your DeployIfNotExists policy assignments. This is a one-time action per policy.

Go to Azure Policy Compliance

Click on the non-compliant policy assignment

Click Create Remediation Task

Select the scope (your VM's resource group)

Click Remediate.

Only one remediation task can be created during policy assignment. For initiatives with multiple policies, you need to create separate remediation tasks for each policy within the initiative.

You can include remediation tasks directly in your Bicep to make this fully automated.

Note: The managed identity on the policy assignment needs Contributor role on the target scope for the remediation to succeed. Verify this is in place.

Even after remediation creates the guest configuration assignment, the assignmentType parameter determines whether the VM settings are actually enforced.

Audit (default): Only reports does not change settings inside the VM

ApplyAndMonitor: Applies the configuration once, then monitors. If it drifts, reports non-compliant but does not auto-correct.

ApplyAndAutoCorrect: Applies and continuously enforces. If settings drift, automatically corrects at next evaluation.

When creating your policy assignments via Bicep, make sure you're passing the correct parameter for the assignment type. For example, if the policy has an IncludeArcMachines or assignmentType parameter, set it to ApplyAndAutoCorrect for full enforcement:

parameters: { MinimumPasswordLength: { value: '14' } // If the policy definition exposes this parameter: // IncludeArcMachines: { // value: 'false' // } }

You can check the specific built-in policy definition parameters in the portal under Policy > Definitions > [your policy] > Parameters to see which parameters are available.

Hope this helps! Please let us know if you need further assistance. Thanks

Seelam, Bharath 0

@Bharath Y P ,
Thank you for the detailed information.

I am currently using this bicep block to assign the policy bicep:

resource passwordHistoryPolicy 'Microsoft.Authorization/policyAssignments@2025-11-01' = {
  name: 'enforce-password-history-on-${virtualMachine_hubutil.name}'
  scope: virtualMachine_hubutil
  properties: {
    displayName: 'Enforce Password History'
    policyDefinitionId: '/providers/microsoft.authorization/policydefinitions/5b054a0d-39e2-4d53-bea3-9734cad2c69b'
  }
}

With this I can see a policy assignment on my vm and it reported non-compliant.
But the "Create remediation task" button is disabled on the policy. And when I verified the policy definition, I can see this block of code in its policy definition:

"effect": {
        "type": "String",
        "metadata": {
          "displayName": "Effect",
          "description": "Enable or disable the execution of this policy"
        },
        "allowedValues": [
          "AuditIfNotExists",
          "Disabled"
        ],
        "defaultValue": "AuditIfNotExists"

So here, if I have to remediate that policy, Do I have to create a new custom policy definition supporting "DeployIfNotExists" ? What is the best possible way here ?

Bharath Y P 10,450 Reputation points Microsoft External Staff Moderator

2026-05-26T21:19:53.03+00:00

The built-in policies for these individual password settings only support AuditIfNotExists and Disabled effects. There are no built-in DeployIfNotExists (DINE) versions for these specific policies.

The "Create remediation task" button is disabled because remediation tasks are only available for policies with DeployIfNotExists or Modify effects. AuditIfNotExists policies can only report non-compliance they cannot take corrective action.

You can try by skip Azure Policy entirely for enforcement. Go back to the direct guestConfigurationAssignments approach but use AzureWindowsBaseline which does NOT require contentUri and bundles all password settings into one assignment with ApplyAndAutoCorrect.You can optionally keep the audit-only policies alongside for compliance reporting in Azure Policy dashboard, while the baseline handles the actual enforcement.

Or

Create a Custom DINE Policy Definition

If you must use Azure Policy for enforcement (e.g., organizational governance requirement), you would need to create a custom policy definition with DeployIfNotExists that deploys the guest configuration assignment with the correct contentUri and contentHash. the Drawbacks is you need to extract contentUri and contentHash from the built-in audit policy definitions (using the PowerShell method I shared earlier), and these values may change when Microsoft updates the guest configuration packages.

Seelam, Bharath 0

@Bharath Y P ,
I tried the "AzureWindowsBaseline", it is also in Pending State as in the below screenshot:
User's image

And the bicep for that guest configuration assignment is as below:

resource AzureWindowsBaseline 'Microsoft.GuestConfiguration/guestConfigurationAssignments@2020-06-25' = {
  name: 'AzureWindowsBaseline'
  scope: virtualMachine_hubutil
  // location: resourceGroup().location
  properties: {
    guestConfiguration: {
      name: 'AzureWindowsBaseline'
      version: '1.*'
      assignmentType: 'ApplyAndMonitor'
      configurationParameter: [
        {
          name: 'Minimum Password Length;ExpectedValue'
          value: '14'
        }
        {
          name: 'Minimum Password Length;RemediateValue'
          value: '14'
        }
        {
          name: 'Maximum Password Age;ExpectedValue'
          value: '75'
        }
        {
          name: 'Maximum Password Age;RemediateValue'
          value: '75'
        }
      ]
    }
  }
}

Am I missing anything here ?

Bharath Y P 10,450 Reputation points Microsoft External Staff Moderator

2026-05-27T21:59:03.7633333+00:00

This is the most likely reason for the "Pending" state. In your code your code you have commented the location.

The official Microsoft example explicitly includes location.

location: resourceGroup().location // Required

The guest configuration agent uses the location property to determine which regional endpoint to communicate with. Without it, the assignment is created but the agent cannot properly process it, resulting in a Pending state.

https://learn.microsoft.com/en-us/azure/governance/machine-configuration/how-to/assign-configuration/bicep

Missing dependsOn on the Guest Configuration Extension: In your original individual assignments (MinimumPasswordLength, etc.), you had:

dependsOn: [

guestConfigExtension // You had this before

] But in the AzureWindowsBaseline assignment, this dependency is missing. Without it, Bicep may deploy the assignment before the AzurePolicyforWindows extension is fully provisioned, and the agent won't be ready to pick up the assignment.

Seelam, Bharath 0

Alright, I have made one change to the firewall and it changed a lot. I have allowed https oubound access to *.guestconfiguration.azure.com endpoint and after that my pending guest configurations are now atleast deployed although they are non-compliant. And I can also see the azure policy enforced guest configurations as in the below image:
User's image

The source which has "Azure Policy" are the guest configurations enforced by PCI DSS v4 and other initiatives. And the ones whose source is "Manual assignment" are deployed by me using below bicep code:

resource AzureWindowsBaseline 'Microsoft.GuestConfiguration/guestConfigurationAssignments@2024-04-05' = {
  name: 'AzureWindowsBaseline'
  scope: virtualMachine_hubutil
  location: location
  properties: {
    context: 'Azure policy'
    guestConfiguration: {
      name: 'AzureWindowsBaseline'
      version: '1.*'
      assignmentType: 'ApplyAndAutoCorrect'
      configurationParameter: [
        {
          name: 'Minimum Password Length;ExpectedValue'
          value: '14'
        }
        {
          name: 'Minimum Password Length;RemediateValue'
          value: '14'
        }
        {
          name: 'Maximum Password Age;ExpectedValue'
          value: '75'
        }
        {
          name: 'Maximum Password Age;RemediateValue'
          value: '75'
        }
      ]
    }
  }
  dependsOn: [
    guestConfigExtension
  ]
}

// --------------------------------------------------------
// Assignment 1: Minimum Password Length
// Policy ID: a2d0e922-65d0-40c4-8f87-ea6da2d307a2
// Default: 14 characters
// --------------------------------------------------------
resource guestConfig_minPasswordLength 'Microsoft.GuestConfiguration/guestConfigurationAssignments@2024-04-05' = {
  name: 'MinimumPasswordLength'
  scope: virtualMachine_hubutil
  location: location
  properties: {
    guestConfiguration: {
      name: 'MinimumPasswordLength'
      version: '1.*'
      assignmentType: 'ApplyAndAutoCorrect' // Auto-fixes if password policy drifts
      configurationParameter: [
        {
          name: '[AccountPolicy]MinimumPasswordLength;Minimum_Password_Length'
          value: minimumPasswordLength
        }
      ]
    }
  }
  dependsOn: [
    guestConfigExtension
  ]
}

// --------------------------------------------------------
// Assignment 2: Password History
// Policy ID: 5b054a0d-39e2-4d53-bea3-9734cad2c69b
// Default: 24 unique passwords before reuse
// --------------------------------------------------------
resource guestConfig_passwordHistory 'Microsoft.GuestConfiguration/guestConfigurationAssignments@2024-04-05' = {
  name: 'EnforcePasswordHistory'
  scope: virtualMachine_hubutil
  location: location
  properties: {
    guestConfiguration: {
      name: 'EnforcePasswordHistory'
      version: '1.*'
      assignmentType: 'ApplyAndAutoCorrect' // Auto-fixes if password policy drifts
      configurationParameter: [
        {
          name: '[AccountPolicy]EnforcePasswordHistory;Enforce_password_history'
          value: enforcePasswordHistory
        }
      ]
    }
  }
  dependsOn: [
    guestConfigExtension
  ]

Coming to the "AzureWindoesBaseline" guest configuration, eventhough I am using "ApplyAndAutoCorrect", it could not remediate the guest configuration. And it even turned to "Audit" after sometime.

Coming to the other two guest configurations- MinimumPasswordLength and EnforcePasswordHistory, I am seeing this error:

PowerShell DSC resource MSFT_AccountPolicy  failed to execute Set-TargetResource functionality with error message: Set functionality is not supported in this version of the DSC resource.  The SendConfigurationApply function did not succeed. LCM failed to start desired state configuration manually.

How can I implement these guest configurations that I can enforce these Password length and password history ?

Bharath Y P 10,450 Reputation points Microsoft External Staff Moderator

2026-06-02T05:10:04.1133333+00:00
Yes, your latest findings actually line up with how Azure Machine Configuration / Guest Configuration is expected to behave.

Allowing outbound HTTPS to the guest configuration service was a real blocker. The official network requirements say the agent must reach the machine configuration service and storage endpoints over TCP 443, and for Azure/private networking scenarios Microsoft documents agentserviceapi.guestconfiguration.azure.com plus regional/storage endpoints as supported endpoints. For Arc/outside Azure, the documented global pattern is *.guestconfiguration.azure.com. So your “Pending > Deployed” transition strongly suggests the agent could finally download assignments/packages and report status correctly.

For AzureWindowsBaseline, the current documented experience is primarily audit/compliance-oriented, not “manual built-in guest assignment used as a guaranteed remediation engine.” That is why your resource can show up, evaluate, and still remain non-compliant or revert to an audit-style posture.

So on this one, your expectation was understandable, but the documented Microsoft behavior does not support treating the baseline assignment like a generic enforcement package.

“Set functionality is not supported in this version of the DSC resource”

This error is actually the clearest clue.

Microsoft’s built-in package list shows these are built-in packages mapped to audit policies:

“Audit Windows machines that allow re-use of the previous 24 passwords” → configuration EnforcePasswordHistory → DSC moduleSecurityPolicyDsc

“Audit Windows machines that do not restrict the minimum password length to 14 characters” → configuration MinimumPasswordLength → DSC module SecurityPolicyDsc

Because these built-ins are documented as audit packages, changing the guest assignment to ApplyAndAutoCorrect does not magically add Set/remediation support. Your runtime error is consistent with exactly that: the DSC resource version backing that built-in package on the machine doesn’t support Set for that path, so remediation fails.

You cannot enforce password policies using your current built-in guest configuration assignments because:

They are audit-first packages

The underlying DSC resource does not support Set in your scenario

The correct way to enforce is:

Create a custom Machine Configuration package (AuditAndSet) using DSC Publish it and assign with ApplyAndAutoCorrect.
vasudeva reddy 41 Reputation points

2026-07-28T05:42:24.1533333+00:00
Hi @Bharath Y P

Thanks for the detailed explanation of Guest Assignments, we are also having similar guest assignments which does some configuration changes, I have observed one weird behaviour when ever contentURI changes

We have almost 1000+ VMs under the policy which are compliant, later point if we change the contentURI, what ever new VMs are getting created after the change will work as expected but the existing not complaint VMs are using the old contentURI and becomes non-complaint and those are not changing in the next evaluation even the policy is set as "ApplyAndAutoCorrect" and this problem solves only when we do manual remediation.

I see that we can change the policy contentVersion from 1.0.0 to 1.0.1 or similar, wanted to understand the behaviour of existing the resources which are already complaint and few are non-complaint(No exemptions) what happens to those existing resources, due to complexity in our networks we cant use storage accounts in our environment so we end up changing the contectURIs sometimes.

Can you please help me to understand the behaviour for existing resources when changed the contentVersion?

"version": "1.0.0"

1 answer

Your answer

Seelam, Bharath 0 Reputation points

2026-05-21T15:19:43.16+00:00

@Bharath Y P
I have updated the bicep to use policy assignment to enforce some policies onto my VM.
But I am seeing the policies are still non-compliant as in the below screenshot. Am I missing anything here ?

And I have a built-in initiave named PCI DSS v4 which is assigned at the subscription scope. And it contains these policies which I manually added to the bicep at the VM Scope. Why could not it automatically remediate those policies non-compliancy. And how would my present bicep change adding policy assignment at the VM level remeditate that ?
Seelam, Bharath 0 Reputation points

2026-05-24T09:42:01.2666667+00:00

@Bharath Y P ,
Thank you for the detailed information.

I am currently using this bicep block to assign the policy bicep:

resource passwordHistoryPolicy 'Microsoft.Authorization/policyAssignments@2025-11-01' = { name: 'enforce-password-history-on-${virtualMachine_hubutil.name}' scope: virtualMachine_hubutil properties: { displayName: 'Enforce Password History' policyDefinitionId: '/providers/microsoft.authorization/policydefinitions/5b054a0d-39e2-4d53-bea3-9734cad2c69b' } }

With this I can see a policy assignment on my vm and it reported non-compliant.
But the "Create remediation task" button is disabled on the policy. And when I verified the policy definition, I can see this block of code in its policy definition:

"effect": { "type": "String", "metadata": { "displayName": "Effect", "description": "Enable or disable the execution of this policy" }, "allowedValues": [ "AuditIfNotExists", "Disabled" ], "defaultValue": "AuditIfNotExists"

So here, if I have to remediate that policy, Do I have to create a new custom policy definition supporting "DeployIfNotExists" ? What is the best possible way here ?
Bharath Y P 10,450 Reputation points Microsoft External Staff Moderator

2026-05-26T21:19:53.03+00:00

The built-in policies for these individual password settings only support AuditIfNotExists and Disabled effects. There are no built-in DeployIfNotExists (DINE) versions for these specific policies.

The "Create remediation task" button is disabled because remediation tasks are only available for policies with DeployIfNotExists or Modify effects. AuditIfNotExists policies can only report non-compliance they cannot take corrective action.

You can try by skip Azure Policy entirely for enforcement. Go back to the direct guestConfigurationAssignments approach but use AzureWindowsBaseline which does NOT require contentUri and bundles all password settings into one assignment with ApplyAndAutoCorrect.You can optionally keep the audit-only policies alongside for compliance reporting in Azure Policy dashboard, while the baseline handles the actual enforcement.

Or

Create a Custom DINE Policy Definition

If you must use Azure Policy for enforcement (e.g., organizational governance requirement), you would need to create a custom policy definition with DeployIfNotExists that deploys the guest configuration assignment with the correct contentUri and contentHash. the Drawbacks is you need to extract contentUri and contentHash from the built-in audit policy definitions (using the PowerShell method I shared earlier), and these values may change when Microsoft updates the guest configuration packages.
Seelam, Bharath 0 Reputation points

2026-05-27T02:46:22.5133333+00:00

@Bharath Y P ,
I tried the "AzureWindowsBaseline", it is also in Pending State as in the below screenshot:

And the bicep for that guest configuration assignment is as below:

resource AzureWindowsBaseline 'Microsoft.GuestConfiguration/guestConfigurationAssignments@2020-06-25' = { name: 'AzureWindowsBaseline' scope: virtualMachine_hubutil // location: resourceGroup().location properties: { guestConfiguration: { name: 'AzureWindowsBaseline' version: '1.*' assignmentType: 'ApplyAndMonitor' configurationParameter: [ { name: 'Minimum Password Length;ExpectedValue' value: '14' } { name: 'Minimum Password Length;RemediateValue' value: '14' } { name: 'Maximum Password Age;ExpectedValue' value: '75' } { name: 'Maximum Password Age;RemediateValue' value: '75' } ] } } }

Am I missing anything here ?
Bharath Y P 10,450 Reputation points Microsoft External Staff Moderator

2026-05-27T21:59:03.7633333+00:00

This is the most likely reason for the "Pending" state. In your code your code you have commented the location.

The official Microsoft example explicitly includes location.

location: resourceGroup().location // Required

The guest configuration agent uses the location property to determine which regional endpoint to communicate with. Without it, the assignment is created but the agent cannot properly process it, resulting in a Pending state.

https://learn.microsoft.com/en-us/azure/governance/machine-configuration/how-to/assign-configuration/bicep

Missing dependsOn on the Guest Configuration Extension: In your original individual assignments (MinimumPasswordLength, etc.), you had:

dependsOn: [

guestConfigExtension // You had this before

] But in the AzureWindowsBaseline assignment, this dependency is missing. Without it, Bicep may deploy the assignment before the AzurePolicyforWindows extension is fully provisioned, and the agent won't be ready to pick up the assignment.
vasudeva reddy 41 Reputation points

2026-07-28T05:42:24.1533333+00:00

Hi @Bharath Y P

Thanks for the detailed explanation of Guest Assignments, we are also having similar guest assignments which does some configuration changes, I have observed one weird behaviour when ever contentURI changes

We have almost 1000+ VMs under the policy which are compliant, later point if we change the contentURI, what ever new VMs are getting created after the change will work as expected but the existing not complaint VMs are using the old contentURI and becomes non-complaint and those are not changing in the next evaluation even the policy is set as "ApplyAndAutoCorrect" and this problem solves only when we do manual remediation.

I see that we can change the policy contentVersion from 1.0.0 to 1.0.1 or similar, wanted to understand the behaviour of existing the resources which are already complaint and few are non-complaint(No exemptions) what happens to those existing resources, due to complexity in our networks we cant use storage accounts in our environment so we end up changing the contectURIs sometimes.

Can you please help me to understand the behaviour for existing resources when changed the contentVersion?

"version": "1.0.0"

Answer 1

For built‑in guest configuration packages such as:

MinimumPasswordLength
EnforcePasswordHistory
MaximumPasswordAge

no contentUri or contentHash is required in the guestConfigurationAssignments resource. Those properties are only needed when assigning a custom guest configuration package that has been uploaded to storage.

The built‑in configurations are referenced only by:

properties: {
  guestConfiguration: {
    name: 'MinimumPasswordLength'   // or EnforcePasswordHistory, MaximumPasswordAge
    version: '1.*'
    assignmentType: 'ApplyAndAutoCorrect'
    configurationParameter: [ ... ]
  }
}

This matches the schema for Microsoft.GuestConfiguration/guestConfigurationAssignments where contentUri and contentHash are optional fields used to point to a custom package.

If the assignments remain in Pending state, the cause is not a missing contentUri. Troubleshooting should instead focus on the VM/extension side (for example, ensuring the Guest Configuration extension is healthy and that the VM can reach the guest configuration service), but that information is outside the provided context.

References: