Deployment Options for Remote Desktop Services in Windows Server 2012 R2
in today Ask the adminI’ll explain how RDS Session Host deployment in Windows Server 2012 R2 differs from earlier versions of Windows Server and the available deployment options.
Remote Desktop Services in Windows Server has improved over the years, but can be difficult to understand due to the many components involved. RD Session Hosts do the dirty work of serving your users’ terminal services sessions. But even in a single-server deployment scenario, an RD connection broker is mandatory. Before planning an RDS deployment, it is important to understand the role of the RD connection broker.
RD Connection Broker
When a remote desktop session is disconnected, applications in the user’s session continue to run. To track user sessions, RD connection agents store information such as the name of the RD Session Host server where each session resides, the session state and ID, and the user logged in to each session. This information is used to connect users to existing sessions, if any, on RD Session Host servers. When establishing new sessions, RD connection brokers also play a role in connecting users to RD session host servers under the lowest load.
Starting with Windows Server 2012, RD Connection Agents 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 functionality, management consoles, and RemoteApp functionality.
Centralized Resource Publishing
Windows Server 2012 also introduced the concept of collections. Windows Server 2008 R2 required system administrators to publish applications to each RD Session Host in a server farm individually. Now that RD Connection Broker stores configuration information, this is no longer necessary.
Deployment options: rapid or standard
The key to understanding how to deploy RDS in Windows Server 2012 R2 is that installing the RD Session Host role alone probably won’t get you very far. Server Manager provides a special deployment mode for installing RDS so that you can install all the necessary components, and in the right places, to get your deployment up and running easily.
Remote Desktop Services in Windows Server 2012 R2 (Image credit: Russell Smith)
The Add Roles and Features Wizard in Server Manager has a special install option, Installing Remote Desktop Services, which you must choose when deploying RDS. The wording of this option is a little confusing, but it allows installing RD Session Hosts without deploying a full virtual desktop infrastructure (VDI).
Standard deployment is the default deployment model, and unless you really want to install all required roles on a single server, which is not best practice, you should choose this option. Quick Start can be useful in test scenarios or in small branch offices where there is only one server available.
The standard deployment allows the RD Connection Broker, RD Session Host, and RD Web Access roles to be installed on one server or 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, all of which are required, but the RD Gateway role is optional. The RD Web Access role allows users to access RemoteApps or desktops from the Start menu or a web portal. If you want to use RDS beyond the 120-day trial period, you will also need to install the RD license role.
Management consoles
All required management consoles are located 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 RDS deployment options and the components involved. In the next article in this series, I’ll show you how to deploy RDS using PowerShell.
Comments are closed.