Migrating from the Azure MMA to AMA Agent

Paul Bergson · ‎Jan 29 2024

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

Select “Create.
Enter Rule Name.
Subscription.
Resource Group.
Region.

This needs to be in the same location as the Log Analytics Workspace.

Platform Type.

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

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.

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.

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

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

Select “Add data source”.

Select “Review + create”.

Select “Create”.

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.

Select “JSON view”

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

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.

Click on the “Search” box.

Enter “Configure Windows virtual machines”.

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

The new tab can be closed.

Click on the ellipse (the three dots at the end of the Name) and select “Assign”.

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

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

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

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

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

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

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.

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

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

Select a “Scope” to remediate.

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

Click on “Remediate”.

A remediation task should now commence.

Verify that the Windows AMA Agent Installation Remediation Worked

Wait about 5 minutes…

Browse to Azure Virtual machines.
- Click on “Extensions + applications”

Select a VM that was to be remediated

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

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

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

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

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

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

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

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

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

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

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

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

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

Click on “Create remediation task”.

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

Select the scope to remediate and click “Select”.

Click on “Remediate”.

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.

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

Creating a DCR for Linux Machines

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

Select “Create.
Enter Rule Name.
Subscription.
Resource Group.
Region.

This needs to be in the same location as the Log Analytics Workspace.

Platform Type.

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

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

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

Select the “Destination” tab.
- Select “Destination type”, “Subscription” and “Account or namespace”.

Click the “Add destination” button.

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

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

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

Click on the “Search” box.

Enter “Configure Linux virtual machines to”.

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

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

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

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

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

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

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

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

Click on the “Search” box.

Enter “Configure Linux virtual machines”.

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

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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.

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

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

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

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

Connect Microsoft Sentinel to Azure, Windows, and Microsoft services | Microsoft Docs

Products (50)

Special Topics (27)

Video Hub (462)

Most Active Hubs