KB ID 0001753
Problem
This is a horrible subject to find any decent information on. Microsoft are typically ‘vague’ and most people are stuck with using trial and error, or massively overestimating hardware to be on the safe side. I get asked this occasionally and, just like Microsoft, it’s a question I don’t like to answer!
People are reticent to tell you that you need ‘x’ amount of CPU and ‘y’ amount of RAM. Simply because ‘it depends’ e.g. a dozen users just doing some file and print, and working on office documents, will be much less of a requirement, than a dozen users making MS Teams calls and doing 3D Auto CAD modelling.
I’m going to Assume: That we are deploying RDS in a virtual environment, so I’ll be talking about vCPU requirements. BE AWARE: Running a VM with a LOT of vCPUs can be counter productive for performance (Google CPU Ready).
RDS Sizing Requirements
RDS Dependancies
Most of these will be common sense,
- Domain Authentication: Usually via Active Directory or Azure AD credentials.
- DNS Resolution: Not just for the RDS server roles deployed, for resolving the names on Certificates, and for third party hosted applications.
- Third Party (Line of Business) Applications: Not all apps support RDS deployment, and many that do, require different licensing (Check!)
- File and Print: Thankfully these days most file storage is moving into the cloud, but users still need user profiles? How are you going to present them?FXLogix, Redirected folders, Shared folders etc.
- Access: These days having RDP open to the outside world is a thing of the past, it you want to connect to RDS you either come in via an RDS Web Gateway, or even better, by connecting to a VPN, then accessing the RDS deployment.
- Licensing: Obviously the RDS servers themselves require licensing, but so does RDS. Depending on what licence model you buy, (user CALs, or device CALs). Typically most people buy user CALs (Device CALs are good for things like call centres e.g. where 3 shift workers use the same PC in a 24 hour period so you can buy 1 device CAL rather than 3 user CALs).*
*Note: Whats a SAL then? A Subscriber Access Licence is used if you have your servers SPLA licenced from a service provider. These are usually on a monthly rental basis.
RDS Sizing: Roles
You can, (and I think it’s still the default) put all the RDS roles on one server, obviously this is not ideal for anything other than a tiny deployment (5-10 users doing very low impact roles for example). But the individual roles required are;
RD Session Host: This is what does all the heavy lifting, it hosts the remote user sessions. Typically these will be the server(s) in your deployment that suffer with recourse constraints if you get something wrong. As I’ve mentioned above if you’re running 3rd Party Line of Business applications on here MAKE sure they are designed and optimised for RDS. Finally based on what your users are doing is it worth having better/faster/local storage on these servers.
RD Connection Broker: This role had two primary jobs, 1) Connect remote users to the least utilised session hosts, and 2) Reconnect users to the correct session host if they’ve dropped a connection, or have an existing open RDS session.
RD Web Server: This provides a web logon portal for RDS so that RDS desktops and applications can be accessed over HTTPS. Remember just because traffic is on HTTPS (TCP port 443) do not assume it’s trusted and non malicious. Nearly every exploit and attack these days used HTTPS or SSH to get traffic in and out of your network. Unless you are inspecting https it’s not more secure than http! Typically the RD Web server is deployed in a DMZ. In some small deployments it can also be on the RD Connection broker.
RD Licence Server: Typically this gets put on ‘Another‘ server in the environment, the draw back of this is people forget where it is, and don’t check before decommissioning a server then find out a few days later their licence server disappeared. You install this role, then register it with Microsoft, then finally add your licences to it.
RDS Sizing Calculations
For all RDS roles apart from the RD Session Host(s) Then the footprint is relatively small.
RD Session Host(s) CPU: This depends on the amount of users, typically no more more than 4 users per vCPU , and up to a maximum of 8 vCPUs per host, (this should tell you you need an RDS Session Host for every 24 (approx) users). Remember to factor in additional hosts in case you suffer a loss of server/hypervisor. For that reason it’s also good practice to deploy your session hosts with anti-affix city rules so that they are not all on the same hypervisor host!
RD Session Host(s) RAM: Again depends on the user and what they will be doing, as a rule of thumb, allow between 2 and 8 GB per user, but do not allocate more than 128 GB per RDS Session Host.
RD Connection Broker: (2x vCPU, 8GB RAM, 70GB HDD) Note: Can scale up to 8 vCPU, 16 GB RAM, 70 GB HDD) for larger deployments.
RD Web Server: (2x vCPU, 4GB RAM, 70GB HDD) Note: Can scale up to 8 vCPU, 16GB RAM, 70 GB HDD) for larger deployments. Once you get larger than this you need to look as load balancing multiple RD Web servers.
RD Licensing: (1 x vCPU, 4GB RAM, 70GB HDD) Assuming there’s no additional compute requirements on the same host.
I welcome any feedback and recommendations below.
