Edit

Share via

Migrate to Azure Monitor Agent from Azure Diagnostic extensions (WAD/LAD)

The Azure Diagnostics extensions (WAD/LAD) are on a deprecation path and will retire on March 31, 2026. Read the full migration guidance here.
As one of the migration options, customers can migrate to Azure Monitor Agent (AMA) configured with Data Collection Rules (DCRs) to continue collecting guest OS logs and performance data and to unlock multi-destination routing, centralized and more secure configuration, and at-scale management.

Note

DCRs provide transformations (ingestion-time filtering, parsing) to reduce cost and tailor schemas - something not available in WAD/LAD.

Comparison of WAD/LAD agents and AMA

Area WAD/LAD AMA
Status Legacy; retiring March 31, 2026 Current and strategic agent
Config model XML/JSON/WAD, LAD schema Centralized DCRs in Azure, also providing transformations (ingestion-time filtering, parsing) to reduce cost and tailor schemas
Security Storage keys, classic auth patterns Azure Managed Identity based access; modern TLS endpoints
Network Per extension outbound Standardized endpoints/service tags for AMA and DCEs

Migration steps

Phase 1: Discover & assess

  1. Inventory machines running WAD/LAD

    1. For per-VM view in Azure portal, navigate to Extensions + applications tab.
    2. For fleet view, use Azure Resource Graph query from the WAD/LAD overview article to find extensions by publisher == "Microsoft.Azure.Diagnostics".

  2. Extract current diagnostics config - Gather WAD public config XML (Windows) and LAD JSON (Linux) to list counters, events, syslog facilities/severities, file paths, transfer schedules, and destinations.

  3. Prioritize what to keep / drop - Use this moment to reduce noise and unused data types, if any. With DCR transformations, you can additionally filter to essential signals.

Phase 2: Design DCRs

  1. Create DCRs that replicate the WAD/LAD intent:
    1. Standard VM data sources like Windows events (e.g., System, Application, Security), Linux syslog, performance counters.
    2. Custom text logs (same file paths wildcards; ensure custom tables exist; often requires a DCE) sent to low-cost Auxiliary tier in Log Analytics.
    3. [ADX-destination routing] (../vm/send-fabric-destination.md#create-a-data-collection-rule)

Note

Keep Windows and Linux in separate DCRs to avoid accidental counter duplication (same metric from both naming styles).

Phase 3: Deploy AMA and assign DCRs at scale

  1. Prepare prerequisites for AMA installation and DCR association, including verifying supported OS, network settings
  2. Ensure you have Log Analytics workspace setup with Auxiliary tier as needed.
  3. (Recommended) Use Azure Policy built‑in initiatives to install AMA on Windows/Linux and associate DCRs. Using policy ensures new machines are auto-onboarded and existing machines are remediated, aligning to the migration best practices.

Phase 4: Validate

  1. Agent health: Confirm AzureMonitorWindowsAgent / AzureMonitorLinuxAgent extension status is Provisioning succeeded on VMs.
  2. Data flow:
    1. Logs: Query in Log Analytics workspace (e.g., Event, Syslog, custom table) as per the DCR data source.
    2. Performance counters to Metrics: switch VM Metrics blade to the Virtual machine guest namespace to see counters via AMA-to-Metrics routing.

Phase 5: Remove WAD/LAD

  1. Coordinate a cutover window per environment (Dev → Test → Prod).
  2. Stop/Remove the Microsoft.Azure.Diagnostics extension from each VM after AMA data parity is confirmed; this is explicitly recommended to avoid double ingestion and extra costs.

Common troubleshooting tips

  • Agent installed but no service visible on Windows: AMA runs under an extension model/process; verify via VM Extensions blade and DCR association rather than looking for an “Azure Monitor Agent” service.
  • No data from custom logs: Confirm custom table exists, DCE configured (where required), file patterns are correct, and the record delimiter/time format matches your files.
  • Firewall/proxy blocked: Validate outbound 443 to the control, DCR, ODS, and DCE ingest endpoints; HTTPS inspection must be disabled.
  • Last updated on