Databricks Workspace Deployment Failed

JamesSmith-0225 0 Reputation points
2026-07-23T15:26:15.7666667+00:00

I'm deploying a VNet-injected Azure Databricks Premium workspace (Secure Cluster Connectivity, enableNoPublicIp: true, custom subnets, requiredNsgRules: NoAzureDatabricksRules) via ARM/Bicep, wrapped in an Azure Managed Application.

The error message I get is:

  • Microsoft.Databricks/workspaces/write failed with ApplianceDeploymentFailed → the nested deployment into the workspace's auto-created sibling managed resource group failed with: {"error":{"code":"InternalServerError","message":"Encountered an internal server error. The tracking id is 'c825aad1-50b6-4148-bc4a-76b15d9dc486'."}}

I don't however see deployment issues in the managed resource group. Can anyone from Microsoft help please?

Azure Databricks
Azure Databricks

An Apache Spark-based analytics platform optimized for Azure.

0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Smaran Thoomu 335 Reputation points Microsoft External Staff Moderator
    2026-08-09T06:14:43.0433333+00:00

    Hi @JamesSmith-0225

    Thank you for sharing the deployment details and tracking ID.

    Before proceeding with further investigation, please verify the following for the VNet-injected workspace:

    • Delegated subnets are configured correctly.
    • Subnet sizes meet the required Databricks deployment requirements.
    • enableNoPublicIp: true and requiredNsgRules: NoAzureDatabricksRules are configured as intended.
    • No Azure Policy, RBAC restriction, or resource lock is preventing resource creation in the Databricks-managed resource group.
    • Review the Azure Portal deployment details for any additional nested deployment errors.

    The deployment error includes the tracking ID c825aad1-50b6-4148-bc4a-76b15d9dc486. If the configuration checks are valid and the issue persists, please provide the deployment details along with the tracking ID so the failure can be correlated with the backend provisioning logs.

    Please also share in private message about the Azure region, workspace name, subscription ID, and the subnet configuration if further investigation is required.

    Was this answer helpful?

    0 comments
  2. kagiyama yutaka 4,915 Reputation points
    2026-07-25T07:24:50.01+00:00

    I think a safe step is opening the portal deployment log and sending that tracking‑id to Azure Support, and the user can re‑check the subnet size and the custom NSG rules because those are the parts ARM actually shows. And the internal reason isn’t visible from the user side, so Support has to pull it with the tracking‑id.

    Was this answer helpful?

    0 comments
  3. Allan Solomon Mejia 3,755 Reputation points
    2026-07-23T18:32:58.3733333+00:00

    Hello James,

    The ApplianceDeploymentFailed wrapper combined with an InternalServerError during creation of the Databricks-managed resource group usually points to a backend provisioning issue rather than a problem with your ARM/Bicep template.

    Before escalating, I'd verify a few prerequisites:

    The delegated host/container subnets are configured correctly for VNet injection.

    The subnet sizes meet Azure Databricks requirements.

    enableNoPublicIp and requiredNsgRules=NoAzureDatabricksRules are supported in the target region.

    No Azure Policy, RBAC restriction, or resource locks are preventing resources from being created in the managed resource group.

    Since you already have a tracking ID, I'd recommend opening a Microsoft Support request and providing that ID. The engineering team can use it to correlate the backend deployment logs, which typically contain the actual failure reason that's not surfaced in the ARM deployment output.

    Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

    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.