Microsoft has shipped the first preview of Trusted Launch virtual machines for on-premises Hyper-V, delivering Azure-style boot security to Windows Server — but with sharp restrictions that keep it firmly in the lab for now. Windows Server vNext Insider Preview Build 29621, released in late March 2026, introduces the capability for newly created Generation 2 VMs, combining Secure Boot, virtual TPM (vTPM), and encryption of the vTPM state. However, the feature lacks support for live migration, failover clustering, Hyper-V Replica, boot-integrity verification, and Windows Admin Center management, leaving it unsuitable for production workloads that depend on high availability or mobility.

That verdict is not cautionary speculation; it comes directly from Microsoft’s own documentation for the build. Administrators are told to pilot the feature only on standalone Generation 2 VMs, using PowerShell, and to treat the VMs as host-bound. A new host service, IGVmAgent, becomes a hard dependency: if the agent stops, any VM with protected guest state won’t start. The message is clear — learn the technology now, but don’t place it under your business-critical services.

What Build 29621 actually delivers

The Trusted Launch VM in Build 29621 is not just a renamed Secure Boot setting. It brings together three security pillars that have long been standard in Azure’s Generation 2 VMs: Secure Boot (to ensure the VM boots from an approved path), a vTPM (to store secrets like BitLocker keys or credentials inside the guest), and at-rest protection for the vTPM state itself. That last piece is significant: it means an attacker with temporary access to the Hyper-V host’s storage cannot simply copy the vTPM data and use it elsewhere. The protection is applied to newly created Generation 2 VMs only; existing VMs cannot be converted, and Generation 1 VMs are out of scope.

Enabling Trusted Launch requires a few explicit steps: install the preview build on an isolated Hyper-V host, enable the IsolatedGuestVm optional feature, confirm the IGVmAgent service is running, and then create a new Generation 2 VM through a PowerShell workflow that toggles Secure Boot and vTPM. Microsoft has not yet released a graphical interface for this in Windows Admin Center or Hyper-V Manager, so the preview is a pure PowerShell experience.

What it means for you

For Hyper-V admins and IT pros

The preview is a deliberate sandbox. You can validate guest OS compatibility, test backup and recovery behavior, and build operational runbooks around the new IGVmAgent dependency. However, you must accept that the resulting VM cannot be moved, replicated, or clustered. If the host needs maintenance, you cannot live-migrate the VM; if the host fails, there is no Replica-based recovery design; if you need high availability, clustering is not an option. A Trusted Launch VM in this build is host-bound, requiring a planned outage window for any host-level change.

The IGVmAgent service dependency is an early warning system. Microsoft explicitly states that a VM with protected guest state will not start if IGVmAgent is stopped. That means you must incorporate service health monitoring into your operational checklist — something many Hyper-V environments overlook. A simple host reboot or patching cycle could accidentally disable the service, rendering the VM unbootable until the service is restored. The pilot should include deliberate tests: stop the service, confirm the VM won’t start, restart the service, and verify recovery.

For security architects

Trusted Launch is not a replacement for Shielded VMs and the Host Guardian Service (HGS). Shielded VMs are designed for a guarded fabric where the host’s trustworthiness is attested by HGS, protecting VMs from potentially compromised host administrators. Trusted Launch, on the other hand, focuses on the VM’s own boot integrity and TPM secrecy, without requiring a guarded fabric. It’s a simpler, more Azure-aligned security posture that fits organizations not ready to deploy HGS. The two technologies have different trust boundaries; mixing them up could lead to false assumptions about what is being protected.

For developers and lab managers

If you have disposable workloads — test beds, development environments, or sandboxed applications — you can start experimenting with Trusted Launch immediately. A lab environment is ideal for building familiarity, testing guest OS support (Windows Server 2022 and later, plus selected Linux distributions that support Secure Boot and vTPM), and documenting PowerShell scripts. Just remember: the VM won’t move, and it won’t survive a host failure gracefully, so keep it isolated.

How we got here

Microsoft’s Azure platform has offered Trusted Launch as the default security posture for new Generation 2 VMs since 2021. It became a natural next step to bring that consistency to Windows Server, especially as hybrid cloud strategies blur the line between on-premises and cloud-hosted infrastructure. The Windows Server Insider program has teased next-generation security features for months, and Build 29621 is the first tangible deliverable. It follows a pattern Microsoft has used before: release core, low-level capabilities early via PowerShell, gather feedback from admins willing to run preview builds, and later integrate management-plane support (like Windows Admin Center) once the feature set stabilizes.

For context, the original source that accompanied this announcement is a Microsoft Learn article about System Guard Secure Launch — a different, older technology that caused boot failures in Windows Server 2019 VMs due to missing hardware prerequisites. Microsoft supplied that article as a troubleshooting reference, but it has nothing to do with the Trusted Launch VM feature. Admins should keep the two technologies distinct: System Guard Secure Launch is a host-level boot integrity technology that never worked properly in Hyper-V guests, while Trusted Launch is a guest-level VM security posture. The confusing naming overlap has already caused some head-scratching, so your documentation should explicitly call out the difference.

What to do now

  1. Set up an isolated test host. Use a nonproduction Hyper-V server running Build 29621 (Insider Preview). Do not mix this host with your existing cluster or live workloads.
  2. Install the prerequisite feature. Run Enable-WindowsOptionalFeature -Online -FeatureName IsolatedGuestVm and reboot. Confirm the IGVmAgent service starts automatically.
  3. Create a test Generation 2 VM via PowerShell. Use the documented Trusted Launch workflow to enable Secure Boot and vTPM. Do not attempt to convert an existing VM.
  4. Test lifecycle operations. Start, stop, restart, apply guest patches, reboot the host, check backup and restore, and deliberately stop IGVmAgent to see how the VM behaves. Record the results.
  5. Monitor the service dependency. Set up a script or monitoring tool that alerts you if IGVmAgent stops unexpectedly. Document the recovery procedure: restart the service and then the VM.
  6. Do not attempt mobility. Live migration, storage migration, failover clusters, and Hyper-V Replica are explicitly unsupported for Trusted Launch VMs in this build. If you need to move the workload, you’ll have to rebuild it as a conventional VM.
  7. Stay informed. Bookmark the official Windows Server Insider announcements and the known-issues list. Microsoft has signaled that future previews will add boot-integrity verification and Windows Admin Center support, but no date has been given.

Outlook

The next logical milestones are clear: Microsoft must deliver VM mobility support (at least live migration and clustering), boot-integrity verification so you can attest that the VM booted securely, and a graphical management experience through Windows Admin Center. Without those, Trusted Launch remains a security island — valuable for standalone, stateless VMs but incompatible with the operational requirements of most enterprise Hyper-V estates.

For now, the playbook is straightforward: run the pilot, collect evidence, feed back to Microsoft, and prepare your runbooks. The direction is promising, but the feature is not ready for the data center floor. Admins who invest the time now will be ahead when the production-ready milestone arrives.