Home / Azure

AzureRunbookIntermediate

Transformation: from the legacy Log Analytics agent to Azure Monitor Agent and data collection rules

Finish the move from the retired Log Analytics (MMA/OMS) agent to Azure Monitor Agent. Inventory agents, translate workspace settings into data collection rules, roll out with Azure Policy, validate data parity and remove the old agent.

Deepak Bhardwaj3 min read

Applies toAzure Monitor Agent on Azure VMs, VM scale sets and Azure Arc servers; Log Analytics workspaces

Background

The Log Analytics agent (MMA on Windows, OMS on Linux) is retired. Machines still running it may stop sending data or lose support. Azure Monitor Agent (AMA) is configured by data collection rules (DCRs) instead of workspace-wide settings, which lets you collect different data from different machines.

1. Inventory

Heartbeat
| where TimeGenerated > ago(1d)
| summarize arg_max(TimeGenerated, *) by Computer
| summarize machines = dcount(Computer) by Category, OSType

Category shows Direct Agent (legacy MMA/OMS) versus Azure Monitor Agent. Also list extensions:

az vm extension list -g rg-app --vm-name vm-app01 --query "[].{name:name, type:typePropertiesType}" -o table

2. Translate what the old agent collected

Check the workspace's legacy agent configuration (Windows event logs, performance counters, Syslog facilities) and solutions that depended on MMA (VM insights, Change Tracking, Update Management, Defender for Servers). Each has an AMA-based replacement or a newer service:

Legacy Replacement
Workspace event log / perf / syslog config DCRs
VM insights (MMA) VM insights with AMA DCR
Update Management Azure Update Manager (no agent dependency)
Change Tracking (MMA) Change Tracking with AMA
Defender for Servers via MMA Defender for Endpoint integration / agentless scanning

3. Create DCRs

{
  "location": "westeurope",
  "properties": {
    "dataSources": {
      "windowsEventLogs": [{
        "name": "system-app-errors",
        "streams": ["Microsoft-Event"],
        "xPathQueries": ["System!*[System[(Level=1 or Level=2 or Level=3)]]", "Application!*[System[(Level=1 or Level=2)]]"]
      }],
      "performanceCounters": [{
        "name": "core-perf",
        "streams": ["Microsoft-Perf"],
        "samplingFrequencyInSeconds": 60,
        "counterSpecifiers": ["\\Processor(_Total)\\% Processor Time", "\\Memory\\Available MBytes", "\\LogicalDisk(*)\\% Free Space"]
      }]
    },
    "destinations": { "logAnalytics": [{ "name": "law", "workspaceResourceId": "<workspace-id>" }] },
    "dataFlows": [{ "streams": ["Microsoft-Event", "Microsoft-Perf"], "destinations": ["law"] }]
  }
}

az monitor data-collection rule create -g rg-mon -n dcr-windows-core --rule-file dcr-windows-core.json

Collect only what you query. DCR XPath filters are the easiest way to cut ingestion cost during the migration.

4. Roll out with policy

Assign the built-in initiatives that deploy AMA and associate DCRs to VMs, scale sets and Arc servers in scope, then run remediation tasks. Enable a system-assigned managed identity on machines (the initiatives can do this).

5. Validate parity

Run both agents side by side for a short period and compare:

Event
| where TimeGenerated > ago(1h)
| summarize count() by Computer, _ResourceId

Check that every alert rule and workbook still gets data. Watch for duplicate records while both agents run.

6. Remove the legacy agent

az vm extension delete -g rg-app --vm-name vm-app01 -n MicrosoftMonitoringAgent   # Windows
az vm extension delete -g rg-app --vm-name vm-app02 -n OmsAgentForLinux           # Linux

Checklist

  • All machines reporting via AMA in Heartbeat
  • DCRs cover every event, counter and syslog source used by alerts
  • Dependent solutions moved (Update Manager, Change Tracking, VM insights)
  • Legacy extensions removed, workspace legacy config cleared

Related fixes