Virtual Desktop Infrastructure, Part 2: Finally, VDI

In “Virtual Desktop Infrastructure, Part 1”, I covered the technologies that make up desktop virtualization, including application virtualization, roaming profiles, folder redirection, and OS virtualization. I explained how combining these technologies lets you dynamically construct the entire user environment as needed on a local OS, a presentation virtualization platform such as Remote Desktop Services (RDS), and a Virtual Desktop Infrastructure (VDI) environment. In this article I discuss the components necessary to create a pure Microsoft VDI solution based on Windows Server 2008 R2.

Prerequisites

Before we step through the typical process of connecting to a hosted desktop, it’s helpful to identify the types of services necessary for a successful VDI architecture. Figure 1 shows the major steps required for VDI functionality, from the initial user contact all the way to a usable VDI session—except for technologies such as Microsoft Application Virtualization (App-V), roaming profiles, etc., that actually populate the OS environment.

Figure 1: VDI components

The process involves seven distinct steps, as Figure 1 shows. First, users must find the remote desktops they can connect to, which can include presentation virtualization sessions (Terminal Services), published applications, and VDI sessions. Although an RDP file can be created and deployed to users through various methods, a more dynamic approach is to use the Remote Desktop Web Access role service, which presents a browser-based list of available connections from which the user can choose. An alternative to users having to browse a website and have a list of dynamically published connections and applications is to use the Windows 7 RemoteApp and Desktop Connections feature to subscribe to an RSS-based feed from the Remote Desktop Web Access servers to automatically populate the available connections, which can be configured using a Group Policy–deployed script. Users can then see these published services straight from their Start menu.

The second step is to create a list of published applications and connections that are presented to the user. To accomplish this task, the Remote Desktop Web Access server communicates with the Remote Desktop Connection Broker, which has knowledge of the VDI pools, personal desktops, and other published connections and applications through its own communication with configured RemoteApp sources.

In the third step, the Remote Desktop Connection Broker communicates with Active Directory (AD) to determine the user’s exact access. This communication also exposes any personal desktop configurations, which I discuss later in the article.

No matter what method is used, whether Remote Desktop Web Access, the RemoteApp and Desktop Connections feature, or a deployed RDP file, users now have an RDP file that can be used to initiate the connection (see step 4). If a user were outside the corporate network, then a direct RDP connection would be blocked by most organizations’ firewalls. Thus, we’d need to initiate a secure VPN connection. However, we have an alternative solution that doesn’t require any end-user action or additional client-side software. Windows Server 2008 introduced Terminal Services Gateway, which allows the RDP traffic to be encapsulated in HTTPS (port 443) packets. (Terminal Services Gateway is renamed Remote Desktop Gateway in Server 2008 R2.) With Remote Desktop Gateway in the architecture, we place the Remote Desktop Gateway server in the demilitarized zone (DMZ), or more securely behind some kind of firewall or proxy. Clients then connect to the RDP destination through the Remote Desktop Gateway by adding the Remote Desktop Gateway server as part of the RDP file configuration that’s given to the client. The client encapsulates the RDP traffic in HTTPS and sends the HTTPS-encapsulated RDP data to the Remote Desktop Gateway, which extracts the RDP data and forwards it to the RDP destination. When traffic comes back from the RDP destination bound for the client, the Remote Desktop Gateway encapsulates the RDP data in HTTPS and sends the HTTPS-encapsulated RDP data to the client. With this technology, users outside the corporate network can still access all RDP resources without additional steps or software. Users on the corporate network would bypass the Remote Desktop Gateway and communicate directly with the RDP destination. Authentication to the Remote Desktop Gateway can be through traditional Windows authentication or via smart card, including the ability to connect through current logon credentials, which prevents having to reenter credential information.

In step 5, the user needs an initial RDP connection point because the VDI client virtual machine (VM) destination isn’t yet known, unless the user has a personal desktop configured. A Remote Desktop Session Host is configured in redirection mode, which means the server acts as the connection point for the user’s RDP connection, then redirects the client to the true endpoint, the VDI session. The Remote Desktop Session Host communicates with the Remote Desktop Connection Broker to determine what the RDP target should be for the requesting client. The Remote Desktop Session Host and Remote Desktop Connection Broker are on the same host in this architecture, but you don’t have to place them on the same host (although it’s common to do so because of how closely the two roles work together).

In step 6, the Remote Desktop Connection Broker communicates with the Remote Desktop Virtualization Host role service that’s enabled on the Hyper-V boxes to check the state of the VMs, start the VM if required, and gather any needed information, such as IP address of the client VM OS, which is then passed back to the Remote Desktop Connection Broker, to the Remote Desktop Session Host in redirection mode, then back to the client.

In step 7, the client makes an RDP connection to the destination client VM via the Remote Desktop Gateway (if connecting from outside the corporate network); the connection is now complete. At logon, the profile will be downloaded through roaming profiles, along with data available via folder redirection and applications available through App-V.

Although the process of connecting to a hosted desktop includes a lot of components and steps, it’s a smooth and near-instant process from the users’ perspective, providing a full-featured client experience from any RDP client.

One item that Figure 1 includes but that I didn’t discuss is Microsoft System Center Virtual Machine Manager (VMM). Although VMM isn’t 100 percent necessary for a VDI environment, it can be helpful in managing your VDI environment by providing Hyper-V farm management capabilities, libraries, PowerShell support, and much more.

For a pure VDI environment, you can use the free Microsoft Hyper-V Server solution and save the cost of purchasing Server 2008 R2. Server 2008 R2 SKUs provide the same Hyper-V capabilities as the free Hyper-V Server solution but have additional capabilities beyond virtualization. In addition, Server 2008 R2’s Hyper-V has additional server virtual instance rights—which we don’t need, so you should save your money and use the free solution instead.

When we look at all the steps involved in the connection process, we essentially have five RDS roles. If you decide to use RemoteFX with SP1 (which I’ll cover in a future article), that makes six Remote Desktop role services. Using any of the Remote Desktop role services requires clients to have RDS CALs, in addition to any virtual desktop access/software assurance rights. Let’s dive a little deeper into each of the services and any special considerations related to VDI. For full VDI deployment information, refer to the Microsoft TechNet page “Getting Started: Remote Desktop Services”.

Remote Desktop Web Access

Remote Desktop Web Access provides the initial entry point, giving users a web-based interface to select the desired VDI or published desktop/application target. Although not absolutely required, Remote Desktop Web Access helps give a simple-to-use portal that supports forms-based authentication and single sign-on (SSO), in addition to differentiating between public and private computers.

Windows 7 introduces the RemoteApp and Desktop Connections feature, which—although not directly part of Remote Desktop Web Access—allows a feed from Remote Desktop Web Access to populate the same content shown in the website directly into the Start menu, thus avoiding the need to use the website. Figure 2 shows both the local Start menu and the website view. Note that we can see not only the VDI pool but also published applications from remote desktop session hosts.

Figure 2: Web-based and RemoteApp and Desktop Connections views of published applications and desktops

If you want to create a configuration file that automatically configures the RemoteApp and Desktop Connections feature for Windows 7 clients, use the Create Configuration File option in the Remote Desktop Connection Manager. This option creates a file that you can run on a Windows 7 client to automatically configure the client. It’s a great solution for large deployments.

Remote Desktop Connection Broker

Server 2008 R2’s Remote Desktop Connection Broker role service is one of the major components that allows an all-Microsoft VDI solution, giving RDS the ability to balance and track connections to non–terminal servers—specifically, the ability to manage connections to client OSs. In addition, Server 2008 R2 introduces the ability for the Remote Desktop Connection Broker role service to balance remote applications and support servers with different published applications, allowing a sum view of all the different applications gathered from all servers in the farm, to be displayed to the user—thus removing the need for all servers to have exactly the same applications.

The Remote Desktop Connection Broker role service is really the brains of the VDI environment. It communicates with and controls the other components, working particularly closely with the Remote Desktop Session Host in redirection mode, which is why the Remote Desktop Connection Broker and Remote Desktop Session Host in redirection mode are frequently placed on the same OS instance. However, when you start having more than 250 simultaneous connections, you might need to consider breaking the roles onto separate servers.

VDI pools are created through the Remote Desktop Connection Broker role service—specifically through the Remote Desktop Connection Manager administrative tool, which manages the published application, published session, and virtual desktop resources. The Remote Desktop Connection Manager is a tool you’ll come to love when managing your VDI environment. This single tool not only lets you create VDI pools but also configures the Remote Desktop Virtualization Host, Remote Desktop Web Access, and Remote Desktop Session Host role services. The tool also places the specified Remote Desktop Session Host in redirection mode, saving you the overhead of manually configuring each service for its VDI role.

When we create a VDI pool, we specify the Hyper-V servers that are hosting the VMs, then select the client VMs that will be part of the pool. The VDI pool creation wizard takes care of most of the other necessary configuration.

The Remote Desktop Connection Broker role service handles all incoming VDI requests and first checks to see if the user has a disconnected session within the VDI pool. If so, the user is reconnected; otherwise, a currently unused virtual desktop is assigned to the user.

Remote Desktop Session Host in Redirection Mode

The concept of using a Remote Desktop Session Host in redirection mode isn’t new. We’ve used it with previous version of Windows Server when we had a large terminal server farm. To prevent users from having to connect to different terminal servers, the initial entry point is always a designated session host that does nothing more than talk to the broker and redirect the RDP connection to the correct RDP endpoint. The same process occurs in a VDI environment; we still need an initial RDP connection point for the RDP clients, which is exactly what the Remote Desktop Session Host in redirection mode provides. It then redirects the RDP client to the correct client OS VM that will provide the desktop OS.

The Remote Desktop Session Host is what we used to think of as a terminal server: a server that provides the hosting of sessions. But because Server 2008 R2 has so many RDS parts, we now need to be a little clearer when we actually have a server providing sessions—hence the term Remote Desktop Session Host.

We can manually configure a Remote Desktop Session Host to be in redirection mode. However, if we use the Remote Desktop Connection Manager VDI pool creation wizard, the Remote Desktop Session Host configuration is done automatically, as Figure 3 shows. Note that once a Remote Desktop Session Host server is placed in redirection mode, it can’t also be used to host regular sessions; it can only perform redirections.

Figure 3: Automatic Remote Desktop Session Host configuration through the VDI pool wizard

Remote Desktop Virtualization Host

The Remote Desktop Virtualization Host role service is installed on any Hyper-V host that will be participating in a VDI pool. This role service lets the Remote Desktop Connection Broker role service communicate with the Hyper-V hosts, start and stop VMs, and gather internal information to enable client connections.

Remote Desktop Gateway

The Remote Desktop Gateway role service allows RDP traffic to be encapsulated in HTTPS packets, enabling secure RDP connection through corporate firewalls without having to open up firewall ports or use additional VPN solutions. We can use Remote Desktop Gateway to configure who can connect through the Remote Desktop Gateway service, what they can connect to, and the supported RDP settings, such as device redirection.

Highly Available VDI

Implementing VDI involves centralizing the desktop environment into the data center. If a server fails, users can still use their local OS environment. But when we implement VDI, the entire desktop is in the data center—so if part of the VDI environment fails, the user loses the entire desktop environment and is unable to work. Ensuring that all the elements of a VDI environment are fault tolerant is crucial. Fortunately, we have a solution for each part of the VDI architecture.

Looking at the Remote Desktop Connection Broker role service as the brains of the VDI environment, we use failover clustering because the role service is cluster aware, which ensures that it’s always available and survives the loss of any node. Because we normally co-locate the Remote Desktop Session Host in redirection mode with the Remote Desktop Connection Broker role service, you need to ensure that you install the Remote Desktop Session Host and configure it in redirection mode on all nodes in the cluster. We create a DNS Resource Record for the session hosts, which has the IP address of each session host configured. Thus, when clients connect, all the IP addresses are sent to them in varying order. If one server isn’t available, then the clients will just try the next IP address.

The Network Load Balancing (NLB) service is used to balance between multiple Remote Desktop Gateway instances. We can use the NLB service that’s part of Windows or we can use a hardware load balancer. We can use the same NLB technologies to make Remote Desktop Web Access highly available.

Hyper-V hosts can be placed into failover clusters so that if a Hyper-V host fails, client VMs can be moved to other hosts. Live Migration can be used to move running client VMs between hosts for maintenance purposes if necessary. However, because the user state and data are separate from the OS instance, if an OS instance is lost, users just reconnect to an alternative OS. User states and data are then available again.

Personal vs. Pooled Desktops

So far I’ve discussed pools for VDI clients, which is a configuration in which several VMs running the client OS are grouped together into a pool. As users connect to the pool, they’re automatically assigned one of the VMs that isn’t currently in use. After the user logs off, the VM is placed back into the pool. Because a user potentially (and probably) gets a different VM each time, we need to have various desktop virtualization solutions in place (e.g., roaming profiles, folder redirection, application virtualization) to ensure a consistent desktop experience.

Pooled desktops should be the default for all users. However, certain users might need the same client OS instance every time they connect. Maybe they’re modifying the OS in some way, or perhaps they have an application that needs to be installed because it can’t be virtualized. Whatever the reason, we have the capability to statically assign a VM to a particular user so the user always gets the same client OS. This is known as a personal desktop and is configured through the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, as Figure 4 shows. A user can be assigned only one personal desktop, a VM can be assigned to only one user as a personal desktop, and a personal desktop must not be in a VDI pool but should just be a regular VM in the environment. Make sure the personal desktop name exactly matches the name of the VM, which needs to be the Fully Qualified Domain Name (FQDN)—for example, client.savilltech.net—which means you need to name the VMs the FQDN of the client OS instance.

Figure 4: Assigning a personal desktop to a user

Client VM Configuration

We’ll want to use Windows 7 as the client OS within our VDI VMs for the best experience. With an RDS-based VDI deployment, we must create all the VMs in advance, install the OS, and add to the pool—there’s no dynamic creation or streaming of the OS to populate the VM. (This capability comes with Citrix XenDesktop, which I’ll cover in a future article.) We can use technologies such as VMM to simplify the VM and OS deployment process.

We need to perform some particular configuration inside the client VMs to enable management of the client OS by the Remote Desktop Virtualization Host and connectivity from the clients. The major steps you need to perform in each client OS are:

You can manually perform all the required steps for each VM (see Microsoft TechNet’s Remote Desktop Services in Windows Server 2008 R2, Appendix A, “Configuring the Virtual Machine Manually”; you can use Group Policy to automate the steps to apply the configuration; or you can use a Microsoft-provided script to simplify the entire process.

There’s another interesting aspect to the client VM OS environments. We have multiple client OS environments that are shared by multiple users. We should be locking down these shared client environments so that users can’t change the OS configuration and add or remove software. However, depending on the environment, we might want the OS to be reset to a known state each time a user logs off. We can use Hyper-V and RDS’s snapshot capabilities to achieve this goal.

For each VM, we can create a snapshot that includes RDV_Rollback in the snapshot name. This snapshot should be taken when the VM is in a clean state because you want the OS to be reset each time a user logs off. The snapshot can be taken when the VM is running or not running, but you must make sure no one is logged on when you take the snapshot. When a user logs off from a VDI VM that was connected to via the Remote Desktop Connection Broker role service, the VM is reset back to the RDV_Rollback snapshot. Note that this RDV_Rollback capability applies only to VMs in a pool, not to personal desktops.

If you choose to use RDV_Rollback to ensure that each user gets a clean OS environment, a wrinkle is introduced into the VDI environment related to AD domain membership. Typically, the computer account password of the OS instance automatically changes every 30 days. If we restore to a checkpoint periodically—for example, after each logoff—the old machine account password that’s present in the RDV_Rollback will no longer be valid after the computer changes its password—which could happen while a user is logged on past day 30, which would cause subsequent logons to fail and require an account reset. There are several options to solve this problem. One solution is to disable the machine account password change, which we can accomplish through Group Policy. However, this approach can have security ramifications and therefore isn’t recommended.

Another option is to actually delete all the client VMs, recreate them, and create a new RDV_Rollback periodically (i.e., an interval less than the AD machine account password change interval). This approach might seem ridiculous, but you can use VMM and Microsoft’s scripts for creating VMs for VDI. These scripts let you automate the bulk creation of VMs for your VDI environment, which makes it far easier to recreate your VDI VMs as needed and much more realistic to periodically recreate the VMs. Using this approach also solves another issue. If we keep the VMs around for a prolonged period of time, we need to patch them and perform regular desktop maintenance. If we recreate the VMs every 4 weeks, then all we need to patch is a single master image that’s replicated to create all the VMs in the VDI pool.

Next Steps

RDS-based VDI is a great solution that you can realistically use in production environments. For some large deployments, the static nature of the client VMs might be prohibitive—which Microsoft’s partnership with Citrix addresses and which I’ll cover in the next article in this series. In the meantime, refer to the Microsoft TechNet page “Getting Started: Remote Desktop Services”, for step-by-step VDI instructions. Within a day, you could easily set up a VDI environment in your lab environment and start experimenting.