Table of Contents
Windows Server remains the backbone of many EUC environments, whether it is hosting session-based workloads, published applications, or the supporting infrastructure around a virtual desktop deployment. With Windows Server 2025 now generally available, and Windows Server 2019 approaching the end of its extended support window in January 2029, many organizations are planning their migration path. For the EUC community, the recurring question with every new Server release is the same one asked of every new client OS; what does the newer version cost in terms of resource consumption?
This GO-EUC research compares Windows Server 2019, 2022, and 2025 side by side as session hosts, each running an identical 14-user knowledge worker workload, to measure how the resource footprint of the operating system has evolved across the three releases under a realistic multi-user load.
Three releases, three generations of Windows
Although all three operating systems carry the Windows Server name, they are built on very different foundations. Windows Server 2019 is based on the Windows 10 1809 codebase, Windows Server 2022 on the Windows 10 21H2-era codebase, and Windows Server 2025 on the Windows 11 24H2 codebase. Each generational jump brings not only new features, such as hotpatching, SMB over QUIC, and improved storage performance in Server 2025, but also the accumulated services, security capabilities, and background activity of a newer Windows core.
The results in this research reflect the following fully updated builds at the time of testing:
- Windows Server 2019 - Version 1809 (OS Build 17763.9020)
- Windows Server 2022 - Version 21H2 (OS Build 20348.5386)
- Windows Server 2025 - Version 24H2 (OS Build 26100.32995)
Setup and scenarios
In this research, Login Enterprise is used to generate a consistent user load, running the standard Knowledge Worker 2022 workload. This workload simulates a typical office user working with applications such as Microsoft Office and the Microsoft Edge browser, which is also used for viewing PDF documents, making it representative of the average knowledge worker profile.
The following three scenarios are part of this research:
- Windows Server 2019
- Windows Server 2022
- Windows Server 2025
Each scenario runs as a single virtual machine on Nutanix Community Edition (CE), which uses the KVM-based AHV hypervisor (AOS 6.8.1 and VirtIO 1.2.5). The host is equipped with two AMD EPYC 7551 32-core processors, 512 GB of memory, and all-NVMe storage. Each virtual machine is configured with 8 vCPUs, 32 GB of memory, and a 64 GB disk. During each test, 14 users connect to the virtual machine over RDP and run the knowledge worker workload concurrently. The sessions are launched at an interval of 30 seconds per user, so the full logon phase takes approximately seven minutes. Once all users are logged on, the workload runs in steady state for 30 minutes, followed by the logoff period.
One thing this research deliberately does not measure is the maximum user density of these operating systems. The 14-user load is a fixed, moderate load chosen to compare the three versions under identical multi-session conditions, not to push any of them to their limits. Determining how many users each version can ultimately support on a given host would require a dedicated capacity test, which remains a good candidate for follow-up research.
To ensure consistent and reliable results, Microsoft Defender is completely disabled so it does not influence the benchmark results. Please note that this is not considered a best practice in a production environment, but it is a common approach in benchmarking scenarios where the goal is to isolate and measure the impact of a specific component or configuration change. Windows updates are disabled once each machine is brought up to the build level listed above, so no patching activity can interfere during the test runs. Office updates are also disabled, after earlier test runs revealed background update activity heavily skewing the storage results; this is covered in more detail later in this article. Beyond the Remote Desktop Session Host role required to support multiple concurrent sessions, no additional services or roles are installed, and a power plan is applied to keep each virtual machine always on and running during the test runs.
Apart from the Windows Server version, all hardware, software, benchmark settings, and virtual machine configurations remain identical throughout the research.
During each benchmark run, telemetry is collected from the virtual machine, including CPU utilization, memory usage, disk reads and writes per second, disk queue length, and the number of running processes.
Hypothesis and results
Given that each release is built on a progressively newer Windows codebase, a gradual increase in resource consumption is the reasonable expectation; each generation ships with more services, more security features enabled by default, and a heavier desktop experience. With 14 active sessions, the workload itself is expected to dominate the resource profile, so the interesting question is how much of the generational overhead remains visible once the machine is under a realistic load. Equally relevant is whether the step from 2022 to 2025, the migration most organizations currently face, is larger than the step from 2019 to 2022.
Let’s start with the CPU utilization from the virtual machine perspective.
The line chart shows the expected shape of a session ramp-up, CPU activity climbs during the roughly seven-minute logon phase as the 14 sessions arrive at 30-second intervals, and then settles into a steady state once all users are active. The averages follow the generational pattern of the hypothesis; Server 2019 averages 16.5%, Server 2022 averages 18.9%, and Server 2025 averages 20.2%. In relative terms, Server 2025 consumes roughly 22% more CPU than Server 2019 to run the exact same 14-user workload, although the step from Server 2022 to 2025 is a more modest 7%. The peaks, which occur during the logon phase, climb from 34.3% on Server 2019 to 47.4% on Server 2022 and 45.9% on Server 2025. With averages around 20% on 8 vCPUs there is still plenty of headroom in all three scenarios, but the gap between the versions represents capacity that is spent on the operating system rather than on user sessions.
The memory footprint shows the same generational growth.
The average memory usage increases from 39.6% on Server 2019 to 40.9% on Server 2022 and 44.4% on Server 2025. On a 32 GB virtual machine that translates to approximately 12.7 GB, 13.1 GB, and 14.2 GB respectively. The peak values, reached once all 14 sessions are active, tell the same story, 52.7% (16.9 GB) on Server 2019, 54.1% (17.3 GB) on Server 2022, and 60.7% (19.4 GB) on Server 2025. In practical terms, hosting the same 14 users on Server 2025 requires roughly 2 GB more memory at peak than on Server 2022, and about 2.5 GB more than on Server 2019. For session host sizing this is arguably the most important number in this research. While CPU is usually the first constraint on session host density, memory deserves extra scrutiny at the moment; with the current global memory shortage driving up prices, every gigabyte claimed by the operating system carries a real cost, and the difference measured here is memory that is simply no longer available for additional sessions.
The next charts zoom in on the storage perspective.
Storage is the one area where the three versions are effectively equal. The line charts show the same pattern on all three; read activity is concentrated in the logon phase, as applications are loaded for each new session, and drops off to almost nothing once all users are in steady state, while write activity consists of short bursts spread across the entire run. The write peaks do grow with each newer release, from 460 per second on Server 2019 to 675 on Server 2025, but these are brief bursts rather than sustained load, and no version stands out from the others in the overall picture. Unlike CPU and memory, storage activity under a multi-user workload is dominated by the sessions themselves, and the generational OS overhead disappears into the noise.
The current disk queue length, the number of I/O requests waiting to be serviced by the disk at any given moment, confirms that the storage subsystem is never under sustained pressure during the tests. The averages are well below one outstanding request for all three versions, although Server 2025 averages roughly double the other two and records a noticeably higher peak of 20.1. These spikes all occur during the logon phase in the first minutes of the test, when Server 2025 briefly queues considerably more I/O than its predecessors. On the all-NVMe storage used in this research the spikes are absorbed without any measurable effect, but on shared or slower storage platforms a heavier logon storm is worth accounting for, especially when many session hosts boot or accept logons simultaneously.
Chasing an anomaly: SDXHelper
The clean disk queue results above were not achieved on the first attempt. In an earlier round of testing, the disk queue length on Server 2022 and Server 2025 told a very different story.
Where Server 2019 behaved as expected with an average queue length of 0.174, Server 2022 and Server 2025 sustained averages of 12.2 and 10.1 respectively, with peaks above 29 outstanding requests, for large parts of the run. A sustained queue of this depth means the operating system was continuously generating more I/O than it was completing, which is a level of storage pressure the 14-user workload alone cannot explain.
Analyzing the per-process disk counters of the affected runs identified the culprit - SDXHelper.exe, the Microsoft Office SDX Helper. This background process is launched by the Office Feature Updates scheduled task, which downloads and installs feature updates for Microsoft 365 Apps. Because the accompanying Office Feature Updates Logon task fires when a user logs on, a load test that logs 14 fresh sessions onto a session host is an ideal trigger for it.
The chart above shows the I/O generated by SDXHelper alone during one of the affected Server 2025 runs. The process averaged 111 write operations per second across the run, with bursts above 2,500 operations per second. To put that into perspective, that single background process generated more write activity on its own than the entire virtual machine, workload included, averaged in the final test runs. After Office updates were disabled, the anomaly disappeared completely and the disk queue returned to the near-zero values shown in the results above.
Beyond restoring a fair comparison, this anomaly is a finding in its own right. In a production session host environment, update mechanisms such as this one run during working hours on machines shared by dozens of users, and they do not appear in any sizing calculation. It is a good reminder of why images for session-based workloads are typically optimized to disable background update tasks, and why per-process telemetry matters when a benchmark result looks off.
A metric that was not part of previous comparisons is the number of running processes, which provides a good indication of how much background activity each operating system generation brings along.
Before the first user logs on, all three versions idle at a comparable 87 to 91 processes. Once the 14 sessions are active, the differences become clear, Server 2019 peaks at 498 processes, Server 2022 at 522, and Server 2025 at 591. That works out to roughly 29 processes per session on Server 2019 versus approximately 36 on Server 2025. Each of those additional processes carries its own memory working set and scheduling overhead, which aligns with the higher memory and CPU figures measured above, the growth is not one heavyweight component, but an accumulation of extra per-session services and background activity in each newer Windows core.
Conclusion
This comparison confirms the expected generational trend under a realistic multi-user load, each newer Windows Server release carries a heavier resource footprint than its predecessor when hosting an identical 14-user knowledge worker workload. Windows Server 2025 consumes roughly 22% more CPU on average than Server 2019 and needs roughly 2 to 2.5 GB more memory at peak, with Server 2022 sitting between the two on both metrics. Storage behavior is effectively identical across the versions, with the workload rather than the operating system driving disk activity, although Server 2025 shows a noticeably heavier logon phase in the disk queue. The process count makes the underlying cause visible, Server 2025 runs roughly 90 more processes than Server 2019 with the same 14 users active. The research also produced an unplanned finding, a single Office background update process, SDXHelper, was able to keep the disk queue of an entire session host saturated during earlier test runs, a useful reminder that image optimization for session-based workloads is as relevant as ever.
For EUC architects and administrators planning a migration, the practical takeaway is in the sizing. The step from Server 2022 to Server 2025, the migration most organizations currently face, costs around 7% additional CPU and roughly 2 GB of additional memory at peak for the 14-user load measured here, and that overhead scales with the number of session hosts in the estate. A like-for-like replacement of session hosts may therefore support fewer users per host, or require slightly larger virtual machines to maintain the same density. Depending on where the underlying hosts are in their hardware lifecycle, it may make sense to combine the migration with a hardware refresh, the per-core performance gains of a newer CPU generation may absorb the additional OS overhead and preserve, or even improve, the existing user density.
As this research uses a fixed 14-user load, the maximum achievable density on each version remains to be proven. A dedicated capacity test comparing Server 2022 and Server 2025 as session hosts would be the logical follow-up, and given that Server 2019 leaves extended support in January 2029, it is a question many organizations will need answered sooner rather than later.
Finally, don’t take these numbers as directly applicable to your own environment. They come from one workload, on one hardware platform, with one specific configuration. Your applications, images, and hardware will shift the results, so do your own testing before committing to a sizing or migration decision.
Question to our readers Are you planning to move your session hosts directly from Windows Server 2019 to Server 2025, or are you taking the intermediate step via Server 2022? And does OS resource overhead factor into that decision, or is it driven purely by support lifecycles?
Photo by Scott Rodgerson on Unsplash
