Gain Fundamental Knowledge

In this 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).   

Time is short and organizations need to start migrating now. MMA will be retired on August 31, 2024. 

AMA offers several benefits such as introducing a more flexible approach to configuring data collection using Data Collection Rules. With DCRs, you can choose specific events to collect, making it easier to tailor data collection to your needs. AMA also consolidates and improves on the legacy Log Analytics agents and provides cost savings and simpler management.   

This is the first part of a five-part series that follows the methodology illustrated below: 

Migration Process 2x

This is the first of the series, which will review foundational knowledge prior to migrating. 

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

New Concepts: 

  • Data Collection Rules (DRCs) are instructions supporting data collection and ingestion transformation into your Log Analytics Workspace, the foundation for Microsoft Sentinel. These will need to be created and attached to your systems to collect logs with the Azure Monitor Agent. For more information, review the Microsoft Learn article: Data collection rules in Azure Monitor.
  • Data Collection Endpoints are a component of the Azure Monitor Agent pipeline that are required for custom text file parsing and ingestion, covering Windows logs such as IIS, as well as DHCP or any other text based logs that may reside on your system. 
    For more information, review the Microsoft Learn article: Data collection endpoints in Azure Monitor. 

Changes: 

  • The Azure Connected Machine agent is a prerequisite for your on-premises servers to install the Azure Monitor Agent (AMA). The Azure Connected Machine agent bridges your on-premises systems to Azure, through Azure Arc, which allows each system to be treated as a resource within Azure for management. This requires planning for access management of the systems within Azure and Microsoft has a good Learn document that should be reviewed for Identity and access management for Azure Arc-enabled servers. 
    • After the system is onboarded with Azure Arc, systems can be onboarded directly to DCRs (Data Collection Rules) which automatically installs the AMA extension on hosts or utilize Azure policy for automatic installation of the AMA and DCR rule attachment.  
  • For Windows workstations, the AMA requires that all workstations be joined to a Microsoft Entra tenant, either AADj or Hybrid AADj machines. Afterwards, you can install with an MSI installer. For more information, see the Microsoft Learn article: Install Azure Monitor agent on Windows client devices using the client installer  
  • Azure VM (Virtual Machine) changes: 
    • You no longer need to install the MMA on systems. You can either attach Azure VMs directly to DCRs (Data Collection Rules) which automatically installs the AMA extension on hosts, or utilize Azure policy for automatic installation of the AMA and DCR rule attachment. 
  • The AMA moves from Workspace Ingestion Transformations to Data Collection Rule transformations. 
    • Traditionally, workspace transformations were configured directly on the Log Analytics Workspace tables using Workspace transformations. The new transformation location is directly within the Data Collection Rules themselves. 
  • Data duplication during migration 
    • If you have two collection agents on the same machine it will duplicate data. This should be avoided as collecting duplicate data from the same machine can skew query results, affect downstream features like alerts, dashboards, and workbooks, and generate extra charges for data ingestion and retention. 
      Microsoft provides a few different recommendations to avoid ingestion duplication. The simplest solution is to either disable the legacy connector to stop ingestion of logs from all legacy agents at once, or a more programmatic solution is to onboard systems, verify collection with the AMA, then remove the MMA from the system. 
  • Connectivity requirement changes 
    • Please review and be aware of the Microsoft Learn document for network requirements for Azure Arc-enabled servers as well as the network requirements for the Azure Monitor Agent. If you have a network environment with either outbound connectivity restrictions or HTTPS inspection, you will need to implement network changes to facilitate an easy migration.
  • Permission requirement changes 
    • Please review and be aware of the permission requirements for onboarding systems with the Azure Arc.  
    • Please review and be aware of the permission requirements for onboarding systems to the Azure Monitor Agent.  
  • There are changes to Syslog collectors not managed by BlueVoyant. If you are standing up a Syslog collector to receive Syslog and Common Event Format logs from other hosts/devices, please review the supplemental blog for Syslog Collector Testing for planning considerations after you have reviewed the planning and testing blog posts.

Also Good to Know: 

Microsoft has tools created to assist with the migration Tools for migrating from Log Analytics Agent to Azure Monitor Agent, a Windows and a Linux Azure Monitor Agent troubleshooting application, as well as troubleshooting guides for both Windows (VM & Arc-connected) and Linux (VM & Syslog). 

Thanks for joining us for this foundational understanding review. Please see the next blog post in this series: Plan Your Migration.

Additional Readings

View All