Windows Server vNext 29667: Disable Hybrid TLS to Prevent LSASS Crashes

Windows Server vNext Build 29667 Still Requires a Clean Install from Build 29531​

Microsoft's announcement describes 29667 as a new build of the next Windows Server LTSC preview. The product naming hasn't changed yet: branding remains Windows Server 2025 in this preview, and when reporting issues Microsoft asks testers to refer to Windows Server vNext preview. Search results also show a Windows 11 build with the same number, 29667. BetaWiki describes that client build as released to Windows Insiders in the Experimental (Future Platforms) channel on 11 September 2026, so searching by build number alone can turn up the wrong product.

The upgrade rules haven't changed since earlier in the year. Build 29531 established a new Server preview baseline build. Microsoft asks testers to perform a clean install of Build 29531 (or later), and upgrades from Windows Server vNext preview builds older than 29531 are not supported. The same wording appears in the announcements for builds 29574, 29621, 29641, 29651 and 29659. For anyone who has been following along, 29667 is one more step on the same baseline.

Some coverage has described these older upgrades as blocked, which isn't quite right. NTCompatible's writeup of build 29659 said upgrades from builds older than 29531 are blocked. Microsoft's own wording is more careful: upgrades from earlier Windows Server previews (Build 26525 and older) are not technically blocked by setup.exe. In practice, setup may let you start an upgrade that Microsoft doesn't support. According to the known-issues list, VMs may fail to upgrade or start after upgrade from older preview builds impacting live migration and failover cluster scenarios.

Flighting has its own history. Microsoft says build 29531 itself was never flighted because of upgrade problems, and flighting resumed with build 29550. A labeling bug is still present: the label for this flight may incorrectly reference Windows 11, but when selected, the package installed is the Windows Server vNext update, and Microsoft says to ignore the label and proceed.

Here are the media and licensing details:

To download, you need to be registered with the Windows Insiders for Business program. Microsoft also says downloads may not be available in certain countries.

Trusted Launch for Hyper-V Generation 2 VMs Supports Only Standalone Hosts​

The headline feature is Trusted Launch for virtual machines (TVMs). This is a Hyper-V security option you turn on when you create a Generation 2 VM. In this first preview, TVMs support Secure Boot, a virtual TPM (vTPM) and protection of vTPM state at rest, and everything is managed through PowerShell. Hyper-V admins have used Secure Boot and vTPM for years, so the new piece here is guest state protection. The host's IGVmAgent service guards the VM's protected state, and a protected VM won't start without that service.

This isn't Trusted Launch's first appearance in a vNext build. NTCompatible reported that build 29659 was already adding Trusted Launch for Generation 2 VMs, cloud-powered Quick Machine Recovery, and dual NVMe-over-Fabrics protocols. Build 29667 brings the Trusted Launch documentation forward largely unchanged. Admins who tested it on 29659 won't find a new capability here, just the same preview on a newer build. The 29667 notes also don't mention Quick Machine Recovery.

The list of unsupported scenarios matters more than the feature list. Microsoft says this release does not support:

• Moving a TVM to another server.
• Running TVMs in failover clusters or with Hyper-V Replica.
• Boot integrity verification.
• Managing TVMs in Windows Admin Center (WAC).

Taken together, those limits mean TVMs in 29667 work only on a single standalone Hyper-V host. You can't migrate them, cluster them or replicate them, and you manage them from PowerShell. That's fine for checking guest OS compatibility and seeing how guest state protection behaves. It isn't enough to model a production Hyper-V cluster.

Enabling Trusted Launch on a Build 29667 host​

Microsoft's documented sequence runs on a host with the latest Server Insider build installed. Note that step 1 restarts the server.

1. Enable Hyper-V: Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
2. Create the registry key: New-Item -Path "HKLM:\SOFTWARE\Microsoft\AszIgvmAgent" -Force
3. Set the opt-in value: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\AszIgvmAgent" -Name "TvmWinServer" -Value 1 -PropertyType DWord -Force
4. Enable the feature: Enable-WindowsOptionalFeature -Online -FeatureName "IsolatedGuestVm" -NoRestart
5. Check the host agent with Get-Service -Name "IGVmAgent". The status should be Running. If it isn't, Microsoft asks testers to report the problem with the IGVmAgent and IGVmSystem Operational logs, found in Event Viewer under Applications and Services Logs → Microsoft → Windows.
6. If the VM needs a network connection, identify an external virtual switch: (Get-VMSwitch | Where-Object { $_.SwitchType -eq "External" }).Name

You can create the VM in one of two ways. To use an existing Generation 2 VHDX, run New-VM -Name <VMName> -Generation 2 -GuestStateIsolationType TrustedLaunch -SwitchName <switch> -VHDPath <path to vhdx> -Path <config path>. To start from a blank disk, create a new VHD (Microsoft's example is 40GB) with -NewVHDPath and -NewVHDSizeBytes 40GB, using the same -GuestStateIsolationType TrustedLaunch flag. Then attach a Generation 2-compatible installer with Add-VMDvdDrive -VMName <VMName> -Path <Guest OS ISO path>. Make sure the DVD drive is first in the VM's firmware boot order.

You can check success in two ways. (Get-VM -Name <VMName>).GuestStateIsolationType should return TrustedLaunch. Microsoft also describes a deliberate negative test: stop the IGVmAgent service and restart the VM. A Trusted Launch VM with guest state protection should refuse to start. This check shows the protection works, and it also shows the operational risk: on a TVM host, IGVmAgent is now a service your VMs can't boot without. Start the service again when you finish the test.

The NVMe-oF Initiator Adds NVMe/TCP and NVMe/RDMA to Windows Server Labs​

The second feature is networked storage. NVMe-over-Fabrics (NVMe-oF) takes the NVMe command set, originally built for SSDs attached locally over PCIe, and carries it across a network. The host talks directly to remote NVMe controllers instead of going through SCSI-based protocols such as iSCSI or Fibre Channel. Build 29667 supports two transports:

• NVMe/TCP runs over ordinary Ethernet and needs no specialized hardware.
• NVMe/RDMA is aimed at low-latency, high-throughput access and needs supported RDMA network adapters. Microsoft gives RoCE and iWARP as example fabrics.

The initiator is not new in this build. Microsoft first introduced an in-box NVMe/TCP and NVMe/RDMA initiator in a March 13, 2026 Windows Server blog post, calling it an early, evaluation-focused release. According to that post, you configure it with a command-line utility, nvmeofutil.exe, not PowerShell cmdlets. You set up discovery and I/O connections manually, and connected NVMe namespaces show up as ordinary Windows disks. The same post says there's no multipathing yet and recovery is limited in some network-failure scenarios.

Those limits decide how you should use it. With no multipathing, a lab using the Windows initiator can't reproduce the redundant-path setup that production iSCSI or Fibre Channel deployments rely on. Build 29667 is a good place to check NVMe/TCP connectivity against an existing target, or to compare the TCP and RDMA paths on the same hardware. Don't use it to test failover. NTCompatible's view was that NVMe-oF over TCP should simplify a lot of storage networking that currently relies on legacy SCSI stacks. That's a reasonable long-term reading, but the current initiator can't show it yet.

ReFS Boot in Windows Server vNext Requires Partition Planning Before Setup​

The 29667 notes say ReFS boot is enabled for Windows Server vNext preview builds. With ReFS boot, the Resilient File System can hold the operating system volume as well as data volumes. Microsoft's deployment guidance says ReFS boot is available from build 29531.1000 onward, which Microsoft dates to February 11, 2026. It needs UEFI firmware and a GPT-partitioned system disk, and it isn't available on legacy BIOS systems or Generation 1 VMs. Microsoft describes the main use case as dedicated storage hosts that already use ReFS features such as block cloning and integrity streams, so the whole host runs on one file system.

The recovery partition is where ReFS boot gets complicated. On an NTFS install, Windows Setup shrinks the OS volume on first boot to make room for the Windows Recovery Environment (WinRE). ReFS can't shrink volumes, so Setup can't do that. WinRE also doesn't run from ReFS. Microsoft's guidance is to lay out all four partitions yourself, in an unattend.xml answer file or a DiskPart script in Windows PE:

If you skip the explicit WinRE partition, Microsoft says Setup will still install the OS on ReFS, but automatic repair and BitLocker recovery boot won't work. You also can't fix partition sizes later, because space can't be taken back from a ReFS OS partition. After the first boot, Get-Volume -DriveLetter C should report a FileSystemType of ReFS, and reagentc /info should show WinRE enabled on the recovery partition.

The 29667 release notes add three limits. ReFS boot systems create a WinRE partition of at least 2GB. If WinRE can't be updated because the partition is too small, the system may disable WinRE without removing the partition. And if someone deletes that partition and extends the boot volume over it, the only way back is a clean install. Admins used to reclaiming recovery-partition space on NTFS servers should drop that habit on ReFS-booted machines.

Microsoft also warns that third-party antivirus, backup and disk-management tools may assume the OS volume is NTFS. Test them before relying on a ReFS boot volume. At least one tester on Microsoft's Insider forum has noticed setup differences between builds. They reported that when installing a later build from ISO, there is no ReFS filesystem selection as in build 29621. The unattend or DiskPart approach in Microsoft's guidance doesn't depend on that interactive option.

The LSASS Crash in TLS Hybrid Key Exchange Needs Mitigating First​

The most important known issue affects a security feature. A race condition in the TLS hybrid key exchange implementation may cause the LSASS service to crash when hybrid groups are negotiated by a TLS server. The groups involved pair classical elliptic-curve key exchange with ML-KEM, Microsoft's post-quantum key encapsulation option. Until a fix ships, Microsoft recommends disabling the X25519_MLKEM768, SecP256r1_MLKEM768 and SecP384r1_MLKEM1024 groups using the TLS cmdlets or Group Policy.

This issue has been in the vNext notes for a while. The same wording appears in the build 29621 announcement from July 2026, and in 29641 and 29667. On Windows, the Local Security Authority Subsystem Service (LSASS) handles authentication, so a crash there can take the whole server down. Any lab testing post-quantum TLS on a vNext server acting as a TLS server should apply the mitigation. Remember that disabling these groups also means you aren't testing hybrid key exchange at all.

The second known issue is narrower. On Server Core, installing the latest AppCompat Features on Demand (FOD) package may fail after upgrading to build 29574. Microsoft says this appears limited to Server Core installations with third-party application licenses that fail compatibility checks after the upgrade, and it plans a fix in a future build. Desktop Experience installations aren't named in that issue.

What This Means for Windows Server Insiders​

If your lab is on build 29531 or later, take 29667 through flighting or the new media, and ignore the misleading Windows 11 label. If you're on anything older, and especially on 26525 or earlier, do a clean install. Setup may not stop an upgrade from those builds, but the VM start failures Microsoft documents make it a bad trade. For all three features, set up tests that match their current limits. Trusted Launch belongs on a single standalone host, NVMe-oF on a single-path connection, and ReFS boot on a disk you partitioned before Setup ran.

• Clean-install build 29531 or later before taking 29667. Upgrades from older vNext previews aren't supported, even where setup.exe allows them.
• Test Trusted Launch only on a standalone Hyper-V host. Moving TVMs, clustering, Hyper-V Replica, boot integrity verification and WAC management aren't supported yet.
• Keep IGVmAgent running on any TVM host, since a Trusted Launch VM with guest state protection won't start without it.
• Don't use the NVMe-oF initiator to test failover. It's configured with nvmeofutil.exe and has no multipathing yet.
• For ReFS boot, create the 2GB NTFS WinRE partition directly after the Windows partition at install time, and never delete it to extend the boot volume.
• Disable the three ML-KEM hybrid TLS groups on servers that act as TLS servers until Microsoft ships the LSASS fix.

Build 29667 shows Microsoft's next LTSC release taking shape around VM security, NVMe-based storage networking and a server that can boot entirely from ReFS. All three features are still at a stage where the unsupported lists matter as much as the supported ones. The dates that matter are the fixes Microsoft has committed to, for the LSASS race condition and the Server Core AppCompat FOD failure, and the expiry of this build's license on October 15, 2027. Clustered or migratable Trusted Launch VMs will need later builds. For now, a single Hyper-V host is the right place to test them.