Forum Discussion
jaryszek
9 months agoSuper User
We cannot process the request as we encountered a transient issue when trying to determine user
Hi Guys, I have the issue like that after copying semantic model from one workspace into another using TE3: Underlying Error: {"code":"ASOperationExceptionError","pbi.error":{"code":"ASOperation...
- 9 months ago
Problem solved,
The issue was that I had workspaces within different regions. To move it I have used Tabular Editor 3, after deploying model, I need to change a shared connection string to point to the lakehouse already created within target workspace.
Best,
Jacek
SolomonovAnton
9 months agoSuper User
A) PBIP + Git (most robust & repeatable) Recommended
- In Power BI Desktop, enable Developer Mode and Save as PBIP (this writes your model and report to folders using TMDL).
- Push the PBIP project to Azure DevOps or GitHub.
- In the target workspace (created on the new capacity/region), connect the workspace to your repo/branch and Update from Git to materialize a new semantic model and report.
- Adjust parameters/deployment rules for connections, then run a refresh.
B) Publish Directly From Desktop (fastest)
- Create the new workspace on the desired capacity/region.
- Open your PBIX (or build anew), point data sources to target-region Fabric items (Lakehouse/Warehouse).
- Publish to the target workspace. This creates a fresh semantic model there.
C) Author via XMLA/TMSL in SSMS (Premium/PPU)
- Ensure the target capacity has XMLA read-write enabled.
- Use SSMS to connect to the workspace’s XMLA endpoint and run TMSL to create the model, then process/refresh.
Region & Capacity Prerequisites (avoid permission hiccups)
- Keep data and compute in the same region, especially for Direct Lake. Create the Lakehouse/Warehouse in the target region (or use region-local shortcuts).
- If you must go cross-region, expect extra latency and more frequent transient permission lookups. Ensure Readers on the underlying OneLake items and Build on the semantic model for the caller.
- Re-create credentials/gateways in the target workspace; credentials do not move with metadata.
Minimal, Concrete Checklists
Option A — PBIP + Git
- Power BI Desktop → enable PBIP → Save as PBIP.
- Commit to Azure DevOps or GitHub.
- Target workspace → Connect to Git → select repo/branch → Update from Git.
- Set parameters (e.g., Lakehouse/Warehouse names) → Refresh.
Option B — Publish From Desktop
- Create target workspace on the new capacity/region.
- Point all connections to target-region Fabric items.
- Publish PBIX to the target workspace → configure RLS/OLS and permissions → Refresh.
Option C — XMLA/TMSL (Premium/PPU)
- Enable XMLA read-write on the capacity.
- SSMS → connect to the target workspace XMLA endpoint.
- Run TMSL to createOrReplace the model, then process or trigger a refresh.
Example TMSL Skeleton (XMLA)
Run in SSMS → XMLA query window against the target workspace. Adjust names, data sources, and partitions for your environment.
{ "createOrReplace": { "object": { "database": "SalesModel_Target" }, "database": { "name": "SalesModel_Target", "compatibilityLevel": 1600, "model": { "culture": "en-US", "dataSources": [ { "name": "Lakehouse_DS", "type": "structured", "connectionDetails": { "protocol": "tds", "address": { "server": "<your-warehouse-or-lakehouse-endpoint>", "database": "<db-name>" } }, "credential": { "AuthenticationKind": "OAuth2" } } ], "tables": [ { "name": "DimDate", "partitions": [ { "name": "DimDate", "source": { "type": "m", "expression": "let Source = ... in Source" } } ] }, { "name": "FactSales", "partitions": [ { "name": "FactSales_Full", "source": { "type": "m", "expression": "let Source = ... in Source" } } ] } ], "roles": [ { "name": "Readers", "modelPermission": "read", "members": [ { "memberName": "[email protected]" } ] } ] } } } }After creation, issue a
refresh (full or by table/partition) or trigger a dataset refresh from the Service.After You Build
- Rebind reports if any existing reports should now target the new semantic model (Power BI REST rebind operations help automate this).
- Consider adding the workspaces to Deployment Pipelines later for governed Dev → Test → Prod with connection rules.
- Validate security: OneLake item permissions (Reader at source), workspace role (Viewer+), and Build permission on the semantic model for all callers.
Tip for your case: Since the previous error was driven by cross-region permission resolution, prefer PBIP (Option A) or a clean Desktop publish (Option B) while ensuring your Lakehouse/Warehouse (and any Shortcuts you keep) live in the same region as the new capacity. Then perform a full refresh. This avoids the transient OneLake security lookups that led to the earlier failures.
jaryszek
9 months agoSuper User
Hi,
I am using directLAke over Onelake, can not publish anything, it is just a remote semantic model.
And I am not using GIT integration. Plus how this can switch underlying capacities?
What else can I do ?
Best,
Jacek