Windows Server 2025 Is (Almost) Here

Many more new features than last release, explained in detail: "Maybe Microsoft has realized that not everything is in the cloud, and giving attention to Server is important."

The next version of Windows Server is coming soon, and in this article I'll look at some of the improvements and new features.

Recently Microsoft held a Windows Server summit, full of (pre-recorded mostly) technical sessions looking at all the different enhancements -- catch the recordings here.

As for the release date, various presenters said "soon," "second half of 2024," "later in 2024," "can't tell you because Satya will punch me in the face" -- but the price probably goes to sole System Center 2025 session where the presenter said we'll be releasing it at the same time as Windows Server, in September 2024. If that turns out to be true, I suspect that poor program manager might be in trouble for not keeping the "secret."

In this article I'll focus on Active Directory and security improvements, changes to NTLM and SMB, Hotpatching, storage and networking enhancements, GPU support with both pooling and partitioning, and failover clustering. There are quite a lot of new features, unlike in the Windows Server 2022 release, something I attribute to two factors -- enhancements in Azure are trickling down to Server (especially for Hyper-V) and Azure Stack HCI. This "twice a year(ish)" product is a bit like a canary for Windows Server itself -- getting new features tested out before they make it into the long-term servicing release of Windows Server. Oh, and maybe Microsoft has realized that not everything is in the cloud, and giving attention to Server is important.

Active Directory -- a Very Old Dog Learns New Tricks
I remember reading books (remember those?) back in 1999 on Active Directory (AD) before it was released in Windows Server 2000. Just turning 25, AD has a whole slew of new tricks, such as Non-Uniform Memory Access (NUMA) awareness. Modern servers have oodles of memory and often multiple sockets of CPUs, but not all CPUs have high speed access to all of that memory, instead being divided into NUMA nodes. So perhaps one socket with 12 cores has fast access to 64GB of memory (or 128, or 256, depending on the hardware), and slower access to the rest. This means that if you're running a server application such as an old version SQL Server that's not NUMA aware, you're going to get "weird" performance, but a newer application knows how to adapt to the underlying hardware. The same is true for virtual machines (VMs) as both Hyper-V and VMware can project the underlying configuration into VMs, so they too know how to adapt.

AD in Windows Server 2025 is NUMA-aware, which should bring serious performance improvements, useful in large environments (one company mentioned has 1,200 DCs and a database file in the hundreds of GB size).

Speaking of databases, the new version comes with a new page size, which has been 8KB since the first version, now they can be 32KB. If you're upgrading an existing forest, each new 2025 DC will use 8KB pages until they're all upgraded, after which you manually make the switch using the Enable-ADOptionalFeature PowerShell cmdlet.

There's improved attribute security and auditability, and the Lightweight Directory Access Protocol (LDAP, the language applications use to talk to AD) lets you enforce channel binding support to stop replay attacks of communication. LDAP now prefers encryption and also supports Transport Layer Security (TLS) 1.3. Changing passwords remotely using legacy protocols is blocked, and computer account passwords are now blocked from using any part of the computer name in the password. The encryption used in Kerberos can now be quantum safe, and they've got rid of RC4 and MD5 which should reduce Kerberoasting attacks.

The DCLocator service (which does exactly what it says on the tin) is deprecating another ancient protocol (think MS-DOS era): Mailslots. Good riddance.

These enhancements come in the new Domain and Forest Functional Level (DFL, FFL) version 10 (called Windows Server 2025), the last new one was version 7 in Windows Server 2016.

Delegated Managed Service Accounts
Service accounts are a necessary evil in both AD and Entra ID (where the security risks are solved with Managed Identities). You have an application (database, a Backup program, a custom batch script) that needs to run on a server or servers. Back in the day, you simply created a user account, gave it the right permissions (in some cases Domain Admin, because that always works) ticked the box for password never expires and then forgot about it. Until attackers compromised the account and used it to move laterally amongst your servers.

Some versions ago we got Managed Service Accounts, which did use long random password, that were rotated automatically by AD but could only be used on one server. This was followed by Group Managed Service Accounts (gMSA), which could be used anywhere in the domain and applications such as Defender for Identity used them. However, they required the application to be written to take advantage of them (something I discovered when a client wanted to deploy a smart card app on their DCs, which only supported ordinary accounts).

Migrating an Existing Service Account to dMSA
[Click on image for larger view.] Migrating an Existing Service Account to dMSA

The new Delegated Managed Service Accounts (dMSA) fixes these problems. Take an existing service account, "upgrade" it in a two-step process to a dMSA, and the application keeps running wherever it is, but under the hood there's no longer a password associated with it, instead it uses keys that are managed and rotated by AD.

Burying NTLM
There's no doubt that maintaining backwards compatibility is why Microsoft's products are in every corporate datacenter on the planet. But this also means carrying some serious security baggage from a long time ago -- I watched at least two presentations where it was stated that this focus on compatibility will be changed in favor of stronger security.

Nowhere is this more evident than in the deprecation of the venerable NTLM (that's "New Technology Lan Manager" for you young Padawans, NT being really old, and Lan Manager being positively ancient). This is a comprehensive effort, not just in server, but also in the Windows client. It's a four-part approach: IAKerb, Local KDC, TryIPSpn and move to negotiate.

IAKerb is an extension to Kerberos that allows a client that doesn't have line-of-sight connectivity to a Domain Controller (a remote worker for example) to authenticate through a server that does have connectivity.

Local Key Distribution Server (KDC) uses the local Security Account Manager (SAM) to allow remote authentication of local accounts over Kerberos rather than NTLM. Service accounts in domains can be associated with one or more DNS host names (Service Principal Names, SPN) and if you use that when authenticating, Kerberos is used, but if you use an IP address, it falls back to NTLM. No more though, Windows Server 2025 allows you to associate IP addresses with service accounts, so they'll use Kerberos instead.

The final approach is for Windows components and third-party apps that are hardcoded to use NTLM, even when both ends support Kerberos, by moving the configuration to Negotiate; NTLM won't be used. This is of course the long tail, both in Windows (one presenter spoke about "reduced usage" of NTLM in Windows Server 2025, another of the same in System Center), but I'm sure it'll take time to clean up the old code. Just like was done for applications that insisted on SMB v1, there's going to be a list of applications that insist on using NTLM in an effort to name and shame them.

SMB Is King
The file sharing protocol in Windows: Server Message Block (SMB) is going from strength to strength. This version now turns signing on by default (to stop attackers in the middle), the ability to control which particular versions ("dialects") of SMB you allow and the option to change which port number is used for SMB. In earlier versions, when you enabled file sharing, several default Windows Firewall rules were enabled (some that are so legacy they're not even used by SMB anymore). This has been fixed in Windows Server 2025.

There's now a two-second delay when you enter the wrong password until you can try again, which shouldn't impact a normal sleepy user on a Monday morning but will considerably slow down automated brute force attempts.

One cool feature that Microsoft has been dribbling out over the last few versions is SMB over Quick UDP Internet Connections (QUIC, being an alternative to TCP that uses TLS 1.3 for security). In essence you get a secure tunnel from your Windows (or Android) client directly to an SMB file share over the internet, without using a VPN. In previous versions it was only available in the special "Azure Edition" of Windows Server, and you could only run it in Azure (later on also on Azure Stack HCI), it's now available in all editions of Server: Standard, Datacenter and Azure Edition.

Hotpatching Is So Hot Right Now
Hotpatching is another feature that's been available only in certain versions that is now coming to all versions of Windows Server. This is another inheritance from Azure where millions of Hyper-V servers are patched with updates without requiring a restart. There's a cycle to it, so say starting in January you'll install a baseline update, which will require a reboot, but for the February and March patch Tuesdays you simply apply the hot patch (which only has security fixes in it) while the server is running (using your favorite method, WSUS, Intune, third party). This is followed by another baseline update in April, containing both security and other bug fixes, so you've gone from 12 restarts a year, to four. Because the patches are memory only, they're also wicked fast compared to normal patches.

In Windows Server 2022 and 2025 Azure Edition this is included at no extra cost. Windows Server 2025 Standard and Datacenter editions on-premises or in a third-party cloud need to be Arc connected, and there's a small monthly fee.

Storage -- Security and Blistering Speed
I last covered Confidential Computing here, so I won't go over the basics here, but essentially this is using hardware support (in AMD and Intel CPUs) to protect data as it's being processed, not just at rest (Bitlocker) or in transit (TLS). You can use this both in on-premises servers, and in Azure (and other clouds), as long as the right hardware is in place.

Turns out that if you have OS disks for confidential compute hosts that are NTFS-formatted, replay attacks using older disk snapshots are possible, bypassing Secure Boot. Now you can use the ReFS file system, which gives you SHA 256 checksums for both file and meta data. In combination with UEFI and measured boot you get roll back protection.

For performance there's a completely rewritten driver for NVMe access, providing up to 70 percent speed boost. For those with deep pockets, NVMe storage over Fabrics (NVMe-oF), connecting to remote super-fast storage support is coming after the release of Windows Server 2025 in the form of a built in initiator.

Deduplication Running on an S2D Cluster
[Click on image for larger view.] Deduplication Running on an S2D Cluster

The ReFS file system supports deduplication and compression (both or either), and you can tune your repair / resynchronization jobs when a disk has failed with five levels of either faster rebuilds or better workload (VM) performance in Storage Spaces Direct clusters. And you can convert fixed size volumes into thinly provisioned ones.

GPUs for Everyone
Graphical Processing Units (GPUs) are the new hotness (see exhibit A -- Nvidia stock price) as every tech company are using them for their AI workloads, and some people even want to use them for you know -- faster graphics processing in their remote desktop workloads.

Graphics Workload in VMs During Live Migration
[Click on image for larger view.] Graphics Workload in VMs During Live Migration

Once upon a time (Windows Server 2016 and earlier) there was RemoteFX, a technology to share GPUs amongst VMs, but it was deprecated in Windows Server 2019 due to a security flaw in the design. Azure Stack HCI has its successor, GPU partitioning (GPU-p), coming to Windows Server 2025, where you can divide up the memory and processing power of a GPU amongst several VMs, either for remote desktop users or machine learning inference workloads. Only certain Nvidia GPU models are supported, and only with supported drivers. And if you have VMs with assigned GPUs, you can also Live Migrate them from host to host, while they're running, using GPU Pooling.

Failover Clustering
Upgrading from Windows Server 2012 R2, 2016, 2019 and 2022 to 2025 is possible using Feature Update -- just like you can upgrade Windows 10 to 11 in the Settings app. Before you start hyperventilating, you can control the availability of this using Group Policy settings. For clusters you can use the built in Cluster Aware Updating (CAU) to do a rolling upgrade of a cluster.

Storage Spaces Direct (S2D) brings "campus clusters," so you can have nodes in separate buildings. Currently that's four copies of your data on two nodes, or three mirrored copies on four nodes (two in each building). Coming are four copies on two, four and six nodes.

A lot of work has gone into software-defined networking (SDN), which as you can probably guess inherits a lot of functionality from the same stack in Azure's public cloud with Network Security Groups (NSGs) supported for isolation of workloads. There's now tag-based application (a bit like Application Security Groups in Azure) so that you can tag all SQL Servers or Web servers, and they'll automatically get the right NSGs applied. SDN in multisite configuration now supports layer 2 connectivity, and policies follow VMs as they're migrated between sites.

Selecting a Network Security Tag when Creating a New Web Server
[Click on image for larger view.] Selecting a Network Security Tag when Creating a New Web Server

Interestingly the Network Controller feature (the "brain" of SDN in Hyper-V) has been migrated from running in VMs on the cluster itself (taking up resources, and quite a long time to spin up new ones), to a Failover Cluster role.

New Default Networking Policies lets you assign either an existing NSG when you create a new VM, or lets you define which ports should be open (only RDP for example), which will create and assign a default NSG, protecting the VM even before the OS firewall has been enabled. Rotating certificates for the various SDN roles are now automated using PowerShell and the capabilities of Network ATC (Azure Traffic Controller) have been expanded. It'll automatically name clusters, lets you copy cluster settings from a (test) environment to a production cluster and use the intent based networking pioneered in Azure Stack HCI which is coming to Windows Server 2025 SDN. Instead of manually configuring each NIC and virtual NIC in a cluster to be used for storage, cluster / workload, or management traffic, you simply define the intent of a set of NICs and it configures all of them for you, including assigning IP addresses automatically.

For troubleshooting Azure Stack HCI brings the Network Heads Up Display (HUD) into Windows Server, which alerts you to issues. Examples include PCIe oversubscription -- a NIC with 2 x 100 Gbps ports in a PCI slot which doesn't support 200 Gbps, for example -- or a flapping connection that goes up and down intermittently. Learn more about Hyper-V SDN here.

But Wait, There's More
You want scale? Hyper-V now lets you create a single VM with 240TB (yes, 240,000 GB) of memory, and 2,048 CPU cores, provided you have the hardware.

There are many more, smaller, new features coming that I haven't covered, and it's actually looking like Windows Server 2025 has received the attention that it deserves -- well done Microsoft. If you want to play with the preview -- enroll in Windows Server Insiders here.


Subscribe on YouTube