Migrating from the Azure MMA to AMA Agent

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
  • MMA
  • MMA Agent Removal
  • References

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 .

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.

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, 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 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 .

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 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, 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, space, and network bandwidth.

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

AMA is feature complete with MMA with reference to Windows Server. The exceptions are Windows Server 2008 R2, Windows 2008 Sp2, Windows 8 Enterprise and Pro and Windows 7 SP1.  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.

Before you begin to set up your new policies to migrate to the new AMA agent, be aware that if you run both agents at the same time, it can duplicate the data captured. So please take this into consideration and as you bring new AMA collection on board it is recommended to stop collecting the same data from the MMA process.

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

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 Azure Policy.
  • 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

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 that the MSI) is supported, this is being amended to reflect that endpoint workstations are supported utilizing 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:

  • 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 that the MSI) is supported, this is being amended to reflect that endpoint workstations are supported utilizing 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

MMA Gateway

Some people might worry that the MMA 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

The removal of the MMA agent from PowerShell can be done with a relatively simple (Example below) script.

################################################################################################

## This sample is not supported under any Microsoft standard support program or service. 

## The script is provided AS IS without warranty of any kind. Microsoft further disclaims all

## implied warranties including, without limitation, any implied warranties of merchantability

## or of fitness for a particular purpose. The entire risk arising out of the use or performance

## of the sample and documentation remains with you. In no event shall Microsoft, its authors,

## or anyone else involved in the creation, production, or delivery of the script be liable for 

## any damages whatsoever (including, without limitation, damages for loss of business profits, 

## business interruption, loss of business information, or other pecuniary loss) arising out of 

## the use of or inability to use the sample or documentation, even if Microsoft has been advised 

## of the possibility of such damages, rising out of the use of or inability to use the sample 

## script, even if Microsoft has been advised of the possibility of such damages. 

################################################################################################

# Find the Microsoft Monitoring Agent (MMA)

$agent = Get-WmiObject -Query “SELECT * FROM Win32_Product WHERE (Name LIKE ‘Microsoft Monitoring Agent%' OR Name LIKE ‘Microsoft Azure Log Analytics%')”

# Check if the agent is installed

if ($agent -ne $null) {

    # Uninstall the agent

    $agent.Uninstall()

    Write-Host “Azure Monitoring Agent has been uninstalled.”

} else {

    Write-Host “Azure Monitoring Agent is not installed on this machine.”

}

PaulBergson_0-1705596204165.png

The script above could be pushed via a management process to remove in bulk if the more formalized process defined in my blog linked below, isn't the route you would like to take.

I 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

 

This article was originally published by Microsoft's Core Infrastructure and Security Blog. You can find the original article here.