Unable to create a managed private endpoint in synapse (because it already exists)

Hi @Roman Rietmann

It sounds like you're encountering a conflict when trying to create a managed private endpoint in Azure Synapse because a private endpoint with the same name already exists in the virtual network.

Please check the below options:

1. Even if the managed private endpoint is not listed in the Synapse Studio UI, it may still exist in the underlying virtual network.

az network private-endpoint list --resource-group <rg-name> --query "[].{name:name, vnet:vnet}" --output table

If the endpoint exists, consider deleting it before attempting to create a new one.

2.When deploying Synapse workspaces using ARM templates, ensure that the templates are correctly configured to manage private endpoints. Improper configurations can lead to orphaned resources.

3. Be cautious with resource naming conventions to avoid conflicts with existing resources.

I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.

Thank you

Hi, thank you. But i don't think this helps.

The error says that there is already an managed endpoint in this subscription:

Private endpoint already exists in the vnet

/subscriptions/f3fbb49a-c522-483f-ab8e*********/resourceGroups/vnet-****************-westeurope-90-rg**/providers/Microsoft.Network/virtualNetworks/vnet-f3fb-westeurope-90 with PEReferenceName synapse-ws-sqlOnDemand--fgch-synapse-euw-test and status Approved. Client id: b1c1352d-2b41-4c6b-b768-***********

But on this tenant i do not have such a subscription:

... and there are currently no other subscriptions on this tenant (100% sure). I assume that Synapse creates managed endpoint on a virtual network managed by Azure or Synapse Instance.

I also not have any client ID in my Entra having the ID mentioned in the message.

@Roman Rietmann Thanks for sharing the details, I understand it can be quite frustrating and unclear when an error refers to a subscription that isn’t under your control.

Please help me with the questions below. In the meantime, I’ll check internally to resolve your issue as quickly as possible.

Are you trying to deploy the Synapse workspace into a user-managed VNet or letting Azure create one?(Important because Microsoft-managed VNets behave differently.)

Have you tried deploying with a completely different workspace name (e.g., with a unique suffix)? (To verify if the issue is purely a naming conflict.)

Did you recently delete a Synapse workspace with the same name? (Sometimes Azure retains ghost resources for a short time.)
Have you checked the Azure activity log for any failed or conflicting deployments? (To find clues on previous deployments or hidden conflicts.)

Are there any existing private endpoints in the target VNet/subnet from previous deployments or other services? (A subnet can only have one Private Endpoint per service.)

@Roman Rietmann

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Hi, thanks for the quick response.

We do use Synapse (Azure) managed vnets:

By default Synapse creates private endpoint connections which are located in Azure managed subscription, and i can "manage" them on the Azure portal. Our production looks like:

the first ones, are the ones i referee to. On the test i do not have them:

... but the error shows, if i try to create a new one directly in synapse

Have you tried deploying with a completely different workspace name (e.g., with a unique suffix)? (To verify if the issue is purely a naming conflict.)

--> yes we had a public synapse worksspace in place with the same name. I deleted it and recreated it with set managed vnet to true. For test and production the same.

the only difference was that i did a deployment in Synapse test using a template from a public workspace (dev). It seems that probably some parts of the pep configuration got messed up during the deployment.

Did you recently delete a Synapse workspace with the same name? (Sometimes Azure retains ghost resources for a short time.) Have you checked the Azure activity log for any failed or conflicting deployments? (To find clues on previous deployments or hidden conflicts.)

--> yes, see above
--> it was working until the deployment.
--> I did check the Activity Logs in the Azure Monitor... and there is nothing related to it.

Are there any existing private endpoints in the target VNet/subnet from previous deployments or other services? (A subnet can only have one Private Endpoint per service.)

--> there are currently 2: one DFS and one to Synapse Private link hub:

I can try to remove the workspace and recreate it?