If you work with Azure you probably heard of Azure Policy. It’s a key component for governing your infrastructure and services to audit and enforce proper compliance. Azure policy can not only be used to audit and govern Azure resources, it also extends to Windows and Linux servers that run on Azure or somewhere else. In this post I will look a little behind the curtain of Azure Policy Guest Configurations for servers.

Azure Policy Basics

I will not cover the basics of Azure Policy in this blog post. There is lots of content about this available out there, so I will just focus on Guest Configurations here.

Guest Configuration Management in Azure

The first thing you need to do is to enable the “Microsoft.GuestConfiguration” resource provider for the appropriate subscriptions. This is the endpoint that guest configuration-managed servers will communicate to. This might happen automatically in the background depending on your exact permissions.

Let’s continue by navigating to Azure Policy and have a look at the available policy definitions. To get a better overview of the available Guest Configuration definitions you can use the filter option to hide all other definitions.

Now open the “Audit Windows VMs on which the log Analytics Agent is not connected as expected”. This in an initiative definitions that contains two policy definitions. It obviously checks if servers are correctly connected to a specific log analytics workspace. Let’s have a closer look at the two policy definitions now.

As you can immediately see, there is one definition that deploys (DeployIfNotExists) something, and another definition that audits (AuditIfNotExists) something. We first have a look at the deploy definition. If you check the definition JSON file and navigate to the “if”-section you will find out a first interesting fact. This obviously targets virtual machines (Microsoft.Compute/virtualmachines) as well as Azure Arc-managed servers (Microsoft.HybridCompute/machines). So it not only works for Azure VMs, but also VMs that run on-premises or on any other cloud platform (e.g. AWS) – they just need to be managed with Azure Arc for servers.

Now let’s see what gets deployed by navigating to the “then”-section of the JSON definition. There are two areas, one for virtual machines and one for azure arc-managed servers. For virtual machines 3 things get deployed:

• A Guest Configuration Assignment (the details that should be tested)
• A managed Identity for the VM
• The VM extension “Guest Configuration”

Don’t get confused here: all these components are deployed and configured in Azure, not on the virtual machine! In the backend this deploys an ARM template to Azure.

For Azure Arc-managed servers only one resource gets deployed to Azure.

• A Guest Configuration Assignment

That’s it. This first definition obviously prepares and monitores everything so that the second policy definition can later just analyze and report the result. So let’s have a look at the second policy definition in the initiave. This is an easy one as it only checks the result of the already deployed guest configuration. If this return “compliant” the audit result is obviously compliant, otherwise it will be non-compliant. This is again true for virtual machines as well as Azure Arc-managed servers.

Now it’s time to assign the initiative definition to the desired scope. In my case I assign the initiative definition to one of my subscriptions.

Now add the only parameter value that is needed for this example, the Log Analytics workspace id you want your servers to be connected to.

The last important configuration is the remediation and Managed Identity configuration. The deploy-definition will deploy everything automatically for you. Optionally you can create a remediation task that allows you to start a task that runs the deploy-definition (DeployIfNotExists) manually in case something does not work as expected. For those deployments a Managed Identity is needed that has the proper permissions to deploy the relevant ARM templates to the Azure platform.

We are all set now. It takes a while to initialize everything. The new assignment is visible after a few seconds, but it takes some time to initialize everything.

After a while the status changes.

Now let’s analyze why we have a compliance issue here. When you open the initiative definition you can now see which of the contained policy definitions are non-compliant. In this case the deploy policy was successful. If this would have been an issue, the deploy-procedure could be started manually by using the remediation task. But this does not help here because in your case there seems to be a real issue with the target server. So let’s show more details about the non-compliance policy.

Now we can see the non-compliant resource. In my case it’s an Azure Arc-managed server that runs on AWS. Let’s have a look at the details.

In the details you can immediately see that the current value of the assigned guest configuration assignment returns “NonCompliant”, but to be compliant it should return “Compliant”. If you click on the link you will see some more details about the assigned Guest Configuration.

The link brings me to the details where I can now immediately see that this server is obviously not configured for any or at least not the desired Log Analytics workspace. Ths can now be fixed manually or with whatever procedure you want to use. Once it’s fixed, everything will show a compliant status.

On the target machines

Let’s also have a quick look at the targeted machines now. The service on the virtual machines (or physical servers) that is responsible to process guest configurations is the Guest Configuration Service.

Once the servers are connected they will download the assigned guest configurations from Azure. You will find a folder for every assigned guest configuration in the c:\programdata\confguration folder. There is also a log for troubleshooting issues.

A look into the folder you will know that Guest Configurations are DSC-based definitions. I will cover more details about this in a later post. If you don’t want to wait for the next post you can already check out the Microsoft docs today.

These files are analyzed and checked continuously. The results are shown in the Azure portal. Give it some time after you make configuration changes to initialize and report everything. Depending on what you check and change this might take some minutes or even hours.

That’s it for now. I hope this helps you to better understand the process of using, assigning and monitoring Azure Guest Configuration policies. Watch out for more posts on this topic.

So long
Marcel