Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Migrating from the Azure MMA to AMA Agent
Published Jan 29 2024 05:20 AM 7,690 Views
Microsoft

I have another conversation about the sunset of the Microsoft Monitoring Agent (MMA). Back on November 13, 2023 I posted and article on how to do a bulk removal of the Azure MMA agent, but before you can remove the MMA agent you need to have the AMA agent ready to take over the work. Below are details to assist in this endeavor.  *17

 

Just as my miniature schnauzer, Raven, loves to explore the backyard, sniffing out new scents and chasing after squirrels, so too must we venture into the world of Azure’s new AMA agent. Raven’s curiosity and adaptability are traits we can admire and emulate as we navigate this transition. She doesn’t shy away from the unfamiliar; instead, she embraces it with a wagging tail and an eager spirit. Similarly, we should approach the migration from Azure’s MMA agent to the AMA agent with the same enthusiasm and readiness for discovery.

 

Think of the DCR as a specific set of instructions or a recipe that you use when baking Raven’s favorite dog treats. This recipe precisely dictates what ingredients should go into the mix. Similarly, the DCR in the Azure environment defines what log components should be sent to Azure. Just as you wouldn’t add anything not listed in Raven’s treat recipe, the AMA agent only sends the log components specified by the DCR.

 

Now, installing the AMA agent alongside the MMA agent is like giving Raven a new bone while she still has her old one. However, the key is to ensure that the new bone is presented before the old one is taken away. Raven, being the smart dog she is, immediately takes to the new bone, forgetting all about the old one. Similarly, once the DCR definition has been pushed to the server, the new AMA agent becomes active, and the old MMA agent becomes redundant. It’s a seamless transition, just like Raven’s shift of attention from the old bone to the new one. This way, we ensure a smooth transition while avoiding redundancy, making our migration process more efficient and tailored to our needs.

 

This is a large article, so I have added a content listing to help.

 

Contents

  • Transitioning to the Azure Monitor Agent (AMA) when you are using the Log Analytics Agent (MMA/OMS).
  • What is the MMA agent (Also known as OMS or Log Analytics agent)?
  • What is the AMA agent?
  • Coexistence with other agents
  • When should I consider using/migrating from MMA to AMA?
  • Agent Installation
    • Creating a DCR for Windows machines
    • Using Azure Policy to install the Windows Azure Monitoring Agent (AMA)
    • Verify that the AMA Agent Install Policy was Assigned and Create a Remediation Task for Any Existing Windows Servers
    • Verify that the Windows AMA Agent Installation Remediation Worked
    • Using Azure Policy to install the Windows Data Collection Rule
    • Verify that the DCR Policy was Uploaded and Create a Remediation Task for Any Existing Windows Servers
    • Creating a DCR for Linux Machines
    • Using Azure Policy to install the Linux Azure Monitoring Agent
    • Using Azure Policy to install the Linux Data Collection Rules
    • Verify Policy Assignments Have Been Completed
  • Installation of the AMA agent and Push of the DCR Definition on Azure ARC Hosts
    • Using Azure Policy to install the Windows Azure Monitoring Agent for Azure ARC
    • Using Azure Policy to install the Windows Data Collection Rule for Azure ARC
    • Using Azure Policy to install the Linux Azure Monitoring Agent for Azure ARC
    • Using Azure Policy to install the Linux Data Collection Rule for Azure ARC
  • Verify Agents Are Communicating with Azure
    • Querying the Heartbeat Table
  • Find Out Which Agents are Loaded and Where
  • AMA Data Sources and Locations
  • OMS Gateway
  • MMA Agent Removal
  • References

Transitioning to the Azure Monitor Agent (AMA) when you are using the Log Analytics Agent (MMA/OMS).

 

What is the MMA agent (Also known as OMS or Log Analytics agent)? *1

 

The Azure Log Analytics agent collects telemetry from Windows and Linux virtual machines in any cloud, on-premises machines, and those monitored by System Center Operations Manager and sends collected data to your Log Analytics workspace in Azure Monitor. The Log Analytics agent also supports insights and other services in Azure Monitor such as VM insights, Microsoft Defender for Cloud, and Azure Automation.

 

The MMA collects ALL the data from the logs defined below, with limited ability to filter:

Data Source

Description

Windows Event logs

Information sent to the Windows event logging system.

Syslog

Information sent to the Linux event logging system.

Performance

Numerical values measuring performance of different aspects of operating system and workloads.

IIS logs

Usage information for IIS web sites running on the guest operating system.

Custom logs

Events from text files on both Windows and Linux computers.

 

Regardless as to which O/S or installation method the installer will require the workspace ID and key for the Log Analytics workspace that the agent will connect to. This requirement is a key differentiator from the new AMA because the AMA does the installation for the customer.

 

What is the AMA agent? *2

The Azure Monitor agent (AMA) collects monitoring data from the guest operating system of Azure virtual machines and delivers it to Azure Monitor solutions, including Log Analytics and products such as Microsoft Sentinel. The Azure Monitor agent is meant to replace the Log Analytics agent (also known as MMA and OMS) for both Windows and Linux machines.

 

NOTE: The Log Analytics agent will be deprecated on August 31, 2024, so if you are using the MMA/OMS agent, it’s a good idea to start planning your migration to AMA well ahead of time.

Eventually, the Azure Monitor agent will replace the following legacy monitoring agents that are currently used by Azure Monitor.

  • Log Analytics agent: Sends data to a Log Analytics workspace and supports VM insights and monitoring solutions.
  • Telegraf agent: Sends data to Azure Monitor Metrics (Linux only)
  • Diagnostics extension: Sends data to Azure Monitor Metrics (Windows only), Azure Event Hubs, and Azure Storage.

In addition to consolidating this functionality into a single agent, the Azure Monitor agent provides the following benefits over the existing agents:

  • Cost savings
    • Granular targeting via Data Collection Rules to collect specific data types from specific machines, as compared to the "all or nothing" mode that the MMA supports.
  • Security and performance
    • For authentication and security, it uses Managed Identity (for virtual machines) and AAD device tokens (for clients)
    • This agent performs better at higher EPS compared to legacy agents.
  • Simplified management of data collection
  • Management of dependent solutions or services

 

Coexistence with other agents

The Azure Monitor agent can coexist (run side by side on the same machine) with the legacy Log Analytics agents so that you can continue to use their existing functionality during evaluation or migration. For this reason, you can begin transition even with limitations, but you must review the following points carefully:  *12

  • Be careful in collecting duplicate data because it could skew query results and affect downstream features like alerts, dashboards, or workbooks. For example, VM insights uses the Log Analytics agent to send performance data to a Log Analytics workspace. You might also have configured the workspace to collect Windows events and Syslog events from agents.
  • If you install the Azure Monitor agent and create a data collection rule for these same events and performance data, it will result in duplicate data. As a result, ensure you're not collecting the same data from both agents. If you are, ensure they're collecting from different machines or going to separate destinations.
  • Besides data duplication, this scenario would also generate more charges for data ingestion and retention.
  • Running two telemetry agents on the same machine would result in double the resource consumption, including but not limited to CPU, memory, storage space, and network bandwidth. In general, we only recommend this for short periods of time when cutting over from the MMA/OMS agents to AMA and to validate that the same data is being collected but not for extended periods. 

 

When should I consider using/migrating from MMA to AMA?

AMA is feature complete with MMA with reference to Windows Server. For the most up to date details please see *3 in the References section.

Agent Installation

The first set of steps will be to apply an Azure policy to deploy both the AMA agent and the Data Collection Rules. The use of Azure policy is no different, in their use, than other Azure policies you may have built and applied.

 

What are Data Collection Rules, you might ask?

 

“Data Collection Rules (DCRs) define the data collection process in Azure Monitor. DCRs specify what data should be collected, how to transform that data, and where to send that data. DCRs will be created and managed by Azure Monitor to collect a specific set of data to enable insights and visualizations. You may also create your own DCRs to define the set of data required for other scenarios.”  *4

 

Data Collection Rules (DCRs) in Azure Monitor are sets of instructions that support data collection. They provide a consistent and centralized way to define and customize different data collection scenarios. Depending on the scenario, DCRs specify details such as what data should be collected, how to transform that data, and where to send it. They are stored in Azure so that you can centrally manage them. Different components of a data collection workflow will access the DCR for particular information that it requires. In some cases, you can use the Azure portal to configure data collection, and Azure Monitor will create and manage the DCR for you. Other scenarios will require you to create your own DCR.

 

Note: If the Azure Monitor Agent (AMA) isn’t already installed, pushing a Data Collection Rule (DCR) to a host server in the Azure environment can trigger an automatic installation of the AMA. The AMA agent then becomes active and starts working according to the instructions provided by the DCR, ensuring an efficient data collection process. However, it’s important to note that this is not the recommended approach. Best practices suggest a more controlled deployment and configuration of the AMA to suit the specific needs of your environment.

Creating a DCR for Windows machines

  • Browse to the Azure “Monitor” blade and select “Data Collection Rules”.

PaulBergson_0-1704989534297.png

  • Select “Create.
  • Enter Rule Name.
  • Subscription.
  • Resource Group.
  • Region.
    • This needs to be in the same location as the Log Analytics Workspace.
  • Platform Type.

PaulBergson_1-1704989569572.png

  • Select “Next: Resources >”.
  • Click on the “Add resources”.
  • Drill down through the subscription to find a resource. In this example I have selected a Resource Group (RG). The DCR rule created for this RG will be used to apply against all the machines that fall within the scope of the Resource Group.
  • Click “Apply”.

PaulBergson_0-1704989627658.png

 

  • Select “Next: Collect and deliver >”
  • Select “+ Add data source”.
  • Select “Data source type”.
    • In this example we will select “Windows Event Logs”.

At this point here is a key difference from the MMA agent. The data can now be filtered. For now the example shown will choose the complete set of Events from a log file, but they could be filtered using an XPath definition.

 

Before we continue on, I just wanted to show that if the “Custom” definition of logs is selected, it can be noted that there is no logs being collected. After we select the logs to collect, we will look at the “Custom” again to see the XPath generated by the system.

 

  • Choose custom.

PaulBergson_1-1704989663177.png

 

  • Choose Basic
    • The “Information” type was selected to help gather more events but in reality, both “Information” and “Verbose” probably wouldn’t be selected.
    • Select all but “Verbose” as seen in the screen grab below.

PaulBergson_2-1704989663082.png

 

Once these have all been selected, click on “Custom” to see what the XPath filter looks like for this selection.

PaulBergson_3-1704989663097.png

 

  • Select “Next: Destination”.
  • Select “+ Add destination”.
    • Destination type = “Azure Monitor Logs »
    • Suscription = 999999999999999999999999999
    • Account or namespace = xxxxxxxxxxxxxxxxxxxxxxxxx

Note the 9's and X's are place holders for the user to populate with your specific tenant.

 

Limit event log data collection from VM’s via XPath Filters.  *5

 

PaulBergson_4-1704989663060.png

 

  • Select “Add data source”.

PaulBergson_5-1704989663097.png

 

  • Select “Review + create”.

PaulBergson_6-1704989663098.png

 

  • Select “Create”.

PaulBergson_7-1704989663095.png

 

As can be seen, the new DCR has been created. This new DCR is the exact same definition as “Paul-Test” so from this point forward all examples will use “Paul-Test” since there has already been a deployment using this DCR.

 

  • Select the DCR to be used for the Azure policy.

PaulBergson_8-1704989663438.png

 

  • Select “JSON view”

When the DCR rules “Resource ID” is needed, the “Copy to Clipboard” is all that will be needed.

PaulBergson_9-1704989663096.png

 

  • Cancel out of here.

Using Azure Policy to install the Windows Azure Monitoring Agent

Note: Although the documentation doesn’t specifically call out that installing the agent on Windows 10/11 or later (Current documentation only states the MSI) is supported via Azure Policy, this is being amended to reflect that endpoint workstations are supported pushing the AMA agent via Azure policy.  #18

 

  • Browse to the Azure Policy blade.
  • Select Definitions.

PaulBergson_10-1704989663170.png

 

  • Click on the “Search” box.
    • Enter “Configure Windows virtual machines”.

PaulBergson_11-1704989663187.png

 

  • Select “Configure Windows virtual machines to run Azure Monitor Agent using system-assigned managed identity”.

Note: You must have system-assigned managed identity enabled on each virtual machine before you deploy the agent.

To check to see if the virtual machine is configured for system assigned Identity:

  • Open up a new browser tab and browse to Azure Virtual Machines.
    • “System assigned” tab.
    • Settings > Identity.
  • Verify that the “Status” is set to “Enabled”.

PaulBergson_12-1704989663379.png

 

  • The new tab can be closed.
  • Click on the ellipse (the three dots at the end of the Name) and select “Assign”.

PaulBergson_13-1704989663277.png

 

  • Enter the correct “Scope”.
  • Enter any “Exclusions”, if needed.
  • Select “Next”.

PaulBergson_14-1704989663236.png

 

  • There is nothing to be Configured in “Advanced”, so click “Next”.

PaulBergson_15-1704989663329.png

 

  • There should be no “Parameters”, so click “Next.

PaulBergson_16-1704989663199.png

 

If there are any resources that already exist a remediation task can be created once this “Policy Definition” has been completed. Ensure the following have been completed:

 

Note: If you’re deploying a large number of Azure Monitor Agents (AMA), it’s better to use user-assigned managed identities. These identities are more flexible and can handle more volume compared to system-assigned identities. You can create them once and use them across many virtual machines, which is helpful for big deployments. Remember, each method has its own advantages, so choose based on what your setup needs.

 

  • The “Create a Managed Identity” is selected.
  • Select “System assigned managed identity”.
    • If you want to use a “User assigned managed identity” then the policy needs to be “Configure Windows virtual machines to run Azure Monitor Agent using user-assigned managed identity”.
  • Select the location to where the system assigned identity should reside.
  • Select “Next”.

PaulBergson_17-1704989663168.png

 

  • Enter any details required in the “Non-compliance message”.
  • Select “Next”.

PaulBergson_18-1704989663127.png

 

  • The policy definition should look similar to below.
  • Select “Create”.

PaulBergson_19-1704989663139.png

 

 

Verify that the AMA Agent Install Policy was Assigned and Create a Remediation Task for Any Existing Windows Servers

  • Browse to Policy > Authoring / Assignments.
    • Review the “Assignment name” column looking for the newly created Assignment.

PaulBergson_20-1704989663214.png

 

For servers that already exist, a remediation task will need to be run to install the AMA agent. The following steps will create a remediation task to install the AMA agent on any servers in the scope defined.

  • Click on the newly created Policy Assignment

PaulBergson_21-1704989663141.png

 

  • On the “New remediation task” window, click on “Applicable resource to remediate”.

PaulBergson_22-1704989663247.png

 

  • Select a “Scope” to remediate.

PaulBergson_23-1704989663142.png

 

 

Any servers that don’t have the AMA agent loaded should now appear under the “Name” column.

PaulBergson_24-1704989663129.png

 

  • Click on “Remediate”.

A remediation task should now commence.

PaulBergson_25-1704989663394.png

 

Verify that the Windows AMA Agent Installation Remediation Worked

Wait about 5 minutes…

  • Browse to Azure Virtual machines.
    • Click on “Extensions + applications”
      • On the “Extensions” tab, verify that the “AzureMonitorWindows Agent” is installed.
    • Select a VM that was to be remediated

PaulBergson_26-1704989663210.png

 

 

Using Azure Policy to install the Windows Data Collection Rule

A policy must be made to link the DCR that was created earlier to the same scope as the assignment for the AMA agent.

  • Browse to the “Policy” blade, similar to before and select “Definitions”.

PaulBergson_27-1704989663174.png

 

  • Click on the “Search” box.
    • Enter “Configure Windows virtual machines”.

 

  • To the right of “Configure Windows virtual machines to be associated with a Data Collection Rule or a Data Collection Endpoint”
    • Click on the ellipse (the three dots at the end of the Name) and select “Assign”.

PaulBergson_28-1704989663164.png

 

PaulBergson_29-1704989663148.png

 

  • Enter the correct “Scope”.
  • Enter any “Exclusions”, if needed.
  • Enter the “Assignment Name”.
  • Click “Next”.

PaulBergson_30-1704989663377.png

 

  • There is nothing to configure on the “Advanced” tab.
  • Click on “Next”.

PaulBergson_31-1704989663251.png

 

  • Open a new browser tab and browse to Azure Monitor.
  • Under “Settings”, select “Data Collection Rules”.

PaulBergson_32-1704989663256.png

 

  • From the work earlier in this process, select the DCR rule created.

PaulBergson_33-1704989663165.png

 

  • From the “Overview” blade, select the “JSON View”.

PaulBergson_34-1704989663166.png

 

  • Click on the “Copy” at the end of the Resource ID”.

PaulBergson_35-1704989663147.png

 

 

  • Switch back to the Policy browser tab.
  • On the “Parameters” tab, paste the “Resource Id” into the “Data Collection Rule Resource Id or Data Collection Endpoint Resource Id” entry box.
  • Select “Next”.

PaulBergson_36-1704989663209.png

 

  • On the “Remediation” tab, leave as default and click Next.

PaulBergson_37-1704989663230.png

 

  • On the “Non-compliance messages” tab, enter a message for out of compliance servers.
  • Click Next

PaulBergson_38-1704989663216.png

 

  • The policy definition should look similar to below.
  • Select “Create”.

PaulBergson_39-1704989663159.png

 

 

The Policy assignments for any new servers will have the DCR applied against the scope as defined in the policy settings. For any current servers, a Remediation task will need to be run to upload the DCR to any existing servers in “Scope”.

Verify that the DCR Policy was Uploaded and Create a Remediation Task for Any Existing Windows Servers

  • Browse to Policy > Authoring / Assignments.
    • Review the “Assignment name” column looking for the newly created Assignment.

For servers that already exist, a remediation task will need to be run to upload the DCR definition. The following steps will create a remediation task to upload the DCR definition any servers in the scope defined.

  • Click on the newly created Policy Assignment

 

PaulBergson_40-1704989663124.png

 

  • Click on “Create remediation task”.

PaulBergson_41-1704989663275.png

 

  • Click on the “Scope” within the “Applicable resources to remediate”.

PaulBergson_42-1704989663205.png

 

  • Select the scope to remediate and click “Select”.

PaulBergson_43-1704989663173.png

 

  • Click on “Remediate”.

PaulBergson_44-1704989663130.png

 

Give the system about 10 minutes to push the DCR and data to start flowing, then you can verify that data is being uploaded to the Log Analytics Workspace (LAW) defined in the DCR. Open up a new browser tab and browse to the Log Analytics Workspace defined in the DCR. 

 

Note: If the MMA agent is currently sending data, then query 2 below will be needed to ensure data is being sent by the AMA agent.

  • Click on “Logs”
    • Run the query below.

Search “Server Name”
| summarize count () by $table

 

Data from multiple tables should now be found.

PaulBergson_45-1704989663456.png

 

To further ensure the data is coming specifically from the AMA agent run the following query. The “Category” column contains the agent that uploaded the data to the LAW.

Heartbeat
| project Computer, Category

PaulBergson_46-1704989663105.png

 

Creating a DCR for Linux Machines

  • Browse to the Azure “Monitor” blade and select “Data Collection Rules”.

PaulBergson_47-1704989663421.png

 

  • Select “Create.
  • Enter Rule Name.
  • Subscription.
  • Resource Group.
  • Region.
    • This needs to be in the same location as the Log Analytics Workspace.
  • Platform Type.

PaulBergson_48-1704989663161.png

 

  • Select “Next: Resources >”.
  • Click on the “Add resources”.

PaulBergson_49-1704989663160.png

 

  • Drill down through the subscription to find a resource. In this example I have selected a single host “Ubuntu-01”. The DCR rules created for this host will be used to apply against all the machines that fall within the Azure Policy.
  • Click “Apply”.

PaulBergson_50-1704989663123.png

 

  • Select “Next: Collect and deliver >”.
  • Select “+ Add data source”.
  • Select “Data source type”.
    • In this example we will select “Linux syslog”.

At this point here is a key difference from the MMA agent. The data can now be filtered. For now, the example shown will choose the complete set of Event from a log file, but they could be filtered using an XPath definition.

Before we continue on, I just wanted to show that if the “Custom” definition of logs is selected, it can be noted that there are no logs being collected.

  • Review the level of logging to capture the logs for each “Facility”.

PaulBergson_51-1704989663261.png

 

PaulBergson_52-1704989663363.png

 

  • Select the “Destination” tab.
    • Select “Destination type”, “Subscription” and “Account or namespace”.
    • Click the “Add destination” button.

PaulBergson_53-1704989663252.png

 

  • Select “Add data source”.
  • Select “Next: Review + Create >”.

PaulBergson_54-1704989663140.png

 

  • Select “Create”.
  • Select “Go to Resource”.
  • From the “Overview” blade, select the “JSON View”.
  • In a later step you will need to copy the “Resource ID”.

PaulBergson_55-1704989663118.png

 

Using Azure Policy to install the Linux Azure Monitoring Agent

 

Note: You must have system-assigned managed identity enabled on each virtual machine before you deploy the agent.

  • Open a new browser tab and browse to Azure Virtual machines.
  • Select a Linux vm that needs to have the AMA agent loaded on it.
    • Verify that the “Status” = “on”.
    • Select “Settings/Identity”.
    • Ensure you are on the “System assigned” tab.

Repeat the above for any machines that you are unclear if the System assigned status is enabled.

  • Browse to Azure Policy.
  • Select “Definitions”.

PaulBergson_56-1704989663200.png

 

  • Click on the “Search” box.
    • Enter “Configure Linux virtual machines to”.

PaulBergson_57-1704989663222.png

 

  • Select “Configure Linux virtual machines to run Azure Monitor Agent with System-assigned managed identity-based authentication”.
  • Click on the ellipse (the three dots at the end of the Name) and select “Assign policy”.

PaulBergson_58-1704989663265.png

 

  • Enter the correct “Scope”.
  • Enter any “Exclusions”, if needed.
  • Enter a name for “Assignment name”.
  • Select “Next”.

PaulBergson_59-1704989663308.png

 

  • There should be no “Advanced”, so click “Next.

PaulBergson_60-1704989663106.png

 

  • There should be no “Parameters”, so click Next.

PaulBergson_61-1704989663190.png

 

  • Select “Create a remediation task” and in the drop down box select “Configure Linux virtual machines to run Azure Monitor Agent using system-assigned managed identity”.
  • Select “System assigned managed identity”.
  • Select the location to where the system assigned identity should reside.
  • Select “Next”.

PaulBergson_62-1704989663162.png

 

  • Enter free form in the “Non-compliance message”, if you so choose.
  • Select “Next”.

PaulBergson_63-1704989663233.png

 

  • The policy definition should look similar to below.
  • Select “Create”.

PaulBergson_64-1704989663171.png

 

 

Using Azure Policy to install the Linux Data Collection Rules

Now a policy will need to be created to assign the previously created DCR to the same scope as the assignment for the AMA agent.

  • Browse to the “Policy” blade, similar to before and select “Definitions”.

PaulBergson_65-1704989663182.png

 

  • Click on the “Search” box.
    • Enter “Configure Linux virtual machines”.

PaulBergson_66-1704989663185.png

 

  • Select “Configure Linux virtual machines to be associated with a Data Collection Rule”.
  • Click on the ellipse (the three dots at the end of the Name) and select “Assign”.

PaulBergson_67-1704989663212.png

 

  • Enter the correct “Scope”.
  • Enter any “Exclusions”, if needed.
  • Enter a name for “Assignment name”.
  • Select “Next”.

PaulBergson_68-1704989663194.png

 

  • There is nothing to do on the “Advanced” tab, click “Next”.
  • Browse back to the tab with the “Data Collection Rule.
  • Click on the “Copy” at the end of the Resource ID”.

PaulBergson_69-1704989663150.png

 

 

  • Switch back to the Policy browser tab.
  • Paste the “Resource Id” into the “Data Collection Rule Resource Id”.
  • Select “Next”.

PaulBergson_70-1704989663149.png

 

  • Select “Create a remediation task” and in the drop-down box select “Configure Linux virtual machines to be associated with a Data Collection Rule”.
  • Click “Create a Managed Identity”
  • Select “System assigned managed identity”.
    • If you want to use a “User assigned managed identity” then a User Managed Identity will be required.
  • Select the location to where the system assigned identity should reside.
  • Select “Next”.

PaulBergson_71-1704989663389.png

 

  • Enter free form in the “Non-compliance message”, if so chosen.
  • Select “Next”.

PaulBergson_72-1704989663241.png

 

  • The policy definition should look similar to below.
  • Select “Create”.

PaulBergson_73-1704989663115.png

 

 

Verify Policy Assignments Have Been Completed

I would suggest taking a 5-minute break.

  • Browse to the Azure Policy “Compliance” blade.
  • Search for the Policies for Linux servers just created and click on both (one at a time), to verify the servers in scope have all had the policies applied.

PaulBergson_74-1704989663263.png

 

PaulBergson_75-1704989663180.png

 

PaulBergson_76-1704989663116.png

 



Installation of the AMA agent and Push of the DCR Definition on Azure ARC Hosts

Using Azure Policy to install the Windows Azure Monitoring Agent for Azure ARC

Note: Although the documentation doesn’t specifically call out that installing the agent on Windows 10/11 or later (Current documentation only states the MSI) is supported via Azure Policy, this is being amended to reflect that endpoint workstations are supported pushing the AMA agent via Azure policy.  #18

 

The assumption has been made that Azure ARC has been installed on the Windows and Linux servers that are to be managed in the following section. To verify is Azure ARC has been loaded on a server:

  • Browse to Azure > Azure Arc > Infrastructure / Machines
    • Review the names of the servers that are to have the AMA agent/DCR definition pushed to them.

PaulBergson_77-1704989663111.png

 

Installing the Windows AMA ARC Agent is almost the same with the exception of the policy name. In the Policy “Search” enter “Configure windows ARC” and select “Configure Windows ARC-enabled machines to run Azure Monitor Agent”. 

From this point forward, please follow the instructions defined in “Using Azure Policy to install the Windows Azure Monitoring Agent”.

PaulBergson_78-1704989663184.png

 

 

Using Azure Policy to install the Windows Data Collection Rule for Azure ARC 

Installing the Windows Data Collection Rule (DCR) is almost the same with the exception of the policy name. In the Policy “Search” enter “Configure windows ARC” and select “Configure Windows ARC Machines to be associated with a Data Collection Rule”. 

From this point forward, please follow the instructions defined in “Using Azure Policy to install the Windows Data Collection Rule”.

PaulBergson_79-1704989663257.png

 

 

Using Azure Policy to install the Linux Azure Monitoring Agent for Azure ARC

Installing the Linux AMA ARC Agent is almost the same with the exception of the policy name. In the Policy “Search” enter “Configure Linux ARC” and select “Configure Linux ARC-enabled machines to run Azure Monitor Agent”. 

From this point forward, please follow the instructions defined in “Using Azure Policy to install the Linux Azure Monitoring Agent”.

PaulBergson_80-1704989663183.png

 

 

Using Azure Policy to install the Linux Data Collection Rule for Azure ARC

Installing the Linux DCR definition  is almost the same with the exception of the policy name. In the Policy “Search” enter “Configure Linux ARC” and select “Configure Linux ARC Machines to be associated with a Data Collection Rule”. 

From this point forward, please follow the instructions defined in “Using Azure Policy to install the Linux Data Collection Rule”.

PaulBergson_81-1704989663203.png

 

 

Verify Agents Are Communicating with Azure

Querying the Heartbeat Table

To verify that an agent was connected to your Log Analytics Workspace You can verify whether or not the machines are reporting to Log Analytics with the use of Kusto and querying the Heartbeat table.

 

The table “Heartbeat” is regularly sent a signal (every minute) from each server monitored. By simply using KQL to see if a heartbeat exists that is coming from each server, you can quickly verify that the servers are able to send Azure data.

 

Heartbeat

| where Category =~ "azure monitor agent"

| distinct Computer

 

PaulBergson_82-1704989663339.png

Find Out Which Agents are Loaded and Where

There is a workbook that is available within Azure Monitor that will provide the details for every agent that is connected to the subscriptions selected within the workbook. The workbook name is “AMA Migration Helper”.

  • Open up the Azure portal and browse to Azure Monitor
    • Workbooks > Azure Monitor Essentials/AMA Migration Helper

PaulBergson_0-1705502664456.png

 

  • Select the Subscription(s), Workspace(s) and TimeRange.

PaulBergson_1-1705502664461.png

 

  • The findings should now be available in one of the 6 tabs in this workbook.
    • The full “Migration Status” can be found at the bottom of the blade.

 

Note in the example below it can be seen that both subscriptions have had all device migrated to the new AMA client.

PaulBergson_2-1705502664459.png

 

  • Selecting the “Azure Virtual Machines” displays the number of servers found within Azure, for the selected location and time range.

PaulBergson_3-1705502664458.png

 

Walk through all the tabs to get a complete list of assets and their status.

 

AMA Data Sources and Locations

The location of where log files are sent to can be found in the table below. *7

PaulBergson_83-1704989663144.png

OMS Gateway

Some people might worry that the OMS gateway will disappear when the MMA agent retires. This is a valid point, but Microsoft will continue to support the gateway until they have a replacement or choose to retire it.

The steps below will explain how to continue to use the gateway and end use of the MMA agent’s data capture.

  • If the host that acts as a gateway is also collecting data with the MMA agent, make sure that the AMA agent is set up and a DCR definition has been sent to this host according to the information given earlier in this document.
  • Within the Azure portal browse to the Log Analytics Workspace.
    • Select the Workspace to manage.
  • Within each of the 5 tabs, remove any defined logs that are actively capturing data.
    • Windows event logs.
    • Windows performance counters.
    • Linux performance counters.
    • Syslog
    • IIS Logs

PaulBergson_0-1705678142761.png

 

After the Logs definition for each of the capture tabs is cleared, the MMA agent will stop sending data to the Log Analytics Workspace. The AMA agent will be unaffected by this change, as its capture definition is based on the DCR.

MMA Agent Removal

After you migrate your machines to the Azure Monitor Agent (AMA), you need to remove the Log Analytics Agent (also called the Microsoft Management Agent or MMA) to avoid duplication of logs. The Azure Tenant Security Solution (AzTS) MMA Discovery and Removal Utility can centrally remove the MMA extension from Azure virtual machines (VMs), Azure virtual machine scale sets, and Azure Arc servers from a tenant.  #18

 

I also have a blog posted on how to remove the MMA agent in bulk.  *17

 

AMA Migration helper

“AMA Migration Helper is a workbook-based Azure Monitor solution that helps you discover what to migrate and track progress as you move from Log Analytics Agent to Azure Monitor Agent. Use this single pane of glass view to expedite and track the status of your agent migration journey.

Do not remove the legacy agents if being used by other Azure solutions or services. Use the migration helper to discover which solutions/services you use today.” *13

 



References

  1. Log Analytics agent overview - Azure Monitor | Microsoft Docs
  2. Azure Monitor agent overview - Azure Monitor | Microsoft Docs
  3. Overview of the Azure monitoring agents - Azure Monitor | Microsoft Docs
  4. Data Collection Rules in Azure Monitor - Azure Monitor | Microsoft Docs
  5. Troubleshoot the Azure Monitor agent on Windows virtual machines and scale sets - Azure Monitor | Mi...
  6. Manage the Azure Monitor agent - Azure Monitor | Microsoft Docs
  7. Azure Monitor agent overview - Azure Monitor | Microsoft Docs
  8. Monitor data from virtual machines with Azure Monitor agent - Azure Monitor | Microsoft Docs
  9. Data collection transformations - Azure Monitor | Microsoft Docs 
  10. Azure Monitor agent overview - Azure Monitor | Microsoft Docs
  11. Azure Monitor FAQ - Azure Monitor | Microsoft Docs
  12. Azure Monitor agent overview - Azure Monitor | Microsoft Docs
  13. Tools for migrating to Azure Monitor Agent from legacy agents - Azure Monitor | Microsoft Docs
  14. XPath
    1. Connect Microsoft Sentinel to Azure, Windows, and Microsoft services | Microsoft Docs
  15. Tutorial - Editing Data Collection Rules - Azure Monitor | Microsoft Docs
  16. Tutorial - Send data to Azure Monitor Logs using REST API (Resource Manager templates) - Azure Monit...
  17. Azure MMA Agent Bulk Removal - Microsoft Community Hub
  18. MMA Discovery and Removal Utility - Azure Monitor | Microsoft Learn
8 Comments
Co-Authors
Version history
Last update:
‎Feb 07 2024 04:58 PM
Updated by: