1) First aid for the error you pasted
Message highlights: PFE_UNIVERSAL_SECURITY_TRANSIENT_ERROR, OneLake permissions, Status code 500, ModelingEngineHost. This typically points to a short-lived platform/security resolution issue when the service tries to evaluate OneLake permissions for the item your semantic model depends on (Lakehouse/Warehouse/Shortcut). Microsoft class it as transient—so a retry often succeeds—but you can harden your setup:
- Confirm access on the underlying OneLake items (Lakehouse/Warehouse/Shortcut used by Direct Lake/DirectQuery): users/service principals running the query need at least Read on the item and Build on the semantic model. Also verify they have a role in the workspace (Viewer+). See OneLake integration & permissions overview.
- Capacity & region health: your cluster shows wabi-us-central-b. If your users are in EU but model runs in US, occasional authorization lookups can be chatty; ensure the workspace is in the capacity/region you expect and capacity isn’t throttled.
- Retry and capture the RootActivityId from the message (you have it). If it recurs, raise a Microsoft support ticket with that ID—engineering can trace it.
- For Direct Lake models, consider enabling DirectQuery fallback temporarily to ride out transient metadata reads while you investigate (you can turn it back off once stable). Community reports align with transient security lookups on Direct Lake.
2) Ways to move a semantic model using only Microsoft tools
Below are four Microsoft-native approaches. Pick the one that best matches your environment (Premium/PPU vs Pro, need for CI/CD, cross-workspace/tenant, etc.).
A) Deployment Pipelines (no-code, click-ops CI/CD)
Best for: moving between Dev → Test → Prod workspaces inside the same tenant/capacity with rules to switch connections/parameters.
- Ensure your workspaces are on Fabric/Premium capacity.
- Create a deployment pipeline and assign the Dev workspace to Stage 1.
- Use Deployment rules to swap data source connections/parameters per stage.
- Deploy to Test, validate, then deploy to Prod. Reports can be rebound automatically to the target semantic model.
Docs: Get started with deployment pipelines.
B) Git integration + PBIP (TMDL) — reproducible & reviewable
Best for: source control and repeatable promotion; works with Azure DevOps or GitHub (both Microsoft). Uses the Power BI Project (.pbip) format with TMDL for the semantic model.
- In Desktop, enable Developer Mode and PBIP, then Save as PBIP. This writes .Report/ and .SemanticModel/ folders (TMDL).
- Push to Azure DevOps or GitHub.
- In Fabric, connect your target workspace to that repo/branch and Update workspace from Git to materialize the semantic model in the new workspace, then refresh.
Why this is robust: it moves metadata (model + report) as text, supports code review/PRs, and plays nicely with pipelines.
C) XMLA backup/restore (.abf) with SSMS (Premium/PPU required)
Best for: exact copy of a semantic model between workspaces/capacities in the same tenant, including large models.
- Enable XMLA read-write on the capacity and configure tenant/workspace-level Backup storage (ADLS Gen2).
- In SSMS, connect to the workspace’s XMLA endpoint, right-click the database (semantic model) → Back Up… to produce an .abf in your storage account.
- Connect to the target workspace’s XMLA endpoint and Restore… from that .abf. You can also script the restore via TMSL.
TMSL restore example (run in SSMS XMLA query window against the target workspace):
{
"restore": {
"database": "SalesModel-Prod",
"file": "https://<storage>.dfs.core.windows.net/power-bi-backup/SalesModel.abf",
"allowOverwrite": true,
"readWriteMode": "readWrite"
}
}
D) REST APIs (automation) — rebind reports and orchestrate
Best for: scripting promotions where models already exist, or when reports must be pointed at a model in another workspace.
- Rebind a report to a semantic model in a different workspace (creates a shared dataset reference if needed).
- Clone a report into the target workspace and bind it to the target semantic model ID.
Note: There isn’t a single REST call that “clones a dataset” end-to-end; for creating new models via automation, combine PBIP/Git or XMLA (Create/Restore). The enhanced Refresh API can manage table/partition refreshes post-move.
Recommended path (quick decision guide)
- Standard Dev–Test–Prod in same tenant → Deployment Pipelines (simple) or Git+Pipelines (governed).
- Exact copy / large models → XMLA Backup/Restore (.abf).
- Just need reports to point at a model in another workspace → REST Rebind Report.
Quick checks to stabilize your current environment
- Verify OneLake item permissions & Build permission on the semantic model for the caller.
- Confirm workspace is on the intended capacity/region; check capacity health.
- Retry with the RootActivityId handy; if frequent, open a Microsoft ticket.
- For promotion: pick one method above and perform a full refresh in the target after move.
|
✔️ If my message helped solve your issue, please mark it as Resolved!
👍 If it was helpful, consider giving it a Kudos!
|
