The problem
Remote Desktop Services (RDS) degrades quietly. Users do not file a ticket that says "the session broker is unbalanced." They say "it's slow today." By the time complaints reach the help desk, the cause is usually structural: undersized session hosts, a broker routing everyone to one server, or a profile-loading bottleneck at logon.
Technical explanation
An RDS farm has a few moving parts that each have their own failure mode:
- Session hosts carry the user load. CPU and, more often, memory and disk I/O are the constraints.
- The connection broker decides which host a new session lands on. If load balancing is misconfigured, sessions pile onto one host.
- User profiles (roaming, FSLogix containers) load at logon. Slow profile storage shows up as slow logons, not slow apps.
- Licensing and the gateway rarely cause performance issues but cause hard failures when misconfigured.
Best practices
- Size hosts for the workload, not the headcount. A task worker and a CAD user are not interchangeable. Profile representative users and measure real CPU/RAM per session before scaling.
- Verify broker load balancing. Set relative session-host weights and confirm new sessions actually distribute. A broker silently favoring one host is the most common cause of "random" slowness.
- Put profiles on fast storage. FSLogix containers on slow SMB shares are a classic logon bottleneck. Low-latency storage matters more than raw capacity here.
- Cap sessions per host. Set a maximum so one host cannot be overloaded past the point of usability.
- Monitor the right counters. Track per-host active sessions, processor queue length, available memory, and average logon time, not just CPU percentage.
A real-world example
In one farm, users reported intermittent slowness with no obvious cause; host CPU looked fine on average. Per-host session counts told the real story: the broker was routing the large majority of new sessions to two hosts while others sat nearly idle. The relative weights had drifted after a rebuild. Correcting the broker weights and adding a per-host session cap evened the distribution, and the "random" slowness disappeared, without buying a single additional server.
Conclusion
RDS performance is a balance problem before it is a capacity problem. Measure per-session resource use, confirm the broker is actually balancing, keep profiles on fast storage, and monitor logon time as a first-class metric. Most RDS slowness is a distribution or profile issue, not a missing server. Finding that out first saves real money.