Yes—eligible Azure Generation 1 (Gen1) virtual machines can be upgraded to Generation 2 by changing them to the Trusted Launch security type. This is a VM-generation and boot-security conversion, not a Windows or Linux operating-system upgrade. Microsoft does not support converting a Gen1 VM to Gen2 without enabling Trusted Launch. Eligibility depends on the guest OS, VM size, disk layout, enabled features, and backup or replication configuration.
The procedure requires preparation inside the guest and a planned interruption while the VM is deallocated. Microsoft Learn’s Upgrade Gen1 VMs to Trusted launch guide was last updated June 19, 2026; check its current supported OS, size, and known-issues information before scheduling a change.
What changes—and what does not
Trusted Launch is an Azure VM security type that combines Secure Boot, a virtual Trusted Platform Module (vTPM), and boot integrity monitoring to protect the boot chain. The Gen1 upgrade changes the VM’s generation and security configuration; it does not change the CPU architecture or upgrade the guest operating system.
| Operation | What it changes | Key distinction |
|---|---|---|
| Gen1 to Gen2 with Trusted Launch | VM generation and boot-security configuration | Microsoft’s supported Gen1-to-Gen2 route. Gen2 conversion without Trusted Launch is not supported, according to Microsoft Learn’s Upgrade Gen1 VMs to Trusted launch. |
| Windows Server in-place OS upgrade | Guest Windows Server version | A separate procedure. Microsoft’s Upgrade Windows Server in an Azure VM guidance covers moving to a later supported Windows Server version while retaining settings, roles, and data. It lists targets through Windows Server 2025, requires managed disks, and recommends taking snapshots before starting. |
Neither operation should be treated as a substitute for the other. If the goal is to change both the OS version and the VM’s generation/security type, plan the two changes as distinct procedures and verify that the intended sequence is supported for the particular VM.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
Check eligibility before you schedule the change
Use Microsoft’s current Trusted Launch support lists to verify the exact guest OS version and VM size family. The supported matrices and known issues can change. Also check whether the VM has features that Trusted Launch does not support and whether a custom OS image or disk is based on a Trusted Launch-capable image.
- Documented OS exclusions: Microsoft’s Gen1 procedure excludes Windows Server 2016, Debian, and Azure Linux from this upgrade path. For Windows Server 2016, the guide suggests upgrading the guest OS to Windows Server 2019 or 2022 first, subject to the separate OS-upgrade prerequisites.
- Linux image limits: The documented Gen1 Linux route is limited to supported Azure Marketplace images and excludes Debian and Azure Linux. Microsoft says Gen1 Linux VMs built from endorsed Canonical, Red Hat (RHEL), and SUSE Marketplace images already have GPT partitioning and EFI system partitions. The guide points to a registration route for other Linux Gen1 cases; that does not establish general support for those configurations.
- Custom disks and images: Confirm they meet Trusted Launch requirements rather than assuming that a VM’s current ability to boot means its disk is ready for Gen2.
- Windows OS-volume encryption: If BitLocker or equivalent encryption protects the Windows OS volume, disable that OS-volume encryption before upgrading and re-enable it after successful completion. This instruction does not apply to data disks or Linux OS volumes.
- VM size: Confirm that the current and intended size family is supported. Microsoft’s Trusted Launch overview, last updated September 25, 2026, describes restrictions on resizing to unsupported size families.
Prepare recovery, backup, and dependent services
Test the process on a representative Gen1 VM before changing a production workload. For production, create a full backup or restore point and make sure the recovery copy predates the conversion. Microsoft says a Gen1 VM cannot be returned to its original Gen1 configuration by simply changing its security type; restoring the VM and disks from a pre-upgrade backup or restore point is the recovery route.
- Azure Backup: If the VM is protected by Azure Backup, use an Enhanced policy before upgrading. Standard policy protection blocks enabling Trusted Launch.
- Azure Site Recovery (ASR): Disable ASR before the Gen1 upgrade. Re-enable and reconfigure it after the conversion.
- Service interruption: The documented portal flow requires deallocating the VM to complete the upgrade. Arrange downtime and account for services that depend on the VM before beginning.
- Windows disk planning: Microsoft recommends defragmenting the OS volume before MBR-to-GPT conversion. The Windows system volume cannot be extended after conversion, so plan any required expansion beforehand.
Prepare the boot disk for Gen2
Gen2 boot requires a GPT disk layout and an EFI system partition. A Gen1 Windows OS disk commonly uses MBR and needs conversion. Supported endorsed Linux Marketplace images identified in Microsoft’s guide already have GPT and EFI configured, but validate the actual VM rather than relying only on its operating system label.
Windows: validate and convert with MBR2GPT
- Identify the Windows OS disk and follow Microsoft’s Gen1 guide to run the built-in
MBR2GPT.exevalidation command against that disk. Use the guide’s command syntax and the correct disk identifier for the VM. - Proceed only if validation succeeds. If it fails, stop and resolve the reported issue rather than attempting conversion.
- Run the conversion command specified in Microsoft’s guide. Conversion changes the boot-mode requirement to UEFI and cannot simply be undone; ensure the pre-upgrade recovery copy is available.
Linux: verify GPT, EFI, and mount configuration
- Confirm the boot device uses GPT partitioning.
- Confirm an EFI system partition exists.
- Confirm
/boot/efiis configured.
Stop if any of these checks fail. Do not assume an unsupported Linux configuration can be made eligible simply by changing the Azure security type.
Enable Trusted Launch and verify the VM
- After the guest disk is ready, use the Azure portal, PowerShell, Azure CLI, or an ARM template to select the Trusted Launch security type and configure its security features. Follow Microsoft’s current Gen1 guide for the interface path or commands applicable to your deployment.
- Be aware of the documented defaults: vTPM is enabled by default, while Secure Boot is not. Microsoft recommends Secure Boot when the VM does not rely on custom unsigned kernels or drivers.
- In the portal flow, deallocate the VM to complete the upgrade, then start it again.
- Verify that you can connect to the guest—RDP for Windows or SSH for Linux—and check the workload before restoring dependent services such as ASR or re-enabling Windows OS-volume encryption.
What rollback means after the conversion
Disabling Trusted Launch does not put the VM back into its original Gen1 configuration. Microsoft distinguishes that from returning the VM to Gen2 Standard: disabling Trusted Launch can produce a Gen2 Standard VM, but recovering Gen1 requires restoring the complete VM and disks from a backup or restore point created before the upgrade. Confirm the recovery copy and restore plan before conversion, not after a boot problem.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
