I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

If you're considering installing Remote Desktop Services (RDS) to deploy and manage virtual or remote desktops, you need to understand how each component works. The RDS components are (see Figure 1):

These are the RDS components in Windows Server 2012 RDS.

Remote Desktop Virtualization Host

RD Session Host

RD Connection Broker

RD Gateway

RD Web Access

RD Licensing

So, what do these RDS roles do? Here's a complete breakdown of each component and how it works with the RDS system:

RD Virtualization Host

The Virtualization Host component is a Hyper-V server configured to deployed personal virtual desktops or desktop pools. You can use multiple RD Virtualization Hosts in a Hyper-V cluster to create a highly available virtual desktop collection.

RD Session Host

The Session Host is the evolution of what is commonly referred to as "Terminal Services." This RDS role allows the server to host RemoteApp programs or session-based desktops.

RD Session Hosts are pooled in a "session collection," where properties such as user groups, session settings, security settings, load balancing, client settings and user profile disks are configured. From a session collection, you can publish RemoteApp programs or the full session-based desktop. RD Session Host servers in a collection can publish either RemoteApps or session-based desktops, but not both at the same time from the same collection.

RD Connection Broker

The Connection Broker connects and reconnects users to their virtual desktops, RemoteApp-published applications and session-based desktops. It's a mandatory RDS component in Windows Server 2012, and it's installed by default when you deploy Remote Desktop Services.

The Connection Broker load-balances requests to RD Session Host servers in a session collection or to virtual desktop pools. The connection broker uses a local database or a SQL database when configured for high availability. (Note that the SQL Server must be at least SQL Server 2008 R2.)

The gateway allows users to connect to RemoteApp programs and desktops that exist in the internal network by proxying the connection from the Internet to the internal network. In this way, only a single IP address and port to the external network are required to access all the published resources in the RDS deployment. The RD Gateway authenticates users' requests before allowing them to access their subscribed resources. For this reason, admins should deploy the RD Gateway into the demilitarized zone portion of the network.

Using the RD Gateway Manager tool, the gateway can enforce connection authorization polices (CAPs) to restrict which users can connect to it. These policies let you specify such authentication requirements as smart cards for two-factor authentication. You can also enable or disable specific device redirection in the CAP.

There are also resource authorization policies that provide restrictions based on Active Directory group membership. These restrictions allow you to restrict connections by specific network resource groups or RD Gateway-managed groups, or allow access to all network resources.

The RD Gateway requires a certificate that is used for SSL encryption between the client and the server.

RD Web Access

RD Web Access is a required component of Windows Server 2012 RDS. It provides access to RemoteApps and desktops via the user's Start menu or a Web browser.

Users authenticate to RD Web Access and select a RemoteApp or desktop to connect to. Based on configuration settings, the connection may be made through an RD Gateway or directly to the RD Connection Broker.

More on Remote Desktop Services roles

In these settings, you can allow the RD Gateway server to be bypassed for local addresses. In that case, the RD Connection Broker server then directs the RDP session to the appropriate RemoteApp or desktop.

In previous versions of RDS, there was a tool to create RDP files for manual connections to the RDS infrastructure without the RD Web Access component being required. In Windows Server 2012 Remote Desktop Services, however, this tool is no longer included, so RD Web Access is a critical component for accessing and brokering RDS connections. This RDS component is what creates the RDP file that the client will use to connect to the infrastructure.

Just as with RD Gateway, the RD Web Access component requires an SSL certificate for SSL encryption between the client and server. Because remote desktop connections start with a connection to the RD Web Access server, you should also deploy an RD Web Access server in the DMZ network with your RD Gateway servers. That way, you will isolate communication and pre-authenticated communication to your RDS infrastructure from your internal network.

RD Licensing

The RD Licensing component manages the licenses required to connect to a RD Session Host session collection or RD Virtualization Host virtual desktop collection. You can achieve high availability of this RDS role using Windows Clustering or by deploying multiple RD Licensing servers.

This component is not installed using the RDS deployment wizards; it has to be installed using the Remote Desktop Services management tool inside Server Manager, the new RDS management console in Windows Server 2012.

Start the conversation

0 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.