Announcing Native NVMe in Windows Server 2025: Ushering in a New Era of Storage Performance
We’re thrilled to announce the arrival of Native NVMe support in Windows Server 2025—a leap forward in storage innovation that will redefine what’s possible for your most demanding workloads. Modern NVMe (Non-Volatile Memory Express) SSDs now operate more efficiently with Windows Server. This improvement comes from a redesigned Windows storage stack that no longer treats all storage devices as SCSI (Small Computer System Interface) devices—a method traditionally used for older, slower drives. By eliminating the need to convert NVMe commands into SCSI commands, Windows Server reduces processing overhead and latency. Additionally, the whole I/O processing workflow is redesigned for extreme performance. This release is the result of close collaboration between our engineering teams and hardware partners, and it serves as a cornerstone in modernizing our storage stack. Native NVMe is now generally available (GA) with an opt-in model (disabled by default as of October’s latest cumulative update for WS2025). Switch onto Native NVMe as soon as possible or you are leaving performance gains on the table! Stay tuned for more updates from our team as we transition to a dramatically faster, more efficient storage future. Why Native NVMe and why now? Modern NVMe devices—like PCIe Gen5 enterprise SSDs capable of 3.3 million IOPS, or HBAs delivering over 10 million IOPS on a single disk—are pushing the boundaries of what storage can do. SCSI-based I/O processing can’t keep up because it uses a single-queue model, originally designed for rotational disks, where protocols like SATA support just one queue with up to 32 commands. In contrast, NVMe was designed from the ground up for flash storage and supports up to 64,000 queues, with each queue capable of handling up to 64,000 commands simultaneously. With Native NVMe in Windows Server 2025, the storage stack is purpose-built for modern hardware—eliminating translation layers and legacy constraints. Here’s what that means for you: Massive IOPS Gains: Direct, multi-queue access to NVMe devices means you can finally reach the true limits of your hardware. Lower Latency: Traditional SCSI-based stacks rely on shared locks and synchronization mechanisms in the kernel I/O path to manage resources. Native NVMe enables streamlined, lock-free I/O paths that slash round-trip times for every operation. CPU Efficiency: A leaner, optimized stack frees up compute for your workloads instead of storage overhead. Future-Ready Features: Native support for advanced NVMe capabilities like multi-queue and direct submission ensures you’re ready for next-gen storage innovation. Performance Data Using DiskSpd.exe, basic performance testing shows that with Native NVMe enabled, WS2025 systems can deliver up to ~80% more IOPS and a ~45% savings in CPU cycles per I/O on 4K random read workloads on NTFS volumes when compared to WS2022. This test ran on a host with Intel Dual Socket CPU (208 logical processors, 128GB RAM) and a Solidigm SB5PH27X038T 3.5TB NVMe device. The test can be recreated by running "diskspd.exe -b4k -r -Su -t8 -L -o32 -W10 -d30 testfile1.dat > output.dat" and modifying the parameters as desired. Results may vary. Top Use Cases: Where You’ll See the Difference Try Native NVMe on servers running your enterprise applications. These gains are not just for synthetic benchmarks—they translate directly to faster database transactions, quicker VM operations, and more responsive file and analytics workloads. SQL Server and OLTP: Shorter transaction times, higher IOPS, and lower tail latency under mixed read/write workloads. Hyper‑V and virtualization: Faster VM boot, checkpoint operations, and live migration with reduced storage contention. High‑performance file servers: Faster large‑file reads/writes and quicker metadata operations (copy, backup, restore). AI/ML and analytics: Low‑latency access to large datasets and faster ETL, shuffle, and cache/scratch I/O. How to Get Started Check your hardware: Ensure you have NVMe-capable devices that are currently using the Windows NVMe driver (StorNVMe.sys). Note that some NVMe device vendors provide their own drivers, so unless using the in-box Windows NVMe driver, you will not notice any differences. Enable Native NVMe: After applying the 2510-B Latest Cumulative Update (or most recent), add the registry key with the following PowerShell command: reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides /v 1176759950 /t REG_DWORD /d 1 /f Alternatively, use this Group Policy MSI to add the policy that controls the feature then run the local Group Policy Editor to enable the policy (found under Local Computer Policy > Computer Configuration > Administrative Templates > KB5066835 251014_21251 Feature Preview > Windows 11, version 24H2, 25H2). Once Native NVMe is enabled, open Device Manager and ensure that all attached NVMe devices are displayed under the “Storage disks” section. Monitor and Validate: Use Performance Monitor and Windows Admin Center to see the gains for yourself. Or try DiskSpd.exe yourself to measure microbenchmarks in your own environment! A quick way to measure IOPS in Performance Monitor is to set up a histogram chart and add a counter for Physical Disk>Disk Transfers/sec (where the selected instance is a drive that corresponds to one of your attached NVMe devices) then run a synthetic workload with DiskSpd. Compare the numbers before and after enabling Native NVMe to see the realized difference in your real environment! Join the Storage Revolution This is more than just a feature—it’s a new foundation for Windows Server storage, built for the future. We can’t wait for you to experience the difference. Share your feedback, ask questions, and join the conversation. Let’s build the future of high-performance Windows Server storage together. Send us your feedback or questions at nativenvme@microsoft.com! — Yash Shekar (and the Windows Server team)Windows Server at Microsoft Ignite 2026: Sessions, our booth, and how to join the pre-day
Start early with the Windows Server pre-day Windows Server: Secure, manage, and accelerate with AI (PREB20) Monday, November 16 | 1:00–5:00 PM PT | Moscone Center This is a demo-filled, deep-dive workshop built for Windows Server professionals and led by the engineers and product team who build Windows Server. You'll see how to manage your servers across Azure, hybrid cloud, and on-premises environments, and get an early look at what's coming in the next version of Windows Server, including local AI, security, Hyper-V, Active Directory, networking, and storage. Expect practical tips you can take back to optimize, modernize, and get the most out of your Windows Server fleet. How to sign up The pre-day was added after Ignite registration opened, and it's a paid add-on that you select during registration. That means it doesn't show up when you search the session catalog, and many people who registered early never saw it. Here's how to get a seat. If you haven't registered for Ignite yet: Visit the Microsoft Ignite registration website and select Register. Choose the in-person Conference pass. When you reach the pre-day options, add Windows Server: Secure, manage, and accelerate with AI (PREB20). The pre-day has an additional fee of $325. Finish registration. The pre-day will appear in your confirmation. Already registered for the in-person event? Sign in to your registration using the same account you used to register. Open your registration page and select "Add a Pre-Day pass". Add Windows Server: Secure, manage, and accelerate with AI (PREB20) and complete checkout; additional fee of $325 applies. Watch for an updated confirmation email. If it doesn't arrive, check your junk folder. Seats are limited, and the Windows Server pre-day has sold out in past years, so we recommend adding it soon. Windows Server sessions on Thursday, November 19 All four of our sessions are on Thursday in the Moscone Center area. The venues are close together with 30 to 45 minutes between sessions, so you can catch all of them. Add them to your schedule from the session catalog. Session Speakers What you'll see When and where BRK418 (Breakout): What's new and what's next for Windows Server Neil Hinnant, Elden Christensen The latest release news and a preview of the next version of Windows Server, covering Hyper-V, Active Directory, storage, and networking, and how the next release raises the bar for security, performance, and AI. Thursday, Nov 19 10:15 AM – 11:00 AM BRK419 (Breakout): From VMware to Hyper-V: Hyperscale virtualization in your datacenter Jeff Woolsey, Davanna White How Windows Admin Center Virtualization Mode helps you build cost-effective, cloud-connected on-premises virtualization with Hyper-V in Windows Server. Thursday, Nov 19 1:30 PM – 2:15 PM THR897 (Theater): Cloud management for every Windows Server Theo Tran, Cindy Wan Consistent management with Azure Arc wherever your servers run, plus lower ESU costs, free hotpatching, and SQL Server optimization. Thursday, Nov 19 10:45 AM – 11:10 AM TT1701 (Table talk): On-prem inferencing with Windows Server Dan Cuomo A small-group conversation on running AI workloads on-premises: planning AI-ready server hardware, and thinking through performance, security, and operational consistency. Thursday, Nov 19 9:00 AM – 9:45 AM Come find us at the Windows Server booth Windows Server has its own booth in the Hub, open November 17 to 19. Stop by to see demos, ask the product team your toughest questions, and tell us what you need from Windows Server. Bring your upgrade plans, your hotpatching questions, and your AI ideas. Can't be there in person? The digital pass is free and includes keynotes and a wide range of sessions. Breakouts and Theater sessions will be streamed or available on demand. Table talks and the pre-day are in-person only. Get hands-on before you arrive Want a head start? Join the Windows Server Insider Program to try preview builds of the next version of Windows Server and share feedback with the team. Several features you'll hear about at Ignite are already in Insider builds, and we've covered them here on Tech Community, including Trusted Launch for virtual machines, ReFS boot, and Windows NVMe-over-Fabrics initiator preview. We can't wait to see you in San Francisco. If you have questions about our sessions or the pre-day, refer to the Ignite event page for more information or leave us a comment below.Introducing the Windows NVMe-oF Initiator Preview in Windows Server Insiders Builds
What Is NVMe-over-Fabrics? NVMe-over-Fabrics (NVMe-oF) extends the NVMe protocol—originally designed for local PCIe-attached SSDs—across a network fabric. Instead of using legacy SCSI-based protocols such as iSCSI or Fibre Channel, NVMe-oF allows a host to communicate directly with remote NVMe controllers using the same NVMe command set used for local devices. In this Insider build, Windows Server supports: NVMe-oF over TCP (NVMe/TCP), allowing NVMe-oF to run over standard Ethernet networks without specialized hardware. NVMe-oF over RDMA (NVMe/RDMA), enabling low-latency, high-throughput NVMe access over RDMA-capable networks (for example, RoCE or iWARP) using supported RDMA NICs. Why NVMe-oF on Windows Server? For Windows Server deployments, NVMe-oF builds on the same principles as Native NVMe support: helping you reduce protocol overhead, improve scalability, and better align your storage stack with modern hardware. For Windows Server customers, NVMe-oF offers: Lower overhead networked storage access — NVMe-oF has less protocol overhead than iSCSI, helping extract the performance of modern NVMe devices while preserving the parallelism and efficiency of NVMe. Flexible infrastructure choices — NVMe-oF supports both TCP and RDMA transports, allowing customers to choose between standard Ethernet-based deployments or low-latency RDMA-capable networks based on their infrastructure and performance goals. A forward-looking storage foundation — NVMe-oF is designed to scale across multiple controllers, namespaces, and queues, making it a strong foundation for future disaggregated and software-defined storage architectures. This Insider release represents the first step in bringing NVMe-oF capabilities natively to Windows Server. What’s Included in This Insider Release In this Windows Server Insider build, you can evaluate the following NVMe-oF capabilities: An inbox NVMe-oF initiator with NVMe/TCP and NVMe/RDMA support A new command-line utility, nvmeofutil.exe, for configuration and management Manual configuration of discovery and I/O connections Automatic exposure of NVMe namespaces as Windows disks once connected Note: PowerShell cmdlets are not available yet. All configuration is performed using nvmeofutil.exe. Getting Started with nvmeofutil.exe To start evaluating NVMe-oF in this build, you’ll use nvmeofutil.exe, the command-line utility included with supported Windows Server Insider builds. 1. Install the Latest Windows Server Insiders Build Ensure you are running a Windows Server Insiders build that includes: The inbox NVMe-oF initiator with NVMe/TCP and NVMe/RDMA support The nvmeofutil.exe utility 2. Open an Elevated Command Prompt All NVMe-oF commands must be run from an administrator command prompt. 3. List Available NVMe-oF Initiator Adapters nvmeofutil.exe list -t ia This command displays the available NVMe-oF initiator adapters on the system. 4. Enumerate Host Gateways nvmeofutil.exe list -t hg -ia <AdapterNumber> Host gateways represent transport-specific endpoints, such as NVMe/TCP over IPv4. 5. Configure an I/O Subsystem Port Tip: You’ll need three values from your target configuration: the Subsystem NQN, the target IP/DNS, and the TCP port. If you haven’t set up a target yet, see the Target Setup section below for a quick Linux-based configuration and where to find these values. nvmeofutil.exe add -t sp -ia <Adapter> -hg <HostGateway> -dy true -pi <PortNumber> -nq <SubsystemNQN> -ta <TargetAddress> -ts <ServiceId> This defines the connection parameters to the remote NVMe-oF target. 6. Connect and Use the Namespace nvmeofutil.exe connect -ia <Adapter> -sp <SubsystemPort> Once connected, the NVMe namespace appears as a disk in Windows and can be partitioned and formatted using standard Windows tools. Target Setup (Recommendations for Early Evaluation) If you plan to evaluate NVMe-oF with an existing storage array, check with your SAN vendor to confirm support and get configuration guidance. Where possible, we also encourage you to validate interoperability using your production storage platform. For early evaluation and lab testing, the simplest and most interoperable option is to use a Linux-based NVMe-oF target, as described below. To evaluate the inbox Windows NVMe-oF initiator in this Insider release, you’ll need an NVMe-oF target that can export a block device as an NVMe namespace over TCP. Recommended: Linux kernel NVMe-oF target (nvmet) over TCP For early testing, the simplest and most interoperable option is the Linux kernel NVMe target (“nvmet”). It’s straightforward to stand up in a lab and is widely used for basic NVMe-oF interoperability validation. Lab note: The example below uses “allow any host” to reduce friction during evaluation. In production environments, you should restrict access to specific host NQNs instead. What You’ll Need A Linux system (physical or VM) A block device to export (an NVMe SSD, SATA SSD, a virtual disk, etc.) IP connectivity to your Windows Server Insider machine A TCP port opened between initiator and target (you’ll choose a port below) VMs are fine for functional evaluation. For performance testing, you’ll want to move to physical hosts and realistic networking later. Option A — Configure nvmet Directly via configfs (Minimal, Copy/Paste Friendly) On the Linux target, run the following as root (or with sudo). This configures one NVMe-oF subsystem exporting one namespace over NVMe/TCP. 1) Load kernel modules and mount configfs sudo modprobe nvmet sudo modprobe nvmet-tcp # Required for nvmet configuration sudo mount -t configfs none /sys/kernel/config 2) Create a subsystem (choose an NQN) and allow host access Pick a subsystem name/NQN. Use a proper NQN format to avoid collisions on shared networks (example shown). SUBSYS="nqn.2026-02.com.contoso:win-nvmeof-test" sudo mkdir -p /sys/kernel/config/nvmet/subsystems/$SUBSYS # Lab-only: allow any host to connect echo 1 | sudo tee /sys/kernel/config/nvmet/subsystems/$SUBSYS/attr_allow_any_host > /dev/null 3) Add a namespace (export a local block device) Choose a block device on the target (example: /dev/nvme0n1). Be careful: you are exporting the raw block device. DEV="/dev/nvme0n1" # <-- replace with your device (e.g., /dev/sdb) sudo mkdir -p /sys/kernel/config/nvmet/subsystems/$SUBSYS/namespaces/1 echo -n $DEV | sudo tee /sys/kernel/config/nvmet/subsystems/$SUBSYS/namespaces/1/device_path > /dev/null echo 1 | sudo tee /sys/kernel/config/nvmet/subsystems/$SUBSYS/namespaces/1/enable > /dev/null 4) Create a TCP port (listener) and bind the subsystem Choose: TRADDR = the Linux target’s IP address on the test network TRSVCID = the TCP port (commonly 4420, but you can use any free TCP port) PORTID=1 TRADDR="192.168.1.92" # <-- replace with target IP TRSVCID="4420" # <-- TCP port sudo mkdir -p /sys/kernel/config/nvmet/ports/$PORTID echo -n $TRADDR | sudo tee /sys/kernel/config/nvmet/ports/$PORTID/addr_traddr > /dev/null echo -n tcp | sudo tee /sys/kernel/config/nvmet/ports/$PORTID/addr_trtype > /dev/null echo -n $TRSVCID | sudo tee /sys/kernel/config/nvmet/ports/$PORTID/addr_trsvcid > /dev/null echo -n ipv4 | sudo tee /sys/kernel/config/nvmet/ports/$PORTID/addr_adrfam > /dev/null # Bind subsystem to port sudo ln -s /sys/kernel/config/nvmet/subsystems/$SUBSYS \ /sys/kernel/config/nvmet/ports/$PORTID/subsystems/$SUBSYS 5) Quick validation (optional, from any Linux host with nvme-cli) If you have a Linux host handy, nvme discover will confirm the target is advertising the subsystem and will show the subnqn value you’ll use from Windows. sudo nvme discover -t tcp -a 192.168.1.92 -s 4420 Mapping the Target Values to Your Windows nvmeofutil.exe Steps In your Windows steps, you already define the key connection parameters in the Subsystem Port add/connect flow. Use these mappings: SubsystemNQN (-nq) → the subsystem name/NQN you created (example: nqn.2026-02.com.contoso:win-nvmeof-test) TargetAddress (-ta) → the Linux target IP address (example: 192.168.1.92) ServiceId (-ts) → the TCP port you used (example: 4420) Option B — If You Prefer a Tool-Based Setup: nvmetcli If you’d rather not manipulate configfs directly, nvmetcli provides an interactive shell and can save/restore configurations from JSON (useful for repeating the setup across reboots in a lab). At a high level, nvmetcli can: Create subsystems and namespaces Configure ports (including TCP) Manage allowed hosts (or allow any host in controlled environments) Save/restore configs (for example, /etc/nvmet/config.json) Optional (Advanced): SPDK NVMe-oF Target If you already use SPDK or want to explore higher-performance user-space targets, SPDK’s NVMe-oF target supports TCP and RDMA and is configured via JSON-RPC. For early evaluation, the Linux kernel target above is usually the quickest path. Known Limitations As you evaluate this early Insider release, keep the following limitations in mind: Configuration is CLI-only (no GUI or PowerShell cmdlets yet) No multipathing Limited recovery behavior in some network failure scenarios These areas are under active development. Try It and Share Feedback We encourage you to try NVMe-oF in your lab or test environment and share your experience on Windows Server Insiders Discussions so the engineering team can review public feedback in one place. For private feedback or questions that can’t be shared publicly, you can also reach us at nvmeofpreview@microsoft.com. We look forward to your feedback as we take the next steps in modernizing remote storage on Windows Server. — Yash Shekar (and the Windows Server team)
Announcing Trusted Launch for Virtual Machines for Windows Server Insiders
Trusted Launch for virtual machines We are excited to announce Trusted Launch for virtual machines (TVMs) in Windows Server Insider Preview. Trusted Launch is a security feature you can enable when creating Hyper-V Generation 2 VMs. It enables Secure Boot, installs a virtual Trusted Platform Module (vTPM), protects vTPM state at rest, and supports boot integrity verification (ability to verify if the VM started in a well-known good state). Further, when the VM runs in a Failover Cluster, the vTPM state is automatically made available when the VM live migrates or fails over to other nodes in the cluster – this ensures the VM remains available after migration or failover. This is unlike a Generation 2 VM with a vTPM, which will not start after migration or failover to another node in the cluster – the TPM state protection key needs to be moved to the destination node manually so the VM can start. With boot integrity verification, the entire boot path is measured and boot integrity is verified by Microsoft Azure Attestation service. This helps detect any alterations to the boot path or boot components. Such alterations, e.g. implanting malware in the boot path, can be detected by boot integrity verification. Increasingly attackers prefer implanting malware in the boot path for a variety of reasons: the OS layer is usually well protected, while firmware – as highly privileged code – can be used to alter what gets loaded (boot loader and drivers). Such alterations are not easily detectable by anti-virus software running at the OS layer. Boot integrity verification helps detect such alterations so a relying party (such as an app or service) can take suitable remediation actions, e.g. shutting down the VM. Boot integrity verification is an important part of establishing trust by verifying that the virtual machine started in a well-known good state. Insider preview TVMs are available for preview starting with Windows Server Insider preview build 29621. This initial preview only supports some of the Trusted Launch capabilities: Secure boot, vTPM, and vTPM state protection (at rest). You can create and manage TVMs using PowerShell. Guest state protection: The guest state (including the vTPM state) for each TVM is protected using a unique key that is stored in a KSP (Key Storage Provider) local to the server. Without this key, the VM will not start. Moving the VM to another server is not supported in this release. Not supported in this release: Moving TVMs to another server. TVMs in Failover Clusters or Hyper-V Replica. Boot integrity verification. Support for TVMs in Windows Admin Center (WAC). Instructions At a high-level, the steps involve: Install Windows Server Insider preview build on your server Enable Hyper-V Enable Trusted Launch feature Verify guest state protection 1. Install Windows Server Insider preview build Trusted Launch for virtual machines is available starting with the Windows Insider preview build number 29621. Install this build or a later build on your server. (Join Windows Server Insiders if you haven’t already!) 2. Enable Hyper-V (if it is not already enabled) Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart After enabling Hyper-V, the server needs to be restarted. 3. Set registry key property value (required to enable the Trusted Launch feature) New-Item -Path "HKLM:\SOFTWARE\Microsoft\AszIgvmAgent" -Force New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\AszIgvmAgent" -Name "TvmWinServer" -Value 1 -PropertyType DWord -Force Setting the above regkey informs relevant system components that the Trusted Launch feature is being used in a Windows Server environment. 4. Enable Trusted Launch feature Enable-WindowsOptionalFeature -Online -FeatureName "IsolatedGuestVm" -NoRestart 5. Verify if IgvmAgent is running IgvmAgent (Isolated Guest Virtual Machine agent) is a system-level service that helps support Trusted Launch capabilities. Get-Service -Name "IGVmAgent" The output should show Status as Running. If the Status is Running, you can skip to next step. If the Status is not Running, please report the issue. Add the following event logs to the report: Event Viewer: Applications and Services Logs => Microsoft => Windows => IGVmAgent => Operational Event Viewer: Applications and Services Logs => Microsoft => Windows => IGVmSystem => Operational You can open Event Viewer via the Run dialog: Press Win + R → type "eventvwr.msc" → press Enter 6. Create an external virtual switch (if you don't already have one you can use) Create and configure a virtual switch with Hyper-V | Microsoft Learn To see available external virtual switches: (Get-VMSwitch | Where-Object { $_.SwitchType -eq "External" }).Name 7. Create TVM If you already have a virtual hard disk (VHD or VHDX) for a Gen 2 VM with an installed guest OS, run: New-VM -Name <VMName> -Generation 2 -GuestStateIsolationType TrustedLaunch -SwitchName <virtual switch name> -VHDPath <path to vhdx> -Path <path to where VM config files will be stored> Else, run: New-VM -Name <VMName> -SwitchName <virtual switch name> -NewVHDPath <path to where new VHD will be stored> -NewVHDSizeBytes 40GB -Generation 2 -GuestStateIsolationType TrustedLaunch -Path <path to where VM config files will be stored> Then, add to the VM a virtual DVD drive containing an ISO image for the guest OS (Windows or Linux OS-compatible with Hyper-V Gen 2 virtual machine). Add-VMDvdDrive -VMName <VMName> -Path <Guest OS ISO image path> Note: The guest OS will be installed when the VM starts up. When connecting to the VM you will be prompted to install the guest OS from the DVD drive. Make sure that the DVD drive is at the top of the boot order specified in the firmware so the VM will boot from the DVD drive. For more information, see New-VM. 8. Verify VM guest state isolation type (Get-VM -name <VMName>).GuestStateIsolationType should return "TrustedLaunch". 9. Verify guest state protection To verify guest state protection, stop IGVmAgent service and restart the VM. Without IGVmAgent in Running state, a TVM with guest state protection will not start. Call to action Trusted Launch brings foundational VM security — Secure Boot, a vTPM, and protected guest state — to Windows Server, helping safeguard your VMs against boot-level and firmware threats. Please try out TVMs and provide your feedback via the Windows Server Insiders Forum. — Christina Curlette and Ram Jeyaraman (and the Windows Server team)Announcing ReFS Boot for Windows Server Insiders
We’re excited to announce that Resilient File System (ReFS) boot support is now available for Windows Server Insiders in Insider Preview builds. For the first time, you can install and boot Windows Server on an ReFS-formatted boot volume directly through the setup UI. With ReFS boot, you can finally bring modern resilience, scalability, and performance to your server’s most critical volume — the OS boot volume. Why ReFS Boot? Modern workloads demand more from the boot volume than NTFS can provide. ReFS was designed from the ground up to protect data integrity at scale. By enabling ReFS for the OS boot volume we ensure that even the most critical system data benefits from advanced resilience, future-proof scalability, and improved performance. In short, ReFS boot means a more robust server right from startup with several benefits: Resilient OS disk: ReFS improves boot‑volume reliability by detecting corruption early and handling many file‑system issues online without requiring chkdsk. Its integrity‑first, copy‑on‑write design reduces the risk of crash‑induced corruption to help keep your system running smoothly. Massive scalability: ReFS supports volumes up to 35 petabytes (35,000 TB) — vastly beyond NTFS’s typical limit of 256 TB. That means your boot volume can grow with future hardware, eliminating capacity ceilings. Performance optimizations: ReFS uses block cloning and sparse provisioning to accelerate I/O‑heavy scenarios — enabling dramatically faster creation or expansion of large fixed‑size VHD(X) files and speeding up large file copy operations by copying data via metadata references rather than full data movement. Maximum Boot Volume Size: NTFS vs. ReFS Resiliency Enhancements with ReFS Boot Feature ReFS Boot Volume NTFS Boot Volume Metadata checksums ✅ Yes ❌ No Integrity streams (optional) ✅ Yes ❌ No Proactive error detection (scrubber) ✅ Yes ❌ No Online integrity (no chkdsk) ✅ Yes ❌ No Check out Microsoft Learn for more information on ReFS resiliency enhancements. Performance Enhancements with ReFS Boot Operation ReFS Boot Volume NTFS Boot Volume Fixed-size VHD creation Seconds Minutes Large file copy operations Milliseconds-seconds (independent of file size) Seconds-minutes (linear with file size) Sparse provisioning ✅ ❌ Check out Microsoft Learn for more information on ReFS performance enhancements. Getting Started with ReFS Boot Ready to try it out? Here’s how to get started with ReFS boot on Windows Server Insider Preview: 1. Update to the latest Insider build: Ensure you’re running the most recent Windows Server vNext Insider Preview (Join Windows Server Insiders if you haven’t already). Builds from 2/11/26 or later (minimum build number 29531.1000.260206-1841) include ReFS boot in setup. 2. Choose ReFS during setup: When installing Windows Server, format the system (C:) partition as ReFS in the installation UI. Note: ReFS boot requires UEFI firmware and does not support legacy BIOS boot; as a result, ReFS boot is not supported on Generation 1 VMs. 3. Complete installation & verify: Finish the Windows Server installation as usual. Once it boots, confirm that your C: drive is using ReFS (for example, by running fsutil fsinfo volumeInfo C: or checking the drive properties). That’s it – your server is now running with an ReFS boot volume. A step-by-step demo video showing how to install Windows Server on an ReFS-formatted boot volume, including UEFI setup, disk formatting, and post-install verification. If the player doesn’t load, open the video in a new window: Open video. Call to Action In summary, ReFS boot brings future-proof resiliency, scalability, and performance improvements to the Windows Server boot volume — reducing downtime, removing scalability limits, and accelerating large storage operations from day one. We encourage you to try ReFS boot on your servers and experience the difference for yourself. As always, we value your feedback. Please share your feedback and questions on the Windows Server Insiders Forum. — Christina Curlette (and the Windows Server team)
Windows Server 2025 Remote Desktop Session Host Capacity Planning Whitepaper
The Remote Desktop Session Host (RDSH) is a role service available on Windows Server 2025, which allows multiple users to access desktops and applications hosted on a single machine simultaneously. This document serves as a guide for capacity planning of Remote Desktop Session Host servers running Windows Server 2025. In a server-based computing environment, all applications execution and data processing occur on the server. Consequently, the server is one of the systems most likely to experience resource depletion during peak loads, which can lead to disruptions throughout the deployment. A multi-session computing environment experiences significantly higher peak loads compared to single-session environments. An RDSH server with a specific hardware capacity has a maximum workload limit that it can support before its resources are exhausted. RDSH server customers need to estimate the required hardware type and quantity for their user base. The process of doing this type of evaluation is referred to as capacity planning. Multi session capacity planning is dependent upon the specific application usage pattern of the user base. Based on the user scenario, an estimation can be made about the hardware required to support the targeted user capacity. This white paper presents guidelines and a general methodology for assessing a server’s capacity using a sample user scenario. It outlines the methodology employed for capacity planning using Microsoft's internal tools. It includes various test cases and provides an analysis of the results. The document also provides guidance on the hardware and other parameters that can have a significant impact on the number of users a server can support effectively. You can read the rest of the whitepaper by downloading here.Introducing the VM Conversion tool in Windows Admin Center – Public Preview
As organizations update their infrastructure, a growing number are seeking adaptable, Microsoft-supported solutions that address current requirements while laying the path for future cloud and AI adoption. Azure provides an agile, scalable, cost-effective platform for infrastructure and innovation. Whether by modernizing to cloud technologies like Windows or Linux VMs, containers, Azure VMware Solution or PaaS services, Azure offers a world-class cloud experience. However, we recognize that some organizations must retain workloads on-premises due to data compliance, governance, or other regulatory requirements. For customers wanting to adopt Windows Server and Hyper-V for this use case, we are excited to provide a new option within Windows Admin Center, the VM Conversion tool, in public preview now. This agentless, cost-free tool streamlines the conversion of virtual machines from VMware to Windows Server with Hyper-V, providing customers flexibility with their on-premises virtualization environments while enabling a seamless transition path to Azure when desired. With minimal infrastructure requirements, the tool is particularly beneficial for small and medium-sized organizations. Additionally, with minimal setup time you can download the new VM Conversion tool extension in Windows Admin Center and begin converting virtual machines in under five minutes. Figure 1- VM Conversion tool in Windows Admin Center 🔑Key Features : Agentless, appliance-free discovery After establishing a connection to the virtualization environment, the tool conducts discovery of all virtual machines without requiring agents or appliances and does so in a non-intrusive manner. Minimal downtime The VM Conversion tool enables initial data replication while the source virtual machine remains operational, thereby preventing any interruptions to ongoing applications. After completing this initial replication, on user consent, the source VM is powered down so a subsequent replication pass can capture any data changes made during the first phase. This two-step process ensures that the cutover time from the source to the target VM is minimized. Group servers You can select and migrate up to 10 virtual machines at a time. This reduces manual effort and accelerates the transition to Windows Server. Boot configuration The tool automatically maps BIOS-based virtual machines to Generation 1 and UEFI-based machines to Generation 2, preserving boot configurations and ensuring compatibility. OS agnostic The tool supports conversion of both Linux and Windows guest OS VMs to Windows Server host. Multi-disk VM support Virtual machines that use several virtual hard disks—common in production environments—are fully supported. The operating system, data, and application disks all migrated together, so manual setup is not needed. ⚙️How It Works To ensure a smooth and reliable transition, the tool performs a comprehensive set of built-in prechecks. These checks validate critical VM attributes such as disk types, boot configuration (BIOS or UEFI), destination disk, memory requirements, and several more. By identifying potential issues early, administrators can proactively address them—minimizing the risk of migration failures and reducing downtime during the final cutover. The VM Conversion tool uses change block tracking (CBT) to efficiently replicate data from one virtual disk format to another. During the initial seeding phase, a full copy of the virtual machine is created while it remains online. This minimizes downtime and ensures data integrity. Before the final cutover, a delta replication captures all changes made since the initial copy, ensuring the destination VM is fully up-to-date post conversion to Hyper-V hosts. 🚀Ready to Take the Next Step? The VM Conversion tool is available now in the public feed of Windows Admin Center. You can install it directly from the Extensions settings in Windows Admin Center. To get started, ensure you're running the Windows Admin Center v2 GA release. 📘 For detailed setup instructions and prerequisites, refer to the Public Preview Documentation. 📍 Summary The VM Conversion tool offers a simple, supported path for organizations to streamline VM conversion to Hyper-V virtualization environments. With no added cost and minimal setup, it empowers customers to streamline VM migration and prepare for the cloud at their own pace. Support for Azure Arc-enabled servers is also planned for future releases, further enhancing hybrid management capabilities. We’re continuously evolving the VM Conversion tool based on user feedback. Please continue to share your feedback here and help us prioritize our efforts for future releases. Happy converting!
Hotpatching for Azure Arc–Connected Servers: General Availability and Subscription Details
Effective July 16, 2025, Hotpatching for Windows Server 2025 on Azure Arc–connected machines will be generally available (GA) and transition to a paid subscription model. This post provides technical details on the service, the value of hotpatching for on-premises servers, and important enrollment information for customers. What Is hotpatching? Hotpatching enables you to install OS security updates on Windows Server without requiring a reboot. This technology, previously exclusive to Windows Server Datacenter: Azure Edition, is now available for on-premises and hybrid environments through Azure Arc. Hotpatching has been in public preview at no cost, but as of July 16, 2025, a monthly subscription fee of $1.50 USD per CPU core will apply. Why hotpatching for on-premises servers? Minimize downtime: Apply critical security updates without interrupting workloads or requiring planned maintenance windows. Improve security posture: Reduce the window of vulnerability by deploying patches as soon as they are available. Operational efficiency: Eliminate the need for frequent reboots, simplifying patch management for IT teams. Consistent experience: Use the same hotpatching process across Azure, on-premises, and hybrid environments with Azure Arc. Enrollment and billing To receive hotpatches on Windows Servers outside of Azure, customers must enroll their servers. The servers must be on the latest cumulative update released during a baseline month (January, April, July and October) by Microsoft on the second Tuesday of the month. Only enrolled servers will continue to receive hotpatches and be billed accordingly. Preview customers: If already enrolled during the preview period, then no action is needed to continue to receive hotpatches. If you enrolled in hotpatching during the Preview and do not wish to be billed after GA, you must disenroll your servers before July 16, 2025, to avoid charges. New customers: Enroll your eligible Windows Server 2025 machines via Azure Arc to activate hotpatching and start receiving updates. How to enroll in hotpatching To begin receiving hotpatches for your Azure Arc–connected Windows Server 2025 machines, follow these steps: Prerequisites Ensure your machine is connected to Azure Arc. Ensure Virtualization Based Security (VBS) is enabled and running. Confirm that the latest cumulative update from a baseline month (January, April, July, or October) is installed. Hotpatching is only offered if this requirement is met. Enrollment via Azure Portal Connect your server to Azure Arc. Navigate to the Windows Server resource in the Azure Arc portal. Click on the Hotpatch blade Check the box “I want to license this Windows Server to receive monthly hotpatches” and click on confirm under the hotpatch blade. Note: Enrollment operation takes a few minutes, so you may need to manually refresh the Azure portal to see the updated status. How to disenroll from hotpatching If you no longer wish to receive hotpatches or want to avoid billing after the preview period ending on July 16, 2025, you must disenroll from hotpatching service on Azure Arc portal. Disenrollment via Azure portal Go to the Azure Arc–connected server in the Azure Arc portal. Open the hotpatch blade. Uncheck the box “I want to license this Windows Server to receive monthly hotpatches” and click on confirm. Important: Disenroll before disconnecting the machine from Azure Arc. If you disconnect first, billing may continue for up to 30 days after the last connection. See this blog post for additional details. Disenrollment via API Set subscriptionStatus to "Disable" in the license profile payload. This action is synchronous and should reflect immediately, though portal refresh may still be required. Learn more If you’re interested in learning more, check out our April blog post and the on-demand session on Hotpatching and Update Management from our recent Windows Server Summit virtual event.
