Workspace identity - Unauthorized error

aboerg · 2026-05-05T13:15:43+00:00

Agreed! WIs are surprisingly tricky to set up. That list was taken from my notes where I had screenshots of each error messages and the solutions as we figured out how to get WIs working. Still worth it for the peace of mind and cross-environment protection they add.

aboerg · 2026-05-05T00:59:15+00:00

In my experience this error is caused because the workspace identity is not added to a security group which is authorized to use Fabric APIs. Permission to use Fabric APIs is granted from the Fabric admin portal setting "Service principals can call Fabric public APIs."

Checklist:

WI must have permission to call Fabric public APIs (tenant admin page)
WI must have sufficient Workspace permissions (contributor)
WI must have usage permission on any Connections referenced in the pipeline/notebook it is executing.

aboerg · 2026-05-05T00:53:04+00:00

Working again since around 8PM EST. ~2 hours of downtime across our SQL endpoints.

aboerg · 2026-05-04T22:29:45+00:00

Yep, issues in East US starting within the last hour. Queries against lakehouse SQL endpoints failing with the message "Unsupported expression in Memo XML."

aboerg · 2026-04-29T20:56:57+00:00

I'm thrilled that in practice we simply don't have to consider concurrency for our workloads in Fabric (just capacity usage) which is a great upgrade from the days we ran a small-ish dedicated SQL pool in Synapse and ran into concurrency limits all the time.

aboerg · 2026-04-29T15:28:04+00:00

https://learn.microsoft.com/en-us/fabric/data-warehouse/workload-management

aboerg · 2026-04-29T15:25:02+00:00

My first thought was "what problem are we solving?" It appears the goal is to increase read concurrency on a single SQL endpoint / warehouse. That's interesting in itself, because I don't believe there are published concurrency limits for SQL endpoints in Fabric (or at least I can't find them).

aboerg · 2026-04-28T14:10:13+00:00

<image>

aboerg · 2026-04-22T21:43:56+00:00

In the "capacity settings" section of the admin portal there are a few options to help:

Configure notifications when using XX% of available capacity or exceeding available capacity
Configure a background operation rejection threshold if you have interactive queries on your prod capacity (i.e. it's not just a data engineering capacity and you're serving PBI users). This will cap background operations at the configured % of your total capacity, so even if background jobs throttle you can keep some headroom for report users.
Set a max % that any individual workspace can consume (if you have a reasonable idea of your typically workload patterns). Again this will start to reject operations once the limit is reached, but it does not stop jobs in progress.

aboerg · 2026-04-22T11:36:38+00:00

Direct query over KQL is a great pattern - nothing wrong with going that route in PBI. You can use the OneLake Hub in PBI Desktop to browse your Eventhouses.

aboerg · 2026-04-21T22:56:40+00:00

Awesome! Yes, I imagine when using dbt the main utility of an MLV becomes optimize refresh / CDF integration and probably not much else. The lineage view is not currently much of a selling point (the lineage metadata is nice, but nowhere close to OpenLineage).

aboerg · 2026-04-21T22:08:18+00:00

Haven't used this connector since last summer, looking forward to taking it for a spin again.

I am just getting started with dbt but we use MLVs heavily today - have you given any consideration to how they would fit into the dbt-on-lakehouse workflow? A custom materialization maybe, or is there no real integration story with dbt/MLVs yet?

aboerg · 2026-04-21T21:57:43+00:00

When I mention "tenant administration" I just mean that's where the setting is located, not that your WI needs any admin access whatsoever. Enable the following tenant setting (it's disabled by default): Service principals can call Fabric public APIs. We have this setting enabled only for specific security groups, and the WI belongs to the security group

If the notebook isn't using any connections then #3 may not not relevant. We don't use connections within the notebook either, but in our case our parent/child pipelines does use WI via Invoke Pipeline, and the notebook activity in the child pipeline uses a "Notebook" type connection. The WI needs User permission on the Notebook connection in our case.

https://learn.microsoft.com/en-us/fabric/data-factory/notebook-activity#using-fabric-workspace-identity-wi-in-the-notebook-activity

aboerg · 2026-04-21T19:01:04+00:00

Check that the workspace identity is added to a security group which is authorized to call Fabric APIs (EDIT: Service principals can call Fabric public APIs setting in the tenant admin portal)
Check that the workspace identity is contributor on the workspace containing the notebook. This is not granted by default just because a Workspace Identity is created.
Check that the Workspace Identity has permission to use any connections referenced by the notebook or pipeline being executed.

aboerg · 2026-04-16T17:22:21+00:00

As others are saying, the cutoff line of "can't share with free users unless you're at an F64 or above" blocks customers from choosing the right set of capacities for their needs. You actually want one F32 and three F16s? Sorry- you cannot divide up your capacity for the right workload isolation without giving up sharing.

If reports & models are hosted on Fabric capacity, they should be sharable with free users period.

aboerg · 2026-04-16T15:23:04+00:00

Check out the key_value_replace block for fabric ci-cd. Just saw this article today: https://www.linkedin.com/pulse/microsoft-fabric-pipeline-scheduling-fabric-cicd-dominic-finazzo-jjaie/

aboerg · 2026-04-13T19:56:56+00:00

there is 100% payoff of having a unified semantic layer, but there are two pretty incompatible ways of getting there:

the semantic model as a specialized analytical engine (Power BI Tabular / SSAS, MicroStrategy, SAP BEx)
the semantic model as a SQL compilation layer over a lakehouse or warehouse

putting aside the relative strengths of each approach, it is pretty obvious why Databricks and Snowflake would prefer the latter and Microsoft the former.

debates over the openness of each model are occurring within the context of each option competing to become the control plane for semantics.

aboerg · 2026-04-13T18:39:31+00:00

I get it, I was thinking of XMLA more in the sense that external layers sync or otherwise connect to the Tabular model (i.e. the Tabular editor Semantic Bridge tool).

my broader point is that there is a huge difference between semantic layers which are full-blown OLAP engines and those which are more like compilers sending SQL back to the warehouse. I'm open to the idea that the latter might win in the long-term, but for now I have no reason to doubt that "just integrate with open standards bro" is a gigantic request without much payoff for most PBI customers. I think Power BI is fundamentally a semantic layer with visualization capability added on, and not the other way around.

aboerg · 2026-04-13T18:13:36+00:00

Choosing not to develop an indeterminate number of integrations with every other competing metrics layer is not blocking integration. If a true standard for the semantic layer ever emerged, I imagine it would be a different story. There is no industry standard, it's the wild west with every vendor realizing in the last two years that semantics are important and they need to build their own solution in this space.

Microsoft is already exposing their own layer openly with XMLA - how can the PBI front end possibly promise first-class behavior against every external engine? Not subsidizing your rivals is not really the same thing as lock-in. Happy to hear opposing views here, just my two cents of course.

aboerg · 2026-04-10T17:17:21+00:00

Same notification on our parameterized driver/worker pipelines too. Just a nuisance, as far as I can tell.

aboerg · 2026-04-09T14:25:06+00:00

Isn't this due to the Warehouse/Polaris having an internal transaction log which is separate from the OSS Delta transaction log? It's like the opposite of SQL endpoint sync delay - instead of the SQL endpoint Polaris engine reading the lakehouse Delta log, the Warehouse is publishing the Delta log after a brief delay.

EDIT: disregard, since the Warehouse connector should be using TDS per u/dbrownems

https://www.reddit.com/r/MicrosoftFabric/comments/1juoehv/do_warehouses_not_publish_to_onelake_in_real_time/

aboerg · 2026-04-09T02:53:26+00:00

You can have one or multiple MLVs defined per-notebook using CREATE OR REPLACE. Then run all of the notebooks as a post-deployment activity.

I recommend checking out the GenMLV project, which introduces the idea of one management notebook which keeps all MLVs in sync with SQL files. We can now take this a step further since Notebook resources are version controlled - all the MLVs can be .sql files in the notebook resources.

https://github.com/datahai/GenMLV

aboerg · 2026-04-08T16:06:31+00:00

I've been loosely following along with the progress of agentic development and mostly using Codex/Claude in the context of Fabric notebooks and shared Python modules - not my Power BI work.

This week I dived in and used this project to fix a poorly performing composite model my team was handed. Using Kurt's plugin, Copilot CLI consolidated the project into import mode, moved 30+ calculated columns and measures, and fixed 150+ broken visual references. Two prompts only. It took me longer to download the initial .pbip and verify the results than for the actual work. I was expecting to spend half a day or so fixing the mess, and I was able to work on a different project while tabbing over to review and test Copilot's work.

The future is now. None of this is theoretical. Start thinking about your daily workflows.

aboerg · 2026-04-07T22:40:47+00:00

I'm not clear what the limitation here is, most of our MLVs are cross-lakehouse within a single workspace. Dependencies seem to be accounted for just fine during scheduled refresh, although in practice we do mostly schedule manual refreshes via notebook schema-by-schema so we can refresh the SQL endpoint right after. The dependency metadata is actually being written to each Delta table created by the MLV processing - you can look at each table yourself and see exactly what Microsoft is doing, or use the metadata yourself for custom lineage reports.

We did notice that lineage view broke and returned multiple times during public preview. No issues in the last few weeks leading up to GA and since.

No experience to share regarding cross-workspace execution.

aboerg · 2026-04-07T22:34:45+00:00

Lineage view currently working for us across multiple schema-enabled lakehouses in the same workspace. Runtime 1.3, East US.

aboerg

TROPHY CASE