Microsoft has released Windows Server vNext Insider Preview build 29621, packing early implementations of Trusted Launch for Hyper-V virtual machines, Quick Machine Recovery, NVMe over Fabrics, and ReFS boot. But the build, available to Insiders on July 15, comes with a blunt warning: these features are for lab testing only, loaded with restrictions that keep them firmly out of production.

A closer look at build 29621’s feature set

Microsoft shipped the latest Server vNext Insider Preview (build 29621) to registered Insiders in Datacenter, Standard, and Azure Edition flavors—both Desktop Experience and Server Core options. Despite the Server 2025 branding it still carries, the company wants feedback flagged as “vNext Preview.” The build is packed with four significant additions, each targeting a different corner of the data center: virtual machine security, automatic recovery, remote storage fabrics, and the return of ReFS as a bootable file system.

Trusted Launch for Hyper-V VMs: Secure Boot, vTPM, and chains you can’t break

The headliner is Trusted Launch for Generation 2 Hyper-V virtual machines. Think of it as bringing the hardware-rooted security Azure offers to your on‑premises testbed. The preview enables Secure Boot, a virtual TPM (vTPM), and—crucially—encryption of the vTPM state when the VM is at rest. That means secrets stored in the vTPM aren’t left in the clear on disk, a small but meaningful step toward protecting workloads from physical compromise.

Configuring it requires PowerShell; there’s no GUI wizard yet. And the restrictions are severe. A Trusted Launch VM cannot live-migrate, cannot join a failover cluster, can’t use Hyper‑V Replica, can’t benefit from boot‑integrity verification, and can’t be managed through Windows Admin Center. In other words, any VM you provision this way is tethered to a single host and invisible to your management stack. That’s by design: Microsoft is testing the core plumbing before tackling high‑availability scenarios. For now, it’s a fascinating sandbox feature—just don’t schedule any production deployments.

Quick Machine Recovery: a self‑healing safety net (eventually)

Quick Machine Recovery (QMR) is an idea that sounds almost too good to be true: when a server hits a boot‑critical failure, it would automatically pull remediation instructions from Microsoft’s cloud through Windows Recovery Environment and apply them. No USB key, no on‑site hands. In this build, QMR is live in test mode, meaning it’s active but Microsoft hasn’t yet provided the Group Policy controls that would let you enable or disable it in a controlled way. Those are promised for a future preview. Until then, you can watch it work on a spare box, but you can’t rely on it as your recovery mechanism.

NVMe over Fabrics: the fast lane to remote storage

Storage teams get a new toy: an NVMe‑over‑Fabrics initiator. Windows Server can now reach remote NVMe drives over standard Ethernet using NVMe/TCP, or over RDMA‑enabled networks with NVMe/RDMA (RoCE or iWARP). The latter is aimed squarely at low‑latency, high‑throughput workloads—think massive databases or real‑time analytics. But before you rip out your Fibre Channel adapters, remember that this is a preview driver. Hardware compatibility, performance tuning, and integration with clustering will need thorough validation.

ReFS Boot: a resilient file system at last, with a recovery partition trap

The Resilient File System (ReFS) has been a Windows Server feature for years, but booting from it was the missing piece—until now. Build 29621 lets you install Server vNext onto an ReFS volume and boot from it natively. The payoff is ReFS’s built‑in integrity checking and self‑healing metadata, which can reduce corruption scares.

But the process makes a particular demand on your disk layout: you need a dedicated Windows Recovery Environment (WinRE) partition of at least 2 GB. If Windows Update later finds that the partition is too small to stage a WinRE update, it may silently disable recovery tools without removing the partition—leaving a dead weight. More dangerously, if you delete that partition to reclaim space and then extend the boot volume, you cannot undo that decision without a clean install. So tread lightly, and always test your disaster‑recovery scenarios.

Who should care (and why you’ll have to wait)

The practical value of build 29621 differs sharply depending on your role.

Virtualization admins will want to kick the tires on Trusted Launch. You can script a new VM with a virtual TPM and confirm that its state is encrypted, but you’ll quickly hit the mobility wall. If you manage a Hyper‑V cluster today, this feature is irrelevant until Microsoft solves live migration. Think of it as a proof‑of‑concept you can show management: “Here’s what’s coming, and here’s what we need to prepare.”

Storage architects get an early look at NVMe over Fabrics. If you’ve been itching to collapse storage networks onto Ethernet, NVMe/TCP is the protocol you’ll want to test. Just be prepared for rough edges: the initiator is still in preview, and performance numbers from a lab won’t translate directly to your 100‑node cluster.

Operations teams responsible for keeping servers running should pay attention to Quick Machine Recovery—but don’t bank on it yet. The automatic recovery flow works in test mode, but without Group Policy controls, you can’t enforce it across a fleet. Worse, if you’re running an air‑gapped environment, QMR’s cloud dependency means it might not help at all. Microsoft hasn’t clarified on‑premises remediation servers or offline modes.

Cautious administrators eyeing ReFS boot for its self-healing properties need to memorize the recovery partition rule. Losing WinRE might not matter until the day a patch renders a server unbootable, and then you’ll wish you hadn’t gambled with the partition layout. Document the partition size requirement and test your backup‑restore procedures before rolling out ReFS boot even to a small pilot.

How we got here

These features didn’t appear out of nowhere. Trusted Launch has been a staple of Azure VMs for years, verifying firmware integrity and boot components. Bringing it to Hyper‑V on‑premises closes a gap that many virtualized workloads have been waiting for. Quick Machine Recovery traces its lineage to the Windows 11 client, where Microsoft first experimented with cloud‑assisted remediation. The jump to Server is logical: if a desktop can self‑heal, why not a rack full of hosts? ReFS boot has been a long‑running request from admins who wanted the file system’s resilience at every layer of the stack. And NVMe over Fabrics is the industry’s answer to the growing performance demands of NVMe flash—the initiator in Windows Server finally gives Microsoft’s OS a seat at that table.

But the preview also reflects the harsh reality of releasing server software: you can’t just drop a new security feature and hope it works across Live Migration and failover clusters. Those scenarios are where the real complexity lives. By shipping an intentionally hobbled Trusted Launch, Microsoft can gather feedback on the cryptography and key management before tackling the messy business of moving encrypted VMs between hosts.

What to do right now

If you’re planning to test build 29621, start with these steps:

  • Install cleanly. Microsoft has designated build 29531 as the preview baseline. Upgrades from earlier Server vNext builds are unsupported. If you have a lab running an older preview, wipe it and start fresh with 29531 or higher, then upgrade to 29621.
  • Isolate your test environment. Trusted Launch VMs can’t move, so dedicate a standalone Hyper‑V host—no clusters, no replication. Use PowerShell to spin up a Gen 2 VM with -TrustedLaunch enabled, and inspect the vTPM state encryption.
  • Check your ReFS recovery partition. If you install to an ReFS volume, note the automatically created WinRE partition. Do not delete it or let it shrink. Build a habit of verifying its size remains at least 2 GB after cumulative updates.
  • Be ready to work around the LSASS bug. Microsoft acknowledges a crash in LSASS during TLS hybrid key exchange negotiations. As a temporary fix, disable the affected hybrid groups via TLS cmdlets or Group Policy until a patch arrives. Without this, a test server could unexpectedly fail during secure communications.
  • Watch the expiration date. The build self‑destructs on September 15, 2026. Plan your evaluation window accordingly.

What comes next

Microsoft’s roadmap for these features is clear even if timelines aren’t. Trusted Launch will need live migration and cluster support before it can graduate from lab curiosity to production tool—expect multiple previews fleshing out the PowerShell tooling and compatibility. Quick Machine Recovery will get Group Policy integration, making it feasible to test in managed environments; Microsoft may also expand its remediation sources beyond the cloud. NVMe over Fabrics will likely see driver refinements and performance tuning as partners submit feedback. And ReFS boot’s recovery partition logic may get smarter, perhaps shrinking the hard‑coded 2 GB requirement once real‑world testing reveals actual size needs.

For now, build 29621 is a clear signal: Microsoft is investing in defense‑in‑depth, automated healing, and high‑speed storage for the next Windows Server release. Admins who want a seat at the design table should download the ISO, fire up a lab, and file their feedback. Just keep the production keys locked away.