The registry key HKLM:\SOFTWARE\Microsoft\AzureStack\HciAttestation doesn't exist

@Robin Lee

Based on current findings, this issue is not caused by customer configuration. It is related to Azure Local (Azure Stack HCI) v24H2 VM attestation, which is required for automatic Windows Server guest activation.

Recommended actions for now:

Validate cluster and attestation health (for confirmation only):

On the Azure Local host, please verify:

1. Cluster is Registered and Connected
2. HCI Attestation status is Active
3. These checks help confirm the environment is healthy, but they will not resolve the activation issue.

Temporary workaround (if activation is urgently required):

1. Activate Windows Server VMs using KMS or a valid MAK key as a short‑term workaround.
2. Automatic activation via Azure Local will resume once the underlying attestation issue is resolved.

Deploy a virtual Azure Local system - https://learn.microsoft.com/en-us/azure/azure-local/deploy/deployment-virtual?view=azloc-2602

Hello Robin Lee,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you the registry key HKLM:\SOFTWARE\Microsoft\AzureStack\HciAttestation doesn't exist.

To permanently resolve the activation failure, first confirm the cluster is properly registered and attestation is active by running Get-AzStackHCI and Get-AzureStackHCIAttestation, then verify VM attestation status using Get-AzStackHCIVMAttestation; if any state is inactive or inconsistent, resync with Sync-AzStackHCI and re-enable attestation via Enable-AzStackHCIAttestation. Inside each Azure Edition VM, validate IMDS connectivity using Invoke-RestMethod -Headers @{Metadata="true"} -Uri http://169.254.169.254/metadata/attested/document?api-version=2018-10-01, ensure the Guest Service Interface integration service is enabled, and confirm the Guest Attestation service is running. If the registry path HKLM:\SOFTWARE\Microsoft\AzureStack\HciAttestation is missing, stop HciAttestationSvc, remove stale entries, restart the service, and reinitialize attestation to regenerate the configuration. This restores the host-to-VM attestation handshake required for Automatic VM Activation of Windows Server Azure Edition on Azure Local, as documented in Microsoft’s Azure Local attestation and activation guidance - https://learn.microsoft.com/azure/azure-local/manage/vm-attestation and Azure Stack HCI registration documentation - https://learn.microsoft.com/azure/azure-local/manage/manage-cluster-registration.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Activating a virtual machine running Windows Server 2025 Datacenter Azure Edition or Windows Server 2022 Datacenter Azure Edition on Azure Local requires the virtual machine to satisfy two criteria.

1. Product Key installation
2. Instance Metadata Service (IMDS) attestation to verify the virtual machine is running on Azure Local

If Automatic Virtual Machine Activation keys are accepted, this completes #1. To check #2, run this command from within the guest VM.

Get-CimInstance -ClassName SoftwareLicensingService | Select AzureMetadataResponse

• A successful response is 1. This confirms the VM can communicate with the host's IMDS service. If 1 is returned, this validates #2 above.
• Any other result (e.g., 4294967295, 0 or an error) indicates a failure in the Guest Service Interface transport or the certificate validation.

The most likely cause for a non-1 result is a lack of internet access to internet URLs from the guest VM to validate the host's IMDS attestation certificate.

The virtual machine will need access to the internet to validate the IMDS attestation certificate. If this is not possible due to an air-gapped or highly restricted environment, it will require manually downloading and installing all required certificates and configuring a local CRL/CTL source. See Configure trusted roots and disallowed certificates in Windows | Microsoft Learn for more information on this.

⚠️ Important: For internet connected environments you must ensure the Azure Edition VM has outbound HTTP access to all required endpoints for certificate validation.

1. Windows Certificate Trust Lists (CTLs)

• The Windows OS must contact Windows Update to download the latest lists of trusted and untrusted root certificates. If this is blocked, chain validation can fail even if the intermediate CA URLs are accessible.
• Primary Document: Certificate trust in Windows
• Required Endpoints:

  - `http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab`
  
        - `http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab`
  

2. Azure PKI & CRL/AIA URLs

• Once the root is trusted, the OS must download the intermediate certificates (via AIA) and check revocation status (via CRL/OCSP).
  • Primary Document: Azure Certificate Authority Details
  • Direct link to endpoint list: Certificate downloads and revocation lists