Synapse managed VNet not receiving private endpoint approval state new MPEs stuck "Pending" for days while target shows "Approved"; sibling workspace works

Question

Synapse managed VNet not receiving private endpoint approval state new MPEs stuck "Pending" for days while target shows "Approved"; sibling workspace works

Rushil Shetty 0

Summary

On one Synapse workspace (PRD, managed VNet enabled), every managed private endpoint created since 11 Sep 2026 reaches provisioningState: Succeeded but connectionState.status stays Pending indefinitely (now 3+ days), even though the target storage account shows the connection as Approved. Traffic does not flow. A sibling workspace in the same tenant approves against the same target without issue.

Per the Private Link pending-approval troubleshooting guide (Step 2 table), target = Approved / consumer = Pending after several minutes is classified as a control-plane inconsistency requiring a support request. Posting here first in case the product group has seen this pattern.

Environment

Synapse workspace with managed virtual network (default), West Europe
Target: Azure Storage (StorageV2, HNS enabled), sub-resource file, different subscription, same tenant
MPEs created via az synapse managed-private-endpoints create and via Synapse Studio is identical result
Connection approved via portal and via az network private-endpoint-connection approve is identical result

Repro (two targets, one control)

	Workspace	Target	Synapse `connectionState`	Storage-side connection
Case 1	WS-A (PRD)	Storage account X, `file`	`Pending` (3+ days)	`Approved`, `provisioningState: Succeeded`
--------	--------	--------	--------	--------
Case 1	WS-A (PRD)	Storage account X, `file`	`Pending` (3+ days)	`Approved`, `provisioningState: Succeeded`
Case 2	WS-A (PRD)	Storage account Y, `file`	`Pending` (hours)	`Approved`
Control	WS-B (PRD, same tenant)	Storage account Y, `file`	`Approved`	`Approved`

Storage accounts X and Y are in the same resource group and subscription, same configuration (StorageV2, HNS on, defaultAction: Allow, publicNetworkAccess not restricted).
WS-A has 7 pre-existing MPEs (storage dfs, Key Vault, Synapse SQL): all Approved, all created before 11 Sep. Only MPEs created since then are affected.
~90 MPEs across 9 other workspaces in the tenant are all Approved.

Evidence the PE object itself is stuck

Attempting to create a second MPE from WS-A to storage account X returns:

409 PrivateEndpointAlreadyExists: Private endpoint already exists in the vnet
/subscriptions/<microsoft-owned-sub>/resourceGroups/vnet-<id>-WestEurope-<n>-rg/providers/Microsoft.Network/virtualNetworks/vnet-<id>-WestEurope-<n>
with PEReferenceName <mpe-name> and status Creating.

So the NRP-side private endpoint in the managed VNet has a private IP allocated (visible in Studio) but never transitions out of Creating, which is consistent with it not being able to receive the approval state.

properties.privateEndpoint.id on the storage-side connection matches properties.resourceId on the Synapse MPE exactly the objects are correctly linked.

Already ruled out

Locks on target: a ReadOnly lock was present on storage account X on 11 Sep and caused the very first MPE attempt to fail with ScopeLocked on privateEndpointConnectionProxies/validate/action. Lock was removed (now CanNotDelete only). Storage account Y never had a ReadOnly lock and shows the same symptom.
Azure Policy: no Deny-effect policies on the target scope; activity log on both storage accounts shows zero failed operations since 11 Sep 09:30 UTC no RequestDisallowedByPolicy, no ScopeLocked.
RBAC: approver has Microsoft.Storage/storageAccounts/privateEndpointConnectionsApproval/action; approve returns 200 with status: Approved.
Approval timing: approved only after Synapse reported provisioningState: Succeeded.
Delete / recreate: MPE and storage-side connection deleted and recreated twice (waited for both sides to list empty in between). Same result each time.
Reject → re-approve: Storage RP treats Rejected as terminal (InvalidValuesForRequestParameters), so this path is not available.
Wait: Case 1 has been Pending for over 72 hours across a weekend. Studio Refresh and repeated CLI show calls do not change it.
Name / target / sub-resource: reproduced with two different MPE names and two different target accounts, same sub-resource that works from WS-B.
Linked service test connection from the managed VNet IR fails (connection not established), confirming this is not a display issue.

Questions

Is there any customer-side action that forces the managed VNet to re-read connection state from NRP for an existing MPE?
Is there any known condition (e.g. a failed privateEndpointConnectionProxies/validate on the first attempt) that can leave a workspace's managed VNet unable to finalise subsequent PEs, and any way to clear it without a support case?
If this requires backend intervention: which team should a support request be routed to Synapse or Private Link/NRP given the PE object appears stuck on the NRP side but only for this one workspace?

Workspace name, cluster ID, managed VNet resource ID and PE resource IDs are available on request via private message.

0 comments

1 answer

Your answer

Answer 1

Allan Solomon Mejia 8,420

Hello @Rushil Shetty

If you’re referring to a Managed Private Endpoint created from an Azure Synapse workspace that has Managed VNet enabled, the expected lifecycle is:

Synapse Managed VNet > Managed Private Endpoint created > Provisioning State = Succeeded > Approval State = Pending > Target resource owner approves > Approval State = Approved

The connection is created in Pending state, and the owner of the target Private Link resource must approve or reject it. Only an Approved managed private endpoint can carry traffic.

So if Synapse Studio shows the managed private endpoint as created successfully but you don’t see a corresponding approval request on the target resource, check the following:

Confirm the workspace actually has a Managed workspace Virtual Network. Managed private endpoints are only supported when Managed VNet is enabled.
Confirm the Private Link Resource ID and groupId are correct for the target service.
On the target resource, open Networking / Private endpoint connections and look for the pending connection.
If the target is in another subscription or tenant, verify you have the required permissions on that target resource and that cross-tenant configuration is allowed.
If approval fails or the Approve button is missing, verify the approver has the target service’s privateEndpointConnectionsApproval/action permission. Microsoft’s current Private Link troubleshooting guidance specifically calls out missing approval permissions as a common reason managed-service private endpoints remain stuck or can’t be approved.

Also note that managed-service private endpoints such as those created by Synapse do not auto-approve simply because the source and target are in the same subscription. Microsoft specifically calls managed Azure services such as Azure Synapse out as requiring approval.

You can also verify the Synapse-side object from CLI:

az synapse managed-private-endpoints list \
  --workspace-name <workspace-name>

or inspect a specific endpoint:

az synapse managed-private-endpoints show \
  --workspace-name <workspace-name> \
  --pe-name <endpoint-name>

These commands are the supported CLI operations for Synapse managed private endpoints.

If the Synapse endpoint shows provisioningState: Succeeded but the target resource has no pending private endpoint connection, that would be the interesting failure condition. In that case, capture the managed private endpoint JSON, target resource ID, groupId, exact UTC creation time, and Activity Log entries from both source and target subscriptions, then raise it with Azure Support because the Synapse control plane appears to have created the consumer-side object without successfully creating the corresponding target-side connection request.

References:

Managed private endpoints in Azure Synapse Analytics

Create a managed private endpoint in Synapse

Managed virtual network in Azure Synapse

Azure CLI - Synapse managed private endpoints

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

Rushil Shetty 0 Reputation points

2026-09-15T06:46:44.7766667+00:00
Thanks for replying @Allan Solomon Mejia but it addresses a different failure than the one described. To be precise:

The target-side connection does exist and is Approved (status: Approved, provisioningState: Succeeded, privateEndpoint.id matching the MPE's resourceId). Screenshots and CLI output in the original post.

The Synapse side has already been checked with az synapse managed-private-endpoints show; that is where the provisioningState: Succeeded / connectionState.status: Pending values in the post come from.

Managed VNet is enabled (both workspaces show identical managedVirtualNetworkSettings), resource ID and groupId are correct (same target/groupId approves fine from the control workspace), approver holds privateEndpointConnectionsApproval/action and the approve call returned 200, target is same-tenant.

The failure is the approved state not being reflected on the Synapse/NRP side, for one specific workspace only, with the NRP-side PE reported as status: Creating in a 409 response. Per the Private Link troubleshooting guide's Step 2 table, target=Approved / consumer=Pending is a control-plane inconsistency.

Could this be escalated to the Synapse product group? Identifiers (workspace, cluster ID, managed VNet ID, PE resource IDs, UTC timestamps) are ready to share via private message.
Allan Solomon Mejia 8,420 Reputation points

2026-09-15T13:23:46.55+00:00
Hi @Rushil Shetty

Thanks for the clarification and for providing the additional evidence. You're correct; my previous response focused on the normal approval workflow, but your case is different.

Based on what you've documented, I agree this no longer looks like a customer-side approval, RBAC, target-resource, or Managed VNet configuration issue.

provisioningState and connectionState are separate properties of the Synapse managed private endpoint. Under normal operation, once the target resource owner approves the connection, the private link should become established, and the Synapse-side approval state should eventually reflect that approval.

In your case, the target-side privateEndpoint.id matching the Synapse MPE resourceId is particularly useful evidence because it shows we're looking at the same underlying private endpoint, not two unrelated PE objects.

The control test with WS-B also strengthens the case. The same target and groupId successfully reach Approved from WS-B, while newly created MPEs from WS-A remain Pending. Combined with approximately 90 working MPEs elsewhere in the tenant, this points much more strongly toward a workspace-specific control-plane state problem than a Storage, RBAC, subscription, tenant, or Private Link configuration problem.

I don't recommend further delete/recreate cycles at this point. You've already reproduced the condition against two storage accounts and recreated the MPE/target-side connection twice after confirming both sides were cleared.

The 409 PrivateEndpointAlreadyExists response is especially significant because it reports the private endpoint in the Microsoft-managed VNet with status Creating while Synapse reports its MPE provisioning as Succeeded and Storage reports the corresponding connection as Approved. That strongly suggests the remaining problem is between the Synapse managed-VNet control plane and the underlying Network Resource Provider (NRP) private endpoint state, rather than the approval operation itself.

Also, a properly provisioned and approved private endpoint should show both provisioningState: Succeeded and connectionState: Approved.

Escalate this rather than make further configuration changes.

Initially, route the support request under Azure Synapse Analytics / Managed Virtual Network / Managed Private Endpoint, because the customer-visible resource being managed is the Synapse MPE and the failure is isolated to one Synapse workspace. In the case description, explicitly ask the Synapse engineering team to engage Azure Private Link/NRP because the underlying managed Microsoft.Network/privateEndpoints object appears stuck in Creating.

Include the following information privately:

Synapse workspace and workspace resource ID

workspace/cluster ID

managed VNet resource ID

Synapse MPE resource ID

underlying private endpoint ID

target private endpoint connection ID

target Storage resource ID and groupId

exact UTC timestamps for creation and approval

output showing Synapse Succeeded/Pending

output showing Storage Succeeded/Approved

the 409 PrivateEndpointAlreadyExists response showing the NRP-side PE as Creating

the successful WS-B control test

Also mention the original ScopeLocked / privateEndpointConnectionProxies/validate/action failure as historical context, but I don't assume it is the root cause because you've reproduced the same condition against Storage Y, which never had that ReadOnly lock.

So yes, based on the evidence you've now provided, escalation to the Synapse product/support team with NRP/Private Link involvement is the appropriate next step. I don't see another documented customer-side remediation that I'd recommend before escalation.

Thanks for correcting the distinction and for documenting the control tests; they make the failure domain much clearer.

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.