@Data_Engineer14,
Great troubleshooting so far. The fact that every Azure-side check passes cleanly but the storage credential creation still fails is a strong signal that this is a backend registration issue, not a misconfiguration on your end.
When you create an Access Connector for Azure Databricks, Azure's Resource Provider is supposed to fire an internal callback to Databricks that registers the connector's managed identity. This registration is what allows Unity Catalog to later resolve the connector when you create a storage credential. The error you are seeing means that the registration step either never fired or failed silently when your Access Connector was originally created. Your connector exists in Azure and is perfectly healthy, but Databricks' internal credential store has no record of it.
This is a known pattern. It can happen due to transient issues during connector provisioning, timing gaps in the Resource Provider callback, or (less commonly) if the connector was created in a standalone resource group that isn't associated with the expected Databricks account.
Here are some options for you to try...
Force a re-registration by modifying the connector's identity. A tag-only update won't trigger the necessary callback, but changing the identity configuration will. The most reliable approach is to temporarily add a User-Assigned Managed Identity alongside your existing System-Assigned one:
- Create a throwaway User-Assigned MI in the same resource group
az identity create -n temp-reregister-uai \
-g <your-resource-group> -l <your-region>
- Update the Access Connector to include both identity types (this preserves your existing System-Assigned MI's principalId):
az resource update \
--ids <access-connector-resource-id> \
--set identity.type="SystemAssigned, UserAssigned" \
identity.userAssignedIdentities.<uai-resource-id>={}โ
-
Retry creating the storage credential. If the callback fires successfully, it should now work.
-
After confirming success, you can revert the connector back to System-Assigned only and delete the temporary UAI. The internal registration persists even after removing the User-Assigned identity.
Alternatively, try the Databricks CLI instead of the Account Console UI. Another community member reported that the same operation that failed in the web UI succeeded through the CLI. You can create the storage credential using.
databricks storage-credentials create --json '{
"name": "<credential-name>",
"azure_managed_identity": {
"access_connector_id": "<access-connector-resource-id>"
}
}'
For the full setup steps, see Use Azure managed identities in Unity Catalog to access storage.
In terms of the separate account-switching error.. "Selected user account does not exist in tenant 'Microsoft Services'" error with application ID 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d is a Microsoft Entra ID authentication issue, not directly related to the storage credential problem. It typically means the identity you're using to sign into the Account Console isn't recognised in the tenant associated with that application. It shouldn't block storage credential creation, but it's worth confirming that the identity you're using to log into the Databricks Account Console belongs to the same Entra ID tenant as your Access Connector's subscription.
If the identity-touch workaround and the CLI approach both fail, this is likely something that needs backend investigation by Databricks Support. Open a support case referencing the UC_AZURE_MANAGED_IDENTITY_CREDENTIAL_NOT_FOUND error and include your Access Connector resource ID and Databricks Account ID. The support team can verify whether the internal credential registration exists and re-trigger it if needed.
Hope this helps.
If this answer resolves your question, could you mark it as โAccept as Solutionโ? That helps other users quickly find the correct fix.
Regards,
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***
