Azure Data Manager for Energy Analytics Reaches GA: ACZ Syncs OSDU Data to Fabric and More

What Microsoft announced​

In a November 4 post, Sverre Brandsberg Dahl, General Manager for Energy at Microsoft Cloud for Industry, announced general availability of the native analytics capabilities. Selected ADME data becomes available in an open format for Microsoft Fabric, Azure Databricks, Snowflake and other compatible platforms.

ADME is Microsoft's managed cloud data platform for the energy industry, built around the OSDU Data Platform. Microsoft Learn describes it as a secure, reliable, hyperscale, fully managed cloud-based data platform solution for the energy industry.

The post also says an ADME MCP server is in preview. The MCP server gives AI agents a governed route to subsurface data. Domain-intelligence features, including knowledge graphs, are only on the roadmap. Those items are separate from the GA announcement.

How ACZ works​

Microsoft Learn says ACZ exports selected entity data from Azure Data Manager for Energy to your Azure Data Lake Storage Gen2 account, in open Delta Parquet format. The Learn pages say customers choose which kinds to export. They take an initial historical snapshot, and then ACZ syncs changes as they happen.

The setup has two parts, according to the Learn pages:

• You enable ACZ once per ADME resource in the Azure portal.
• You create up to three ACZ instances per data partition through REST APIs. Each instance defines which kinds to export and where to write them.

Nothing is exported until an instance exists. Instance definitions can't be edited. To change the kinds you export, you create a new instance, and downstream shortcuts or tables must then point at the new output path.

Choosing what to sync​

Kind patterns act as filters. The documented examples are Well and UnitOfMeasure catalog kinds, plus WellLog as a Wellbore DDMS kind. An optional allCatalogSync flag exports every catalog kind in the partition. A version mode controls history: LATEST_VERSION is the default and recommended setting, and ALL_VERSIONS keeps the full version history.

How changes show up in the tables​

This is the part downstream teams should read closely. The docs describe these behaviors:

• A new record, or a change to a record's data, produces a new row and version.
• Metadata-only changes to the access control list, legal tags or tags update the existing row.
• A soft delete sets isActive to false and keeps the row.
• A purge removes the row permanently.
• The output is a raw "bronze" layer. A table can hold more than one row for the same record ID and version, and ACZ doesn't remove the duplicates. Downstream builds should select the latest active row per ID.
• To detect changes incrementally, Microsoft recommends the ingestTime column rather than modifyTime. modifyTime doesn't change on a soft delete.

The sync is read-only and one-way. Microsoft warns against modifying, adding or deleting files in the ACZ folders, because doing so corrupts the sync. All edits belong in ADME.

Setup requirements​

The enablement guide lists these steps and prerequisites:

1. Create an ADLS Gen2 account with hierarchical namespace enabled.
2. Create a dedicated user-assigned managed identity. Microsoft recommends a dedicated one for cleaner audit trails, independent lifecycle management, narrower permissions and easier troubleshooting.
3. In the ADME resource in the Azure portal, open Analytics Consumption Zone under Advanced. Enable it and assign the identity. You can't disable ACZ in the portal afterward, so removing it requires a support request.
4. Confirm that the user calling the ACZ APIs belongs to three entitlement groups: users, users.datalake.ops and service.entitlements.user, each scoped to the data partition.
5. Give the managed identity Storage Blob Data Contributor on the destination storage.
6. Call POST /api/acz/v1/aczs. A successful call returns HTTP 201 with an aczId, and the historical snapshot shows as PROCESSING. When it reaches COMPLETED, the initial export is done.

The docs also include several cautions:

• Data residency: ACZ writes to whichever storage account you name, wherever it is. A destination in another region means your data is copied outside the ADME region.
• Public network access: The destination account must currently allow public network access. Firewall IP rules, disabled public access and private endpoints aren't supported. ADME instances that use private endpoints are supported.
• Cost: ACZ is an optional, billable feature, and charges begin when you enable it.
• Backup and disaster recovery: ACZ isn't covered by ADME backup and restore or cross-region failover. After either, you recreate the instances and take a new snapshot.
• History retention: ACZ runs VACUUM and OPTIMIZE maintenance, so time travel only reaches recent table versions. Copy the data elsewhere if you need longer history.

Connecting to Fabric​

Microsoft's Fabric guide uses OneLake shortcuts:

1. Confirm that the osducatalog folder under your ACZ ID folder contains _delta_log and Parquet files.
2. Create or pick a lakehouse.
3. Add an ADLS Gen2 shortcut using the storage account's DFS endpoint, and point it at osducatalog. In schema-enabled workspaces, create it as a table shortcut at the schema level.
4. Query it through the SQL analytics endpoint or a PySpark notebook, or build a Power BI semantic model on top.

The guide lists a Fabric capacity of F2 or higher, or a trial, plus at least Storage Blob Data Reader for the identity behind the shortcut. If Fabric and the storage account sit in different Entra tenants, you need a service principal or SAS token. Microsoft also publishes Databricks and Snowflake guides. A sample "silver layer" notebook flattens the nested OSDU records into cleaner tables.

GA or preview? The documentation disagrees​

Microsoft's own documentation doesn't give one consistent status, so check before you plan around it.

• The newer Learn pages retrieved for this report, last updated October 30, 2026, say catalog export is generally available. They say Wellbore DDMS export, entitlements export and the Wellbore DDMS kinds are still preview. They list Developer and Standard tier support, and they don't mention an allow-list.
• Older indexed copies of the same docs tell a different story. One says Analytics Consumption Zone is currently in preview. The enablement page in that copy lists Developer tier only and includes a step to share the identity and instance details with Microsoft.
• The ADME release notes for June 2026 describe ACZ as available as a preview on Developer Tier.

The likeliest reading is that the docs were updated around launch and the older copies are stale. That's an inference on my part, not something Microsoft states. Confirm tier eligibility, region availability, pricing and any enablement steps for your own subscription before you commit.

What this does and doesn't deliver​

ACZ solves a real and common problem. Teams otherwise build and maintain a custom export pipeline for every analytics use case. A managed sync into open Delta tables in your own storage removes that work and keeps one governed source feeding many tools.

The rest of Microsoft's post is vision. The three layers it describes are authoritative data, shared context built from ontologies, semantic models, Fabric Graph, Foundry IQ and Work IQ, and agent-driven action. ACZ only covers the first layer. The modeling, the context layer and the agents are separate work, and the post doesn't say ACZ provides them.

Microsoft cites "early deployments" that brought ADME data into Fabric and built ontologies on it. It gives no names, benchmarks or results for them. The Equinor quote is attributed only to a "Sr. Manager, Enterprise Data Platform," and it's a vendor-published testimonial. Nothing in the material shows measured gains in recovery, capital efficiency or reliability.

Several design points need planning:

• ACZ doesn't enforce row-level security downstream. Entitlement-aware filtering needs the separate preview entitlements export and your own work.
• Purged records disappear from ACZ tables, so downstream copies have to be reconciled or rebuilt.
• Duplicate rows must be handled.
• The three-instance limit and the lack of editing mean you should design kind selections carefully up front.

Bottom line​

For energy-sector IT and data teams, the practical news is a documented, managed route from OSDU data in ADME into Fabric, Databricks or Snowflake without a hand-built pipeline. Treat the "intelligence compounds" language as marketing. Treat the docs as the real contract, and verify the GA details against your own environment first.