Microsoft Rolls Out Trusted Launch for Hyper-V on Windows Server — But There’s a Critical Catch

Microsoft quietly shipped a security milestone for on-premises virtualization last week: Windows Server Insider Preview build 29621 introduces Trusted Launch virtual machines to Hyper-V — a feature that until now was largely the domain of Azure. The update adds Secure Boot, a virtual TPM, and new protections for the vTPM’s stored state, all aimed at blocking boot-time malware. But the immediate trade-off will catch many administrators off guard: Trusted Launch VMs cannot be moved between hosts, clustered, or replicated. A feature designed to lockdown virtual machines also locks them in place.

The security punch: What Trusted Launch actually delivers

Trusted Launch is not a single setting but a bundle of three hardening technologies that work together to guard the startup process of a Generation 2 VM. The first is Secure Boot, which ensures only signed, trusted code loads before the operating system takes over. The second is a virtual TPM (vTPM), giving the guest its own dedicated trust anchor for BitLocker, certificate storage, and other crypto-sensitive operations. The third and newest component in this preview is protected vTPM state — the vTPM’s secrets are now encrypted at rest so that simply copying a virtual hard disk and starting the VM on another machine does not grant access.

The combination targets bootkits and rootkits, the kind of stealth malware that executes before traditional antivirus software can load. Microsoft has been pushing Trusted Launch across its cloud platform for years, and now it is bringing the concept to Windows Server, albeit in a carefully limited early test form.

To deploy a Trusted Launch VM, you must start from the latest Windows Server Insider build, enable the Hyper-V role, and then activate the IsolatedGuestVm optional feature. The IGVmAgent service must be running. Creating the VM itself is a PowerShell-only operation — there is no Windows Admin Center support yet — and requires setting the guest-state isolation type to TrustedLaunch during provisioning.

The immediate roadblock: No VM movement, no clustering, no replicas

Here is where the practical reality clashes with the security promise. The same build notes that Trusted Launch VMs are totally stationary. Microsoft’s official announcement lists these hard limitations:

• Trusted Launch VMs cannot be moved to another server via live migration or any server-to-server move.
• Failover Clustering is not supported.
• Hyper-V Replica cannot replicate these VMs.
• Boot integrity verification (a monitoring feature in Azure) is absent.
• There is no Windows Admin Center support; everything is PowerShell-driven.

An early report by Neowin on July 15 initially suggested that clustered Trusted Launch VMs could carry their vTPM state during live migration or failover. That turned out to be incorrect. Microsoft’s own release post explicitly contradicts it, and sources familiar with the matter confirm that mobility features are not part of this preview. For now, a Trusted Launch VM is a static entity on a single host.

For many enterprise environments, this is a non-starter for production workloads. High availability and live migration are table stakes in virtualized data centers. The preview is essentially a lab tool, and Microsoft makes that clear by branding the entire build as an Insider preview for the next Windows Server Long-Term Servicing Channel (LTSC) release. Even the build itself still displays “Windows Server 2025” in parts of the interface, underscoring its pre-release nature.

How we got here: From Azure innovation to on-premises preview

Trusted Launch first appeared in Azure in 2021 as a security option for Generation 2 VMs. Over the following years, it gained features like integrity monitoring, guest attestation, and policy-based enforcement. The technology proved effective enough that organizations began asking for on-premises equivalents to standardize their security posture across hybrid environments.

Microsoft’s response has been methodical. The Windows Server Insider program, launched in early 2025, gave admins an early channel for testing future LTSC features. Build 29621, released in July 2026, marks the first time Trusted Launch has landed in a Hyper-V context outside Azure. The roadmap is clearly incremental. Previous builds laid the groundwork with Isolated Guest VM infrastructure; build 29621 wires up the security layers but keeps mobility — and much of the tooling — on a future to-do list.

For managers looking at compliance requirements, this is a promising direction. Hardware-based security features like TPMs and Secure Boot have been mandatory in many regulatory frameworks for physical servers. Extending equivalent protections to VMs is a logical and overdue step. But the path from preview to production-grade feature usually takes multiple build cycles, and Trusted Launch on Windows Server is definitely in the earliest stage.

What to do now: A practical checklist for early testers

If you want to kick the tires on Trusted Launch today, here’s how to set up a functional test environment:

1. Install or upgrade to build 29621 (or later). Microsoft recommends using build 29531 or newer as your baseline; you cannot upgrade from older Insider builds.
2. Install the Hyper-V role if it’s not already present.
3. Enable the IsolatedGuestVm optional feature via PowerShell or DISM.
4. Ensure the IGVmAgent service is running on the host.
5. Create a new Generation 2 VM using PowerShell. Set the GuestStateIsolationType to TrustedLaunch. There is no checkbox in Hyper-V Manager or Windows Admin Center for this yet.

Enable-WindowsOptionalFeature -Online -FeatureName IsolatedGuestVm

Restart if prompted

1. Install the guest OS from a trusted image (Windows Server 2025 or later; Linux support is not yet detailed in this preview).

Once the VM is running, verify the vTPM is active inside the guest (check tpm.msc on Windows or dmesg | grep -i tpm on Linux). Because boot integrity verification isn’t available, you won’t see attestation reports like in Azure. But you can confirm that Secure Boot and vTPM are operational.

Do not attempt the following, because the feature does not support them:

• Adding the VM to a Failover Cluster or placing it on Cluster Shared Volumes.
  
• Configuring Hyper-V Replica.
  
• Moving the VM using live migration or storage migration.
  
• Backing up the VM with tools that rely on Hyper-V’s migration APIs (check with your backup vendor; most will need updates).

Treat the VM as disposable. It’s meant for exploring the security model, running validation scripts, and giving feedback to Microsoft via the Windows Server Insider hub.

Outlook: When will Trusted Launch be ready for the data center?

Microsoft hasn’t published a timeline for filling the feature gaps, but history offers clues. Hyper-V features that debut in Insider builds typically take six to twelve months to reach full maturity, and often align with a new LTSC release. The next Windows Server LTSC is widely expected to land in late 2026 or early 2027, and that milestone is the most likely target for a production-ready Trusted Launch with live migration, clustering, and replica support.

Between now and then, expect a stream of incremental previews. The immediate next step is likely boot integrity monitoring — a feature already available in Azure — which would let hosts verify that a VM’s boot chain hasn’t been tampered with. Mobility features are more complex because they require securely transferring vTPM state between hosts, a non-trivial cryptographic problem. Failover clustering adds another layer of coordination.

For now, the message is cautiously optimistic. Trusted Launch on Windows Server is real, functional, and a clear signal that Microsoft is bringing cloud-grade VM security to its on-premises platform. But it’s not yet a replacement for existing security configurations, and no reasonable administrator would deploy it in a production environment that depends on VM mobility. If you manage a lab or a dev/test fabric, dive in and start learning. For everyone else, watch the Insider builds — and keep the live migration queues humming for a while longer.