Windows Server

Remote Desktop Services Deployment Options in Windows Server 2012 R2

Petri IT Hero Contest

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.

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.

Sponsored Content

What is “Inside Microsoft Teams”?

“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts. Our next episode, “Polaris Inc., and Microsoft Teams- Reinventing how we work and play” will be airing on Oct. 28th from 10-11am PST.

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.

Centralized Resource Publishing

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.

Deployment Options: Quick or Standard

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.

Remote Desktop Services in Windows Server 2012 R2 (Image Credit: Russell Smith)
Remote Desktop Services in Windows Server 2012 R2 (Image Credit: Russell Smith)

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.

Management Consoles

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.

 

Related Topics:

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register
Comments (0)

Leave a Reply

IT consultant, Contributing Editor @PetriFeed, and trainer @Pluralsight. All about Microsoft, Office 365, Azure, and Windows Server.
External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by: