Azure and DevOops

Using Azure Policy to configure your resources

Azure Policy as a configuration engine?

Azure Policy


Azure Policy Guest Configuration

In a previous blog, I showed how to audit your GPO-contained settings inside Azure VM’s using Azure Policy Guest Configuration. The packaging process is a bit too much for some, and in some cases, you only need to perform a few configuration settings. Luckily there are some settings you can already configure with built-in policies. In this blog, I will show you what Azure Policies are and how they are assigned. When you’ve read this post, you’ll be able to assign Azure Policies to configure the state in your Azure environment and your Virtual Machines.

Assigning policies and policy initiatives

Azure Policy

As a recap, Azure Policy is a service Microsoft offers to audit, configure, and enforce the configuration of Azure resources to govern the state of your Azure environment. You could say that they are the embodiment of the ‘desired state’ of your Azure resources. Azure Policies are defined within the policy definitions. A policy definition (JSON) defines which resource types and properties to check for and what effects are supported by that policy.

Policy effects are operations, which are triggered if the Policy rules have been violated. Policies can be identified by their unique ‘policy definition id’. More information about Azure Policies can be found on Microsoft Docs.

Policy definitions are assigned to resources scopes (resourcegroup(s), subscriptions or management groups). This assignment has a distinct name and a policy effect is chosen. For example, when assigning an Azure Policy which evaluates if Azure Key Vaults have soft-delete in place, you can choose the action in that assignment to be Deny. This will deny new resource deployments in the scope the policy is assigned to.

Some policy definitions allow for several effects, such as “Audit” or “Deny”. During the assignment of the policy, you can supply what policy effect you want executed in case the policy is violated. More information about Azure Policy effects can be found at Microsoft Docs.

Azure Policy Definition ID

As mentioned earlier, policy definitions are referenced by their id. You can search for policy- and initiative definitions, using their ID or display name on the Azure Portal.

Search Azure Policy Definitions

Azure built-in policies can be referenced at each level with the same id (subscription and Management Group), so the definition id will always be the same.

Be wary if you’re creating custom policies and initiatives. These are stored at the object and level you create them. So if you’ve created a custom policy definition at a Management Group scope, you can apply that to that MG or resources scopes beneath the MG, but not in other scopes (not contained beneath that MG).

Azure Policy Assignment


Another gotcha from the custom policies is that their policy definition id’s differ from built-in policy definitions. The policy definition id of a custom policy has a reference to the resource scope where the policy definition is stored.

Built in policy definition id’s look like this:


vs. custom policy definitions id’s

Custom policy definition (id) stored in a Management group:


Custom policy definition (id) stored in a subscription:


Azure Policy Initiatives have a similar definition id, but just a small difference (policySetDefinitions instead of policyDefinitions):



vs. custom


Assigning Azure Policies

While Azure Policy Definitions are a tool to reach a state, the policy requires a target resource scope to be applied. The Azure Policy assignment is a configuration item which contains the following:

There are multiple methods to assign policies to Azure resource scopes. In my previous blog I showed how to assign policies using the Azure Portal. I like using PowerShell, so I’ll use that. More methods to assign Azure Policies can be found on the Microsoft Docs at the Quickstarts tab.

To make it extra interesting, let’s configure objects we can’t edit in the Azure portal. For example, settings in a virtual machine OS.


We do need to setup a few things before we can configure Azure Policy to make changes to our VM’s.

In your subscription(s):

On your VM resources:

Having met all these requirements, we’re all set to deploy built-in GC policies. Documentation for the built-in GC policies is available at Microsoft Docs. There’s also a built-in policy initiative.

Assigning policies

To show the concept, I’m using the Audit Windows machines that are not set to the specified time zone. built-in Azure Guest Configuration Policy. It’s policy definition ID is: /providers/Microsoft.Authorization/policyDefinitions/4221adbc-5c0f-474f-88b7-037a99e6114c. In the policy definition the policy parameter timeZone is referenced, but it has no defaultValue. So we’re required to supply the parameter when assigning this policy. Assigning the policy will create another unique ID, containing the scope of the assignment and the assignment name ({scope}/providers/Microsoft.Authorization/policyAssignments/{policyAssignmentName}).


We start with an Azure Policy that audits the setting on the machine. We’ll perform the policy assignment with:

 1$DefinitionId = "/providers/Microsoft.Authorization/policyDefinitions/c633f6a2-7f8b-4d9e-9456-02f0f04f5505"
 3$splat = @{
 4  Name = 'Audit Windows machines - Timezone - Test'
 5  Scope = "/subscriptions/0192d01f-1632-4c36-a89e-807d825b5017"
 6  PolicyParameterObject = @{
 7    timeZone= "(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna"
 8    }
 9  PolicyDefinition = Get-AzPolicyDefinition -Builtin | Where-Object PolicyDefinitionId -eq $DefinitionId
12New-AzPolicyAssignment @splat


The policy we assigned in the previous example has AuditIfNotExists as a policy effect. However, we’re interested in configuring Windows Configuration via Azure Policies, instead of auditing.

Some policies can deploy resources or modify existing resources to automate the steps towards desired state. Deploying and modifying does require a managed identity for the Assignment, to perform the policy effects. When assigning a policy with those effects (DeployIfNotExists (DINE) or Modify), the managed identity is assigned the RBAC-role, as defined in the policy definition under the roleDefinitionIds.

Using Azure Policy, we can now also set the timezone used on the machine. We can do so with a policy definition conveniently named: Configure time zone on Windows machines. This has a roleDefinition property in the policy definition:


In the built-in roles reference we can see that b24988ac-6180-42a0-ab88-20f7382dd24c, maps to Contributor resource role. The role is assigned to a special type of service principal called a managed identity (Microsoft Docs page about managed identities).

Assigning the policy with a DeployIfNotExists policy, with the -AssignIdentity switch will create the Identity and assign the Contributor role to the Identity. Do mind that you need the proper authorizations to perform this assignment. Otherwise the remediation actions won’t be performed.

 1$DefinitionId =  "/providers/Microsoft.Authorization/policyDefinitions/6141c932-9384-44c6-a395-59e4c057d7c9"
 3$splat = @{
 4  Name = New-Guid
 5  DisplayName = 'Configure time zone on Windows machines - test'
 6  Scope = "/subscriptions/0192d01f-1632-4c36-a89e-807d825b5017"
 7  PolicyParameterObject = @{
 8    timeZone="(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna"
 9    }
10  PolicyDefinition = Get-AzPolicyDefinition -Builtin | Where-Object PolicyDefinitionId -eq $DefinitionId
11  Location = 'westeurope'
14New-AzPolicyAssignment @splat -AssignIdentity

After assigning the policy, the same principles apply as with the previous blogpost. Monitoring policy compliance is done with the Compliance-view in the Policy-management blade:

Azure Policy


Non-compliant resources will not be remediated until a remediation action is performed, a resource deployment is done (including a tag deployment). So don’t forget to perform a remediation action or trigger a policy evaluation by adjusting a resource property.

In this case the assignment is done on an Azure Subscription. To remediate non-compliant resources of an assignment, using a remediation task, you have two options. You can remediate per-resource or remediate all the non-compliant resources for the whole assignment.

1Start-AzPolicyRemediation -Name "RemediationAction" -PolicyAssignmentId "/subscriptions/0192d01f-1632-4c36-a89e-807d825b5017/providers/Microsoft.Authorization/policyAssignments/b0b59220-dcfa-4dc2-9638-bda2133ed7b4"

Using the name we supplied we can view the changes in the Remediation-view in the Policy-blade. Under the Remediation Tasks we can see the progress of the remediation task. After a few minutes if remediation succeeded, the compliance will show that the previously non-compliant items are remediated. This can take up to 30 minutes. If remediation failed you can check the task and it’s deployments (remediation actions use regular resource deployments to change configuration to be compliant).

Conclusion and next steps

In this blog I’ve explained what Azure Policies definitions and assignments are. I’ve shown the differences in assigning the policies using Azure PowerShell with the policy actions Audit and DeployIfNotExists. I also showed how you can initiate Remediate Tasks using Azure PowerShell.

#Azure Guest Configuration   #Azure Policy   #Assigning Azure policies