Azure verification for VMs

> Applies to: Azure Stack HCI, version 23H2 and later.

Microsoft Azure offers a range of differentiated workloads and capabilities that are designed to run only on Azure. Azure Stack HCI extends many of the same benefits you get from Azure, while running on the same familiar and high-performance on-premises or edge environments.

Azure verification for VMs makes it possible for supported Azure-exclusive workloads to work outside of the cloud. This feature, modeled after the IMDS attestation service in Azure, is a built-in platform attestation service that is enabled by default on Azure Stack HCI 23H2 or later. It helps to provide guarantees for these VMs to operate in other Azure environments.

For more information about the previous version of this feature on Azure Stack HCI, version 22H2 or earlier, see Azure Benefits on Azure Stack HCI.

Benefits available on Azure Stack HCI

Azure verification for VM enables you to use these benefits available only on Azure Stack HCI:

Workload What it's How to get benefits
Extended Security Update (ESUs) Get security updates at no extra cost for end-of-support SQL and Windows Server VMs on Azure Stack HCI.
For more information, see Free Extended Security Updates (ESU) on Azure Stack HCI.
You must enable Legacy OS support for older VMs running version Windows Server 2012 or earlier with Latest Servicing Stack Updates.
Azure Virtual Desktop (AVD) AVD session hosts can run only on Azure infrastructure. Activate your Windows multi-session VMs on Azure Stack HCI using Azure VM verification.
Licensing requirements for AVD still apply. See Azure Virtual Desktop pricing.
Activated automatically for VMs running version Windows 11 multi-session with 4B update released on April 9, 2024 (22H2: KB5036893, 21H2: KB5036894) or later. You must enable legacy OS support for VMs running version Windows 10 multi-session with 4B update released on April 9, 2024 KB5036892 or later.
Windows Server Datacenter: Azure Edition Azure Edition VMs can run only on Azure infrastructure. Activate your Windows Server Azure Edition VMs and use the latest Windows Server innovations and other exclusive features.
Licensing requirements still apply. See ways to license Windows Server VMs on Azure Stack HCI.
Activated automatically for VMs running Windows Server Azure Edition 2022 with 4B update released on April 9, 2024 (KB5036909) or later.
Azure Policy guest configuration Get Azure Policy guest configuration at no cost. This Arc extension enables the auditing and configuration of OS settings as code for servers and VMs. Arc agent version 1.39 or later. See Latest Arc agent release.

Note

To ensure continued functionality, update your VMs on Azure Stack HCI to the latest cumulative update by June 17, 2024. This update is essential for VMs to continue using Azure benefits. See the Azure Stack HCI blog post for more information.

Architecture

This section is optional reading, and explains more about how Azure VM verification on Azure Stack HCI works "under the hood."

Azure VM verification relies on a built-in platform attestation service on Azure Stack HCI. This service is modeled after the same IMDS Attestation service that runs in Azure, and returns an almost identical payload. The main difference is that it runs on-premises, and therefore guarantees that VMs are running on Azure Stack HCI instead of Azure.

Diagram showing Azure verification architecture.

  1. Azure VM verification is turned on by default with Azure Stack HCI running version 23H2 or later. During server startup, HciSvc generates an Integration Service over Hyper-V sockets that is, (VMBus) to facilitate secure communication between VMs and servers.

    Legacy OS support: Workloads that can't make Win32 API calls or directly query an integration service must enable Legacy OS support. This setting provides a private and nonroutable REST endpoint to VMs on the same server.

    To enable this endpoint, an internal vSwitch is configured on the Azure Stack HCI server (named AZSHCI_HOST-IMDS_DO_NOT_MODIFY). After that, VMs must have a NIC configured (AZSHCI_GUEST-IMDS_DO_NOT_MODIFY) and attached to the same vSwitch.

    Note

    Modifying or deleting this switch and NIC prevents Azure VM verification from working properly. If you encounter errors, try turning off and then turning back on legacy OS support.

  2. Whenever Azure Stack HCI syncs with Azure, HciSvc obtains a certificate from Azure, and securely stores it within an enclave on each server.

    Note

    Certificates are renewed every time the Azure Stack HCI cluster syncs with Azure, and each renewal is valid for 30 days. As long as you maintain the usual 30 day connectivity requirements for Azure Stack HCI, no user action is required to renew certificates.

  3. To activate benefits, consumer workloads request attestation from servers. They try to send requests via VM Bus, or they can also query the REST endpoint using the networking components configured in legacy OS support. Both approaches for VM-server communication are supported and can coexist on the same cluster.

    Note

    When using legacy OS support, you must manually enable access for VMs that require the activation of benefits.

    HciSvc then returns a signed response using the Azure certificate it stored. Consumers verify the response and activate associated benefits.

Manage Azure VM verification

Azure VM verification is automatically enabled by default in Azure Stack HCI 23H2 or later. The following instructions outline the prerequisites for using this feature and steps for managing benefits (optional).

Note

To enable Extended Security Updates (ESUs), you must do additional setup and turn on legacy OS support.

Host prerequisites

VM prerequisites

You can manage Azure VM verification using Windows Admin Center or PowerShell, or view its status using Azure CLI or the Azure portal. The following sections describe each option.

Check server status of Azure VM verification

  1. In Windows Admin Center, select Cluster Manager from the top drop-down menu, navigate to the cluster that you want to activate, then under Settings, select Azure verification for VMs.

  2. To check Azure VM verification server status:

    • Cluster-level status: Host status appears as On.

    • Server-level status: Under the Server tab in the dashboard, check that the status for every server shows as Active in the table.

      Screenshot showing server status.

Troubleshoot servers

  • Under the Server tab, if one or more servers appear as Expired:
    • If the server hasn't synced with Azure for more than 30 days, its status appears as Expired or Inactive. Select on Sync with Azure to schedule a manual sync.

Manage benefits activated on VMs

  1. To check what benefits are activated on VMs, navigate to the VMs tab.

  2. The dashboard shows the number of VMs with:

    • Active benefits: These VMs have Azure-exclusive features activated via Azure VM verification.
    • Inactive benefits: These VMs have Azure-exclusive features that need further action before activation.
    • Unknown: We can't determine the eligible benefits for these VMs because Hyper-V data exchange is turned off. See the following troubleshooting section.
    • No applicable benefits: These VMs don't have Azure-exclusive features and hence don't require Azure VM verification.
  3. The table displays the Eligible benefit that is applicable for each VM. See the full list of benefits available on Azure Stack HCI.

    Screenshot showing virtual machine dashboard and status.

Troubleshoot VMs

  • Under the VMs tab, if one or more VMs appear as Inactive benefits:

  • Under the VMs tab, if one or more VMs appear as Unknown:

Legacy OS support

For older VMs that lack the necessary Hyper-V functionality (Guest Service Interface) to communicate directly with the host, you must configure traditional networking components for Azure VM verification. If you have these workloads, such as Extended Security Updates (ESUs), follow the instructions in this section to set up legacy OS support.

1. Turn on legacy OS support on the host

  1. In Windows Admin Center, select Cluster Manager from the top drop-down menu, navigate to the cluster that you want to activate, then under Settings, select Azure verifications for VMs.

  2. In the section for Legacy OS support, select Change status. Select On in the context pane. This setting also enables networking access for all existing VMs. You must manually turn on legacy OS support for any new VMs that you create later.

  3. Select Change status to confirm. It might take a few minutes for servers to reflect the changes.

  4. When legacy OS support is successfully turned on:

    • Check that Legacy OS support appears as On.

    • Under the Server tab in the dashboard, check that legacy OS support for every server shows as On in the table.

      Screenshot showing dashboard with legacy OS support information.

2. Enable access for new VMs

You must enable legacy OS networking for any new VMs that you create after the first setup. To manage access for VMs, navigate to the VMs tab. Any VM that requires legacy OS support access appear as Inactive. Select the action to Set up legacy OS networking for the selected VM, or for all existing VMs on the cluster.

Screenshot showing legacy VM dashboard.

Note

To successfully enable legacy OS support on Generation 1 VMs, the VM must first be powered off to enable the NIC to be added.

FAQ

This section provides answers to some frequently asked questions about using Azure Benefits.

What Azure-exclusive workloads can I enable with Azure VM verification?

See the full list here.

Does it cost anything to enable Azure VM verification?

No. Turning on Azure VM verification incurs no extra fees.

Can I use Azure VM verification on environments other than Azure Stack HCI?

No. Azure VM verification is a feature built into the Azure Stack HCI OS, and can only be used on Azure Stack HCI.

If I just upgraded to 23H2 from 22H2, and I previously turned on the Azure Benefits feature, do I need to do anything new?

If you upgraded a cluster that previously had Azure Benefits on Azure Stack HCI set up for your workloads, you don't need to do anything when you upgrade to 23H2. When you upgrade, the feature remains enabled, and legacy OS support is turned on as well. However, if you want to use an improved way of doing VM-to-host communication through VM Bus in 23H2, make sure that you have the required host prerequisites and the VM prerequisites.

I just set up Azure VM verification on my cluster. How do I ensure that Azure VM verification stays active?

  • In most cases, there's no user action required. Azure Stack HCI automatically renews Azure VM verification when it syncs with Azure.
  • However, if the cluster disconnects for more than 30 days and Azure VM verification shows as Expired, you can manually sync using PowerShell and Windows Admin Center. For more information, see syncing Azure Stack HCI.

What happens when I deploy new VMs, or delete VMs?

  • When you deploy new VMs that require Azure VM verification, they're automatically activated if they have the correct VM prerequisites.

  • However, for legacy VMs using legacy OS support, you can manually add new VMs to access Azure VM verification using Windows Admin Center or PowerShell, using the preceding instructions.

  • You can still delete and migrate VMs as usual. The NIC AZSHCI_GUEST-IMDS_DO_NOT_MODIFY still exists on the VM after migration. To clean up the NIC before migration, you can remove VMs from Azure VM verification using Windows Admin Center or PowerShell using the preceding instructions for legacy OS support, or you can migrate first and manually delete NICs afterwards.

What happens when I add or remove servers?

  • When you add a server, it's automatically activated if it has the correct Host prerequisites.
  • If you're using legacy OS support, you might need to manually enable these servers. Run Enable-AzStackHCIAttestation [[-ComputerName] <String>] in PowerShell. You can still delete servers or remove them from the cluster as usual. The vSwitch AZSHCI_HOST-IMDS_DO_NOT_MODIFY still exists on the server after removal from the cluster. You can leave it if you're planning to add the server back to the cluster later, or you can remove it manually.

Next steps