Deploy Trusted launch for Azure Arc VMs on Azure Stack HCI, version 23H2

Applies to: Azure Stack HCI, version 23H2

This article describes how to deploy Trusted launch for Azure Arc virtual machines (VMs) on Azure Stack HCI, version 23H2.

Prerequisites

Make sure that you have access to an Azure Stack HCI, version 23H2 cluster that is deployed and registered with Azure. For more information, see deploy using the Azure portal.

Create a Trusted launch Arc VM

You can create a Trusted launch VM using Azure portal or by using Azure Command-Line Interface (CLI). Use the tabs below to select a method.

To create a Trusted launch Arc VM on Azure Stack HCI, follow the steps in the Create Arc virtual machines on Azure Stack HCI using Azure portal, with the following changes:

  1. While creating the VM, select Trusted launch virtual machines for security type.

    Screenshot showing Trusted launch type selection.

  2. Select a VM guest OS image from the list of supported images:

    Screenshot showing supported guest image selection.

  3. Once a VM is created, go to the VM properties page and verify the security type shown is Trusted launch.

    Screenshot showing properties page.

Example

This example shows a Trusted launch Arc VM running Windows 11 guest with BitLocker encryption enabled. Here the steps to exercise the scenario:

  1. Create a Trusted launch Arc VM running a supported Windows 11 guest operating system.

  2. Enable BitLocker encryption for the OS volume on the Win 11 guest.

    Sign in to the Windows 11 guest and enable BitLocker encryption (for the OS volume): In the search box on the task bar, type Manage BitLocker, and then select it from the list of results. Select Turn on BitLocker and then follow the instructions to encrypt the OS volume (C:). BitLocker will use vTPM as a key protector for the OS volume.

  3. Migrate the VM to another node in the cluster. Run the following PowerShell command:

    Move-ClusterVirtualMachineRole -Name $vmName -Node <destination node name> -MigrationType Shutdown
    
  4. Confirm that the owner node of the VM is the specified destination node:

    Get-ClusterGroup $vmName
    
  5. After VM migration completes, verify if the VM is available and BitLocker is enabled.

  6. Verify if you can log in to the Windows 11 guest in the VM, and if BitLocker encryption for the OS volume remains enabled. If you can do this, this confirms that the vTPM state was preserved during VM migration.

    If vTPM state was not preserved during VM migration, VM startup would have resulted in BitLocker recovery during guest boot up. That is, you would have been prompted for the BitLocker recovery password when you attempted to log in to the Windows 11 guest. This was because the boot measurements (stored in the vTPM) of the migrated VM on the destination node were different from that of the original VM.

  7. Force the VM to failover to another node in the cluster.

    1. Confirm the owner node of the VM using this command:

      Get-ClusterGroup $vmName
      
    2. Use Failover Cluster Manager to stop the cluster service on the owner node as follows: Select the owner node as displayed in Failover Cluster Manager.  On the Actions right pane, select More Actions and then select Stop Cluster Service.

    3. Stopping the cluster service on the owner node will cause the VM to be automatically migrated to another available node in the cluster. Restart the cluster service afterwards.

  8. After failover completes, verify if the VM is available and BitLocker is enabled after failover.

  9. Confirm that the owner node of the VM is the specified destination node:

    Get-ClusterGroup $vmName
    

Next steps