Microsoft Remote Desktop Services (RDS) Explained
Windows Server 2008 R2 (WS2008R2),
Terminal Services (TS) has been expanded and has been renamed to
Remote Desktop Services (RDS). The new and enhanced architecture takes advantage of virtualization and makes remote access a very flexible solution with new deployment scenarios.
There are five, main architectural components in RDS, as shown, and all require a RDS licensing server. Each component includes a set of features designed to achieve a particular function. Together, the five form a framework for accessing Terminal Services applications, remote desktops, and virtual desktops, all with WS2008R2 capabilities. Hence, WS2008R2 offers a set of building blocks with essential functions for constructing an enterprise, remote access architecture.
Remote Desktop Gateway (RDG) is optional, and it functions very much the same with that in TS. A RDG is to be placed at the edge of a corporate network to filter out incoming RDS requests from the Internet by referencing criteria defined in a designated Network Policy Server (NPS). With a server certificate, RDG offers secure remote access to RDS infrastructure. As far as a system administrator is concerned, RDG is the boundary of a RDS network. There are two policies in NPS relevant to an associated RDG:
In RDS, applications are installed and published in a Remote Desktop Session Host (RDSH) similar to a TS Session Host, or simply a Terminal Server in a TS solution. A RDSH loads applications, crunches numbers, and produces results. It is our trusted and beloved working horse in a RDS solution. Digital signing can be easily enabled in a RDSH with a certificate. Multiple RDSHs can be deployed along with a load balancing technology, which requires every RDSH in a load-balancing group to be identically configured with the same applications.
A noticeable enhancement in RDSH (as compared with TS Session Host) is the ability to trim the presence of a published application based on the access control list (ACL) of the application. An authorized user will see, hence have an access to, only published applications for which the user is included in the ACL. By default, the Everyone group is included in a published application’s ACL, and all connected users will have access to a published application.
Remote Desktop Virtualization Host (RDVH) is a new feature which serves requests for virtual desktops running in virtual machines, or VMs. A RDVH server is a Hyper-V based host, for instance a Windows Server with Hyper-V server role enabled. When serving a VM-based request, an associated RDVH will automatically start an intended VM, if the VM is not already running, and a user will always be prompted for credentials when accessing a virtual desktop. However, a RDVH does not directly accept connection requests and it uses a designated RDSH as a “redirector” for serving VM-based requests. The pairing of a RDVH and its redirector is defined in Remote Desktop Connection Broker (RDCB) when adding a RDVH as a resource.
Remote Desktop Connection Broker (RDCB), an expansion of the Terminal Services Session Broker in TS, provides a unified experience for setting up user access to traditional TS applications and VM-based virtual desktops. Here, a virtual desktop can be running in either a designated virtual machine, or a virtual machine dynamically picked based on load balancing from a defined virtual machine pool. A system administrator will use the RDCB console, called Remote Desktop Connection Manager, to include RDSHs, TS Servers, and RDVHs such that those applications published by the RDSHs and TS Servers, and those VMs running in RDVHs can be later composed and presented to users with a consistent URL by RDWA. And with this URL, authenticated users can access authorized RemoteApp programs and virtual desktops.
A Remote Desktop (RD) Client gets connection information from the RDWA server in a RDS solution. If a RD client is outside of a corporate network, the client connects through a RDG. If a RD client is internal, the client can then directly connect to an intended RDSH or RDVH once RDCB provides the connection information. In both cases, RDCB plays a central role to make sure a client gets connected to a correct resource. With certificates, a system administrator can configure digital signing and single sign-on to provide a great user experience with high security.
Conceptually, RDCB is the chief intelligence and operation officer of a RDS solution and knows which is where, whom to talk to, and what to do with it. Before a logical connection can be established between a client and a target RDSH or RDVH, RDCB acts as a go-between passing and forwarding pertinent information to and from associated parties when serving a RDS request. From a 50,000-foot view, a remote client uses RDWA/RDG to obtain access to a target RDSH or RDVH, while RDCB connects the client to a session on the target RDSH, or an intended virtual machine running in RDVH.