Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

feature-xmla-endpoint.mdv2 · history
CurrentApplies to ServiceUpdated last weekSource Microsoft Learn

What it does

An open connectivity endpoint on Premium, Premium Per User and Power BI Embedded workspaces that exposes the semantic model as if it were an Analysis Services database. Client tools connect using the XMLA protocol, so anything that speaks to Azure AS or SQL Server AS can query — and, with write enabled, modify — a Power BI model.

Key facts

  • Read-only connectivity is on by default for the semantic models workload in a capacity. Read-write is a separate switch and is what actually opens up the ALM scenarios.
  • The workspace URL acts as the server name. In SSMS the workspace shows as an Analysis Services server and each semantic model as a database.
  • Version floors matter: SSMS 18.9 or higher, SQL Server Profiler 18.9 or higher, the Visual Studio Analysis Services projects extension 2.9.14 or higher (models at compatibility level 1500+), and Click-to-Run Office 16.0.13612.10000 or higher for Excel PivotTables.
  • Refreshes issued through the endpoint aren't subject to the 48-per-day scheduled refresh limit, and the scheduled refresh timeout isn't imposed. This is the usual reason enterprise teams want it.
  • Refreshes through XMLA don't refresh tile caches. Tiles update when someone opens the report.
  • Write operations on a model authored in Power BI Desktop require Enhanced Metadata, and — this is the one that hurts — once a write has happened, the model can no longer be downloaded back as a .pbix.
  • Terms of use distinguish single-user applications (scripts, dev tools, automation, using one account or app identity) from multi-user applications. On PPU workspaces every end user must sign in with their own PPU licence and a service account can't act on their behalf; on Premium capacity workspaces a service principal or service account can.
  • Dynamic Management Views are available but limited to those needing database-admin permissions. Anything requiring server-admin rights isn't exposed.
  • Access through the endpoint is audited under its own operation names — ConnectFromExternalApplication, RefreshDatasetFromExternalApplication, EditDatasetFromExternalApplication and friends.
  • Default semantic models that come with a Fabric warehouse can't be modified through the endpoint.

When to use / skip

Turn read-write on when the client is running enterprise models: partition-level refresh, deployment from Visual Studio or Tabular Editor, scripted metadata changes, translations, or anything where a full refresh is too expensive to run daily. Combined with incremental refresh, fine-grained refresh through XMLA is often the difference between a model that refreshes in twenty minutes and one that doesn't finish.

Leave it read-only if the client's models are Desktop-authored and self-service. The moment someone writes through the endpoint you've lost the .pbix download, and on a self-service team that's the file they think of as the source of truth. Turning write on for a team without a source control story creates a model nobody can rebuild.

Configuration decisions

  • Read-only or read-write, per capacity. This is the gate on everything else and it deserves a governance conversation, not a tick-box.
  • Whether service principals are permitted, and which tenant settings allow them. Automation without service principals means somebody's personal account is your refresh identity.
  • Which tools are sanctioned for write access — Tabular Editor, SSDT, custom TOM scripts — and who is allowed to install them.
  • Where the model definition lives once write is enabled. PBIP in a repo, a Visual Studio project, or nothing at all; the third answer is the one you'll find in the wild.
  • Whether refresh moves off the service scheduler entirely onto an orchestrator calling the endpoint.

Gotchas

  • The .pbix download is gone after a single write. Nobody is warned in the moment and the person who discovers it is usually not the person who caused it.
  • Power BI Desktop declares data sources as inline Power Query M expressions, which Azure AS and SSAS don't support. Premium supports both inline M and structured/provider declarations, but not mixed in the way people assume when migrating a model in either direction.
  • PPU's multi-user rule catches embedding and middle-tier scenarios. If the app authenticates on behalf of users against a PPU workspace, that's outside the terms — it needs Premium capacity.
  • Read-only is enabled by default, so Excel users may already be connecting through the endpoint without anyone having decided that they should.
  • Uncapped refresh through the endpoint is uncapped in frequency, not in capacity impact. A team that discovers it can refresh hourly will happily flatten an F64.

Consultant notes

  • Frame read-write as a one-way door for the models it touches. That single sentence usually gets the source-control conversation started properly.
  • Check the audit log operations early in a governance engagement. XMLA connections are a good indicator of shadow tooling nobody mentioned in workshops.
  • If the client's argument for PPU is "we need the XMLA endpoint", check whether the actual scenario is multi-user. It often is, and then the answer is capacity.
  • Migrating from Azure Analysis Services? The endpoint is what makes that a change of server URL for report connections rather than a rebuild. Lead with that.

Recheck the tool version floors and the PBIX download behaviour before you promise anything to a client migrating from Analysis Services

Was this accurate?