How Much Server Do You Actually Need?

Size a server from measurement, not from a vendor minimum or a user count. Collect CPU, memory commit, disk latency and network throughput on the existing workload across at least one full business cycle including month-end, then size against observed peak plus growth headroom. Published minimums tell you what will boot, not what will perform.

Microsoft’s hardware requirements documentation for Windows Server declines to publish recommended specs, saying the diversity of potential deployments “makes it unrealistic to state recommended hardware requirements that would be applicable,” and directs admins to run test deployments instead.

Read that again if you’ve been handed a quote justified with “this meets Microsoft’s requirements.” It meets the floor, and the floor is low. Microsoft’s published requirements put the Windows Server 2025 minimum at 2 GB of RAM for Server Core and 2 GB for Server with Desktop Experience, with 4 GB recommended; the same page gives Windows Server 2022, 2019 and 2016 a Microsoft’s hardware requirements page lists 1 GB Server Core minimum. Those numbers exist so setup completes. Nobody runs a business on them.

Where the published requirements do bite is compatibility, hardest when someone reuses existing hardware. Microsoft’s stated processor minimum is a 1.4-GHz 64-bit processor supporting NX and DEP, CMPXCHG16b, LAHF/SAHF, PrefetchW and Second Level Address Translation — and for Windows Server 2025 it adds SSE4.2 and POPCNT, which rules out a lot of older silicon.

Named users is the number everyone reaches for because it’s the number everyone knows. On its own it’s a weak proxy: it says nothing about concurrency, nothing about what those users are doing, and nothing about the batch jobs, backups and integrations that generate load with no human attached.

Where Microsoft does publish a per-user figure, it is role-specific. Its Active Directory Domain Services capacity planning guidance gives a working-environment starting point of 40 KB to 60 KB of database for each user and 1,000 concurrent users for each core. Useful for a domain controller. Meaningless for your ERP database.

Shared session hosts are the other role with published density. Microsoft’s session host sizing guidelines for Azure Virtual Desktop and Remote Desktop Services put the maximum users per vCPU at 6 for light workloads, 4 for medium, 2 for heavy and 1 for power users. Even those, Microsoft says, “are generic guidelines, and you should only use them for initial performance estimates” — to be refined by a pilot under gradually increasing load, or a simulated load test. Our Azure Virtual Desktop work starts from that kind of pilot.

Start with the counters Microsoft names in that same Active Directory guidance: Processor Information(_Total)\% Processor Utility for CPU, and Avg Disk sec/Read and Avg Disk sec/Write on the drive holding the NTDS database. The names are role-specific; the discipline transfers to any workload. Collect four things on the server you already have.

• CPU — peak, not average. A comfortable daily average hides the month-end close that pins the processor. Microsoft’s Active Directory capacity planning guidance recommends targeting “a peak period CPU between 40% and 60% of system capacity,” and sets 60% as its warning threshold.
• Memory — working set, not installed. Track committed bytes against the commit limit across a full business week, month-end included, then size to observed peak commit plus headroom.
• Storage — latency first. The same guidance sets a target of 10 ms and a warning threshold of 15 ms for average read and write latency on the NTDS database drive — a latency target, not an IOPS target. Size to hold latency down under load, not to hit an IOPS number somebody quoted.
• Growth rate. A couple of historical data points beat any assumption. Measure the rate your data has actually been growing, then extend the line to the end of the intended service life.

The window matters as much as the counters. Microsoft is specific: sample intervals for Network Interface counters “should be either 15, 30, or 60 minutes,” because “anything less is too volatile for good measurements, and anything greater excessively smooths out daily peaks.” Sample too coarsely and the month-end peak flattens into a line that looks fine.

Cores do not scale linearly. Microsoft’s session host sizing guidance puts the scaling factor “typically” between 1.5 and 1.9, and says running on virtual machines “can incur a 15-20% capacity cost compared to bare metal, based on internal testing,” with user response times 10% to 20% higher. Size from a bare-metal benchmark, deploy virtual, and that overhead comes off the top.

Past a point, more cores make things worse. The same guidance says to limit multi-session VM size to between 6 vCPUs and 24 vCPUs, noting that synchronization overhead climbs with core count and that “user experience is better with two 16-core VMs instead of one 32-core VM.” More, smaller hosts beat fewer, larger ones — far cheaper to decide before provisioning than after.

Then verify after deployment, not just before it. The same Microsoft guidance frames the bar as user expectation: “users generally expect a response time of less than 200 milliseconds for their actions, and any delay beyond that can lead to a degraded user experience.”

Provisioning is where it pays. Moving a workload to hosted infrastructure means specifying vCPU, RAM and disk tier as line items, and a workload sized from real counters behaves in production the way it did in testing. The same pass applies on premises with managed server infrastructure, during a migration, or building out Azure, and it feeds backup and recovery targets, disaster recovery capacity and business continuity planning downstream.

How much RAM does a Windows Server actually need?

There is no published answer, by design. Microsoft’s hardware requirements documentation for Windows Server says the diversity of potential deployments “makes it unrealistic to state recommended hardware requirements that would be applicable.” Its published minimums are install floors: Microsoft puts the Windows Server 2025 minimum at 2 GB of RAM for Server Core, with 4 GB recommended. Measure committed memory against the commit limit and size to observed peak.

How long should I collect performance data before sizing a server?

Long enough to capture your worst day: at least one full business cycle including month-end close, payroll and scheduled batch reporting. Microsoft’s Active Directory capacity planning guidance is specific — sample intervals for Network Interface counters “should be either 15, 30, or 60 minutes,” because “anything less is too volatile for good measurements, and anything greater excessively smooths out daily peaks.”

Does moving to a virtual machine change how much CPU I need?

Yes, and not by a rounding error. Microsoft’s session host sizing guidance puts the CPU scaling factor “typically” between 1.5 and 1.9 rather than linear, and says virtual machines “can incur a 15-20% capacity cost compared to bare metal, based on internal testing,” with response times 10% to 20% higher.

Should I size storage by IOPS or by latency?

Latency is the number that maps to what users feel. Microsoft’s Active Directory capacity planning guidance sets a target of 10 ms and a warning threshold of 15 ms for average read and write latency on the NTDS database drive — a latency target, not an IOPS target. Measure latency on the production volume and pick a tier that holds it down at your peak.

If you would rather not run the measurement pass yourself, that is a good place to start a conversation. We bring 20+ Years Experience sizing and provisioning workloads for Texas businesses, with 100% Texas-Based Support during business hours plus after-hours emergency support, and automated monitoring on the counters around the clock once the workload is live. Talk to us about managed IT services before your next server purchase.