Migration Plan for moving from MMA to AMA

In this blog I break down the migration plan | process for migrating from the legacy MMA to the modernized AMA agent as per Microsoft’s recommendations. The aim of the procedures stipulated below are to ensure a safe and non-disruptive AMA migration and deployment during the migration proces using an incremental and controlled strategy.

As we all should know by now, the current Log Analytics agent (also known as MMA) for both Windows and Linux virtual machines, both in Azure and non-Azure (on-prem and 3rd party clouds) will be retired on August 31, 2024. Thus, if you are using the Log Analytics agent with Azure Monitor or any of the other supported features and services, you should start planning your migration to the newer version called Azure Monitor Agent.

Migration Plan:

During the migration plan, do not remove any legacy agents being used by other Azure solutions or services. Use the migration helper to discover which solutions and services that are currently being used.

Migration steps:

Step 1 - Monitoring Solution Analysis

The AMA Migration Helper is a workbook-based Azure Monitor solution that helps you perform a current / as-is discovery of what configurations to migrate and track the progress as you migrate and modernize from Log Analytics Agent to Azure Monitor Agent.

Go to your Azure portal > Monitor > Workbooks > Public Templates > Azure Monitor essentials > select AMA Migration Helper,

On the Azure Monitor Migration Helper, select your filters > and then scroll down to Migration Status,

Migration Status:

The Migration status shows us our current state.

I have deployed a new virtual machine with only MMA for this migration exercise in the highlighted subscription.

Step 2 – Provisioning Data Collection Rules

Use the DCR Config Generator tool to parse Log Analytics Agent configuration from your workspaces and generate/deploy corresponding data collection rules automatically. You can then associate the rules to machines running the new agent using built-in association policies.

2.1 Install the DCR Config Generator:

1. Download the PowerShell script zip file,
2. Extract the zip file into a target folder,
3. Change to the target folder location,
4. Run the PowerShell script:

$subId = "00000000-0000-0000-0000-0000000000"
$rgName = "resource group name of your connected workspace"
$workspaceName = "Name of the current connected workspace"
$dcrName = "Name of the new DCR"
$location = "Region location for the new DCR"
$folderPath = "." #specify the output location of your json files. By default, Azure Monitor uses the current directory.

.\WorkspaceConfigToDCRMigrationTool.ps1 -SubscriptionId $subId -ResourceGroupName $rgName -WorkspaceName $workspaceName -DCRName $dcrName -Location $location -FolderPath $folderPath -GetDcrPayload

# -GetDcrPayload is optional and is used to generate the .json files if so desired. Omitting this final option, will only output the ARM template and parameter files for you.

The script can produce two types of ARM template files, depending on the agent configuration in the target workspace:

#1 Windows ARM template and parameter files – if the target workspace contains Windows performance counters or Windows events.

#2 Linux ARM template and parameter files – if the target workspace contains Linux performance counters or Linux Syslog events.

#3 If you run the -GetDcrPayload, then you will be generating an additional set of .json files

2.2 – Deploy your generated ARM templates

Use the ARM templates to generate the DCR’s using your custom templates in the Azure portal.

The WorkspaceConfigToDCRMigrationTool.ps1 powershell script is able to parse data such as existing PerformanceCounters, WindowEvents includeing xpath queries, as well as LinuxSyslogs and use this information to provision the DCR’s along with their destination Log Analytic Workspaces.

2.3 – Populate the DCR’s

Now associate your source virtual machines to your newly provisioned data collection rules:

From the Monitor > Data Collection Rules > select your data collection rule > view resources > Add > select your machines > Apply.

So what if you have hundreds or thousands of virtual machines to onboard into DCR’s? How can we automate the ingestion of these endpoints as resources into a DCR? Click on this link for a quick walkthru on how to configure the azure policy for linking your virtual machines as resources at scale.

Step 3 – Identity your non-Production / Testing / Dev / Scope

Begin testing deployment by provisioning your AMA to a few resources running in your non-production environments,

Step 4 - Validation

After you validate that data is flowing as expected with Azure Monitor Agent, check the Category column in the Heartbeat table on the target Log Analytics Workspace for the value Azure Monitor Agent for AMA collected data. Ensure it matches data flowing through the existing Log Analytics agent.

Step 5 - Production Testing

After you have validated the data collected on your non-production / test resource scope, roll out the AMA to production by repeating the same procedure,

Step 6 - Removing MMA

The MMA agent deployment needs to be removed from the platform to ensure that no duplicate charges are incurred once the verification process has been concluded.

Completion

This completes your migration plan to AMA.

(Alternaltive Option) Provision via (MDC) Microsoft Defender

All newly deployed and existing virtual machines can be subject to automated deployment of the AMA agent at a subscription level and may also be configured via the (MDC) Microsoft Defender for Cloud console whereby the AMA will be enabled and pointed to a target Log Analytics Workspace. This ensures that all newly deployed virtual machines are automatically provisioned with AMA and automatically joined to the target Log Analytics Agent to ensure that all servers are monitored across the subscription thus ensuring that no newly deployed virtual machines slip through the cracks. The destination / target Log Analytics Workspace may be connected to a SIEM.