Interview Questions

Fabric Data Agents vs. SSAS Live Connection: Architecture, Errors, and Direct Lake Migration

As organizations race to integrate AI into their analytics stack, a critical architectural barrier has emerged for legacy environments: Fabric Data Agents cannot connect to SSAS Live Connections. While the interface may display a connected Semantic Model, this is merely a ‘proxy’ artifact that blocks the XMLA endpoint discovery required for AI grounding.

This guide provides a technical dissection of why the On-Premises Data Gateway fails to support conversational AI, analyzes the latency costs of Composite Models, and outlines the necessary steps to migrate from SSAS to Fabric Direct Lake to unlock true enterprise intelligence.

Using Fabric Data Agents over Live Connection to Azure SSAS | GigXP

The Hard Stop: Fabric Data Agents and SSAS Live Connections

Executive Summary

Fabric Data Agents cannot connect to SSAS cubes via Live Connection. The architecture prevents the XMLA schema discovery required for the AI to function. The “Semantic Model” you see in Fabric is a proxy artifact, not a data container. To enable AI agents, migration to Direct Lake is the only supported path.

Organizations managing legacy investments in SQL Server Analysis Services (SSAS) face a new friction point. The promise of Microsoft Fabric is unified intelligence, specifically the ability to use Data Agents to chat with enterprise data. However, for those using On-Premises Data Gateways to connect to SSAS, the answer is a definitive no.

This report dissects the architectural block. We explain why the connection fails and clarify the confusing terminology around “Semantic Models” in a hybrid landscape.

The Compatibility Verdict

Fabric Data Agents rely on a process called Grounding. To answer a question like “What were sales in Europe?”, the AI must first scan the database schema to understand that a table named “Sales” and a column named “Region” exist. The Agent performs this scan using the XMLA (XML for Analysis) endpoint.

This is where the Live Connection fails. Microsoft Fabric treats Live Connection artifacts as “proxy models.” These proxies point to an external server but block the metadata exposure required by the XMLA endpoint. Without access to the XMLA endpoint, the Data Agent is blind. It cannot see your tables. It cannot see your columns. Consequently, it cannot generate queries.

Interactive: Data Architecture Path
Figure 1: Visualizing the Metadata Gap. The XMLA request (Blue) hits a wall at the Live Connection proxy, while Direct Lake (Green) allows full traversal.

Technical Deep Dive: The Metadata Wall

Why the Handshake Fails

When a Data Agent initializes, it attempts to “ground” itself in your data. It sends a specific sequence of TMSL (Tabular Model Scripting Language) discovery commands. In a Live Connection scenario, these commands hit a void.

The Discovery Sequence:

> REQUEST: SELECT * FROM $SYSTEM.MDSCHEMA_DIMENSIONS
> TARGET: Fabric “Proxy” Semantic Model
> RESPONSE: [Error] The requested operation cannot be performed on a remote model.

The “Proxy” model in Fabric does not cache schema information. It blindly forwards DAX queries for visualization but refuses to service metadata discovery requests. Since the Agent cannot “read” the map of your data, it cannot navigate it.

The Sample Value Problem:
Even if schema discovery worked, Agents require access to “sample values” (e.g., seeing that the “Country” column contains “USA”, “UK”, “DE”). Reading these distinct values via a Gateway for every column in a large SSAS cube would trigger a massive performance penalty, potentially timing out the Agent before it answers a single question.

The Composite Model Trap

A common workaround architects attempt is creating a “Composite Model” (DirectQuery for Power BI Datasets). In this scenario, you create a new Fabric Semantic Model that connects to the SSAS Live Connection but allows you to add local tables or calculation groups.

While this technically places a “real” model in Fabric, it remains unfit for Data Agents. The Agent queries the wrapper model, which then attempts to fold queries down to SSAS. The complexity of mapping natural language to DAX, and then folding that DAX through a DirectQuery wrapper to a legacy server, introduces two fatal flaws:

  • Limited Relationships: Composite models use “Limited Relationships” (no physical integrity constraint). This prevents the Agent from accurately inferring how filters propagate between tables, leading to “I don’t know” responses.
  • Folding Failures: Simple questions often generate DAX that cannot be folded to the SSAS source. The result is an attempt to pull millions of rows into the wrapper model’s memory, causing an instant timeout.

The Latency Compounder

Even if the metadata block were removed, the physics of the Gateway would degrade the experience. An AI conversation is “chatty”—it doesn’t run one query; it runs discovery loops. Use the simulator below to see how Gateway latency kills the “Real-Time” feel of AI.

Simulation: Gateway Latency Impact
Gateway Latency (Ping) 50 ms
Agent Complexity (Queries per Answer) 5 Queries
Total Wait: 0.5s
Note: AI processing time (approx 2s) is added to network time. Anything over 3s feels “broken” to a user.

The Economic Shift: CapEx vs. OpEx

Moving from SSAS to Fabric Direct Lake is not just a technical migration; it is a financial one. You are moving from a Capital Expenditure model (buying hardware cores) to an Operational Expenditure model (renting Azure Capacity).

SSAS Live Connection
CapEx

You own the hardware. The compute cost is “sunk.” Fabric is only used for rendering pixels, meaning very low CU (Capacity Unit) consumption.

Fabric Direct Lake
OpEx

Compute is metered. Every question the Data Agent answers burns Fabric CUs. Heavy usage requires higher F-SKUs (F64+ recommended for production AI).

Diagnostic Toolkit

Need to prove this limitation to stakeholders? Use these checks to confirm the metadata block.

1. The DAX Studio Test: Connect DAX Studio to your Fabric Workspace. Try to query the Live Connection proxy with `SELECT * FROM $SYSTEM.MDSCHEMA_TABLES`. Result: Empty or Error.
2. The Settings Check: Go to the Semantic Model Settings in Fabric. If the “Scheduled Refresh” and “Data Source Credentials” tabs are grayed out or missing, it confirms the artifact is a Proxy, not a Model.
3. The Q&A Setup: Attempt to configure “Q&A” (the precursor to Agents) on the dataset. The option will be disabled, citing “Remote Model” as the reason.

Error Decoder: What You Will See

If you attempt to force a Data Agent (Copilot) to connect to a report backed by an SSAS Live Connection, you will likely encounter one of these obfuscated error states. Click a card to reveal the technical root cause.

“The model is not supported”

Root Cause: The Fabric backend checks the `ModelType` property. If it detects `LiveConnection` or `DirectQueryOverAS`, it immediately aborts the grounding process to prevent timeouts.

“Sorry, I can’t see your data right now”

Root Cause: A generic timeout. The Agent attempted to query column statistics (cardinality) to understand the data shape, but the On-Premises Gateway latency exceeded the 30-second rigid timeout for interactive AI responses.

“Visuals on this page cannot be analyzed”

Root Cause: The Agent is trying to read the visual’s data backing. Since the visual query must travel via Gateway -> SSAS -> Gateway -> Fabric, the asynchronous wait time fails the Agent’s synchronous expectation.

“Switch to Direct Lake mode”

Root Cause: An explicit error message added in late 2024 Fabric updates to guide users away from legacy connectivity modes.

Strategic Alternatives

The hybrid era of “data on-premises, pixels in the cloud” is ending for AI-driven organizations. To leverage Fabric Data Agents, the metadata must reside in the Fabric capacity.

Migration to Direct Lake

The recommended path is migrating SSAS models to Fabric Direct Lake mode. By exporting data to Delta Parquet files in OneLake, you achieve near-memory performance. Crucially, the metadata resides natively in Fabric. This opens the XMLA endpoint, allowing Data Agents to index the schema and answer user questions immediately.

Migration Readiness Checklist

Inventory: Identify SSAS Tabular models using compatibility level 1500 or higher (required for easy script migration).
Script Extraction: Use Tabular Editor to save Model.bim files, stripping out data source partitions.
Data Movement: Set up Data Factory pipelines to move source SQL data into Fabric Lakehouse (Delta Parquet).
Metadata Rebinding: Open the stripped Model.bim in Fabric and point partitions to the Delta tables in OneLake.
Agent Activation: Enable “Allow User Data in Copilot” in the Fabric Tenant Settings.

Comparison of Connectivity Modes

Feature SSAS Live Connection Fabric Direct Lake Fabric Import
Data Location On-Premises Server OneLake (Cloud) Fabric Memory
Metadata Access Blocked (Proxy Only) Open (Fabric Native) Open (Fabric Native)
Agent Compatible NO YES YES
XMLA Endpoint Unsupported Supported Supported
Latency High (Gateway Hops) Low (In-Memory/Parquet) Lowest

Frequently Asked Questions

Can we enable XMLA for Live Connections via tenant settings?

No. While there is a tenant setting to “Allow XMLA endpoints,” it applies only to Import, DirectQuery, and Direct Lake models. Enabling it does not remove the architectural block on Live Connection proxies.

Why does the Semantic Model exist if it holds no data?

It acts as a security boundary. It allows Fabric to manage the “EffectiveUserName” property passed to the Gateway for Row-Level Security (RLS) enforcement without exposing the physical server directly to the report layer.

Does Direct Lake require a full rewrite of our SSAS cubes?

Not necessarily. Tools like Tabular Editor allow you to script out measures and relationships from SSAS and deploy them to a Fabric model. The primary effort is repointing the data source from SQL views to OneLake tables.

Can we use Composite Models as a bridge?

It is risky. Composite models over SSAS often fail AI schema discovery due to metadata limitations. It is not a certified path for Data Agent stability.

Does Direct Lake respect my SSAS Role-Based Security?

Direct Lake requires you to recreate the roles in the Fabric Semantic Model. However, you can automate this using scripts. Once defined, Fabric honors RLS filters before the Agent sees the data.

Does my data leave the region with Agents?

If you are in a supported region (e.g., US, Europe), the AI processing happens within the tenant compliance boundary. However, with Live Connection, the question is moot because the Agent cannot reach the data in the first place.

© 2025 GigXP.com. All rights reserved.

Research based on Microsoft Fabric Architectural Specifications (Oct 2025).

Disclaimer: The Questions and Answers provided on https://gigxp.com are for general information purposes only. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose.

What's your reaction?

Excited
0
Happy
0
In Love
0
Not Sure
0
Silly
0
Next Article:

0 %