Forum Discussion
Refresh failure for DirectQuery to Semantic Models after migrating from Premium P1 to Fabric F64 (SS
- 6 months ago
Hi AntoineW ,
Please try below things to fix the issue.
1. Replace Default (SSO) connections with explicit connections per source.
2. Set those connections to service principal or workspace identity for Azure SQL/Fabric.
3. Ensure the Service Principle or service account has Build or higher on each upstream semantic model and any gateway data source permissions.4. Keep Use SSO via Azure AD for DirectQuery queries on for interactive user experience when the source supports it, not expect it to power refresh with Entra SSO.
5. If refresh still fails and your model has calculated tables/columns over SSO‑enabled DQ, either move those calcs out or ensure the dataset is bound to non‑SSO explicit credentials.
Is best practice to use a Service Account (SA) with admin rights to manage these connections without SSO? Is it possible with DirectQuery sources?
Yes, use a service principal or a service account to own the dataset and to bind explicit, non‑SSO connections used for refresh, especially when the DQ sources are other semantic models. This is both feasible and common in production. Viewers still get row‑level results “as themselves” during interactive DQ, but refresh uses the dataset owner/SP identity. If your DQ sources are Azure SQL / Fabric Warehouse / Lakehouse, consider Workspace Identity instead of SP to avoid secret rotation. However, you currently can’t grant a workspace identity access to another Power BI dataset, so for DQ‑to‑semantic‑model chains you will still need SP/service account.Are there known limitations or configuration changes regarding SSO for DQ‑to‑Semantic Models on Fabric vs Premium?
Microsoft Entra (AAD) SSO only covers interactive DirectQuery, while refresh with SSO is supported only for Kerberos (on‑prem) scenarios. When a model chains to other Power BI semantic models and also uses features like calculated tables/columns, Dual/Import partitions, or default SSO connections, scheduled refresh will fail unless you bind explicit credentials.
Please refer below links.
Solved: Default connection on Semantic Models - Microsoft Fabric Community
Solved: Refresh error - Single Sign-on (SSO)-enabled Direc... - Microsoft Fabric Community
Manage Semantic Model Access Permissions in Power BI - Power BI | Microsoft Learn
Overview of single sign-on for on-premises data gateways - Power BI | Microsoft Learn
I hope this information helps. Please do let us know if you have any further queries.
Regards,
Dinesh
Hello AntoineW
I could not locate any published Microsoft documentation or official Microsoft blog that outlines a functional distinction in SSO-based DirectQuery authentication between Power BI Premium capacity and Microsoft Fabric capacity.
The official documentation indicates that SSO operates for DirectQuery by transmitting the user’s identity via Kerberos or Microsoft Entra ID, depending on the data source. There are some nuances; for example, Microsoft notes that Direct Lake employs SSO by default, and there is an automatic fallback from Direct Lake to DirectQuery when certain features are unsupported, although this scenario does not pertain to your case.
It remains possible that there is an undocumented behavioural difference that you have discovered!