Virtual desktop deployment easier in Windows Server 2008 R2

Microsoft will be the third major virtualisation vendor to release a virtual desktop infrastructure (VDI) product by the end of 2009, following the lead of VMware Inc. and Citrix Systems Inc. With the impending release of Windows Server 2008 R2, Microsoft will add the necessary orchestration and management components to its Terminal Services and Hyper-V hypervisor to make low-cost VDI a reality.

With the R2 release, Microsoft's VDI play involves the integration of several components with which you're likely already familiar. The most notable of these components are Hyper-V and Terminal Services or, as it is now known, Remote Desktop Services (RDS). This tip examines how familiar components of Terminal Services have been integrated into Windows Server 2008 R2 to better orchestrate and manage Microsoft VDI deployments.

Hyper-V and RDS: Two critical components of hosted desktops
In Windows Server 2008 R2, Hyper-V provides the virtualisation platform for hosting desktops. As a result, the first step in any Microsoft VDI deployment is to determine -- and then deploy -- the number of Hyper-V servers you'll need to support your virtual machines (VMs).

The second necessary component is Microsoft's Remote Desktop Services. The re-named RDS expands on Terminal Services by supporting connections to traditional presentation virtualisation servers while also supporting hosted desktops.

RDS accomplishes this through augmentation of what was previously known as the Terminal Services Session Broker (or TS Session Broker). In Windows Server 2008's RTM version, TS Session Broker directed users to the correct terminal server in a farm of similarly configured servers. With R2, the RDS Session Broker service can also direct users to their assigned Hyper-V VM. The result is that RDS Session Broker plays a critical role in your environment.

Remote Desktop Gateway and Remote Desktop Web Access
Windows Server 2008 R2 contains other Terminal Services featuers. Terminal Services Gateway and Terminal Services Web Access have now been re-named as Remote Desktop Gateway (RD Gateway) and Remote Desktop Web Access (RD Web Access), respectively. The combination of these two services provides a Web-based mechanism for presenting a list of assigned applications and hosted desktops to users. As previously, adding the RD Gateway to an environment enables you to traffic applications and desktops across the Web through an encrypted connection.

For end users, the result is a relatively unchanged experience from the RTM version of Windows Server 2008. To connect to an application, users log on to an RD Web Access server and then select an application. Hosted desktops are presented as clickable icons in the interface, providing a seamless mechanism for users to connect. The RD Web Access server itself has been augmented with new features that change its appearance. The most obvious of these changes is the new Silverlight-based user interface, which sports a much "sleeker" look. In addition, it supports greater numbers of extensibility points for unique branding.

Provisioning virtual machines in Microsoft VDI deployments
In data centers, changes have occurred in how VMs are provisioned to users. Administratively speaking, VMs can be made available to users in one of two ways. The first is through a direct assignment called a personal virtual desktop. Using this mechanism, the administrator can create a VM on a Hyper-V host. That VM is then directly assigned to a user through the RemoteApp and Desktop (RAD) Connection Manager console. Once a VM is created, the user assigned to it will then see his personal desktop available as a link in RD Web Access.

This one-to-one mapping between users and desktops is useful if you plan on having users work with their desktops over time. But the creation of a desktop that is tagged to a specific user doesn't fulfill Microsoft's mission of providing legacy application support. To fully enable this capability, Microsoft decouples users from specific desktops and instead creates an available VM from among a pool of resources. The result is a pooled virtual desktop, which provides a place for users to interact with their applications without the administrative overhead of managing user-tagged VMs.

A pooled virtual desktop makes life easier for admins because it allows them to take entire pools of VMs offline for updates as they become necessary. Pooled virtual desktops are designed to be implemented as clones of one another, creating a set of VMs with a common basis. If these clones need to be updated after creation, they can be individually modified through a configuration control mechanism (such as Group Policy, ConfigMgr, etc.). Alternatively, because VMs in a pool are intended to be stateless, clones can be thrown away. Doing this enables an administrator to make changes to the original-source VMs and re-create the clones as needed. For larger environments, Microsoft suggests Application virtualisation (or App-V) as a mechanism for timely delivery of applications to clones.

In both cases, user profiles are abstracted from individual VM instances through the use of Remote Desktop Services roaming profiles. These roaming profiles are similar to the traditional Terminal Services roaming profiles that have been used with Terminal Services for years.

Much like Citrix's recent move to VDI with XenDesktop, Microsoft's foray into the VDI space is brilliant in how it takes mature technologies and repurposes them for a more advanced use. In the next article of this series, I'll give you click-by-click instructions on how to begin building a VDI deployment with Windows Server 2008 R2, Hyper-V and RDS.