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 :

• http://technet.microsoft.com/en-us/library/dn283323.aspx
• http://technet.microsoft.com/en-us/library/hh831447.aspx