The cluster was deployed two days ago. Local Identity with Azure Key Vault, single node, West Europe. Registration is healthy, connection status shows Connected, sync is running on schedule. Everything looks exactly the way it should.
Then the update pre-check blocks with a single health fault:
Microsoft.Health.FaultType.Cluster.KeyVaultDoesNotExist
The Key Vault exists. The secrets are in it. So what is actually going on?
The Environment
| Property | Value |
| Cluster | ClusterKADZ |
| Deployment Model | Local Identity with Azure Key Vault |
| Region | West Europe |
| Resource Group | azl-we-rsg-azl-koogaandezaan-01 |
| Key Vault | ClusterKADZ-hcikv1 |
| Node | node01 |
| Connection Status | Connected |
Step 1: Verify Cluster Health
Before diving into the Key Vault, confirm the cluster itself is in good shape. On the cluster node:
PS C:\Users\hciadmin> Get-AzureStackHCI
ClusterStatus : Clustered
RegistrationStatus : Registered
RegistrationDate : 27-5-2026 13:30:57
AzureResourceName : ClusterKADZ
ConnectionStatus : Connected
LastConnected : 29-5-2026 03:00:03
IMDSAttestation : Enabled
DiagnosticLevel : Basic
Region : westeurope
Clustered, registered, connected. The cluster is healthy and syncing to Azure. The problem is isolated to the Key Vault integration.
Step 2: Verify the Key Vault Exists
The fault says the Key Vault does not exist. First thing to check is whether that is actually true.
PS C:\Users\hciadmin> az keyvault secret list --vault-name "ClusterKADZ-hcikv1" --query "[].name" -o table
Result
------------------------------------------------------------------
ClusterKADZ-BL-Data-xxxxxxxxxx
ClusterKADZ-BL-Data-xxxxxxxxxx
ClusterKADZ-LocalAdminCredential-xxxxxxxxxx
ClusterKADZ-TVMKey-Master-RSA-Private
ClusterKADZ-TVMKey-Master-RSA-Public
node01-RecoveryAdminPassword
Six secrets. BitLocker keys, local admin credentials, TVM keys, recovery admin password. The vault is healthy, the secrets are accessible, and everything was provisioned correctly during deployment.
So the vault exists. The fault name is misleading.
Step 3: Check the Cluster Identity
Azure Local uses a system-assigned managed identity to authenticate to Azure services. The CLI session works because you are logged in as a user. The cluster service uses its own identity.
PS C:\Users\hciadmin> az resource show --ids "/Subscriptions/2a234050-.../providers/
Microsoft.AzureStackHCI/clusters/ClusterKadz" --query "identity" -o json
{
"principalId": "c6cbeb2d-xxxx-xxxx-xxxx-e8f5261c5bcd",
"tenantId": "cd41dae2-xxxx-xxxx-xxxx-56161d080b65",
"type": "SystemAssigned"
}
The cluster has a system-assigned managed identity with principal ID c6cbeb2d-xxxx-xxxx-xxxx-e8f5261c5bcd. This is the identity the cluster uses to access Key Vault. Keep this ID in mind.
Step 4: Check Key Vault RBAC
The Key Vault uses RBAC authorization. Check who actually has access:
PS C:\Users\hciadmin> az role assignment list --scope "/subscriptions/.../providers/
Microsoft.KeyVault/vaults/ClusterKADZ-hcikv1" \
--query "[].{Principal:principalId, Role:roleDefinitionName}" -o table
Principal Role
------------------------------------ -----------------------------------
b11a9918-xxxx-xxxx-xxxx-be18f8eea738 Key Vault Data Access Administrator
b11a9918-xxxx-xxxx-xxxx-be18f8eea738 Key Vault Secrets Officer
ee90e0d3-xxxx-xxxx-xxxx-3d6a24222a7b Key Vault Secrets Officer
ee90e0d3-xxxx-xxxx-xxxx-3d6a24222a7b Key Vault Certificates Officer
Two principals have access. The first is likely the deployment service principal. The second is the Arc node identity.
The cluster identity c6cbeb2d-xxxx-xxxx-xxxx-e8f5261c5bcd is not in this list. That is the root cause.
The cluster’s managed identity has no RBAC role on the Key Vault. When the health service tries to validate Key Vault access using the cluster identity, it cannot authenticate. The health service interprets this as the Key Vault not existing.
The CLI works fine because the az session is authenticated as a different principal entirely. The cluster service does not use that session.
The Fix
Grant the cluster’s managed identity the Key Vault Secrets Officer role on the vault.
Option A: Azure Portal
1. Open the Key Vault Almere01-hcikv in the Azure portal
2. Go to Access control (IAM)
3. Click Add > Add role assignment
4. Select role: Key Vault Secrets Officer
5. Click Members > select Managed identity
6. Choose Azure Stack HCI (or Azure Local) as the managed identity type
7. Find and select Almere01
8. Click Review + assign
Option B: Azure CLI
Run this from a workstation or Cloud Shell with Owner or User Access Administrator permissions:
az role assignment create \
--assignee-object-id "c6cbeb2d-xxxx-xxxx-xxxx-e8f5261c5bcd" \
--assignee-principal-type "ServicePrincipal" \
--role "Key Vault Secrets Officer" \
--scope "/subscriptions/2a234050-.../providers/Microsoft.KeyVault/vaults/ClusterKADZ-hcikv1"
You cannot run this from the cluster node itself. The hciadmin session on the node is authenticated as the Arc machine identity, which does not have permission to write role assignments. Use the Azure Portal or a CLI session with sufficient privileges.
Force Health Re-evaluation
After applying the role assignment, the health service needs to re-check. You can wait for the next scheduled evaluation or force it manually.
Start with the most targeted approach and work your way up:
Trigger a health check
Get-StorageSubSystem Cluster* | Debug-StorageSubSystemForce a sync with Azure
Sync-AzureStackHCIRestart the Health Service
Stop-ClusterResource "Health Service"
Start-ClusterResource "Health Service"
Restart Cloud Management
Stop-ClusterGroup "Cloud Management"
Start-ClusterGroup "Cloud Management"
After each step, verify the fault is gone:
Get-StorageSubSystem Cluster* | Debug-StorageSubSystemIf this returns nothing, the fault has cleared. Retry the update.
Key Things to Know
The fault name is misleading. KeyVaultDoesNotExist does not necessarily mean the vault was deleted. It can mean the cluster identity cannot authenticate to it. The health service makes no distinction between “not found” and “access denied.”
Your CLI session is not the cluster. When you run az keyvault secret list and everything works, that proves your user identity has access. It says nothing about the cluster’s managed identity. Always verify the RBAC assignments for the cluster principal separately.
Check all three identities. A Local Identity with Key Vault deployment involves at least three principals: the deployment service principal, the Arc node identity, and the cluster’s system-assigned managed identity. All three need appropriate access. If the cluster identity is missing, the health fault fires.
Run the fix from the right context. The hciadmin session on the cluster node runs under the Arc machine identity, not your user account. Role assignments require Owner or User Access Administrator permissions. Use the Azure Portal or a workstation CLI session.
