RDS – Remote Desktop Services Roles – Part II

Hello World,

In part I of our RDS services, we have briefly introduced the concept and technologies covered by Remote Desktop Services.  In this post, we will go a little bit more into details and see what Roles services are available to your when planning your RDS deployment.

In this post, we will provide a quick overview of what you can do with RDS and quickly describes the different available roles for your deployment.

So, let starts !

Remote Desktop Services Roles Overview

If you plan to use RDS solution, you should become familiar with the different role services that a RDS server can host. When performing the installation of the Remote Desktop Services, you will see that you will be prompted with a dialog box where you can choose which role the server will host (see screenshot below)


Click on Picture For Better Resolution

Based on your deployment architecture, you do not need to have all the roles installed within your RDS servers.  The roles you will be using will depends mainly on how do you want to deliver Remote desktop services to your customer.  However, note that any RDS deployment will require the installation of 3 mandatory roles.  The following illustration shows you which roles have to be implemented during a RDS deployment.


The mandatory  roles are :

  • Remote Desktop Connection Broker  (RDCB)
  • Remote Desktop Web Access (RDWeb)
  • Remote Desktop xx Host (which can be either a Session host (RDSH) or the Virtual Host (RDVH) )

You have then the optional roles that can be installed which are

  • Remote Desktop Gateway (RDGW)
  • Remote Desktop Licensing Host (RDLH)

Note : If you do not install your RDLH role, you can use the RDS for 120 days.  After that, you should activate your RDS license in order to keep your RDS infrastructure working

Remote Desktop Services Roles Defined 

So far, we have seen that in order to have a working RDS architecture, you will need to install some required roles.  Based on your needs to you can use optional roles that can provide you with more specific features.  It might be time to have a closer look at the roles and what they are used for. 


The remote Desktop Connection broker (RDCB) will try to connect or reconnect a user to its remoteApp or session-based desktop session.  This role is like a load balancer which will intercept the connection request and send it to the back end host.  This role will also try to reconnect the user to the same connection as before.


The Remote Web access role (RDWeb) is a cool one.  It basically allows your users to access a web interface and to connect to RemoteApp,VDI or session based desktop.  This is a nice feature because nowadays everybody expect to have some kind of web based access to an application or a service.


The remote desktop Session host (RDSH)  is the backend server that will have the Terminal service functionality where you can either publish your applications or publish your VDI.


If you want to use VDI, you will have to install the remote Desktop Virtualization host role (RDVH).  This server needs to have Hyper-V role installed as well in order to server your Virtual Machine.

 Next to these 4 roles, you can install 2 additional roles as you can see on the screenshot below


You can install RDS roles in your domain and test it for 120 days.  After this period, in order to have you infrastructure working as expected, you will need to obtain RDS licenses.  To ease the management of your licenses, you can install the RD licensing server role.


Finally, you can decide to install the RD Gateway component. This is used in scenarios where you want to grant access to internal resources through internet without exposing your RDS infrastructure. The RDS Gateway will basically be used to pass your rdp traffic through an HTTPS “tunnel”.   You could use this RDS Gateway internally as well in a situation where you have multiple locations protected by Firewalls and where the port 3389 is blocked. In this case, you can check or ask to have the port 443 open and offer Remote Desktop services to your users and please your firewall guys at the same time J

Remote Desktop Services Architecture

Similar to an Exchange infrastructure, you can decide to host server roles to one or between multiple servers.  The best practice when deploying an RDS solution is to have each component hosted on their own dedicated servers.  This would be the best practice in a production environment where you need to have reliability, scalability and stability.  In a test environment, you can combine roles in one or more server as required.   In the next post, we will describe how to perform an installation on a single servers in order to become familiar to the RDS technology.  In a production environment, we usually combine some roles. As a standard deployment, we usually combined the following roles :

  • Remote Desktop Web Access (RDWeb) and Remote Desktop Gateway (RDGW)
  • Remote Host Server (either Session host or Virtual Host)
  • Remote Desktop Connection broker
  • Remote Desktop Licensing (which will be hosted on an existing server)



Final Notes

This is it for this post.  We have gone through a basic overview of the Remote desktop services offered by Windows 2012 R2.   We have seen that you can install up to 6 different roles when deploying your Remote desktop solution.  Each roles will provide a specify service or functionality.

I like the RDS solution because you can indeed consolidate and centralize your infrastructure by publishing RemoteApp and make them accessible to any user or any device (it’s web based/rdp based solution).

In part 3, we will describes how to install basic Remote Desktop Services Infrastructure in order for you to play around and become familiar with the new management interface.

Till Next Time

See ya

References :




4 thoughts on “RDS – Remote Desktop Services Roles – Part II

  1. Hi,

    I have a public domain panatit.com with public IP address and set up the following servers on my local domain controller panatit.com

    Windows 2012 R2 and wild card certificate

    DC01: panatit.com internal domain and License server
    RDCBWEB: RD Connection Broker and RD Web Access Server
    RDSH01: RD Session Host servers
    RDSH02: RD Session Host servers
    RDGWY01: RD Gateway Server (still in the internal domain but to be moved to the Perimeter network)

    I can access Remote app internally through https://RDCBWEB.panatit.com/rdweb, but how and where can I point the URL to be https://rds.panatit.com/rdweb ?

    What DNS setting do i need to setup internally for rds.panatit.com as it not resolving internally
    What setting do i need to configure for my RD Gateway?

    Also, how can I point the both the Internal and External URL to be the same?

    My Public IP address is pointing to rds.panatit.com



  2. Hello Eddy,

    I’m travelling for work..So limited input can be provided so far

    Have you checked this post for configuring the url you want to use (see http://c-nergy.be/blog/?p=4991) ???
    This might help you as well in order to configure RD Gateway (http://c-nergy.be/blog/?p=5290)

    Start with this….. and let us know if this is working for you
    Then we will tackle the next questions 🙂

    Till next time

  3. hi
    i am doing a mini project of remote desktop. for that can u suggest me that which one is the latest &best algorithm implemented..

  4. Hello there,

    The easiest setup for you would be to do the quick deployment option (see RDS – Quick Install Remote Desktop Service – Part III). This will install the mandatory roles on a single computer. From there, you can test RDS services

    Hope this help
    Till next time
    See ya

Leave a Reply