Share via

System-managed MPE 'synapse-ws-sqlOnDemand--<workspace>' stuck in Rejected state

Rock 41 Reputation points
2026-06-08T16:06:11.1433333+00:00

Environment

  • Azure Synapse Analytics workspace (serverless SQL pool only — no dedicated SQL pool)
  • Managed Virtual Network: Enabled
  • Data Exfiltration Protection (DEP): Enabled
  • Public network access: Disabled
  • Region: Central US

Problem

The system-managed Managed Private Endpoint named:


synapse-ws-sqlOnDemand--<workspace_name>

with target sub-resource SqlOnDemand is showing Approval state = Rejected in Synapse Studio → Manage → Managed private endpoints.

A second system MPE synapse-ws-sql--<workspace_name> is also Rejected (lower priority because no dedicated SQL pool exists).

Because DEP is enabled, any server-side workload (pipeline Copy activity, Spark job, Script activity) needs this MPE in Approved state to reach the workspace's own serverless SQL endpoint (<workspace>-ondemand.sql.azuresynapse.net) from inside the Managed VNet. Currently every pipeline attempt fails with TCP 10060 / SqlFailedToConnect.

Interactive SQL Script queries (via Dev endpoint) still work — confirming the issue is scoped to MVNet outbound to the workspace's own serverless endpoint.

What I've tried (all failed)

  1. Deleted the MPE in Synapse Studio → workspace platform auto-recreates it (this is documented "system-only" use per the description shown in the detail pane) → state returns as Rejected (not Pending).
  2. Approve via Azure Portal: workspace → Networking → Private endpoint connections → the system MPE does not surface in this list. Only external customer-inbound PEs are visible.
  3. PowerShell: Get-AzPrivateEndpointConnection -PrivateLinkResourceId <workspaceId> returns only the customer-inbound PEs. The system MPE's underlying PE resource lives in a Microsoft-managed subscription (visible in the MPE detail pane), inaccessible to me.
  4. Approve-AzPrivateEndpointConnection — not applicable; resource isn't returned by the API.
  5. Create a parallel user-named MPE to the same target (same workspace + same SqlOnDemand sub-resource) → blocked with: 
    
   Managed private endpoint

   ('synapse-ws-sqlOnDemand--<workspace>')

   has already been created for the selected resource.
    So no parallel route is allowed — 1:1 enforcement per (target workspace, sub-resource) from the MVNet.

What I know

  • Other Synapse workspaces in the same tenant with the same Managed VNet + DEP configuration have this MPE in Approved state and working — so this is an anomaly, not a design choice.
  • The Approval state appears to be persisted on the Microsoft-managed side, so delete/recreate from the customer side doesn't reset it.

My question

  1. Is there any customer-accessible API or REST endpoint that can flip the approval state of a system-managed Synapse MPE? (REST, ARM template, az CLI undocumented flag, anything?)
  2. If not, is there a workspace-level reset that's safe to run (e.g., toggle a setting that triggers full MPE reconciliation with re-approval)?
  3. Has anyone successfully resolved this without Microsoft Support?
  4. As a workaround pattern, what production-grade alternatives have others used? (CETAS from interactive sessions doesn't scale; Spark pool requires net new compute provisioning.)

Any pointers appreciated — thanks!

Azure Synapse Analytics
Azure Synapse Analytics

An Azure analytics service that brings together data integration, enterprise data warehousing, and big data analytics. Previously known as Azure SQL Data Warehouse.

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-06-08T16:06:46.28+00:00

    There is no customer-accessible way in the provided documentation to change the approval state of the system-managed Managed Private Endpoints synapse-ws-sql--<workspace> or synapse-ws-sqlOnDemand--<workspace>.

    From the documented behavior:

    • For workspaces with a Managed Virtual Network, Managed private endpoints are created and managed by Azure Synapse on the customer’s behalf.
    • For dedicated SQL pool and serverless SQL pool, two Managed private endpoints are automatically created when the workspace is created, one targeting dedicated SQL and one targeting serverless SQL (synapse-ws-sqlOnDemand--<workspace>). These are system-managed and not billed.
    • A private endpoint connection uses the standard Private Link approval workflow: when a Managed private endpoint is created, the connection is initially Pending, and the private link resource owner must approve or reject it. Only an Approved Managed private endpoint can be used to send traffic to the linked resource.
    • The resource owner (Microsoft in the case of these system-managed endpoints) controls which private endpoint connections are approved or denied and is in full control of who can connect.

    Within this documented model:

    1. No API or CLI is documented that allows customers to flip the approval state of these system-managed Synapse Managed private endpoints. The approval workflow and control are explicitly on the private link resource owner side.
    2. No workspace-level “reset” or toggle is documented that forces re-approval or re-provisioning of these system-managed endpoints beyond the automatic creation that occurs when the workspace is created. The documentation only states that these endpoints are created automatically and appear under Manage → Managed private endpoints.
    3. The documentation does not describe any customer-side procedure to recover from a Rejected state for these system-managed endpoints without involvement from the resource owner (which, for these built-in endpoints, is Microsoft). There is no documented self-service remediation path for this specific condition.
    4. For production-grade alternatives or workarounds, the documentation focuses on using Managed private endpoints and Private Link as the supported pattern for secure, DEP-enabled connectivity. It does not describe an alternative pattern that bypasses these system-managed endpoints for serverless SQL pool traffic from within the Managed Virtual Network.

    Given the above, the documented behavior and controls imply that resolving a system-managed synapse-ws-sqlOnDemand--<workspace> endpoint stuck in Rejected state requires action on the resource-owner side (Microsoft) via a support channel, not via customer-exposed APIs or configuration toggles.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.