About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A farm is not adequately sized just because today's users fit across all its hosts. Decide whether it must support the same workload while one host is unavailable, and whether morning sign-ins or returning sessions create a different peak from normal application use.
This article builds a capacity worksheet for those decisions. For inventory and counter-collection instructions, use the existing Windows and RDS measurement guide; the question here is how to turn workload evidence into a per-host operating limit and maintenance plan.
Separate the workload cohorts
Group users by what they actually do, not merely job title. An order-entry session may stay small; a reporting session may open large datasets and create bursts of CPU and temporary files. Include the maximum expected concurrent users in each group, the applications open together and important events such as payroll or monthly reporting.
Microsoft's session-host tuning guidance estimates memory as operating-system overhead plus memory per session multiplied by sessions. It identifies private session memory as important and notes that genuinely shared code/data pages need only one copy. Simply adding every process working set can count shared pages more than once. Conversely, assuming all application memory is shared understates private data and document use.
Use measured incremental memory under representative load to estimate each cohort. Keep the operating system, shared components and monitoring/security agents in a separate base allowance. Reconcile the result against actual host commitment, resident-memory pressure and paging; it is a model, not a substitute for observing the host.
An illustrative memory worksheet
Every number below is invented to explain the arithmetic. None is a benchmark, a vendor minimum or a NetLeverage capacity promise.
Assume 48 concurrent users: 36 order-entry users and 12 reporting users. For this example only, measured-like planning inputs are 0.6 GiB private demand per order-entry session, 1.5 GiB per reporting session and 8 GiB of base/shared demand on each host. The host has 40 GiB RAM, and the planner reserves 8 GiB for variability, leaving a 32 GiB planning budget.
| Placement | Users on each remaining host | Estimated demand per host | Compared with 32 GiB budget |
|---|---|---|---|
| Three hosts, balanced normal use | 12 order-entry + 4 reporting | 8 + 12 × 0.6 + 4 × 1.5 = 21.2 GiB | Within the illustrative budget |
| One of three hosts unavailable | 18 order-entry + 6 reporting | 8 + 18 × 0.6 + 6 × 1.5 = 27.8 GiB | Within the illustrative budget |
| Two-host farm with one unavailable | 36 order-entry + 12 reporting | 8 + 36 × 0.6 + 12 × 1.5 = 47.6 GiB | Exceeds both budget and installed RAM |
This suggests a three-host candidate for the stated memory assumptions. It does not prove that three hosts are sufficient: CPU, storage, profile access and application licensing may impose lower limits. A reporting-heavy placement can also exceed the model even if the total session count seems reasonable. The even distribution in the table is an assumption to validate, not a promise that the broker recognises workload intensity.
Test three operating states
First, assess steady use at the expected cohort mix. Second, assess a morning arrival window with profile loading and application startup. Microsoft notes that creating sessions can be CPU intensive. Third, assess one-host maintenance: drain users through an agreed process and run the required mix on the remaining hosts in an isolated test.
Distinguish a brief client-network interruption from a host failure. The Connection Broker reconnects users to an existing session on its original host when that session still exists. It does not move that running session's memory to a different server. If a host is unavailable, fresh sessions may need to load profiles and reopen applications elsewhere; spare capacity is not seamless failover or preservation of unsaved work.
For each state, record task correctness, failures, elapsed user-visible time, peak resource use and the remaining operating margin. Include the worst credible workload mix rather than multiplying one idle session by the headcount.
Decide the admission limit
Set the supported per-host session limit from the most restrictive successful test, then document what happens when that limit is reached: defer maintenance, add capacity or limit admissions through the supported deployment controls. Do not silently replace the full-service requirement with degraded performance during patching.
If used as supporting evidence, User Input Delay is supported on Windows Server 2019 or later. Process instances identify session and process; session instances summarise that session, and each sample reports maximum queued-input delay for its interval. A low value does not exclude later application, database or storage work, nor client/network presentation delay. On Server 2016 or with missing counters, record that measurement as unavailable.
No capacity or maintenance test was performed for this article. The worksheet is an editorial planning example requiring application-specific validation.
Related service: ThinPoint remote access.
This article was originally published on .