Deploy Trusted launch for Azure Arc VMs on Azure Local, version 23H2
Applies to: Azure Local, version 23H2
This article describes how to deploy Trusted launch for Azure Arc virtual machines (VMs) on Azure Local, version 23H2.
Prerequisites
Make sure that you have access to an Azure Local, version 23H2 system 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 Local, follow the steps in the Create Arc virtual machines on Azure Local using Azure portal, with the following changes:
Example
This example shows a Trusted launch Arc VM running Windows 11 guest with BitLocker encryption enabled. Here the steps to exercise the scenario:
Create a Trusted launch Arc VM running a supported Windows 11 guest operating system.
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.
Migrate the VM to another node in the cluster. Run the following PowerShell command:
Move-ClusterVirtualMachineRole -Name $vmName -Node <destination node name> -MigrationType Shutdown
Confirm that the owner node of the VM is the specified destination node:
Get-ClusterGroup $vmName
After VM migration completes, verify if the VM is available and BitLocker is enabled.
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.
Force the VM to failover to another node in the cluster.
Confirm the owner node of the VM using this command:
Get-ClusterGroup $vmName
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.
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.
After failover completes, verify if the VM is available and BitLocker is enabled after failover.
Confirm that the owner node of the VM is the specified destination node:
Get-ClusterGroup $vmName