Plan Your Migration

In our blog series, we’ll review the steps required for migrating from the MMA (Microsoft Monitoring Agent), also known as the Log Analytics agent, to the AMA (Azure Monitor Agent).

In this post we focus on creating the PLAN for your migration. Refer to the previous blog, UNDERSTAND, if you haven’t covered before reaching this page. 

We highly recommend beginning your journey by reading through Microsoft’s excellent Learn documentation where they have a dedicated page on this topic: Migrate to Azure Monitor Agent from Log Analytics agent.

The bulk of this planning phase is related to onboarding the on-premises systems with Azure Arc, which is where we will start. The latter part of this post will review planning for the Azure Monitor Agent deployment. 

Tracking Migration Progress 

Microsoft has a helpful Azure Monitor Agent Migration Helper workbook prepopulated to help track migration status. Please review and use it to help track your migration.

Linux Host Onboarding Decisions 

There are 2 different ways to onboard Linux systems in your environment. You can either onboard all systems directly with Azure Arc and the AMA, or you can use dedicated syslog collectors for collection of Linux server events, and both options have their pros. 

• Individual Linux host onboarding with ARC + AMA 
  • Required for Defender for Server plan 2 Sentinel ingestion credit. If your organization is licensing these Linux servers with Defender for Server Plan 2, you will need these hosts to be directly onboarded with Arc + AMA to get the 500MB per system per day ingestion credit to Log Analytics (also extends to Sentinel if you’re using simplified billing) 
  • Connects all systems into Azure Arc which affords system management from Azure 
  • Streams all logs directly to Log Analytics over HTTPS rather than having to ensure syslog is able to communicate from all of your servers to your syslog collectors 
• Syslog collector method 
  • No additional application installation requirements on individual Linux hosts, instead merely requiring an rsyslog or syslog-ng configuration tweak to send logs to collectors 
  • If you’re collecting network or firewall logs already, you likely already have the required collectors in the environment 

Azure Arc Deployment (non-Azure native systems) 

Before beginning to onboard your systems with Azure Arc, you will need to: 

• Ensure that your environment and operating systems are supported at Connected Machine agent prerequisites 
• Ensure that you have the following Azure resource providers registered in your target subscription (for instructions how to add resource providers, please see Azure resource providers prerequisites): 
  • Microsoft.HybridCompute 
  • Microsoft.GuestConfiguration 
  • Microsoft.HybridConnectivity 
  • Microsoft.AzureArcData (if you plan to Arc-enable SQL Server instances) 
• Identify if you have a direct/open connection to the internet or you need any custom configurations for proxy or private endpoint and if so, reviewing the Azure ARC connectivity options and the network requirements for Azure Arc-enabled servers and modify your deployment strategy accordingly. 

Next you will need to identify how you will onboard the systems.  

A list of all onboarding methods can be found at Microsoft Learn at Azure Arc Onboarding Methods. Our recommendation if you have a large fleet of systems is to use one of the methods marked as “at scale” which requires creation of a Service Principal Name (SPN, directions included) and corresponding secret, which is then used in the onboarding script to facilitate at-scale system onboarding.  

Alternatively, if you have just a handful of systems to onboard, you can simply ensure that your Azure account has the Azure Connected Machine Onboarding role (recommended, most limited) or the Contributor role (most power) and onboard the systems interactively one at a time with the Learn article Connect hybrid machines to Azure using a deployment script ensuring that you have administrative permissions to all hosts that you intend to onboard (Administrator for Windows and root/sudo for Linux). 

Afterwards you need to decide if you are going to add the systems all to one Resource Group (simplest) or if you have a more complicated administrative/management structure that will require multiple resource groups to be created. Note that if you decide on multiple resource groups, you will need to create onboarding scripts for each subset of systems, including the aforementioned permission requirements to the SPN (or multiple SPNs) for each resource group, which will add both rollout and continuous management complexity. 

Once you complete onboarding systems to Azure Arc, the next step is to push the Azure Monitor agent to systems for log collection. 

Azure Monitor Agent (AMA) Deployment (all systems) 

Before beginning to deploy the Azure Monitor Agent to your systems, you will need to: 

• Ensure that your environment and operating systems are supported at AMA supported operating systems. 
• Identify if you have a direct/open connection to the internet or you need any custom configurations for proxy or private endpoint and if so, reviewing the proxy or private endpoint links for AMA connectivity options and the network requirements for the Azure Monitor Agent and modify your deployment strategy accordingly. 
• Ensure a managed identity is created on all Azure VMs, as it’s part of the onboarding process with Arc, otherwise a system-assigned managed identity will be automatically pushed to the systems for pushing the AMA when you create Data Collection Rules to collect system logs. 
• Use the DCR Config generator from Microsoft to assist with the migration of any ingestion transformations that may need to be migrated when moving from the MMA (workspace transformation) to the AMA (DCR transformations). 

The simplest way to push the AMA extension to systems is through the creation of Data Collection rules which we will cover in the next post for Testing. BlueVoyant recommends creating (at minimum) 2 data collection rules for Windows systems (Security events and System/Application events) and 1-2 data collection rules for Linux (Syslog and if applicable, CEF [Common Event Format] logs). Some more complex environments may prefer to have different collection rules for different subsets of systems, but keep in mind this will add both rollout and continuous management complexity.  

Note: This can also be done in an automated fashion with Azure Policy. If you are interested in onboarding systems with Azure Policy on your own, please reach out to your CSM for supplemental documentation for Azure policy.  

In conclusion, planning for your migration from the Microsoft Monitoring Agent (MMA) to the Azure Monitor Agent (AMA) requires a thorough understanding of your current infrastructure and future needs.  

Key considerations include onboarding on-premises systems with Azure Arc, tracking migration progress, making Linux host onboarding decisions, and planning for Azure Arc and Azure Monitor Agent deployment. Important factors to consider include system requirements, network connectivity options, onboarding methods, resource group management, and data collection rules.  

Remember, Microsoft provides comprehensive resources to guide you through each step of this process.  

Following these steps will ensure a smooth transition to the Azure Monitor Agent, ultimately enhancing your system management capabilities. The next post will dive into testing as we continue our journey on migrating to AMA.