How to recover Synapse Workspace provisioning state from Failed state

Question

How to recover Synapse Workspace provisioning state from Failed state

Yadav, Ankit 60

Hello Q&A team,

we have a Synapse Workspace on which our team had performed an operation named "Create Or Update Azure AD only authentication for workspace and its sub resources." and that ended up in Failure with message "Create or Update Azure AD only authentication for workspace and its sub resources request validation failed, check error details for more information" and the error code was "ValidationFailed".

[I can share the synapse workspace details over Private Message if that helps to debug the details and provide the appropriate solution for the issue]

This was an event done 3 days earlier ie Fri Jul 03 2026 08:06:45 GMT+0530 (India Standard Time) however still the cluster seems to be in Failed state due to which we are blocked to perform any operations on the Workspace.

As part of Azure AI analysis, we have received some solutions like below but none of them applies to this situation, it'll be helpful if anyone could help to fix this issue.

Yadav, Ankit 60 Reputation points

2026-07-07T14:34:55.3133333+00:00

Hi Team,

Can we have some updates on this query?
Manoj Kumar Boyini 18,920 Reputation points Microsoft External Staff Moderator

2026-07-07T14:46:38.12+00:00
Hi @Yadav, Ankit

I kindly request you to please share the details requested in the private message for further investigation.
To help you narrow it down quickly, can you share:

Did you change public network access (or any firewall/private endpoint/network restrictions) around the same time as the “Azure AD only authentication” operation?

Does this Synapse workspace use Customer Managed Keys (CMK) / encryption with an Azure Key Vault?

In the Azure portal, what is the exact provisioning error details shown under the Failed operation (beyond the high-level “request validation failed”)? Any mention of policy, network, or Key Vault/managed identity?

Is your environment subject to any Azure Policy that denies public network access or restricts certain networking changes?

If you can answer those, I can map your scenario to the most likely recovery path from the provided guidance.
Yadav, Ankit 60 Reputation points

2026-07-07T15:40:53.1333333+00:00
Hey Manoj,thanks for reaching out, plz find the requested details below:

Did you change public network access (or any firewall/private endpoint/network restrictions) around the same time as the “Azure AD only authentication” operation?
Yes public network access was enabled that time.

Does this Synapse workspace use Customer Managed Keys (CMK) / encryption with an Azure Key Vault?
No

In the Azure portal, what is the exact provisioning error details shown under the Failed operation (beyond the high-level “request validation failed”)? Any mention of policy, network, or Key Vault/managed identity?
Sorry I don't have this detail as it was done by our Data Engg team, I'll try to check if they have the error faced handy with them.

Is your environment subject to any Azure Policy that denies public network access or restricts certain networking changes?
No (atleast not that we have seen it otherwise it'd have shown in the error/activity logs too).

Answer accepted by question author

0 additional answers

Your answer

Yadav, Ankit 60 Reputation points

2026-07-07T14:34:55.3133333+00:00

Hi Team,

Can we have some updates on this query?
Manoj Kumar Boyini 18,920 Reputation points Microsoft External Staff Moderator

2026-07-07T14:46:38.12+00:00

Hi @Yadav, Ankit

I kindly request you to please share the details requested in the private message for further investigation.
To help you narrow it down quickly, can you share:

Did you change public network access (or any firewall/private endpoint/network restrictions) around the same time as the “Azure AD only authentication” operation?

Does this Synapse workspace use Customer Managed Keys (CMK) / encryption with an Azure Key Vault?

In the Azure portal, what is the exact provisioning error details shown under the Failed operation (beyond the high-level “request validation failed”)? Any mention of policy, network, or Key Vault/managed identity?

Is your environment subject to any Azure Policy that denies public network access or restricts certain networking changes?

If you can answer those, I can map your scenario to the most likely recovery path from the provided guidance.
Yadav, Ankit 60 Reputation points

2026-07-07T15:40:53.1333333+00:00

Hey Manoj,thanks for reaching out, plz find the requested details below:

Did you change public network access (or any firewall/private endpoint/network restrictions) around the same time as the “Azure AD only authentication” operation?
Yes public network access was enabled that time.

Does this Synapse workspace use Customer Managed Keys (CMK) / encryption with an Azure Key Vault?
No

In the Azure portal, what is the exact provisioning error details shown under the Failed operation (beyond the high-level “request validation failed”)? Any mention of policy, network, or Key Vault/managed identity?
Sorry I don't have this detail as it was done by our Data Engg team, I'll try to check if they have the error faced handy with them.

Is your environment subject to any Azure Policy that denies public network access or restricts certain networking changes?
No (atleast not that we have seen it otherwise it'd have shown in the error/activity logs too).

Answer 1

Hi @Yadav, Ankit

Our investigation indicates that the issue was related to a service-side provisioning problem affecting Synapse workspace update operations. The problem impacted workspace update requests, including PatchWorkspace operations, and caused workspace update activities to fail.

The issue has since been mitigated by the engineering team, and service health monitoring has returned to a healthy state.

We have also received confirmation that similar workspace update failures were observed across multiple regions, with a higher concentration of impact in the Japan East region.

If the issue still persists, please let us know.

Answer 2

kagiyama yutaka 4,340

I think Synapse workspace stuck in Failed after that AAD‑only auth update can only be handled by checking the Activity‑log error and fixing or reverting that auth setting, trying the same update once from the portal and sending the error to Azure support when it stays Failed.

Yadav, Ankit 60 Reputation points

2026-07-06T12:34:06.0066667+00:00

Hey @kagiyama yutaka , thanks for your suggestions however the error which I have posted in my original question is from Activity logs only. We have tried to pass through the same deployments however it ends up saying that the workspace itself is in failed state. That's why I felt it's kind of a deadlock that I have to fix the provisioning state first and that itself was induced with a failed operation. Maybe someone from Microsoft Ext Staff users could help me raise a SR using this request or some working solution for this issue.

Answer 3

The workspace is stuck in a Failed provisioning state after a control-plane operation, so only limited actions are possible until the state is corrected. For Synapse workspaces after tenant- or identity-related changes, the supported recovery pattern is to reset the workspace’s managed identity and then reapply access and identities.

Use the following sequence (only if the subscription/tenant move or identity change is already complete):

Disable and re-enable the system-assigned managed identity (SAMI) for the Synapse workspace

Build the workspace REST URL (Azure CLI example):

     $resourceGroupName="<resource-group>"
     $workspaceName="<workspace-name>"
     $subscriptionId="<subscription-id>"
     
     $url="https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Synapse/workspaces/$workspaceName?api-version=2021-06-01"

Disable the system-assigned identity:

     az rest --method patch --headers Content-Type=application/json \
       --url $url \
       --body '{ "identity": {"type": "None"}}'

Wait a few minutes, then check provisioning state and identity type:
```
     az rest --method GET --uri $url
```
The provisioningState should become Succeeded and identity.type should be None. If it shows Provisioning, wait until it changes to Succeeded before continuing.

Re-enable the system-assigned identity:

     az rest --method patch --headers Content-Type=application/json \
       --url $url \
       --body '{ "identity": {"type": "SystemAssigned"}}'

Verify again:
```
     az rest --method GET --uri $url
```
provisioningState should be Succeeded and identity type SystemAssigned.

The same can be done with Azure PowerShell using Invoke-RestMethod with a PATCH body that sets identity.type to None and then back to SystemAssigned.

Recreate and reassign user-assigned managed identities (if used)
- After the workspace is back to Succeeded, recreate any user-assigned managed identities and assign them to the workspace as needed. See “Credentials in Azure Data Factory and Azure Synapse” from the referenced article.
Reapply access and RBAC so operations in Synapse Studio work again Once the provisioning state is healthy:
- Reassign Azure RBAC roles on the Synapse workspace and related resources (for example, ADLS Gen2) to Microsoft Entra users, groups, and managed identities.
- Set the SQL Active Directory admin for the workspace’s SQL pools.
- Recreate Microsoft Entra logins/users in dedicated and serverless SQL pools and add Synapse RBAC role assignments so Synapse Studio can be opened without 403/Unauthorized errors.

If, after disabling and re-enabling the system-assigned managed identity, the workspace still remains in a Failed provisioning state or PATCH operations themselves fail, open an Azure support ticket and include the full error details from the failed operation, as control-plane recovery beyond these steps requires backend intervention.

References: