In today’s Ask the Admin, I’ll explain how RDS Session Host deployment in Windows Server 2012 R2 differs from earlier versions of Windows Server and the deployment options available.
Remote Desktop Services in Windows Server has improved over the years, but can be difficult to understand because of the many components involved. RD Session Hosts perform the dirty work by serving up your users’ terminal services sessions. But even in a single-server deployment scenario, an RD Connection Broker is mandatory. Before you plan a RDS deployment, it’s important to understand the role of the RD Connection Broker.
When a remote desktop session is disconnected, the apps in the user’s session continue to run. To keep track of user sessions, RD Connection Brokers store information such as the name of the RD Session Host server where each session resides, session state and ID, and the user logged in to each session. This information is used to connect users to existing sessions, should they exist, on RD Session Host servers. When establishing new sessions, RD Connection Brokers also perform a role by connecting users to RD Session Host servers under the least load.
Starting in Windows Server 2012, RD Connection Brokers not only store user session data, but also configuration information. RD Connection Broker uses the Windows Internal database to store session and configuration information, except when installed in high availability (HA) mode where SQL Server 2008 R2 (or later) is used.
RD Connection Broker requires an Active Directory domain, but cannot be installed on a domain controller (DC). It is possible to deploy RDS in a workgroup by installing the server role, although you lose centralized management features, management consoles, and RemoteApp functionality.
Windows Server 2012 also introduced the concept of collections. Windows Server 2008 R2 required that system administrators publish apps on each RD Session Host in a farm individually. Now that RD Connection Broker stores configuration information, this is no longer necessary.
The key to understanding how to deploy RDS in Windows Server 2012 R2 is that installing the RD Session Host role alone isn’t likely to get you very far. Server Manager provides a special deployment mode for installing RDS so that you can get all the necessary components installed, and in the right places, to get your deployment up and running easily.
The Add Roles and Features Wizard in Server Manager has a special installation option, Remote Desktop Services installation, which you should choose when deploying RDS. The wording under this option is a little confusing, but it does allow RD Session Hosts to be installed without deploying a full virtual desktop infrastructure (VDI).
Standard deployment is the default deployment model, and unless you really want to install all the required roles on a single server, which is not best practice, then you should choose this option. Quick Start can be useful in testing scenarios or in small branch offices where there’s only a single server available.
Standard deployment allows the RD Connection Broker, RD Session Host, and RD Web Access roles to be installed on one server, or across multiple servers, which is the most likely deployment scenario in a production environment. The RD Connection Broker includes the Windows Internal database, RD Session Host, and RD Web Access roles, which are all required, but the RD Gateway role is optional. The RD Web Access role provides users access to RemoteApps or desktops from the Start menu or a web portal. If you want to use RDS beyond the 120-day trial period, you’ll need to additionally install the RD Licensing role.
All the required management consoles can be found in Server Manager on the server where RD Connection Broker is installed, except for RD Gateway and RD Licensing.
In this article, I explained the different options for deploying RDS, and the components involved. In the next article in this series, I’ll walk you through how to deploy RDS using PowerShell.