Getting started with Azure Monitor agent on Windows client devices

This week is about something totally different compared to the last weeks and maybe even months. There have been examples before about gathering additional data of Windows devices and using that information for dashboards and more. Those examples were mainly focused on existing data and custom scripting. This time the focus is on the Azure Monitor agent for Windows client devices. A few months ago Microsoft introduced the Windows client installer that can be used to collect data from desktops, workstations and laptops, in addition to the already existing options for servers and virtual machines. It enables the collection of Event Logs, Performance Counters and more. That could be useful with for example the introduction of AppLocker, to gather events about the behavior of apps. This post will go through the steps to distribute the Azure Monitor agent, by using Microsoft Intune, the steps to create a Data Collection Rule and the steps to create and associate a Monitored Object. This post will end by showing the results of collected data.

Important: At the moment of writing the Windows client installer of the Azure Monitor agent is in public preview. 

Distributing the Azure Monitor agent

When looking at collecting data by using the Azure Monitor agent, the first action is to make sure that the agent is distributed to the required devices. The installer for that agent is available for download here. The best method to deploy that installer, by using Microsoft Intune, is as a Win32 app. That method enables the creation of a flexible installation method for making the Azure Monitor agent available on devices. Before creating the app within Microsoft Intune, the Microsoft Intune Win32 App Packaging Tool should be used to wrap the installation file (AzureMonitorAgentClientSetup.msi) in an .intunewin file. Those steps are pretty straight forward when starting the app packaging tool. Once the wrapping was successful, the following twelve steps can be used to walk through the process of adding the app, and focusses on the Azure Monitor agent installation specifics.

Note: Most of the information is prepopulated, as the Win32 app is based on a Windows installer file (MSI).

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Apps Windows > Windows apps
  2. On the Windows | Windows apps page, click Add > Windows app (Win32) and click Select
  3. On the App information page, select the just created .intunewin file and click Next
  4. On the expanded App information page, specify at least a NameDescription and Publisher and click Next
  5. On the Program page, specify at least the following information and click Next
  • Install command: Specify msiexec /i “AzureMonitorAgentClientSetup.msi” /qn as the installation command
  • Uninstall command: Specify msiexec /x “{C46FBFAA-AF0D-4741-A189-D8071E3A99C9}” /qn as the installation command

Tip: Configure the restart behavior that corresponds with the deployment process of the app and the device.

  1. On the Requirements, specify at least an Operating system architecture and Minimum operating system and click Next
  2. On the Detection rules page, select Manually configure detection rules, specify the following rules and click Next
  • Rule type: Select MSI as the rule type
  • MSI product code: Specify {C46FBFAA-AF0D-4741-A189-D8071E3A99C9} as the product code to detect the installation
  • MSI product version check: Select No to not specifically check the version
  • Associated with a 32-bit app on 64-bit clients: Select No
  1. On the Dependencies page, click Next
  2. On the Supersedence page, click Next
  3. On the Scope tages page, click Next
  4. On the Assignments page, configure the assignment to deploy the Azure Monitor agent and click Next
  5. On the Review + create page, verify the provided configuration and click Create

Creating a Data Collection Rule

When looking at collecting data by using the Azure Monitor agent, the second action is to create a Data Collection Rule. That rule is used for specifying the data that should be collected. The following five steps walk through the process of creating a Data Collection Rule that is used for collecting information from a specific Event Log (in this example the log that provides insights about the MDM enrollment and related events).

  1. Open the Azure portal, navigate to Monitor > Data Collection Rules and click Create
  2. On the Basics page, specify a Rule Name, select the Subscription, select the Resource Group, select the Region, select Windows as the Platform Type and click Next: Resources
  3. On the Resources page, click Next: Collect and deliver
  4. On the Collect and deliver page, click Add data source, provide te following information and click Review + create
    • On the Data source tab, provide the following information
      • Data source type: Select Windows event logs
      • Select Custom and provide Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin!* as the XPath query to filter
    • On the Destination tab, select the Destination type, the Subscription and the Account or namespace

Note: This XPath query will filter and limit data collection to events that match the query.

  1. On the Review + create page, click Create

Creating and associating a Monitored Object

When looking at collecting data by using the Azure Monitor agent, the third action is to create and associate a Monitored Object. That Monitored Object is used to create a representation of the Azure AD tenant in Azure Resource Manager (ARM). And the earlier created Data Collection Rule must be associated with it. That association can currently only be done at Azure AD tenant scope and makes sure that devices running the Azure Monitor agent will start collecting and sending data. Currently the best method for creating and associating that Monitored Object, is using PowerShell. The following sections will go through a PowerShell script for that specific purpose.

Note: The provided PowerShell snippets, in the different sections, are coming almost straight from the docs.

Section 1: General information

The first section of the PowerShell script, as shown in the snippet below, contains the general information that is required. That means that it describes the important details (e.g. tenant, subscription, etc.), creates the required connection, selects the required subscription, creates a new role assignment, gets an access token and sets the authentication header.

$TenantID = {YourTenantID}
$SubscriptionID = {YourSubscriptionID}
$ResourceGroup = {YourResrouceGroup}
$DCRName = {YourDataCollectionRuleName}

Connect-AzAccount -Tenant $TenantID
Select-AzSubscription -SubscriptionId $SubscriptionID

$user = Get-AzADUser -UserPrincipalName (Get-AzContext).Account
New-AzRoleAssignment -Scope '/' -RoleDefinitionName 'Owner' -ObjectId $user.Id

$auth = Get-AzAccessToken

$AuthenticationHeader = @{
    "Content-Type" = "application/json"
    "Authorization" = "Bearer " + $auth.Token
 }

Section 2: Assigning the Monitored Object Contributor role to the operator

The second section of the PowerShell script, as shown in the snippet below, contains the action to grant the ability to create and link a Monitored Object to a user. That means that it describes the role definition for the Monitored Object Contributor role, sets the request uri for the role assignment and invokes the put on the uri to set the role for the user.

$newguid = (New-Guid).Guid
$UserObjectID = $user.Id

$body = @"
{
    "properties": {
        "roleDefinitionId":"/providers/Microsoft.Authorization/roleDefinitions/56be40e24db14ccf93c37e44c597135b",
        "principalId": `"$UserObjectID`"
    }
}
"@

$request = "https://management.azure.com/providers/microsoft.insights/providers/microsoft.authorization/roleassignments/$newguid`?api-version=2021-04-01-preview"

Invoke-RestMethod -Uri $request -Headers $AuthenticationHeader -Method PUT -Body $body

Note: This action might require the administrator to elevate access to manage resources in subscriptions and management groups, as documented here.

Section 3: Creating a Monitored Object

The third section of the PowerShell script, as shown in the snippet below, contains the action to create the Monitored Object for the Azure AD tenant scope. That means that it sets the request uri for the Monitored Object, describes the properties (i.e. the location of the Monitored Object) and invokes the put on the uri to create the Monitored Object.

$request = "https://management.azure.com/providers/Microsoft.Insights/monitoredObjects/$TenantID`?api-version=2021-09-01-preview"
$body = @'
{
    "properties":{
        "location":"westeurope"
    }
}
'@

$Respond = Invoke-RestMethod -Uri $request -Headers $AuthenticationHeader -Method PUT -Body $body -Verbose
$RespondID = $Respond.id

Note: This action requires the administrator to have the Monitored Object Contributor role at an appropriate scope, as assigned in the previous section.

Section 4: Associating the Data Collection Rule to the Monitored Object

The fourth section of the PowerShell script, as shown in the snippet below, contains the action to associate the Data Collection Rule with the Monitored Object. That means that it sets the request uri for associating the Data Collection Rule with the Monitored Object, describes the properties (i.e. the Data Collection Rule) and invokes the put on the uri to create the association.

$request = "https://management.azure.com$RespondId/providers/microsoft.insights/datacollectionruleassociations/assoc?api-version=2021-04-01"
$body = @"
{
    "properties": {
        "dataCollectionRuleId": "/subscriptions/$SubscriptionID/resourceGroups/$ResourceGroup/providers/Microsoft.Insights/dataCollectionRules/$DCRName"
    }
}

"@

Invoke-RestMethod -Uri $request -Headers $AuthenticationHeader -Method PUT -Body $body

Note: This action requires the administrator to have the Monitored Object Contributor role at an appropriate scope, as assigned in the previous section.

Verifying the collected data

After distributing the Azure Monitor agent, creating a Data Collection Rule and creating and associating a Monitored Object, the data collection should start. The easiest place to verify a succesful configuration, is by simply looking at the data in the Log Analytics workspace that is connected to the Data Collection Rule. Below, in Figure 3, is an overview of a device that is writing information from the specified Event Log. When dealing with a mixed environment of devices writing data to the workspace, an alternative place to look would be the Heartbeat log. That provides more details about the devices writing data to the workspace. Eventually there should be Windows 10/11 devices with Non-Azure registration with ComputerEnvironment.

More information

For more information about the Azure Monitor agent, refer to the following docs.

12 thoughts on “Getting started with Azure Monitor agent on Windows client devices”

  1. I’ve seen that there is increasingly a useful amount of data collected by Defender for Endpoint if you have his licensed and deployed.

    ASR Events, Applocker events and more are captured and can be queried with KQL.

    Great article! I’ll keep this in mind should the need for this in the future arise

    Reply
  2. I’m having issues with the PowerShell script. Is there a certain version of PowerShell needed? It keeps failing at Connect-AzAccount

    Reply
  3. Hi,
    Thanks for this article.
    I have a question about the Monitored Object, it represents the Azure AD Tenant and so when you assign the DCR to it, it will be applied to all the devices in the tenant.
    In our case, we already have on-prem servers in Monitor through Azure Arc and the AMA extension.
    Does that mean that the DCR assigned to the Monitored Object will also apply to the servers ?
    For example if on my Windows Clients I want to get all the events from the Group Policy log, I will also have them from the servers even if the DCRs applied to the servers are not configured to take them ?

    Regards
    Marc

    Reply
      • Hello,
        Thanks for your answer.
        I just did the setup and I can answer my own question.
        The dcr applied to the monitored object seems to be only applied to windows client machines. (at least until now I can’t see any data from the Arc servers, that’s great)
        No need to add the devices as resources in the dcr, it is directly applied through the monitored object on the whole tenant. And also, no need to configure the client machines.
        It is a little bit confusing in the azure portal as you might think that the dcr is not used because there is no resource assigned to it.

        Regards,
        Marc

        Reply
  4. Hi,

    I’ve been trying unsuccessfully to create a monitoring object on a Windows 11 device using a Service Principal. I keep getting the following error message:

    Invoke-RestMethod : {“error”:{“code”:”AuthorizationFailed”,”message”:”The client ‘XXXXXXXXXXXX’ with object id ‘XXXXXXXXXXXXXX’ does not have authorization to perform action ‘microsoft.insights/datacollectionruleassociations/write’ over scope ‘/providers/microsoft.insights/datacollectionruleassociations/assoc’ or the scope is invalid. If access was recently granted, please refresh your credentials.”}}

    Modified the script:
    $TenantID = “ID”
    $SubscriptionID = “ID”
    $ResourceGroup = “GROUP”
    $DCRName = “NAME”

    $ServicePrincipalAppId = “ID”
    $ServicePrincipalSecret = “SEC”

    $SecurePrincipalSecret = ConvertTo-SecureString $ServicePrincipalSecret -AsPlainText -Force
    $Credential = New-Object System.Management.Automation.PSCredential ($ServicePrincipalAppId, $SecurePrincipalSecret)

    Connect-AzAccount -ServicePrincipal -Credential $Credential -Tenant $TenantID

    Select-AzSubscription -SubscriptionId $SubscriptionID

    $auth = Get-AzAccessToken -ResourceUrl “https://management.azure.com/”

    $AuthenticationHeader = @{
    “Content-Type” = “application/json”
    “Authorization” = “Bearer ” + $auth.Token
    }

    $request = “https://management.azure.com/subscriptions/$SubscriptionID/resourceGroups/$ResourceGroup/providers/Microsoft.Insights/monitoredObjects/$TenantID`?api-version=2021-09-01-preview”
    $body = @{
    properties = @{
    location = “westeurope”
    }
    }

    $Respond = Invoke-RestMethod -Uri $request -Headers $AuthenticationHeader -Method PUT -Body $body -Verbose
    $RespondID = $Respond.id

    $request = “https://management.azure.com$RespondID/providers/microsoft.insights/dataCollectionRuleAssociations/assoc?api-version=2021-04-01-preview”
    $body = @{
    properties = @{
    dataCollectionRuleId = “/subscriptions/$SubscriptionID/resourceGroups/$ResourceGroup/providers/Microsoft.Insights/dataCollectionRules/$DCRName”
    }
    }

    Invoke-RestMethod -Uri $request -Headers $AuthenticationHeader -Method PUT -Body $body

    The Service Principal is owner in the subscription and the permissions are inherited to Log Analytics, etc.

    I am really lost :/

    Maybe you have some advice for me 🙂

    Thank you and enjoy the weekend.
    Regards Jim

    Reply

Leave a Reply to Peter van der Woude Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.