The Case of Connected Machine Agent and Microsoft Monitoring Agent on the Same Server with Azure Arc

Hey Checkyourlogs Fans,

Today, we encountered an issue when deploying Azure Arc with a customer and discovered that when deploying the Azure Arc Connected Machine Agent, some machines had a very old version of the Microsoft Monitoring Agent deployed. These seemed to coexist fine, but here is some of our research on the ramifications of having both agents/extensions running at the same time.  As it turned out for us, the duplication of agents came from the deployment of Microsoft Defender Endpoint from security.microsoft.com, which had the MMA as a deprecated requirement for protecting the systems.    Anyway, here are our findings.

Overview of Agents Involved

• Microsoft Monitoring Agent (MMA) – Also known as the Log Analytics agent or OMS agent, this legacy monitoring agent reports to an Azure Log Analytics workspace. It collects events, performance counters, etc., and is traditionally installed directly on servers (manually or via solutions like SCOM or Azure Automation). (Note: MMA was officially retired as of August 31, 2024​.)
• Azure Arc Connected Machine Agent – This agent onboards a non-Azure machine into Azure Arc (projecting the server as an Azure resource). It primarily provides management and governance capabilities (Azure Resource Manager representation, policy, run command, etc.), not telemetry itself. By itself, the Arc agent does not send performance or event logs to Log Analytics. Instead, it enables deploying extensions (such as monitoring agents) on the machine via Azure.
• Log Analytics Agent Extension (OMS extension). This refers to deploying the MMA agent as an Azure VM/Arc extension in an Arc context and, for example, using Azure Arc’s extension management to install MicrosoftMonitoringAgent (Windows) or OMSAgentForLinux (Linux) on the machine and connect it to a specified Log Analytics workspace. This is essentially the same MMA, just managed through Arc.
• Azure Monitor Agent (AMA) – The modern replacement for MMA. Unlike MMA, AMA is typically deployed via Azure Arc or Azure VM extensions (with Data Collection Rules) and supports multi-workspace and more flexible configuration. (As of 2025, AMA is feature-complete for Azure Monitor scenarios and is the recommended agent going forward​.) In Azure Arc, you can deploy AMA as the “AzureMonitorAgent” extension instead of the legacy MMA extension.

Coexistence and Potential Conflicts

Can MMA and Azure Arc (and its extensions) coexist on the same server? – Yes. There are no direct technical conflicts or crashes caused by having both the Azure Arc agent and MMA on a machine. They serve different purposes and run side by side. Microsoft allows the coexistence of the legacy Log Analytics agent (MMA/OMS) with the new Azure Monitor agent on the same machine to facilitate migration and testing. The Azure Arc Connected Machine agent runs independently and does not interfere with MMA’s essential operation.

However, when you use Azure Arc to install a monitoring extension on a machine with MMA, you must consider configuration to avoid unintended overlaps carefully. Key points to note:

• No Automatic Override: One agent will not automatically disable or override the other. If both MMA and AMA (or a second MMA instance via extension) are present and configured, each will attempt to collect and send telemetry as instructed. There is no built-in “precedence” – they operate in parallel. For example, suppose you had MMA already reporting to Workspace A, and then you use Arc to deploy another MMA extension pointing to Workspace B. In that case, the machine reports to two workspaces simultaneously (this is essentially MMA’s supported multi-homing on Windows​). Likewise, if you install the new AMA while MMA is still running, both agents will run concurrently unless one is removed.
• Duplicate Data Risks: The primary “conflict” to be aware of is duplicate data collection. If both agents are configured to collect the same logs or metrics and send them to Log Analytics (whether the same workspace or different ones), the data will be duplicated from that server. Microsoft warns that collecting identical data from two agents on one machine can skew your query results and analytics (e.g. double counting in Azure Monitor or Sentinel) and double your ingestion costs. You should ensure you’re not simultaneously collecting the same counters/events from both agents.
• Resource Consumption: Running two telemetry agents also means higher resource usage on the server. Each agent will consume CPU, memory, and I/O for its operations. Microsoft notes that “running two telemetry agents on the same machine would result in roughly double the resource consumption… including CPU, memory, storage, and network bandwidth”. This overhead is usually acceptable only for short transitional periods.
• Extension Installation Behavior: If you deploy the MMA (Log Analytics) extension via Arc onto a machine that already has MMA manually installed, the outcome depends on the scenario:
  • On Windows, MMA supports multi-homing, so the extension might detect the existing agent and add the new workspace to its configuration (or the installer will reconfigure the existing agent). In this case, you end up with one MMA agent reporting to two workspaces (no second service, just one agent with multiple workspaces). There is no conflict per se, but now that single agent is sending data to both the original and the Arc-specified workspaces.
  • On Linux (legacy OMS agent), multi-homing wasn’t supported similarly. Installing the extension might attempt to re-onboard the agent to the new workspace, potentially replacing the old configuration. This could lead to the machine switching workspaces (unless you manually run multiple agent instances, which is complex). In any case, you wouldn’t normally run two OMS agents on one Linux box – you would choose one workspace or use the new AMA, which can handle multiple via DCR.
  • If instead you deploy the AMA extension via Arc on a machine that still has MMA, you have two different agent services running (since AMA is separate). They can coexist without crashing, but all the duplication considerations apply.

Bottom line: There’s no low-level conflict (the Arc agent + MMA/AMA don’t fight each other), but coexistence must be managed to avoid duplicate telemetry and unnecessary overhead. No priority or precedence; whichever agent is configured to collect specific data will do so independently. Thus, it’s on the administrator to coordinate what each agent is collecting (or disable one of them).

Telemetry and Workspace Considerations

• Single vs Multiple Workspaces: It is technically possible for a single server to send data to two Log Analytics workspaces at once – either by using an agent that supports multi-homing (MMA on Windows can report to up to 4 workspaces​), or by running two different agents each pointed to different workspaces (e.g. MMA to workspace A and AMA to workspace B). Azure Arc could facilitate the latter scenario (for instance, keep your existing MMA connected to an on-prem workspace and use Arc+AMA to send to a cloud workspace). Microsoft generally advises against dual-reporting the same data to multiple workspaces unless necessary. If you do multihome, you will ingest duplicate data sets into each workspace, doubling costs with little added value. The official guidance is to use a single workspace for monitoring wherever possible and leverage Azure’s cross-workspace querying or other features if you need a unified view. Only in specific cases (such as separating security logs to a Sentinel workspace and IT ops data to a different workspace) might multi-workspace connections be justified – and even then, one should partition data types (e.g. send security events to one workspace and performance metrics to another) rather than sending everything to both.
• Telemetry Precedence: If both agents are sending to the same Log Analytics workspace, you may notice that each agent reports heartbeats and data with its own agent identity. For example, the Log Analytics Heartbeat table will contain entries from the MMA (legacy agent) and AMA, distinguished by a “Category” or agent field (MMA vs Azure Monitor Agent). There is no merging of these – the workspace sees them as two sources (even though the “Computer” name is the same). No agent inherently “wins” or overrides data in the workspace; instead, you get two data sets. This can confuse monitoring solutions if not accounted for (e.g. two heartbeat records per minute). When sending to separate workspaces, each workspace will get a complete set of data from its respective agent – again, no conflict, but double volume overall. In short, both agents will faithfully send their telemetry; it’s up to you to prevent overlap.
• Azure Arc’s Role: The Connected Machine agent (Arc) does not send logs to Log Analytics, so having it on the machine doesn’t create duplicate telemetry. However, the Arc is the enabler for deploying Azure Monitor extensions. Suppose you onboard a machine to Arc and do nothing about monitoring. In that case, your existing MMA (if present) will continue working as-is (reporting to whatever workspace it was configured for), and Arc will manage the server as an Azure resource. If you choose to use Azure Arc to deploy a monitoring extension:
  • Deploying MMA via Arc to the same workspace the server was already in will ensure the agent is installed (which it already was) – often, this scenario is unnecessary. If the goal is to move to Azure-managed monitoring, you’d more likely deploy MMA to a new workspace or, preferably, AMA.
  • Deploying AMA via Arc while MMA is still running means the machine will start sending data via AMA/DCR to the target workspace in addition to whatever MMA was sending. This is the typical migration scenario. As noted, you should avoid configuring AMA to collect exactly the same data as MMA at the same time. Instead, you might temporarily have AMA send a subset for testing, send to a different workspace, or ideally stop MMA once AMA is confirmed to be working.
• SCOM (System Center Operations Manager) Consideration: Because MMA is essentially the same agent SCOM uses, a server might already be connected to a SCOM management group. Introducing Azure Arc/AMA does not interfere with SCOM directly – the Arc agent is separate, and AMA is separate from the SCOM-installed agent. If the server’s MMA is dual-purposed for SCOM and Log Analytics, you’d need to maintain that MMA for SCOM regardless of AMA. In such cases, run AMA alongside for Azure Monitor, but be mindful that MMA is still collecting for SCOM (and possibly also sending to a Log Analytics workspace if configured). This scenario can get complex; Microsoft’s long-term strategy is cloud-first, so consider whether data can be unified in Azure Monitor to eliminate parallel systems eventually.

Implications for Data Collection, Duplication, and Billing

Data Collection & Duplication: The same event or metric can be collected twice if both agents are configured overlappingly. For example, suppose MMA is collecting Windows Event Log entries and sending them to Workspace A. AMA (via Arc) is also set to collect the duplicate Event Log entries (via a Data Collection Rule) to Workspace B. The machine will generate one event, but both agents will pick it up and send it to their destinations. Neither agent knows about the other, so they don’t deduplicate. You won’t see duplicates in one workspace unless it receives data from both (which could happen if both agents report to the same place). But across your environment, you have two copies of that event ingested (one in each workspace). This doubles the total volume of data stored. If both were pointed to the same workspace, that workspace would indeed end up with two records of the same event.

From a billing perspective, Azure Log Analytics charges by data volume ingested. Any duplicate data in one workspace or split across two will incur duplicate ingestion costs. Microsoft explicitly highlights that collecting the same data via MMA and AMA in parallel will cost more money for data ingestion and generation. In other words, you pay twice for the same event if you send it twice (even to two different workspaces). There is no discount or detection of duplicates across workspaces – each workspace is billed in isolation for what it receives. Additionally, if you use solutions like Microsoft Sentinel or Defender for Servers, in that case, those are layered on the workspace data (Sentinel charges per GB and Defender per node), and duplicate data can also affect those costs or counts.

Alerting/Monitoring Impacts: Duplicated telemetry can also lead to false alarms or skewed dashboards. Suppose you have alerts set up on performance metrics or events. In that case, two agents reporting might make it look like two occurrences (when only one actual event happened), potentially triggering alerts erroneously or making metrics (like CPU, memory) appear higher than they are (since each agent’s heartbeat or performance counter might be counted twice). The Microsoft guidance notes that duplicate data can “affect downstream features like alerts, dashboards or workbooks”. It’s essential to adjust your queries to filter out duplicates or, better, prevent them by not double-collecting the same signals.

Billing for Multiple Workspaces: If a server intentionally reports different data to two separate workspaces (for example, sending security audit logs to a security-focused workspace and IT ops data to another), you will pay for data ingestion in each workspace. This is expected if the data is different (no duplication of the duplicate log entries). Many enterprises split workloads by workspace to manage access or costs – e.g., one workspace for Sentinel (security logs) and one for general monitoring. In that design, it’s best to configure each agent/workspace to collect only the data needed, minimizing overlap. Microsoft notes that sending all data to both “most likely creates duplicate data in each workspace, which increases your overall cost”. Instead, consider collecting a given data type in only one place and using Azure’s tools to reference it as needed.

Operational Overhead: Managing two sets of agents also means two points of configuration and troubleshooting. You might have two entries for the machine in Azure Monitor agent health views (one per agent type). When something goes wrong, you have to check two pipelines. From a process standpoint, duplicative monitoring can complicate operations and reporting.

Microsoft’s Official Guidance and Best Practices

1. Prefer the New Azure Monitor Agent (AMA) via Arc: Microsoft’s clear direction is to migrate off MMA to the new Azure Monitor Agent, using Azure Arc for non-Azure machines. The legacy agent is deprecated for direct cloud connection. Azure Arc is now required for on-premises/hybrid scenarios to use the new agent and modern Azure Monitor features. The best practice is to install the Arc Connected Machine agent on your servers and then deploy AMA (with appropriate Data Collection Rules) to send data to Log Analytics. This provides a more flexible, centrally managed monitoring setup. MMA should be kept only if necessary (and it will no longer receive support or new features).

2. Avoid Long-Term Coexistence: Running MMA and AMA (or two MMA instances) on the same machine should be seen as a temporary or transitional state. Microsoft recommends this dual-agent scenario only for short periods – for example, to validate that AMA is collecting all the required data before turning MMA off. Prolonged coexistence is not advised due to the duplication and overhead issues discussed. The goal should be to cut over entirely to one agent. If you onboarded a server to Arc that already had MMA, plan a timeframe to migrate its monitoring: deploy AMA via Arc, configure equivalent data collection, and remove or disable the MMA to avoid overlap.

3. If You Must Use Both, Delineate Their Responsibilities: In some enterprises, you might temporarily or permanently have reasons to keep MMA alongside AMA (for example, third-party integrations or SCOM connectivity via MMA). In such cases, carefully segregate what each agent does:

• You might configure MMA to stop collecting specific data and let AMA handle it, or vice versa, so that only one agent collects each data type.
• Or have them report to different workspaces serving different purposes, as noted earlier. Ensure that “if you are [collecting the same data with both], they’re collecting from different machines or going to separate destinations.”​ In other words, avoid double-coverage on the same machine to the same place.
• Use tags or grouping to decide which machines use which agent during a phased migration – for instance, new servers via Arc+AMA, legacy ones keep MMA until migrated.

4. Do Not Rely on MMA for New Deployments: Since the MMA/OMS agent extension is deprecated, you should not plan on using it except for legacy reasons. Azure Arc allows you to block the installation of the MMA extension if you want to ensure no one accidentally deploys it. For example, you can configure the Arc agent’s extension allowlist/blocklist to block “Microsoft.EnterpriseCloud.Monitoring/MicrosoftMonitoringAgent” (the legacy agent extension). This ensures that all new monitoring deployments use AMA. (Many organizations did this as MMA’s retirement in 2024 approached.

5. Single Workspace vs Multiple: Microsoft’s best practice is to minimize the number of Log Analytics workspaces for monitoring because a single workspace can index and segregate data by resource tags or solutions, and it simplifies management and cross-resource queries. If you’re connecting the same server to two workspaces via Arc/MMA, reconsider if that’s needed. In most cases, it’s simpler and cheaper to send all relevant data to one workspace and use role-based access or filters to scope who sees what. If you keep separate workspaces (e.g., a dedicated Sentinel workspace), consider only sending the security-specific logs to that workspace and not duplicating performance logs to reduce cost. Azure Monitor’s documentation explicitly says there’s “typically little reason to multihome agents” except in scenarios like needing to support Azure Monitor and Sentinel/Defender data in isolation.

6. Follow Microsoft’s Migration Guidance: Microsoft provides guidance and even tooling (workbooks, scripts) to help migrate from MMA to AMA.

The process usually involves:

• Using Azure Arc to deploy AMA (while MMA might still be running).
• Setting up Data Collection Rules equivalent to what MMA was collecting (there are migration tools to convert workspace configuration into DCRs).
• Validating that data flows via AMA (for example, checking that heartbeats and events appear with the new agent’s identifier in the workspace).
• Uninstall or disconnect the MMA agent from the machine once AMA is confirmed. (For Arc-connected servers, you can remove the MMA extension via Azure and/or manually uninstall the agent if it was manually installed originally)​.
• Ensure that AMA is not using any Azure Monitor solutions or VM insights. (As of late 2022 and beyond, VM Insights and other monitoring solutions have added support for AMA, so you no longer need MMA for those​.)

7. Consult Official Docs and Support: Microsoft’s documentation and community posts (Azure Monitor docs, Azure Arc docs, and tech community blogs) cover these scenarios in detail.  Microsoft Support and Q&A forums have addressed questions on Arc + MMA coexistence, where the advice consistently is to avoid duplicate configurations and move to the new agent promptly.

In summary, the Azure Arc-connected machine agent (with an MMA/OMS extension) and a pre-existing MMA on a server will not break the server. Still, it can lead to redundant data collection and higher costs if not managed. The recommended approach in an enterprise environment is to transition to a single agent strategy (preferably AMA via Azure Arc) per machine. During any transition phase where both are present, their data collection should be carefully segregated to avoid duplication. Microsoft’s best practice is to use Azure Arc to deploy the Azure Monitor Agent as we advance and to retire the Microsoft Monitoring Agent from active use in your environment once migration is complete. This will ensure the cleanest setup for telemetry, accurate monitoring data, and optimized cost management.

Thanks,

Dave