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)Why can't I do a Deep Traversal (subfolder) Search on the MAPI Public Folder Tree?
I am sure many of you have at one time or another wanted to do a Deep Traversal (subfolder) Search on the MAPI Public Folder Tree. However, as many of you probably know, Exchange does not allow for Deep Traversal (subfolder) Searches on the MAPI Public Folder Tree: http://support.microsoft.com/default.aspx?scid=kb;en-us;254911. The reason you cannot do this is because when the Public Folder system was designed, it was decided that load balancing would be accomplished by putting only some of the content on some of the servers. For example, if there exists 3 folders and 3 servers. Folder1 may be replicated between servers 1 & 2, folder2 between servers 2 & 3, and folder3 between 1 & 3. If the client created a search folder that simultaneously searched all three folders, they’d get different results depending on which actual Public Folder Server they were connected to. To address this issue, search folders cannot be created that search the content of multiple folders; deep traversal, or subfolder, being a special case of “multiple folders”. One way to get around this “limitation” is by setting up a Non-MAPI Public Folder Tree because you can do a Deep Traversal (subfolder) Search against that: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_exch2k_specifying_a_deep_traversal.asp?frame=true. However, you cannot view this Public Folder Tree via MAPI (i.e Outlook). So what is the difference you ask? Well, the thought behind Application Public Folder Stores was that, for the most part, the content of the folders would not be replicated to any other server. There’s no actual architectural limitation to enforce this – Exchange originally just foresaw organizations would create only one Application Public Folder Store at all and so replication wouldn’t be an issue. Therefore, users can create Search Folders that can search the content of multiple folders. Given this, though, you do actually step back into the original problem. Namely, the search folder itself is replicated among servers but the content is always generated locally. Also, clients are never referred to a different server – search folders always seem (to the client) to have their exclusive replica on the server presently being queried. So, users should be aware that they will get different results depending on which server they contact for the content, and of course replication latency adds a new dimension to the differing results. - Chris AhlersUnderstanding Exoledb default folders
EXOLEDB creates a number of system folders under the NON_IPM_SUBTREE during the Accept Clients phase of MDB initialization. Some of the folders remain for historic reasons, but most have real purposes and impact on the server should they be deleted. None of these folders should ever be replicated. The folders that are created are: \NON_IPM_SUBTREE\schema-root\ \NON_IPM_SUBTREE\schema-root\Default \NON_IPM_SUBTREE\schema-root\Microsoft\ \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1 \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views \NON_IPM_SUBTREE\StoreEvents\ \NON_IPM_SUBTREE\StoreEvents\GlobalEvents \NON_IPM_SUBTREE\StoreEvents\Internal \NON_IPM_SUBTREE\OWAScratchPad In all cases, Subfolders named with the GUID correspond to the MDB object with the same guid. The first folders created are the Schema folders: Schema-Root \NON_IPM_SUBTREE\schema-root\ - introduced in Exchange 2000 RTM. \NON_IPM_SUBTREE\schema-root\Default - introduced in Exchange 2000 SP1 \NON_IPM_SUBTREE\schema-root\Microsoft\ - introduced in Exchange 2000 SP1 \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1 - introduced in Exchange 2000 SP1 The typical schema path for a public mdb looks like: File://.BackOfficeStorage/<domain>/<TLHName>/NON_IPM_SUBTREE/schema-root/microsoft/exchangeV1 The private MDB schema path is under the system attendant mailbox. EXOLEDB supports multiple schemas, or property type definitions. This was part of support for the "never fully implemented" exchange web store development platform. The idea was that Folder items could reference various versions of the schema and live happily alongside of each other. At one point (Exchange 2000 RTM) schema files lived in the schema root folder, and changes to the schema effectively propagated to all items. This lead to problems in the application development workspace where each item needed to be touched to remove or add props as appropriate, so we adopted a versioning method. Under schemaroot, we create subfolders with application and version elements to allow effectively seamless upgrades. EXOLEDB watches the schema folders for changes so that it can propagate the entries, dump the schema cache, and repopulate on the fly. The \schemaroot\default folder is where normal folder items pull their schema from, and the schema root folder is flagged as pointing to the ExchangeV1 folder. EXOLEDB populates the schema entries from the .xml files, which are processed by an event sink - EXSCHEMA.EXE. The schema event sink binding cannot be deleted or removed, as it does not have an entry in the EventBindings folder like most events. EXCHWEB, Views, IMG, Controls \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views Introduced in Exchange 2000 SP1, no longer populated in Exchange 2000 Post SP3 hotfixes and Exchange 2003. For the Local Store to open items that referenced OWA control functionality the files had to be in a sync-able folder. These folders once contained copies of the web data for OWA to allow LIS stored items to open, but have never actually been used outside of LIS. Next, EXOLEDB starts the event binding system, which creates StoreEvents All store event folders have been present since Exchange 2000 RTM. \NON_IPM_SUBTREE\StoreEvents\ \NON_IPM_SUBTREE\StoreEvents\GlobalEvents \NON_IPM_SUBTREE\StoreEvents\Internal This is the event binding folder, where EXOLEDB stores information on events build to a given MDB. At startup EXOLEDB must enumerate the events here, which can lead to long store startup times with large event sink numbers. Titanium performance in this area is greatly improved, but time to mount an MDB is still affected by number of rows. Each binding is validated for class, having a valid event method (onsave, ontimer, ect), valid clsid, and sink parameters. Events with a match class of ANY can only be registered in the GlobalEvents subfolder. After creating the Schema folders and starting the event bindings system, EXOLEDB creates the OWA scratch pad OWAScratchPad \NON_IPM_SUBTREE\OWAScratchPad - Introduced in Exchange 2000 SP1 Posts have to start out somewhere in order to have attachments, and for public store logons, that place is the OWA scratch pad. Because DAV doesn’t do cross mdb operations, we need a point on every mailbox where we can always write posts to, so that we can support adding attachments. The Posts are "Staged" in the OWAScratchPad until all attachments are added (or they are saved). The size limit on the OWA scratch pad controls the size of attachments that can be added via OWA. Attempts to post larger messages should result in an error: "This item exceeds the maximum size defined for this folder and cannot be saved. Contact your administrator to have the folder limits increased." The size of OWAScratchPad is always reset to 1mb at EXOLEDB initialization if the registry key "HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA", a REG_DWORD value "Message Size Limit" is not set. This is required for Sharepoint, because EXOLEDB has no idea of we are running in magma mode or not. OWA posts to the scratch pad are done in flat url format, meaning they directly reference the folder and message. This is to support deep vroots where the friendly URL might be too long. What causes duplicate system folders? This question really falls into two categories. AD Objects -Because when a store is deleted (disaster recovery & friends) we have no way to tell the AD the PF objects went away, then when folders are re-created they do not get "attached" to the corresponding DS objects. New ones are created. Actual Folders - If the folders are set to replicate, and the store in question is deleted, EXOLEDB will recreate the folders on startup, and replication can then create a second, duplicate of any such folders. This wreaks havoc with event bindings. Deleting said folder via friendly URL is dangerous, as the two will often have duplicate friendly URLs.. Why do they get strange names? When the number of system folders with the same number grows, we append a random number to the DS proxy to make it unique, resulting in names like "controls12345678". Why can I not delete them? First off, if you were to delete the folders, EXOLEDB would put them back. Secondly, most of these folders have real uses that will adversely affect the operation of the server if not present. - Jason NelsonSo how does this Deferred Delivery thing work?
There are actually 2 different types of delayed message delivery... I believe stemming form the quaintness of X400. The following applies to Exchange2000/Exchange2003. They have somewhat different behaviors, but both result in getting the message delivered to the intended recipients at some time after the specified time. The first type is delayed send. This is the typical functionality you see when using Outlook to send email. This functionality is controlled by the MAPI property PR_DEFERRED_SEND_TIME. When this property is set, the the message is kept in the MSExchangeIS SendQ. To end users, this means that their messages are visible in their Outbox. They can still double-click on them to open them, and will need to click "Send" for them to resubmitted for delivery. For an administrator, they will need to log into the users mailbox to see the message in that users Outbox. Unless the mailbox is deleted and purged The second type is deferred delivery (controlled by the MAPI property PR_DEFERRED_DELIVERY_TIME). The key difference is that the delay happens on the "delivery" side once transport "owns" the message. While the phrase "deferred delivery" might make you think that message is held on the destination server, it is in fact held in the queues on the source server. From the end-users perspective, the message immediately disappears from their mailbox and they cannot modify it if something occurs to them later. This is somewhat moot, as the past several versions of Outlook do not use this feature. For the email administrator, the message is queued up in the MDB temp tables along with all of the other mail. In Exchange2003, these messages are also exposed through the queues node of the Exchange System Manager. Deleting and purging the mailbox have no effect on these messages, but deleting the MDB they are queued on will make the messages disappear. - Michael SwaffordI'll have some transaction log files for breakfast day
With viruses spreading quick out there today, we had several cases where Exchange transaction logs got either deleted, quarantined or "cured" by file-level anti-virus software that is running on Exchange servers... the result is a bad thing... stores down, transaction logs missing. In some cases the only thing you can do is go back to the last backup if one that is good is available. Otherwise - you are looking at possible repair (= data loss) + Isinteg (maybe 2-3 times) + mandatory offline defrag = a lot of time that is lost :( Please, do not let Exchange directories be scanned by file-level AV. Not "on-demand" one, not the memory resident one. Have Exchange directories excluded, the M: drive excluded, and actually - exclude specifically .log, .edb and .stm files too just to be extra careful. To be more specific, excluding the following on Exchange server is a GREAT idea: Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder. You can verify the locations by pulling up properties of your databases in ESM and checking the Database tab. Exchange MTA files in the Exchsrvr\Mtadata folder. Additional log files such as the Exchsrvr\server_name.log file. The Exchsrvr\Mailroot virtual server folder. The working folder that's used to store streaming temporary files used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location. The temporary folder that is used in conjunction with offline maintenance utilities such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure where you run the file from when you run the utility. Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder. Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder. The Exchange 2000 Server drive M. More appropriate reading: 328841 XADM: Exchange and Antivirus Software 823166 Overview of Exchange Server 2003 and Antivirus Software Nino BilicHow does duplicate detection work?
Duplicate detection of delivered messages is done by the Exchange store. The store does duplicate detection based on two properties on the message - the Internet Message Id and the client submit time. We would have liked to do duplicate detection based solely on the Internet Message Id but there are several not-to-be named applications out there that use the same Internet Message Id on all their messages. The store keeps track of duplicates using a table in JET called the DeliveredTo table. When a message is delivered to a user, the store checks this table and if no entry is found the message is delivered to the user and a row is added to this table to indicate that the user received the message. If an entry is found, the message is turfed. The store only tracks duplicates for 1 hour by default. This can be changed by changing the value of registry setting: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\<Private/Public-Guid>\Track Duplicates (in hours) The maximum value that the store will accept for this registry value is 49 days, if a value greater than 49 days is set, the store will ignore the value and keep duplicates for 24 hours. But keep in mind that increasing this value will cause this table to grow really large and this could slow down delivery. The store will periodically delete the old items from the deliveredTo table which is handled by the background cleanup thread which runs every hour. This is also configurable and the registry setting is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\<Private/Public-Guid>\Background Cleanup (in msecs). There is still a chance that you will get duplicate email if the delivery of email is delayed because of the following reasons: 1) If either the internet message id or the submit time is different on the two messages, the second message will not be treated as a duplicate. 2) If the two are the same, but time interval between the arrival of the two messages is greater than 1 hour, the store cleanup task would have deleted the original entry in the deliveredTo table and the user will get duplicates. 3) If the user is moved. The deliveredTo table is per database and the information is not moved when the user's mailbox is moved. 4) In older versions of Exchange we had a problem where duplicates would occur when a message was sent to a user and a DL containing the user using OWA. When the message was submitted the store would stamp an Internet Message Id on the outgoing message. However, since OWA submits messages with native MIME and the fact that the Internet Message Id stamped by the store on submission did not update the MIME Message Id header, the MAPI message was out of sync with the native MIME. The message would then be bifurcated by Transport and this would result in messages with different Internet Message Ids and therefore, duplicates. We changed this in Exchange 2003 so that the store only stamps the Internet Message Id on a message if it detects that the MIME has to be regenerated or if it is a pure MAPI message. - Jaya Matthew
Unable to Build Switchless Storage using Network ATC
3-Node HV/S2D Cluster using Switchless Storage and Network ATC getting Network HUD Error I have a Dell 3-node server cluster being used to host Hyper-V with S2D. Each node is identical and certified to pass S2D requirements. The networking consists of 2 onboard 1 Gbps and 2 quad-port PCI(e) NICs at 10/25 Gbps. The 2 onboard ports are being used for the management intent, 2 ports from each of those NICs are being connected to 2 top-of-rack switches for the compute intent at a total of 12 10 Gbps connections, and the other 2 ports from each of those NICs are being connected directly to the other nodes in a dual mesh method for the storage intent at a total of 6 25 Gbps connections. Very similar to the Microsoft diagram for a three-node storage switchless, dual TOR, dual link deployment network reference pattern for Azure Local, but I am using Windows Server 2025 Datacenter, not Azure Local. The problem I am encountering is when I attempt to create the switchless storage intent, I get an error (shown below) that reads "Failed to fetch physical NIC mapping from the Network HUD service. Please diagnose..." If I leave off the switchless option, it builds without issue. The error only occurs when I attempt to use the switchless option. I tried without configuring the NIC IP addresses first, as well as trying configuring the NIC IP addresses beforehand. I tried without having a cluster built first, as well as building a failover cluster without storage before running the network intent command. The error I posted below shows my last attempt after having the NICs configured with IP addresses and having a failover cluster established before running the command. The error has remained the same throughout the process. Has anyone else run into an issue like this with switchless storage? It seems like everything that I am trying to do is within scope and should be a supported solution. My fallback plan is to use my existing switches, but that drops my connection speeds down from 25 Gbps to 10 Gbps due to hardware limitations.
OneDrive Taking up space on C: even when nothing is being kept on device.
Recently got a new device and had all my files on the previous device synced to my OneDrive. The C drive has about 120 GB of my data (including OS) but when I check my Disk space, I only have 5GB remaining out of 256. However, OneDrive seems to be taking about 150 GB on the disk even though all the files have the cloud icons on it.
