Forum Discussion
Multi-geo capacity error
I ended up having to delete just about everything in that workspace. Then I reloaded it all back in again manually.
Connecting from SSMS (via the XMLA endpoint) is probably the best way to verify when your workspace is kosher again. If that connection fails then you have probably not deleted enough of the old cruft yet. I'm guessing here ... but I think that after the GEO migration, half of the underlying contents may get left behind in the old storage, without any easy way to move it, clear it, or refresh it.
That error ("LargeModelMovedAcrossRegions") was pretty persistent and couldn't shake it without quite a lot of effort. Of course there is nothing in the portal U/I to suggest *which* artifacts in the workspace are the offending ones. If anyone else encounters this, I suggest you resign yourself to the fact that you will need to clear everything out of your workspace and then load it all in again. I think the folks who designed this GEO migration were content to give us a half-baked solution.
As with many things in Power BI, some of the ideas for the product are pretty good, but the execution is not so good (to put it very lightly). On top of that, the tech support is not very good either. </venting>
I opened a Pro ticket and they said that this error is a customer responsibility.
Here are relevant docs:
https://learn.microsoft.com/en-us/fabric/admin/service-admin-premium-multi-geo?tabs=power-bi-premium#move-content-out-of-multi-geo
"It's possible to create and maintain large-storage format semantic models in remote regions to meet data residency requirements. However, you can't move storage format semantic models to another region. Moving large-storage format semantic models from the region where they were created results in reports failing to load the semantic model.
Move the large-storage semantic model back to its original region to make it available. If you must move such a model, deploy it as if it was a new model, and then delete the old model from the undesired region.
"
Basically they want customers to redeploy and possibly lose metadata in the process.
What is really annoying is that even something like an XMLA clear command won't work, over XMLA endpoints. That should clear out the data, but for this particular scenario, it won't work for some reason.
My next attempt is to use SSMS to generate an XMLA-alter statement for the whole dataset, and try to re-run that against the existing one. Worth a shot.
I opened a Pro ticket and they said that this error is a customer responsibility.
Here are relevant docs:
https://learn.microsoft.com/en-us/fabric/admin/service-admin-premium-multi-geo?tabs=power-bi-premium#move-content-out-of-multi-geo
"It's possible to create and maintain large-storage format semantic models in remote regions to meet data residency requirements. However, you can't move storage format semantic models to another region. Moving large-storage format semantic models from the region where they were created results in reports failing to load the semantic model.
Move the large-storage semantic model back to its original region to make it available. If you must move such a model, deploy it as if it was a new model, and then delete the old model from the undesired region.
"
Basically they want customers to redeploy and possibly lose metadata in the process.
What is really annoying is that even something like an XMLA clear command won't work, over XMLA endpoints. That should clear out the data, but for this particular scenario, it won't work for some reason.
My next attempt is to use SSMS to generate an XMLA-alter statement for the whole dataset, and try to re-run that against the existing one. Worth a shot.
Another update. None of the xmla endpoint commands are possible on a corrupted model. Even an attempt to generate a CREATE script fails like so:
{"error":{"code":"LargeModelMovedAcrossRegions","pbi.error":{"code":"LargeModelMovedAcrossRegions","parameters":{"regionName":"East US"},"details":[],"exceptionCulprit":1}}}
... seems like they could have at least allowed us to retrieve schema before we blow one of these models away.
Obviously this scenario wasn't worthy of too much attention from Microsoft. They allowed customers to bear full responsibility for any fall-out that comes after moving from one region to another. It ain't pretty.