Forum Discussion
Mirrored Azure Databricks Catalog bug?
Hi All,
Thankyou for your suggestions!
With help from Microsoft support, I have now identified the root cause.
The issue is a limitation in using guest accounts with Mirrored Azure Databricks Catalogs.
To summarize, I have two Entra Id tenants A and B in my setup, applied as follows:
- Entra Id tenant A hosts my Fabric and Databricks workspaces.
- Entra Id tenant B contains the organisational account I was using to create the Mirrored Azure Databricks Catalog. That is, the account is a guest in Entra Id tenant A.
It turns out that this configuration is not supported by the current version of Mirrored Azure Databricks Catalog.
The fix is to use either a service principal or an organisational member account from tenant A to setup the connection.
Personally, I would appreciate a more general support for multi-tenant setups, as multi-tenancy is a fact of life in my organisation. Therefore, I have often run into limitations of this kind. One day I might even learn to check for this as a matter of course :).
Best Regards,
Søren
Hi SørenBrandt,
From your explanation, it looks like this is not a Databricks-side issue (since the CLI is able to list catalogs correctly using the same workspace and login). That suggests the problem is specific to how Fabric is integrating with Databricks when creating a Mirrored Azure Databricks Catalog item.
A couple of things you could try/verify while this is being looked into:
Permissions check – Ensure the Fabric service principal (used internally by Fabric when connecting to Databricks) has sufficient workspace and catalog-level permissions in Unity Catalog. Sometimes, permissions differ between CLI (user identity) and Fabric’s backend service call.
Region alignment – Double-check that both your Fabric capacity and Databricks workspace are in the same Azure region. Cross-region connections sometimes cause unexpected failures.
Preview Feature Limitations – Mirrored Databricks Catalog integration in Fabric is still relatively new and may have limitations. If this is reproducible consistently, it may indeed be a Fabric-side bug.
Support path – Since you’ve ruled out networking and CLI confirms things are fine, I’d recommend raising a Microsoft Fabric support ticket with your session ID and timestamp when the failure occurs. That will help the engineering team pinpoint if this is a Fabric connector issue.
Hope this helps. please mark my response as the solution if you find it useful.