Azure ML Provisioning Error - An internal server error occurred. If the problem persists, contact support.

Hello Daniel

Thanks for confirming you've already checked quota — that's usually step one, so good to have that ruled out already.

The "An internal server error occurred. If the problem persists, contact support" message is a generic wrapper that Azure ML returns for several different backend provisioning failures, so it's worth working through a short checklist rather than assuming one cause. A few things that commonly trigger this even when VM-family quota looks fine:

1. A separate, aggregate compute-resource cap (not the same as VM-family quota) It's easy to check quota per VM family and still hit a wall, because Azure ML also enforces a total compute-resource limit per region (default 500, shared across training clusters, compute instances, and managed online endpoint deployments, with a compute instance counted as a single-node cluster). Worth checking this alongside your VM-family quota.
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-quotas?view=azureml-api-2

2. Resource locks A Delete or Read-only lock on the resource group hosting your workspace — or on a separate resource group tied to a linked virtual network — can silently block the create/resize/delete operations a compute instance depends on. Check Resource Group → Locks on both the workspace RG and any VNet RG.
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-compute-instance?view=azureml-api-2

3. Workspace's default storage account A recurring pattern behind this exact error is an issue with the storage account Azure ML provisions for the workspace — commonly because the workspace identity has lost read/write access, whether from a key rotation, a new firewall rule, or an RBAC change. Worth confirming the storage account still exists, isn't behind a firewall blocking the workspace identity, and that the identity's role assignments are intact.

4. Region/SKU capacity If you're targeting a higher-demand SKU (GPU families especially), regional capacity can simply be exhausted at the moment you try to provision, independent of your subscription. Try a different region or VM size as a test — if that succeeds, it isolates the issue to capacity rather than your workspace config.

5. Resource provider registration Less common, but quick to rule out: confirm Microsoft.MachineLearningServices and its dependencies (Storage, KeyVault, ContainerRegistry) show "Registered" under Subscriptions → Resource providers.

6. Workaround while we dig further One person who hit this identical error found that a Compute Cluster provisioned successfully in the same workspace where a Compute Instance kept failing — not a root-cause fix, but useful to confirm the workspace itself is healthy. → https://learn.microsoft.com/en-us/azure/machine-learning/how-to-create-compute-instance?view=azureml-api-2

7. If it's still failing Open the failed operation in the resource group's Activity Log and expand the JSON — there's often a more specific code buried under the generic message. If nothing there explains it, open a support ticket and include that correlation ID; the backend team needs it to pull the actual provisioning trace, since "internal server error" alone isn't diagnosable client-side.

Requested the customer to retry the operation and it succeeded

Thanks,
Manish.