CapacityNotActive for just one workspace

[b_vanderlaan]

Hi All,

I have a workspace containing a lakehouse, several semantic models, and reports built on top of them. Everything was working fine until recently, now I can’t open any lakehouse, semantic model, or report in this workspace. I keep getting the error message: “Capacity operation failed with error code CapacityNotActive.”

The capacity itself is active, and other workspaces using the same capacity work without any issues. I even tried creating a new Azure Fabric capacity, but I still get the same message. I’m a capacity administrator, and other users in the workspace experience the same problem.
It seems like something is wrong specifically with this workspace, but I can’t figure out what.

Any ideas or suggestions on how to fix this?

Details of the error message:
Underlying Error: Capacity operation failed with error code CapacityNotActive

[marcelopesarmen]

I’m seeing the same error and I believe I found a scenario that can trigger it.

In my case the sequence was:

1. Workspace was assigned to Capacity A

2. I created a new Capacity B

3. I deleted Capacity A

4. Only after that I tried to reassign the workspace to Capacity B

The reassignment appears to work. In the workspace settings I can select Capacity B and the workspace shows as correctly assigned to it.

However, some objects inside the workspace (especially semantic models) start returning CapacityNotActive errors. So externally everything looks correct (the capacity is active and the workspace is assigned to it) but internally it seems some artifacts may still reference the old capacity.

Interestingly, the issue sometimes resolves itself after a few days, which makes me suspect there may be some background repair or cleanup process running on the service side.

My hypothesis is that the workspace reassignment expects both capacities to exist during the migration process. If the original capacity is deleted first, the workspace might end up in an inconsistent state.

For anyone doing capacity migrations, I would strongly recommend keeping both capacities active, performing the reassignment while both exist, and only deleting or stopping the old capacity afterwards.

[v-aatheeque]

Hi @marcelopesarmen 

Thank you for sharing the detailed scenario and observations. This is very helpful for other who will face similar issues.

[b_vanderlaan]

We ended up contacting Microsoft Support. They spend some days troubleshooting and last Friday the workspace was working without issues. Today it does not work again. We did not get any feedback on the reason why it is broken. I expect it must be a bug they are solving on their side. 

[v-aatheeque]

Hi @b_vanderlaan 

Thanks for the update. Since Microsoft Support already investigated and the issue temporarily resolved but then returned, it does sound like an ongoing backend or service-side bug.

At this stage, the best next step is to continue working through the existing support ticket so Microsoft can track the recurrence and provide a permanent fix.  Some times intermittent workspace failures are typically tied to backend updates or service incidents, and only the product team can fully validate and resolve them.

[v-aatheeque]

Hi @b_vanderlaan 

Just checking in to see if the previous response helped resolve your issue. If not, feel free to share your questions and we’ll be glad to assist.

[v-aatheeque]

Hi @b_vanderlaan 

Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.

[AntoineW]

Can you verify on this workspace, on the top right corner, there is the workspace settings, see under the Licence Info, the Licence configuration is set on a Fabric Capacity active : 

You can also verify the status of your capacity on the Admin Portal : 

Hope it can help !

Antoine

[svenchio]

Hi @b_vanderlaan   it seems like a very odd thing what's happening to you, I'll try to give you some general advise while you clarify "[...] I even tried creating a new Azure Fabric capacity", so, #1. you created a new Fabric capacity in Azure, #2. assign this new capacity to the same workspace with issues, and after this, the workspace keep saying "Capacity operation failed with error code CapacityNotActive"?  Another clue is that other workspaces using the same capacity are operating just fine, right? So, these two combined I would agree with with you that it seems more like workspace related  ... how about this as next best steps (building on what we know):

#1. Explicitly detach and reattach the capacity, that is, temporarily assign the workspace to a different (non-Fabric or PPU) capacity, save it, then reassign to the Fabric capacity.

#2. Switch to trial mode temporarily (if allowed), go to workspace settings and enable Fabric trial mode, then switch back to the original capacity... some community users reported this workaround “reinitialized” workspace backend links

#3. Try creating a duplicate workspace and assign it to the same capacity, If the new workspace works fine, you’ll confirm the original is corrupted.

Let's see if any of these actions help! If so, then problem solved and marked this as a solution 😉 if not, let us know for some additional ideas. 

[b_vanderlaan]

Dear svenchio, 

Your summary of our problem is correct, thank you for your suggestions.

#1. We attempted to assign the workspace to a different capacity, but got this message:

#2. The trail capacity is not available (we used it in the past). 
#3. We created a new workspace and assigned it to the same capacity, here simple functionalities like the lakehouse and running dataflows work without issues.

We can conclude that the issue is with the workspace, but do not understand what the issue is. Additional help with troubleshooting is highly appreciated.

[svenchio]

On #1, this is well know "restriction" on capacities, they just simpley play only with capacities on the SAME region, for instance, in a pipeline, a dev workspace cannot deploy to a uat workspace if this is attached to a capacity on a different region, in other words, try #1 but the new capacity HAS TO BE ON THE SAME REGION as the current! In this quick example, the new capacity you create to re-attached the faulty workspace would have to be in Norway East (as an example) 

You can also check on Azure about the location and status of your capacity 

Thinking about this, by any chance, have you check any unsuaul activity on the capacity Activity Log from Azure? Perhaps there's some warning or indication that suggest what "changed", as you said, it was working and suddently stopped working, so, I would thinkg to my self, what changed? 

Hopefully test #1 is possible, don't see why you could not create a new capacity on the same region to at least, make your existing workspace get back on business as priority #1, right? if any of these works, my next thought would be permissions ... either the workspace permission? for instance, is the owner of the workspace is a security group? what is a member of this security group has been removed for some reason, and this group or person was the link to the azure subscription where the facbric capacity resides? Do you have the workspace under a domain? Has domain permissions changed? 

Some additional ideas to explore, let me know how it works ... kudos if any of these and/or the prev. suggestino had been useful.