When you set up a Remote Desktop environment for multiple users across multiple Windows Servers, it's recommended to set up a Remote Desktop Services Deployment.
A Remote Desktop Services Deployment consists of a number of roles for which it is not always immediately clear what those roles serve. For example, what does a connection broker do? You may also be wondering which server to install which role on. In this article we zoom in on this and we look at which components a Remote Desktop Services Deployment consists of and on which servers you install which roles.
A minimum recommended Remote Desktop Session Deployment includes the RD Session Host, RD Connection Broker, RD Web Access, and RD Licensing roles. To install Remote Desktop Services, see our Remote Desktop Services tutorial.
Components of a Remote Desktop Services Deployment
A picture is worth a thousand words, so we first look at an overview of a (complete) remote desktop environment.
Remote Desktop Session Host
Simply put, a Remote Desktop (RD) Session Host is a remote desktop server on which one or more end users work on a virtual desktop via a remote desktop client (mstsc in Windows), or use apps made available on the RD Session Host via Web Access. RD Session Host (see the example under RD Web Access). To ensure optimal performance, we recommend that you do not install any other roles on the RD Session Host.
Via an RD Session host you can offer desktop environments or applications (more focused on RD Web Access) to users. You can gather one or more RD Session Hosts in a 'collection', which can be further adapted for specific groups or users. For example, you can give a group access to specific apps and deny others access, while they both keep access to the same Session Host.
Remote Desktop Connection Broker
A Remote Desktop (RD) Connection Broker manages incoming remote desktop connections to RD Session Hosts (both for desktop and app collections).
RD Connection Brokers can apply load balancing to servers in a collection when setting up new connections. A lost connection from the client side, when that connection is reestablished, is linked back by the RD Connection Broker to the RD Session Host it was previously connected to.
RD Gateway
An RD Gateway encrypts the connection between a client and server (the RD Session Host) with SSL. To do this, the gateway uses an HTTPS connection (port 443) to the RD Gateway, which then forwards the remote desktop connection (default port 3389) to the Remote Desktop Session Host. The RD Gateway also connects to the RD Connection Broker for any load balancing and to reestablish connections if necessary.
It is important that you use a certificate from a trusted certificate authority (CA) for an RD Gateway. In addition, the name on the certificate must match the subdomain that you use to connect to an RD Gateway.
RD Web Access
Remote Desktop Web Access (RD Web Access) allows users to access remote desktops or applications through a web portal (the screenshot above is an example of this). The desktops or applications are collected in a collection and are opened via the native Remote Desktop client application. This is, for example, a handy way to offer Windows desktops and applications to both Windows and non-Windows client devices (e.g. a Macbook).
RD Web access uses IIS to set up an encrypted connection between the client and RD Web Server over an HTTPS connection. The RD Web Access server must be accessible via a public IP address that allows TCP connections on port 443.
RD Licensing
As the name suggests, the RD Licensing role verifies remote desktop licenses. As an administrator, you are free to work for free on a Windows Server (maximum with two administrators), but to work on Remote Destkop Session hosts, a license must be available for every regular user (see also our article 'Installing Remote Desktop licenses') .
RD Virtualization Host
The RD Virtualization Host role uses Hyper-V to deliver virtual machines via Remote Desktop Connection and RemoteApp. Hyper-V is not supported on our platform, and this role plays no further role in setting up a Remote Desktop Services Deployment on Windows VPSs.
Which server do I assign which role?
You can always adjust on which server you host which remote desktop role at a later time. In our tutorial about modifying Remote Desktop deployments, we explain how to do this.
Not every role is equally intensive in hardware use. For example, the RD Licensing role requires very little from a server. In addition, not everyone wants or is able to deploy one Windows Server per role, as this also entails a cost. If you are in this situation and you are wondering which server you can best give which role, we recommend the following distribution:
- RD session host: Do not combine with other roles.
- RD Connection broker: combine with AD DS server (your Domain Controller)
- RD Gateway: combining with RD Web Access and RD Licensing
If necessary, you can save even more costs by combining even more roles. For example, you can combine the RD Gateway, RD Web Access and RD Licensing role with a File Server. When you combine roles, it is especially important to keep an eye on the hardware usage of the server. In our test setup (which obviously has a much lower load than a real-world environment), the hardware consumption of an RD Gateway, RD Web Access, RD Licensing and File Server combination on an X4 VPS was negligible.
The scenario described above applies to environments with multiple Windows Servers. If you only deploy one Remote Desktop server, you are free to install all roles on that one server. If you also use a file server, then you could, for example, install all roles except the RD Session Host on the file server to optimize the performance.