Azure SQL private endpoint creation fails with NIC InternalServerError / PutNicOperation in Central US

Because the endpoint repeatedly reaches Failed with no IP configuration and its managed NIC disappears, delete the failed private endpoint, wait until it is absent from the control plane, and perform one clean creation under a new name with debug logging; if that also fails, escalate it as a likely service-side provisioning failure with the UTC timestamp and correlation ID.

1. Capture the failing Network Resource Provider operation

Use Azure CLI 2.50 or later and an identity with Network Contributor on both the private-endpoint resource group and the VNet/subnet. Run a fresh creation with a new endpoint and connection name:

az network private-endpoint create \
  --subscription "$SUBSCRIPTION_ID" \
  --resource-group "$RESOURCE_GROUP" \
  --name "$NEW_PE_NAME" \
  --vnet-name "$VNET_NAME" \
  --subnet "$SUBNET_NAME" \
  --private-connection-resource-id "$SQL_SERVER_RESOURCE_ID" \
  --group-id sqlServer \
  --connection-name "$NEW_CONNECTION_NAME" \
  --debug 2>&1 | tee pe-create-debug.log

Record from the output:

• The complete ARM error JSON.
• x-ms-correlation-request-id from the response headers.
• The operation start and failure times in UTC.
• Whether the create call fails immediately or is initially accepted and later transitions to Failed.

--debug, rather than only --verbose, is needed to expose the correlation-request header. A create that is accepted and subsequently fails requires the remaining dependency checks even when the top-level message is only InternalServerError.^1^

Also inspect Azure portal → Resource group → Deployments → failed deployment → Operation details. Deployment history contains each resource operation, its error, and the deployment correlation ID.^2^

2. Rule out a leftover endpoint or control-plane delete race

You have already ruled out subnet delegation, private-endpoint network policies, and provider registration, so do not repeat those changes. Check for a failed, deleting, or hidden name collision:

az network private-endpoint show \
  -g "$RESOURCE_GROUP" -n "$OLD_PE_NAME" \
  --query "{name:name,state:provisioningState,nic:networkInterfaces[0].id}" -o json

az network private-endpoint list \
  -g "$RESOURCE_GROUP" \
  --query "[].{name:name,state:provisioningState,nic:networkInterfaces[0].id}" -o table

If the old endpoint exists, delete it and poll until show returns not found before creating the new name:

az network private-endpoint delete \
  -g "$RESOURCE_GROUP" -n "$OLD_PE_NAME"

az network private-endpoint wait \
  -g "$RESOURCE_GROUP" -n "$OLD_PE_NAME" --deleted

A rapid delete/re-create can encounter a leftover control-plane object even after it stops appearing in normal listings. Using a new endpoint name distinguishes that condition from a repeatable NIC allocation failure.^1^

3. Check the remaining documented creation gates

Confirm Central US is advertised for privateEndpoints in this subscription:

az provider show \
  --namespace Microsoft.Network \
  --subscription "$SUBSCRIPTION_ID" \
  --query "{state:registrationState,locations:resourceTypes[?resourceType=='privateEndpoints'].locations|[0]}" \
  -o json

registrationState must be Registered, and the returned locations must include Central US. Also examine the full error for limit, quota, cap, exceeded, or maximum; those indicate a private-endpoint service limit rather than stale NIC state.^1^

The approved SQL connection does not prove that the consumer-side endpoint succeeded. A non-Succeeded endpoint is a creation failure, and an empty private IP means its NIC was not successfully provisioned.^3^

Self-service recovery boundaries

A fresh PUT can recover a failed Microsoft.Network resource after the underlying problem has cleared. For a private endpoint whose dependent NIC is healthy, use:

az network private-endpoint update \
  -g "$RESOURCE_GROUP" -n "$PE_NAME"

Alternatively:

Get-AzPrivateEndpoint -ResourceGroupName "<resource-group>" -Name "<endpoint>" |
  Set-AzPrivateEndpoint

However, that recovery path applies when the private endpoint exists and its dependent NIC is healthy. In this case the NIC is failed and then returns 404, so updating the endpoint is unlikely to repair that missing dependency; delete/re-create is the documented action for a failed endpoint or empty private IP.^4^^3^

Do not issue Set-AzNetworkInterface against the vanished managed NIC. Microsoft’s general failed-state recovery requires a preceding Get, warns that a bare Set can overwrite settings, and cannot operate when the resource no longer exists.^5^

Escalation

If a clean creation under a new name still fails at PutNicOperation, open an Azure support request for Virtual Network / Private Endpoint provisioning and provide:

• Subscription, resource group, VNet/subnet, region, and SQL server resource ID.
• New and old private-endpoint names.
• Exact failure time in UTC.
• x-ms-correlation-request-id and deployment correlation ID.
• Complete error JSON and pe-create-debug.log.
• Deployment operation details showing the failed Microsoft.Network/networkInterfaces write.
• Output showing the endpoint’s Failed state, empty NIC/IP data, and the subsequent NIC 404.
• Confirmation that the subnet has no delegation, policies are disabled, and Microsoft.Network is registered.

There is no supported public self-service procedure in the supplied diagnostics for clearing stale internal Network Resource Provider state. A reproducible fresh-name failure after the documented gates are excluded requires Microsoft to inspect backend traces using the correlation ID.

References

1. Troubleshoot private endpoint creation that fails or stalls in Azure ...
2. View deployment history with Azure Resource Manager
3. Troubleshoot private endpoint connectivity failures
4. Azure resource move fails because private endpoint not in Succeeded ...
5. Troubleshoot Azure Microsoft.Network failed provisioning state