RDS VDI Functionality
An RDS-based VDI provides an environment that enables central storage, execution, and management of Windows desktops in a datacenter. An RDS VDI solution supports the creation and management of virtual desktop pools, and personal virtual desktops.
A virtual desktop pool is a collection of identical virtual desktops that are available for connection by multiple users. This type of virtual desktop does not maintain user state; instead it reverts back to its original state when a user logs off. A virtual desktop pool is applicable to users with the following characteristics:
- Do not need a personalized desktop
- Do not need offline access to virtual desktop
- Do not need to save state between sessions
- Need access to the virtual desktop from a collection of client devices
Examples of users that may require access to a virtual desktop pool are call-center workers, POS workers, and administrative office workers.
In contrast, a personal virtual desktop is configured for connection by a single user and maintains user state information when the user logs off. A personal virtual desktop pool is applicable to users with the following characteristics:
- Need a personalized desktop
- Need to save desktop state between sessions
- Need administrative access to virtual desktop
Examples of users that may require access to a personal virtual desktop are offshore software developers and testers.
Core RDS VDI Components
Whether deploying a virtual desktop pool or personal virtual desktops using RDS-based VDI, specific core components are needed and additional components may be necessary depending on the complexity of the solution requirements. The core components required for any RDS-based VDI solution include the following:
- RD Connection Broker
- RD Session Host
- RD Virtualization Host
- RD Licensing Server
The RD Connection Broker builds on the functionality of the Windows Server 2008 TS Session Broker to manage not only session-based remote desktops, but also virtual desktops. The RD Virtualization Host (RDVH) is a new role added in Windows Server 2008 R2. The RD Virtualization Host role runs on Hyper-V hosts and serves to manage the state of virtual machines and connect users to virtual machines.
RD Connection Broker
The RD Connection Broker manages user requests for connection to session-based and virtual machine-based desktops. It tracks the user name for each connection as well as the connection identifier, connection state, and connection host for each connection to an RD Session Host or RD Virtualization Host server. The RD Connection Broker also provides the ability to load balance connections within RD Session Host and RD Virtualization Host server farms, by evenly distributing connections between RD Session Host and RD Virtualization Host servers using a relative server weight value. In addition, the RD Connection Broker enables disconnected users to reconnect to an existing session-based or virtual machine-based desktop.
RD Session Host
In a VDI environment, RD Session Host servers are configured to run in redirection mode, which disallows interactive user sessions. Instead, when a client requests a connection to a virtual desktop, the RD Session Host server role contacts the RD Connection Broker for the IP address of the virtual machine to which the user should connect and returns it to the client. The client then initiates an RDP connection to the virtual machine.
RD Virtualization Host
The RD Virtualization Host is installed on Hyper-V hosts to manage virtual machines in preparation for an RDP connection based on a request from the RD Connection Broker. In addition, the RD Virtualization Host monitors and reports on virtual machine guest sessions to the RD Connection Broker.
RD Licensing Server
If you have worked in a Microsoft Terminal Services environment, you are already familiar with Client Access Licenses (CALs). In Windows Server 2008 R2, an RDS CAL is required for each device or user that connects to RD Session Host or RD Virtualization Host servers. When a user or device attempts a connection through an RD Session Host server, it requires an RDS CAL. The RD Session Host server makes a request to an RD Licensing Server on behalf of the client. If an RDS CAL is available, it is issued to the client, which is then able to connect to the RD Session Host or RD Virtualization Host server.
Microsoft provides a grace period that begins when an RD Session Host server accepts the first client connection. However, after the grace period, each user or device must be issued an RDS CAL before it can connect to an RD Session Host or RD Virtualization Host server. In Windows Server 2008 R2, the grace period lasts 120 days.
If you already have Windows Server 2008 deployed and have Windows Server 2008 TS CALs, you do not need to purchase new CALs as both Windows Server 2008 TS CALs and Windows Server 2008 R2 RDS CALs allow a user or device the right to connect to Windows Server 2008 R2.
Other RDS VDI Components
There are several additional RDS components that may be needed to provide a complete VDI solution. These additional components include the following:
- RD Web Access
- RD Gateway
- RemoteApp
RD Web Access
RD Web Access provides a web portal from which users can access session-based remote desktops, session-based remote applications, or virtual machine-based desktops. User requests for connection to session-based and virtual machine-based desktops made through RD Web Access are managed through the RD Connection Broker.
In Windows Server 2008 R2, RD Web Access allows the view of available remote desktops, remote applications, and virtual desktops to be customized based on user access. This means that a user will only be able to view and access those elements to which an administrator has specifically provided rights and permissions.
The RD Web Access portal also supports both private and public computer modes to control storage of sensitive information. For example, in private mode, RD Web Access cookies storing a user name expire in 4 hours. In public mode, they expire in 20 minutes.
RD Gateway
The RD Gateway is deployed at the edge of a corporate network and allows remote users to connect to resources deployed within a corporate intranet through a secure, encrypted connection. RD Gateway uses RDP over HTTPS to establish the secure connection between the remote user device and internal corporate resources.
RemoteApp
RemoteApp enables applications hosted on an RD Session Host server and virtual desktops hosted on an RD Virtualization Host server to be remotely accessed and integrated with a client desktop. For examples, using RemoteApp, it is possible to launch a remotely hosted application from an icon on the client desktop. When the application launches, an RDP session initiates to the application host and the application is presented on the local desktop in its own resizable window. If a user runs multiple RemoteApp applications, the applications can also share a single RDP session.
Remote Client Connection Sequence in Windows Server 2008 R2 RDS VDI
So how do RDS components work together to provide a remote client access to a virtual desktop within an Active Directory domain? Here is a brief explanation of the process assuming that RD Gateway and RD Web Access are deployed behind an external firewall and used to connect to a virtual desktop:
A remote user opens a web browser and connects to the RD Web Access portal.
RD Web Access requests the list of virtual desktop information to display from the RD Connection Broker.
The RD Connection Broker checks virtual desktop permissions in Active Directory, and then provides the information back to the RD Web Access site.
The users’ browser displays the virtual desktop information from the RD Web Access site.
After the user selects a virtual desktop, the Remote Desktop Client (RDC) opens a connection to the RD Gateway.
The RD Gateway forwards the connection to the RD Session Host server running in redirection mode.
The RD Session Host server requests that the RD Connection Broker prepare the virtual desktop and return its IP address.
The RD Connection Broker queries AD to verify user credentials and personal virtual desktop information associated with the user, if necessary.
The RD Connection Broker requests that the RD Virtualization Host server start the virtual desktop if it is not running, and then returns the virtual desktop IP address to the RD Session Host server.
The RD Session Host server returns the virtual desktop IP address to the Remote Desktop Client running on the users’ computer.
The Remote Desktop Client connects to the virtual desktop through the RD Gateway.
Since there are many different network configurations in which the RD Gateway and other RDS VDI components can be deployed, the connection sequence may slightly vary. For additional information on RD Gateway deployment configurations, you can check out the Microsoft RDS Team blog entry here.
Conclusion
In Windows Server 2008 R2, the RD Connection Broker has been extended to manage not only session-based remote desktops, but also virtual machine-based desktops running on Hyper-V. With this new feature and the addition of the RD Virtualization Host component, it is now possible to build a VDI for small or medium environments using only Windows Server 2008 R2 RDS components. For large deployments, a Microsoft RDS-based VDI solution can still be integrated with Citrix XenDesktop to provide an enterprise scale infrastructure.
