We're seeing increasing memory exhaustion across several full-session RDS farms. The environments include Windows Server 2019, 2022, and 2025, and the biggest contributors appear to be Microsoft Office, Chrome or Edge, Teams, and WebView2. These are traditional desktop sessions rather than published individual applications. What memory-per-user numbers are people using today, and what practical steps help reduce consumption? Is the main answer simply enforcing better browser tab hygiene, or are there configuration and policy changes that make a meaningful difference?
4 Answers
Browser workloads are often better kept on the user's local computer when they don't need access to internal data. Local browsers can use the endpoint's GPU, while running Chrome or Edge inside an RDS session adds a lot of memory pressure. Teams can also exceed 1 GB and sometimes reach 1.5 GB or more, especially when users have large file-heavy chats open.
There are browser policies for putting upper bounds on memory use and for suspending inactive tabs, and those are worth enabling. You can also limit unnecessary video features and restrict non-work streaming. Windows doesn't provide a simple memory limit per user session, so sizing usually has to account for the heaviest applications rather than relying on a hard cap. One rough design point is 64 GB of RAM plus a fixed 32 GB page file for around 40 users, but the actual number depends heavily on the workload.
One effective approach is moving meeting audio and video to the endpoint instead of handling it in the session. Disabling redirected audio, or requiring users to join meetings locally, can noticeably reduce resource usage. It also avoids troubleshooting poor meeting quality caused by an overloaded host.
We took a similar approach with streaming media: if users want music or video, they should run it locally. Remote-session audio quality is usually worse and consumes resources that are better reserved for business applications.
The most reliable solution we've found is using more, smaller hosts with fewer concurrent users on each one. Some environments cap a host at only a handful of users, which limits the impact of a runaway browser, Teams, WebView2, or Adobe process. Also investigate background processes such as Adobe components and AI-related executables; they can contribute significantly to system-wide performance problems. Browser tab suspension, application policies, and user education help, but host sizing and workload isolation usually make the biggest difference.
Forty users on 64 GB would be far too aggressive for our Office, Teams, and browser workload. We treat roughly 10–15 users per 64 GB host as a practical ceiling, then validate it with monitoring and real usage data.