I already wrote a pretty informative article about using PowerShell DSC for configuring Azure DevOps build servers, and here I would like to share a solution for a more common task – onboarding your servers for monitoring with Azure Monitor. Additionally, you will see how to use the discussed approach with other monitoring solutions of your choice.

Note. I prefer the following approach for configuring mostly non-Azure servers as there are other, more convenient ways as of me, for Azure VMs (more on this later in the post).

Prerequisites

If you are using Azure services and cannot stand repetitive manual tasks, I strongly encourage you to go and explore Azure Automation service. Specifically, take a look at its Azure Automation State Configuration feature, which you can think of as a managed DSC Pull Server. Microsoft already has an extensive guide for onboarding machines for management by Azure Automation State Configuration, so I see no reason to repeat it here.

DSC configuration for the Microsoft Monitoring Agent

For your DSC configuration, you will need to use xPSDesiredStateConfiguration module and, optionally, default PSDesiredStateConfiguration module if you want to implement additional logging at the OS level. Also, if I were you, I would avoid putting any keys and secrets such as Log Analytics Workplace ID and key into the configuration itself. It is better to store them as encrypted variables in your Azure Automation account, and reference them from your DSC configuration. So, let’s look at the following sample configuration:

As you might see, the configuration logic is pretty straightforward. Firstly, you need the installation package to be present on the target host. For that, you can use xRemoteFile DSC resource that downloads a remote file to a target local destination. Secondly, use xPackage resource to install software from a Windows Installer or EXE package. You can use just a regular Package resource from PSDesiredStateConfiguration module and not the ‘experimental’ one, but, to my mind, xPackage is also quite stable and has richer functionality. Thirdly, you can doublecheck that the agent was not only installed but also the corresponding service is up and running. Lastly, log the installation event into the system journal, which might be very handy for debugging and troubleshooting.

In the same way, you can implement the configuration for the Microsoft Dependency agent, which is installed separately from the Microsoft Monitoring Agent (MMA). The only difference you should pay attention to is that the Dependency agent requires MMA to be installed first, so you need to specify that dependency.

Bonus: DSC configuration for the Datadog monitoring agent

To be sure, you can use the described approach with any other monitoring solution. For example, you can install the Datadog monitoring agent the same way we did it for the Microsoft Monitoring Agent:

Installing the Microsoft Monitoring Agent on Azure VMs

Basically, with Azure VMs, you can use the same approach. For the sake of consistency, you can manage the configuration of your VMs exclusively with Azure Automation State Configuration and ensure the Microsoft Monitoring Agent is present on them as part of their setup. However, with Azure VMs, you might find it more continent to install the Log Analytics agent, which is another name for the Microsoft Monitoring Agent, as a VM extension.

If you just need to have MMA installed and aren’t going to configure your Azure VMs with PowerShell DSC, it might be an unnecessary overhead to do that with Azure Automation State Configuration. You can save time and effort by deploying MMA as a part of your ARM template for VMs.

I’m not advocating for the approach with the extension for Azure VMs and just want you to be aware of other options. You should understand that there are many ways to accomplish the task and you should choose a solution that best fulfills your requirements.

What is your experience with onboarding machines to Azure Monitor? Share it in the comments!