Share via

Unable to run remediation or install VM Extension

Admin - BL 20 Reputation points
2026-05-13T19:50:50.4966667+00:00

I have owner access on the root level of an Azure tenant and am trying to run a remediation for 3 Virtual machines. When it was failing, I tried to install the extension directly but received the error:
DenyAssignmentAuthorizationFailed",

"message": "The client 'xxxx' with object id 'xxxx' has permission to perform action 'Microsoft.Resources/deployments/validate/action' on scope '/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.Resources/deployments/__dv__GalleryViewCreate_Qualys_xxxxxx'; however, the access is denied because of the deny assignment with name 'System deny assignment created by Azure Databricks /subscriptions/xxxx/xxxx/xxxx/providers/Microsoft.Databricks/workspaces/xxxxxx' and Id 'xxxe' at scope '/subscriptions/xxxxxx/resourceGroups/xxxxxx'

From https://learn.microsoft.com/en-us/answers/questions/5524682/fixing-issue-of-deny-assignment-with-azure-databri, it is because of a deny permission and that Deny permissions cannot be modified even by the owner and that the Databricks workspace will need be deleted first. This is not an option as the the workspace is still in use but we need to run the remediation for the VMs.

Is there a way around this error, even if it requires a Microsoft ticket?

Azure Databricks
Azure Databricks

An Apache Spark-based analytics platform optimized for Azure.

0 comments

Answer accepted by question author

AI answer

2026-05-13T19:51:03.55+00:00

There is no supported way to bypass or override a system deny assignment created by Azure Databricks while the workspace that owns it still exists. Deny assignments are evaluated after role assignments; if a deny applies at the scope of the VMs or their resource group, it blocks deployments and extension operations even for users with Owner at a higher scope.

Because the deny assignment is at the subscription/resource group scope and explicitly blocks Microsoft.Resources/deployments/* operations, any remediation task or direct extension deployment that relies on ARM deployments to those VMs will fail as long as that Databricks workspace (and its system deny assignment) remains in place.

The only supported remediation is to change the Databricks-side configuration that created the deny assignment (if such an option exists in that specific Databricks feature) or to delete the Databricks workspace, which removes the system deny assignment. If the workspace must remain in use and its deny assignment cannot be reconfigured, then the remediation that requires ARM deployments/extensions at that scope cannot be performed.

Opening a Microsoft support ticket can confirm the specific deny assignment and its impact, but support cannot remove or override a system deny assignment that is owned by an active managed service resource such as Azure Databricks.

References:

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

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Manoj Kumar Boyini 15,570 Reputation points Microsoft External Staff Moderator
    2026-05-17T07:56:11.0466667+00:00

    Hi @Admin - BL

    The error is occurring because the affected resources are under an Azure Databricks managed resource group protected by a system-managed deny assignment.

    Although the account has Owner permissions, deny assignments take precedence over RBAC permissions and can block ARM deployment operations such as:

    • VM extension installation
    • Remediation tasks
    • Deployment validation actions (Microsoft.Resources/deployments/validate/action)

    This behavior is similar to other known Azure Databricks managed resource group scenarios where ARM operations (such as policy remediation, tagging, or extension deployment) can fail because of system-managed deny assignments protecting Databricks-managed resources.

    The issue is not caused by missing RBAC permissions, since deny assignments override inherited Owner/Contributor permissions.

    At this time, there is no supported your side method to bypass or remove the deny assignment while the Databricks workspace remains active.

    As a possible workaround, you may move the affected VMs/resources to a resource group that is not managed by Azure Databricks, if operationally feasible.

    If the issue still persists or if the deny assignment appears unexpected, we recommend opening a Microsoft Support request so the backend team can validate whether the deny assignment is functioning as intended or determine whether any stale/orphaned backend state exists.

    References:

    Please let us know if you have any questions.

    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.