Forum Discussion
CapacityNotActive for just one workspace
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.
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.
- svenchio9 months agoSuper User
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.