Microsoft will retire Azure Monitor’s preview “Send virtual machine client data to Event Hubs and Storage” capability on July 31, 2026, so operations teams should find every data collection rule whose kind is AgentDirectToStore, classify its purpose, and build a validated replacement before removing it. Do not assume that another direct Azure Monitor Agent route to Azure Data Explorer is available or equivalent; the appropriate ADX ingestion design must be confirmed against current Microsoft documentation and the organization’s configuration requirements.
Existing requirementReplacement mechanismDecisive limitations or gate
Guest VM data used in Azure Data ExplorerSelect and validate a Microsoft-documented ADX ingestion architectureDo not treat direct AMA-to-ADX delivery as an established replacement without verifying current support, regions, schemas, prerequisites, and production status
Guest VM data sent to a third-party SIEM, Event Hub, or StorageIngest with AMA into Log Analytics, then use a Log Analytics data export ruleThe data must first reach the workspace; every required table must support export; destinations must meet regional requirements; only 10 active export rules are allowed per workspace
Immutable guest-data archiveLog Analytics ingestion and data export to a properly governed Storage accountTable eligibility, export completeness, storage immutability, retention, access, and reconciliation must all be validated
Azure platform logs and metricsAzure resource diagnostic settingsDiagnostic settings collect platform telemetry, not Windows Event Logs or other guest data selected by an AMA DCR
WindowsForum user reports about Azure’s default outbound access change, retiring Reserved VM Instance options, and Microsoft 365 feature retirements illustrate the same operational pattern: retirement notices often collide with networking, cost, security, and application work already in flight. This migration therefore needs an owned inventory and executable change plan, not another entry in a general lifecycle spreadsheet.

Infographic outlining Azure Monitor retirement by July 31, 2026, migration paths, validation, and governed storage.Find Every Affected Rule​

The retiring capability used Azure Monitor Agent, or AMA, to collect client data from virtual machines and send it directly to Azure Event Hubs or Azure Storage. The identifying characteristic is the DCR kind AgentDirectToStore.
An inventory of AMA installations is insufficient. A VM may continue running AMA even though the destination path used by downstream security, analytics, or compliance systems is being retired. Agent health does not prove that those consumers will continue receiving records.
Start with Azure Advisor:
  1. Sign in to the Azure portal.
  2. Open Advisor.
  3. Open Recommendations and review the available service-retirement or service-upgrade recommendations.
  4. Search or filter for the retirement of Send virtual machine client data to Event Hubs and Storage (Preview).
  5. Export or record every affected subscription and DCR resource.
  6. If the retirement appears through the Advisor retirement workbook in your tenant, open Advisor > Workbooks > Service Retirement and review the affected-resource list there as well.
Then independently inventory the DCRs. Advisor should guide the investigation, but the resource configuration is the authoritative check.
In the portal:
  1. Open Azure portal > Monitor > Data Collection Rules.
  2. Open each suspected rule.
  3. Select JSON View from the resource page.
  4. Confirm that the top-level kind value is AgentDirectToStore.
  5. Record the rule’s resource group, subscription, associations, data sources, streams, and destinations.
With Azure CLI, list matching DCR resources in the current subscription:
Code:
az resource list \
  --resource-type Microsoft.Insights/dataCollectionRules \
  --query "[?kind=='AgentDirectToStore'].{name:name,resourceGroup:resourceGroup,id:id,location:location}" \
  --output table
Repeat that command in every relevant subscription, or set the subscription explicitly before each run:
az account set --subscription "<subscription-id-or-name>"
For a tenant-scale search, open Azure portal > Resource Graph Explorer and run:
Code:
resources
| where type =~ "microsoft.insights/datacollectionrules"
| where kind =~ "AgentDirectToStore"
| project subscriptionId, resourceGroup, name, location, id
| order by subscriptionId asc, resourceGroup asc, name asc
For each result, map the complete operational chain:
  1. DCR and DCR associations.
  2. Associated Windows or Linux VMs.
  3. Selected event channels, performance counters, IIS logs, or other sources.
  4. Event Hub namespace, Event Hub, or Storage destination.
  5. Final consumer, such as ADX, a SIEM, an integration service, or an archive process.
  6. Data owner and migration approver.
  7. Expected record volume and a representative validation query.
  8. Replacement route and rollback plan.
Two rules targeting Event Hubs may serve unrelated purposes. One may feed an ADX ingestion process, while another distributes data to a security platform. Likewise, a Storage destination used as an integration buffer is not equivalent to an immutable compliance archive.

Treat ADX as a Design Decision Requiring Validation​

If an Event Hub currently exists to move AMA-collected VM data into Azure Data Explorer, do not automatically replace it with an assumed direct AMA-to-ADX route. The supplied retirement information does not establish that route as the supported successor, document its prerequisites, or show that it is interchangeable with AgentDirectToStore.
Instead, make the ADX path a formal architecture decision. Before implementation, use current Microsoft documentation to verify:
  • The supported ingestion mechanism and its production or preview status.
  • Supported Azure regions and resource relationships.
  • Authentication and managed-identity requirements.
  • Required DCR, endpoint, Event Hub, connector, or ADX configuration.
  • Supported guest-data sources and stream transformations.
  • Destination table creation, mappings, retention, and schema behavior.
  • Throughput, batching, retry, and failure-monitoring behavior.
  • Whether parallel operation is possible during validation.
The migration record should cite the Microsoft documentation used for that decision and list the exact prerequisites applied in the environment. If the validated architecture still uses Event Hubs, document which component now writes to the hub and why that route remains supported after AgentDirectToStore retires.
Test the chosen path at the data-source level. Compare representative time windows, event channels, counters, custom sources, record counts, timestamps, and schemas. A successful ADX connection is not proof that every record selected by the old DCR is arriving.

Gate Log Analytics Export Before Building It​

Log Analytics data export is viable only if the relevant guest data is first ingested into the Log Analytics workspace and every required destination table supports export. Make both conditions pre-migration gates, not late-stage caveats.
Before creating anything:
  1. Configure or identify an AMA DCR that sends the required guest data to the target Log Analytics workspace.
  2. Confirm that the expected records appear in the correct workspace tables.
  3. Inventory the precise tables required by the downstream consumer.
  4. Verify that each table is supported for Log Analytics data export.
  5. Confirm that the Event Hub namespace or Storage account satisfies the documented destination and regional requirements.
  6. Verify that downstream consumers can process the exported table schemas.
  7. Do not approve this branch if a required table cannot be exported.
To create a rule in the portal:
  1. Open Azure portal > Log Analytics workspaces.
  2. Select the workspace receiving the guest data.
  3. Open Data Export under the workspace settings.
  4. Select New export rule.
  5. Enter the rule name.
  6. Select the supported tables to export.
  7. Choose the destination subscription and the Event Hub or Storage resource.
  8. Create the rule and verify its deployment.
  9. Send representative records, then confirm receipt at the destination and final consumer.
A workspace can have no more than 10 active data export rules, although one rule can contain multiple tables. The practical response is to inventory all existing active export rules before allocating one to this migration. Consolidate tables into a shared rule only when their destination, access controls, operational ownership, retention expectations, and change authority permit it. Do not combine unrelated security and application feeds merely to stay under the limit.
Export monitoring also needs an owner. Monitor Azure Monitor’s available export and destination indicators, alert on delivery failures, and reconcile expected records against records received by the Event Hub consumer or Storage process. Workspace ingestion alone proves only that the first stage succeeded.
This end-to-end emphasis matches the lesson WindowsForum users drew from the reported Azure Front Door outage: service health at one layer does not establish that the final application or consumer is functioning. The migration test must follow records all the way to the system that uses them.

Build Immutable Retention Deliberately​

When the old Storage destination exists for audit retention, begin with the retention and evidence requirements rather than simply choosing another storage account. Log Analytics data export can copy supported workspace tables to Storage, but the archive becomes immutable only through the destination’s storage governance and policy configuration.
Use this sequence:
  1. Confirm that AMA sends all required guest records to Log Analytics.
  2. Confirm that every archive table supports data export.
  3. Create the Storage destination in the required region and under the appropriate subscription and ownership model.
  4. Configure the organization’s required immutability, retention, access, and legal-hold controls.
  5. Create the export rule through Log Analytics workspace > Data Export > New export rule.
  6. Validate that records reach Storage with the expected timestamps and structure.
  7. Reconcile source and archived records over representative periods.
  8. Test monitoring and escalation for export or destination failures.
  9. Obtain compliance-owner approval before retiring the old path.
Observing blobs in a container does not prove completeness, immutability, or compliance. The evidence package should show table eligibility, successful export, destination controls, reconciliation results, and named operational ownership.

Use Diagnostic Settings Only for Platform Telemetry​

Diagnostic settings are the established mechanism for sending Azure resource logs and platform metrics to supported destinations. They do not replace AMA guest collection. A diagnostic setting on a VM resource does not recreate Windows Event Log channels, IIS logs, or other operating-system data selected by an AMA DCR.
To create one:
  1. Open the relevant Azure resource in the Azure portal.
  2. Select Monitoring > Diagnostic settings.
  3. Select Add diagnostic setting.
  4. Name the setting.
  5. Select the required platform log categories and metrics.
  6. Select the destination, such as a Log Analytics workspace, Storage account, or Event Hub.
  7. Save the setting.
  8. Confirm that the selected platform records reach the destination.
For subscription activity logs, open Azure portal > Monitor > Activity log > Export Activity Logs, then create or edit the diagnostic setting.
A mixed environment may need both mechanisms: AMA and a DCR for guest operating-system telemetry, plus diagnostic settings for Azure platform logs and metrics. They may converge downstream, but they do not collect equivalent records.

Run the Cutover End to End​

Create the replacement before disabling an affected AgentDirectToStore rule. Where practical, run both paths long enough to compare representative traffic.
For each pipeline:
  • Generate or identify known test records.
  • Confirm workspace ingestion when Log Analytics is part of the route.
  • Verify the correct tables and schemas.
  • Confirm destination receipt.
  • Confirm that every downstream consumer processes the records.
  • Compare counts and time ranges rather than checking a single sample.
  • Test alerts for export or destination failures.
  • Record discrepancies and resolve them before cutover.
  • Disable the old path only after the data owner accepts the results.
  • Retain rollback instructions until the post-cutover validation period ends.
WindowsForum’s reports on Azure networking defaults and Reserved VM lifecycle changes reinforce why dependencies should be tested together. A replacement telemetry path may also depend on private endpoints, outbound connectivity, DNS, identity permissions, quotas, or destination access rules. Validate those dependencies explicitly instead of assuming that successful DCR deployment means successful delivery.

Frequently Asked Questions​

What exactly is retiring?​

Microsoft is retiring the preview capability named Send virtual machine client data to Event Hubs and Storage on July 31, 2026. Affected DCRs are identified by the kind AgentDirectToStore.

Does Azure Monitor Agent itself stop working?​

No. The retirement concerns this destination capability, not the general existence of AMA. A VM can show a healthy agent while the retiring downstream path still requires replacement.

Can diagnostic settings replace the affected DCR?​

Only for Azure platform logs and metrics. Diagnostic settings do not reproduce Windows guest telemetry or application data collected inside the VM by AMA.

Can Log Analytics data export replace direct delivery?​

It can be appropriate when the guest data is first ingested into Log Analytics and all required tables support export. It changes the architecture, introduces workspace ingestion into the critical path, and is subject to destination requirements and the 10-active-rule workspace limit.

Should tables be consolidated into one export rule?​

Only when they can share the same destination, access model, operational owner, retention requirements, and change authority. Inventory existing active rules first; consolidation is not merely a quota workaround.

What should teams do for Azure Data Explorer?​

Treat ADX as an architecture branch requiring validation against current Microsoft documentation. Do not assume direct AMA-to-ADX delivery is an established, universally supported replacement without confirming its current status, prerequisites, supported sources, regions, authentication, schema handling, and monitoring.

When is the migration complete?​

The work is complete when every AgentDirectToStore rule has an approved replacement or documented disposition, required records reach the final consumer, failures are monitored, expected and received records are reconciled, and the old rule can be removed without reducing security, operational, analytics, or compliance coverage.

References​

  1. Primary source: learn.microsoft.com
  2. Independent coverage: azurecharts.com
  3. Independent coverage: cloudscoop.io
  4. Independent coverage: falconersecurity.com
  5. Independent coverage: linkedin.com
  6. Primary source: WindowsForum