Azure Edition VM on Azure Local migrated via Azure Migrate: "Activate Windows by enabling Azure benefits" although AVMA shows Licensed (AzureMetadataResponse = 4294967295, LicenseImdsIntegration fails with 0x800B0004)

Gary 5 Reputation points
2026-11-11T10:39:12.7+00:00

Environment

  • Azure Local, 2 nodes, version/build: 12.2609.1003.7 OS Build 26100
  • Guest: Windows Server 2025 Datacenter: Azure Edition, build 26100, Generation 2, Secure Boot on, no vTPM
  • VM was migrated with Azure Migrate. Before that it ran on a different Azure Local cluster on the same hardware (the cluster was rebuilt).
  • Azure Hybrid Benefit: Activated on the cluster

Problem

After sign-in the VM shows "Activate Windows by enabling Azure benefits" (your VM has been deactivated because you are not running on Azure or a supported Azure Stack hypervisor...). Settings > System > Activation shows "Not active".

What works / what the host side shows

  • slmgr /dlv: License Status Licensed, channel VIRTUAL_MACHINE_ACTIVATION, automatic VM activation is renewed (seen from both nodes).
  • Get-AzStackHCIVMAttestation: VM status Connected, SupportedVersions {V2}.
  • WAC / portal: VM shows Active, no recommended action.
  • Guest Service Interface is enabled.

Comparison with a new VM

I created a new Azure Edition VM through the portal on the same cluster. Hyper-V configuration is identical (config version 12.0, Gen 2, same Secure Boot template, one NIC on the same converged switch, no vTPM). Both VMs are domain-joined. The new VM shows no message and Settings says Active.

Differences found in the guest

  • Get-CimInstance -ClassName SoftwareLicensingService | Select AzureMetadataResponse new VM: 1, affected VM: 4294967295
  • Scheduled task \Microsoft\Windows\Clip\LicenseImdsIntegration new VM: LastTaskResult 0, affected VM: 2148204548 (0x800B0004), runs about 30 seconds, reproducible when started manually
  • The CAPI2 log shows fclip.exe building the certificate chain for metadata.azurestackhci.azure.com successfully on the affected VM (Result 0, chain up to DigiCert Global Root G2). The task still fails afterwards.

What I already checked (same result on both VMs)

  • ctldl.windowsupdate.com reachable (authrootstl.cab, disallowedcertstl.cab), DisableRootAutoUpdate policy not set
  • CRL/OCSP endpoints (crl3/crl4/ocsp.digicert.com, crl.microsoft.com, oneocsp.microsoft.com) reachable on port 80
  • no proxy
  • metadata.azurestackhci.azure.com does not resolve in DNS on either VM, 169.254.169.254 attested document request times out on both. So this does not seem to be the path used.
  • Enabling a vTPM did not help, and it broke live migration (certificates for the local key protector missing on the other node), so I reverted it.
  • The host side Get-AzStackHCIAttestation initially showed Error on both nodes. Enable-AzStackHCIAttestation -AddVM failed with "Access is denied" when opening a PSSession to localhost (WinRM). I enabled Azure benefits through WAC afterwards. This is still unresolved on the nodes, but the new VM works.

Questions

  1. What does LicenseImdsIntegration / fclip.exe validate after building the chain, and what does 0x800B0004 mean in this context?
  2. Is there a supported way to reset or re-register the guest-side attestation state of a migrated VM (without rebuilding it)?
  3. Could leftovers from the previous cluster (Arc agent registration, guest agent configuration) cause this?
  4. Is an in-place repair supported for Azure Edition on Azure Local, and with which media?

Happy to provide additional logs.

Best Regards

Gary

Azure Arc
Azure Arc

A Microsoft cloud service that enables deployment of Azure services across hybrid and multicloud environments.

0 comments

1 answer

Sort by: Oldest
Most helpful Newest Oldest
  1. Vasileios Dionysopoulos 821 Reputation points
    2026-11-12T15:40:22.51+00:00

    Hi Gary,

    Before going deeper into the guest, I'd fix the one thing that's still unresolved on your side: host attestation is in Error on both nodes, and Enable-AzStackHCIAttestation -AddVM never completed. Your new VM was created through the portal and registered automatically. The migrated VM came in through Azure Migrate, so it never went through that registration. The guest then gets an attestation response it cant trust.

    What 0x800B0004 means here: TRUST_E_SUBJECT_NOT_TRUSTED. The certificate chain builds fine and your CAPI2 log shows that, but the signed attestation content isn't trusted for this VM. That points to a stale or missing host-side binding, not to PKI, DNS or proxy.

    Step 1 – Fix host attestation (on each node)

    Sign in directly on the node (RDP/console, not through WAC) with a domain account that's a local administrator, and open an elevated PowerShell:

    Enable-PSRemoting -Force
Test-WSMan localhost                 # must return a response, not "Access is denied"

Enable-AzStackHCIAttestation -AddVM
Get-AzStackHCIAttestation

    Expected: Get-AzStackHCIAttestation shows Connected for the node. Repeat on the second node. If Test-WSMan still fails, fix WinRM first, because the attestation cmdlet depends on it.

    Step 2 – Re-register only the affected VM (on the node that owns it)

    $vm = "<vm-name>"

Get-VMIntegrationService -VMName $vm -Name "Guest Service Interface"   # Enabled = True

Get-AzStackHCIVMAttestation   | Where-Object VMName -eq $vm             # before
Remove-AzStackHCIVMAttestation -VMName $vm
Add-AzStackHCIVMAttestation    -VMName $vm
Get-AzStackHCIVMAttestation   | Where-Object VMName -eq $vm             # after: Connected

    Step 3 – Verify in the guest

    $tp = "\Microsoft\Windows\Clip\"; $tn = "LicenseImdsIntegration"
Start-ScheduledTask -TaskPath $tp -TaskName $tn
Start-Sleep 60
Get-ScheduledTaskInfo -TaskPath $tp -TaskName $tn | Select-Object LastRunTime, LastTaskResult
(Get-CimInstance SoftwareLicensingService).AzureMetadataResponse
    Check Affected VM today Expected after fix (as on your new VM)
    LastTaskResult 2148204548 (0x800B0004) 0
    AzureMetadataResponse 4294967295 1
    Settings → Activation Not active Active (after sign-out/sign-in)

    If it's still failing: compare the guest with the new VM

    & "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" show

    If the migrated VM still has an Arc agent registered from the old cluster and the new VM doesn't, thats a concrete leftover difference . I'd only look into removing it after steps 1–3, and with the output of both VMs side by side.

    I don't know whether an in-place repair is supported for Azure Edition on Azure Local, or which media it would use.

    Was this answer helpful?

    0 comments

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.