Azure Generation 2 (Gen2) VM is based on UEFI-based boot architecture which enables key scenarios including Trusted Launch (TLVM). Gen2 TLVM provides customers with secure compute solutions with security capabilities like:
| Feature Name | Description |
|---|---|
| Secure Boot | Protects OS against rootkits and boot kits. |
| vTPM | It serves as a dedicated secure vault for keys and measurements, enabling attestation by measuring the entire boot chain of your VM |
| Guest VM Attestation | Guest attestation extension enables proactive attestation and monitoring the boot integrity of your VMs. |
Newer OS like Windows Server 2022 Azure Edition require UEFI, Windows 11 requires UEFI & vTPM as pre-requisite for installation. Additionally, for enabling Azure Compute security benchmark (like Secure Boot), UEFI support in OS is mandatory.
You can now upgrade existing Gen1 (BIOS) VMs to Trusted launch by on-boarding to preview at https://aka.ms/Gen1ToTLUpgrade. This repository provides end users with PowerShell script-based guidance which they can self-execute & upgrade existing Gen1 (BIOS) VMs to Gen2 (UEFI) VMs.
NOTE: Please review the list of Known issues before executing validation.
IMPORTANT DISCLAIMER
Production use: The Preview should only be used for testing, evaluation and feedback. Production workloads are not recommended.
Preview features are not backed with Microsoft Support SLA.
| Pre-Requisite | Description |
|---|---|
| On-board subscription for preview | Register for Gen1 to Trusted launch upgrade preview at https://aka.ms/Gen1ToTLUpgrade. |
| Az PowerShell Module | Required cmdlets for Azure Platform. |
| VM Contributor rights on Gen1 VM resource group. | Required RBAC permissions to modify and re-deploy Gen1 VM. |
| VM is in allocated / Running state. | Required to read current state and configuration of Gen1 VM and execute MBR to GPT conversion. |
| Operating System | Operating system should be Trusted launch supported. except
|
| Azure IaaS VM Agent | Azure IaaS Windows VM Agent OR Azure IaaS Linux VM Agent should be installed and healthy. |
| Disk Encryption | If enabled, Disable any OS disk encryption including Bitlocker, CRYPT, Server side encryption with customer managed keys prior to upgrade. All disk encryptions should be re-enabled post successful upgrade. |
| VM Backup | Azure Backup if enabled for VM(s) should be configured with Enhanced Backup Policy. Trusted launch security type cannot be enabled for Generation 2 VM(s) configured with Standard Policy backup protection. Existing Azure VM backup can be migrated from Standard to Enhanced policy using preview migration feature. |
| VM Disaster Recovery | Trusted launch VMs currently do not support Azure Site Recovery (ASR). If enabled, ASR should be disabled prior to upgrade. |
| Best Practice | Description |
|---|---|
| Validate in lower environment | Enable Trusted launch on a test Generation 2 VM and ensure if any changes are required to meet the prerequisites before enabling Trusted launch on Generation 2 VMs associated with production workloads. |
| Backup Gen1 VM | Create restore point for Azure Generation 1 VM(s) associated with workloads before enabling Trusted launch security type. You can use the Restore Point to re-create the disks and Generation 1 VM with the previous well-known state. |
| OS Disk free space | You will not be able to extend OS disk system volume after MBR to GPT conversion. Recommendation is to extend system volume for future before executing Gen2-Trusted launch upgrade. |
| Id | Step | Description |
|---|---|---|
| 1 | Validate Pre-Requisites | Validate pre-requisites for executing script:
|
| 2 | Connect Azure Subscription and read Gen1 VM Configuration | Store Gen1 VM Configuration required for conversion:
|
| 3 | Validate VM SKU Trusted launch Support | Validate if current VM Size assigned to Gen1 VM supports Trusted launch. If not, VM Size for Gen1 VM will need to be updated with Trusted launch support. For steps of changing VM Size, please refer to Change the size of a Virtual Machine. |
| 4 | Execute MBR to GPT conversion | Script will execute online MBR to GPT conversion of OS disk boot partition. Note: For Linux VMs following assumptions are made:
|
| 5 | De-allocate and upgrade VM properties | Script will update the VM attributes from Gen1 to Gen2 and security type to Trusted launch. |
| 6 | Start VM | Post successful upgrade, VM will be started. |
| Parameter Name | Description | Mandatory |
|---|---|---|
| subscriptionId | Subscription ID for Gen1 VM to be upgraded. | True |
| tenantDomain | Primary AAD Domain Name for authentication. (For example, contoso.onmicrosoft.com) | True |
| csvLocation | Local file path location of csv containing vmName, vmResourceGroupName, enableSecureBoot details. | True |
| Csv column Name | Description | Mandatory |
|---|---|---|
| vmName | Resource Name of Gen1 VM to be upgraded. | True |
| vmResourceGroupName | Resource Group for Gen1 VM to be upgraded. | True |
| enableSecureBoot | If target Trusted Launch VM should be deployed with Secure Boot enabled (TRUE) or disabled (FALSE). By default set to TRUE. This option should be disabled if VM is hosting custom or unsigned boot drivers which cannot be attested. |
False |
Example
.\Upgrade-Gen1ToTL.ps1 -subscriptionId $subscriptionId -tenantDomain contoso.onmicrosoft.com -csvLocation "C:\Temp\sampleCsv.csv"
# Upgrade all VMs provided in csv from Gen1 to Trusted launch with specific parameter values.
After successful conversion of Gen1 to Trusted Launch VM, user needs to perform required steps for applicable scenarios from below list:
- Validate health of Virtual Machine OS and workload hosted on converted Gen2 TLVM.
- Re-enable all disk encryptions on Trusted launch virtual machine post successful upgrade.
- Re-enable backup with Enhanced Policy post successful upgrade to Trusted launch virtual machine.
Execute these steps on Linux Gen1 VM to complete MBR to GPT conversion before executing Gen1 -> Trusted Launch upgrade script.
Note: Non-Azure steps are applicable for Non-Azure Linux VMs only, i.e., Linux VMs created outside Azure cloud. These do not apply if the Linux VM has been created in Azure Cloud.
| Id | Step | Description |
|---|---|---|
| 1 | Query the OS Disk using below commandlsblk -o NAME,HCTL,SIZE,MOUNTPOINT | grep -i "sd" |
Identify the boot partition and associated disk |
| 2 | Backup MBR partition:dd if=/dev/sda of=backup.mbr bs=512 count=1 |
Backup should be taken on drive other than Boot drive. |
| 3 | Non-Azure Install EFI Package:
|
  |
| 4 | Execute gdisk command gdisk /dev/sdato create new partition with following values:
|
 |
| 5 | Update partition table changes:partprobe /dev/sda |
|
| 6 | Install Bootloader in re-partitioned boot disk:
|
 |
| 7 | Non-Azure Execute gdisk to add an EFI System partition (ESP) with partition type ef00. Recommended size is +200M Command: gdisk /dev/sda
|
 |
| 8 | Non-Azure Execute gdisk to rename above created partition to EFI-systemCommand: gdisk /dev/sda
|
 |
| 9 | Non-Azure Build vfat filesystem for ESP.mkfs -t vfat -v /dev/disk/by-partlabel/EFI-system |
 |
| 10 | Non-Azure If does not exists already; create ESP Mountpointmkdir /boot/efi |
|
| 11 | Copy existing files in /boot/efi to temporary /mnt/folder.
|
|
| 12 | Non-Azure Add the ESP mountpoint to /etc/fstab. (replace spaces with tab key)/dev/disk/by-partlabel/EFI-system /boot/efi vfat defaults 0 2 |
 |
| 13 | Non-Azure Mount ESPmount /boot/efi |
|
| 14 | Non-Azure Install the GRUB EFI bootloader. Ubuntu/Debian: grub-install --target=x86_64-efi /dev/sdaRHEL: grub2-install --target=x86_64-efi /dev/sda |
  |
Share following log files available at %windir% with feature team to troubleshoot failures related to MBR2GPT execution for Windows VMs:
- setupact.log
- setuperr.log
Windows 10 Gen1 VM is successfully upgraded to Trusted launch followed by successful Windows 11 in-place upgrade. However, the Windows 11 boot fails after Azure VM is stopped and started with below error.
Workaround for the issue currently is to refresh the Windows 11 OS disk. For more details, Refresh Windows 11 OS disk Team is actively troubleshooting this issue.
Gen1 to Trusted launch upgrade script has been validated with Ubuntu 20.04 LTS distro. For other distros, mandatorily validate the upgrade in lower environment before running in production.
This error occurs for one of following reason:
- There is no free space available on the system volume
- System volume is corrupted. You can validate by trying to Shrink Volume by few MBs under Disk Management console. Use command
chkdsk C:/v/fto repair system volume. Virtual Disk Serviceis not running or unable to communicate successfully.- System volume disk is already configured with 4 MBR partitions (maximum supported by MBR disk layout). You need to delete one of the partition to make room for EFI system partition.
- Run
ReAgentc /infoto identify partition actively used by Recovery. Example:Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE - Run PowerShell cmdlet
Get-Partition -DiskNumber 0to identify current partitions configured. - Run PowerShell cmdlet
Remove-Partition -DiskNumber 0 -PartitionNumber Xto remove any extra Recovery partition not actively used by Recovery service as identified in Step 1.
- Run
Temporary storage Drive letter assignment 'D' is changed to 'E' with previous letter assigned to System Reserved post-upgrade. The issue is being troubleshooted. execute below steps manually post-upgrade to workaround the issue:
After the upgrade check the disks on the server, if system reserved partition has the letter D:, do the following actions:
- reconfigure pagefile from D: to C:
- reboot the server
- remove letter D: from the partition
- reboot the server to show the temporary storage disk with D: letter
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent