Terminal Server Calculator

There is no single answer to 'how many users fit on a terminal server', which is exactly why people search for a calculator. Density depends on what the users actually do, how much memory each session holds, how many cores the host has, and whether the box is virtualized. Change any one of those and the answer moves by a factor of three.

This calculator works it out from Microsoft's published session host sizing guidance for Remote Desktop Services and Azure Virtual Desktop, which gives a maximum users-per-vCPU for four workload classes rather than a single number. Enter your user count, pick the workload, describe the host, and you get users per host, session hosts required, total vCPU and RAM, profile storage, peak bandwidth, and what the farm costs to run.

Two things separate this from the wattage-adder style of terminal server calculator.

It reports the binding constraint. A session host carries whichever is smaller: the users its CPUs can keep responsive, or the users its memory can hold. On most real builds memory runs out first, often long before CPU does. A calculator that only multiplies cores by users-per-core will happily tell you a 16 vCPU / 32 GB host carries 64 medium users. It carries 14. The chart below shows both ceilings side by side and marks which one binds.

It models sublinear core scaling. Doubling the cores does not double the users. Microsoft measures a scaling factor of roughly 1.5 to 1.9 per doubling because synchronization overhead grows with core count, which is why their guidance caps a session host at 16 to 24 vCPUs and recommends more, smaller hosts instead of fewer, larger ones.

Users per host = min(CPU ceiling, memory ceiling) × (1 − headroom)

The two ceilings:

CPU ceiling = users_per_vCPU × 8 × (vCPU_effective ÷ 8) ^ log2(scaling_factor)
memory ceiling = (host_RAM − OS_reserve) ÷ RAM_per_user
vCPU_effective = vCPU × (1 − virtualization_overhead)

The exponent is what makes core scaling sublinear. At the 8-vCPU reference point the CPU ceiling equals the simple users-per-vCPU multiplication. Above it the curve bends away: at a 1.7 scaling factor a 16-vCPU host delivers about 15% fewer users than linear arithmetic suggests, a 32-vCPU host about 28% fewer, and a 64-vCPU host about 39% fewer. That is the mathematical form of Microsoft's advice to keep session hosts small.

Everything else follows:

concurrent users = named users × peak concurrency
hosts needed = ceil(concurrent users ÷ users per host)
hosts deployed = hosts needed + redundancy spares
physical cores = (hosts × vCPU ÷ oversubscription) ÷ threads_per_core
profile storage = named users × profile size
peak bandwidth = concurrent users × per-session bandwidth

Note that profile containers are sized against named users, not concurrent sessions. Someone who is signed out still has an FSLogix container on disk. Everything else scales with concurrency.

Workload classes

The users-per-vCPU figures are Microsoft's, from their multi-session sizing table:

• Light, 6 users per vCPU. Data entry, line-of-business apps, command-line work.
• Medium, 4 users per vCPU. Office apps, static web, consultants and researchers.
• Heavy, 2 users per vCPU. Outlook, Teams, dynamic web, software development.
• Power, 1 user per vCPU. CAD, CAM, photo and video editing, machine learning.

Memory, profile and bandwidth per user are the conventional planning values that sit alongside those figures, since Microsoft publishes a minimum VM size rather than a per-user memory number. All of them are editable.

Headroom and redundancy

Two different safety margins, and both matter. Headroom holds back capacity within each host for logon storms; signing in is CPU-expensive, and a farm that comfortably serves 200 steady sessions can fall over when 200 people arrive at 09:00. Redundancy adds whole spare hosts so a failure does not overload the survivors. N+1 is the usual minimum; the calculator reports what capacity remains with one host down.