Microsoft Product Roadmaps

ShareTweet

Recent licensing changes signal stronger Microsoft support for virtual desktop infrastructure (VDI) technology. VDI promises to reduce desktop management costs, improve flexibility for desktop access, and enhance security. However, realizing these benefits requires critical decisions about which users will use VDI, and what client hardware, server hardware, and virtualization architecture will be used to deliver it.

The Windows VDI

In a VDI, a user's desktop (including the OS, applications, and user data) run on a virtual machine (VM) hosted on a centrally managed server, rather than locally on a user's PC. The user's local device, such as a PC or thin-client terminal, interacts with the desktop on the remote VM. The device connects to the VM using Remote Desktop Services (RDS, a superset of what was previously called Terminal Services), which forwards user input and display output over the network between the VM and the device. With the introduction of Windows Server 2008 R2, Microsoft repurposed and expanded the capabilities of Terminal Services components beyond desktop display to also manage connections from local clients to VMs and provisioning of VMs on the server.

VDI can help organizations do the following:

• Reduce the cost of desktop management by managing desktop configuration and applications centrally
• Provide flexible access to desktops from shared devices, remotely located devices, or devices that are not owned or managed by the organization (such as contractors' PCs or employees' home computers)
• Ensure the organization's data is stored centrally, protected from loss, damage, and improper disclosure.

Key VDI Components

Despite being conceptually easy to understand, implementation and operation of a Windows-based VDI can be complex because it requires coordination of two key Windows server roles: Hyper-V, which creates and manages the VMs running on a server, and RDS, which manages the connection and interactions between a user and a VM-hosted desktop.

Windows Server 2008 R2 (with its Hyper-V role; the stand-alone version, Hyper-V Server can also be used) creates and manages the VMs, including coordinating the shared use of the server's hardware by the VMs. As a hypervisor, Hyper-V sits between the hardware, the Windows Server OS, and one or more VMs that run the guest OS, such as Windows 7 and the user's desktop.

RDS lets users interact over a network with applications executing on a remote Windows server or PC. RDS uses the Remote Desktop Protocol (RDP) to send the user's input to the remote application and display the application's output on the user's local device.

Many organizations already use RDS in the traditional Terminal Services fashion—to provide users with desktops in sessions, not VMs, running on Windows Server running on a centralized server. Although the combination of Application Virtualization (App-V) and RDS can eliminate many application compatibility issues, not all applications can run in RDSs; therefore, organizations are turning to VDI.

RDS is also a key component of VDI. A Remote Desktop Connection (RDC) client running on a thin client (without a local hard drive) a PC with a full OS (including PCs running a non-Microsoft OS) uses RDP to initiate the user's connection to and interact with the session running on the server.

The RDS role incorporates specialized RDS services, including the following:

• RD Web Access, which publishes user-specific information about which sessions or VMs are available to each user or group of users
• RD Gateway, which secures and manages user connections coming across the Internet
• RD Connection Broker, which directs the user to the correct session or VM
• RD Session Host (RDSH), which has the dual role of hosting sessions on a server and directing users to the RD Virtualization Host for VDI
• RD Virtualization Host, which interacts with Hyper-V to start or stop VMs and manage requests for VMs from a RD Connection Broker.

(For an illustration of how these RDS and Hyper-V services work together to provide a VDI, see "VDI and RDS Interaction".)

Additional VDI Components

Although Hyper-V and RDS are key VDI components, many other Windows Server roles and services must be coordinated to have a manageable and secure VDI, including the following:

• Active Directory authenticates users and determines which VMs each user is offered, based on attributes such as their ID or group membership
• To support migration of VMs from one physical server to another (for load balancing or reliability), the physical servers need common storage and Windows Failover Clusters
• Folder Redirection and Roaming User Profiles ensure a user's data and preferences are available on his VM.
• Some services, while not mandatory, may also be used in a VDI and may need additional configuration to work with VDI:

Volume Shadow Copy and Data Protection Manager ensure VMs and physical servers are backed up
App-V facilitates deployment and management of user applications to VMs
Network Access Protection ensures a remote device connecting to the organization's servers has the necessary software and antivirus signatures installed
Windows Server Update Services coordinates downloading of patches for installation on Windows Servers and VMs running Windows.
Many of these roles will already be deployed in an organization, but they must be configured to ensure they work cooperatively to facilitate VDI.

Centrally managing desktops shifts some of the burden for updating and patching desktop software to administrators. Some of the following management tools will already be deployed, but they will need to be configured to support the additional workload of managing centralized desktops:

• Virtual Machine Manager (VMM) can manage the library of VMs, create VMs, and move VMs from one physical server to another as necessary
• The Offline VM Patching Solution Accelerator, which is technically a PowerShell script rather than a System Center management tool, makes it easier to automatically keep VMs patched and up to date
• Operations Manager manages the various physical servers and roles and provides status information to both administrators and to tools such as VMM, which can use the data to move VMs between physical servers
• Configuration Manager can manage software installation and patching of both the OS and applications on physical servers and VMs.
• Microsoft is working with long-time partner Citrix to ensure that Citrix and Microsoft virtualization tools work together. For example, Citrix Essentials for Microsoft Hyper-V offers advanced virtualization management capabilities for Windows Server 2008 Hyper-V in the areas of storage management and provisioning services.

Critical VDI Decisions

Supplying users with a powerful and reliable desktop on VDI is greatly dependent on critical decisions that the organization makes in deciding when and how to use VDI. These decisions fall into several major categories: Which users should have their desktop provided by VDI? When might RDS session virtualization be a better solution than VDI? What kind of local device will users have? And how should the physical servers be configured?

Which Users?

Deciding which users are candidates for VDI requires determining whether their desktop needs can be satisfied by desktops running on a centralized VM rather than on a dedicated physical computer. Few organizations will be able to satisfy the desktop needs of all of their users with VDI. Instead, VDI will be deployed to resolve specific problems with specific groups of users.

Organizations already use many devices, types of networks (LAN, WAN, and VPN), and network technologies (direct connections, RDS, and remote boot) to provide users' desktops. Decisions about which type of device and connection are based on the type of work the user has to perform, what applications the user needs to access, how much data they need to access, and where the user is located (in a central or a branch office). (For an illustration of various desktop deployments and how they might be used, see "Desktop Deployment Devices".)

When evaluating whether a user desktop could be better provided by VDI than via an existing method, organizations will want to look at several factors such as the following:

Desktop support requirements. An organization may find that its current desktop deployment requires significant and expensive on-site administration or maintenance. Although VDI can reduce the need to perform support at the user's location, the VDI itself still requires significant administration and support.

Application compatibility. Many organizations have legacy applications that will not run on recent client OSs, such as Vista or Windows 7. Their options are to continue using Windows XP, even on new computers, or to move their desktops to a more recent OS and run incompatible applications on VMs running Windows XP.

Data management. Increasing regulatory requirements mean organizations have to ensure key business data is properly managed to prevent damage, destruction, or unauthorized disclosure. VDI reduces the amount of data which is outside the data center where it is less likely to be backed up and more exposed to potential loss. In addition, many corporate databases that users need to access cannot be downloaded to a local device because they are far too large for network transition or must be used by many users simultaneously not locked for use by one individual.

Resource utilization. VDI desktops accessed by a remote protocol run in server memory and on server processors, thus mandating multiprocessor servers with many gigabytes of memory, while the inexpensive memory and processors on the remote desktop are rarely stressed in VDI scenarios. Organizations will need to calculate the trade-offs, particularly for users whose requirements can be met by lighter-weight solutions, such as applications running on an inexpensive PC and accessing small amounts of corporate data over a relatively inexpensive VPN.

Improved desktop access. Organizations increasingly have to provide desktops for employees of another organization who need access to complete an assignment or to employees of the organization working from a remote location on a device that's not owned and managed by the organization. VDI allows the organization to offer and control such access.

Consideration of these factors may help an organization determine whether deploying a VDI makes sense. But before jumping to VDI to address these factors, the organization should consider whether or not the same goals can be accomplished by deploying RDS session virtualization instead.

Session Virtualization Versus VDI

Remote Desktop Session Host provides a type of virtualization that is sometimes referred to by Microsoft as session virtualization (formerly presentation virtualization or Terminal Services) because users watch and interact with the applications via an RDP protocol, and because a separate session is created for each user. This is the classic "multiuser" scenario in which all users share the same OS instance (of Windows Server), but each user gets his own session. In contrast, a VDI user gets her own OS instance (of Windows 7, for example) running in a VM on the host server.

Because RDSH and VDI deployments share the same RDC and RDP, neither has an advantage on client devices. From an organizational perspective, however, both approaches have pros and cons. (For a more detailed comparison, see the chart "Remote Desktop Session Host Versus VDI".)

RDSH pros. The main reason for using RDSH is that the same physical server hardware can host more RDSH user desktops as sessions than VDI user desktops in VMs (RDSH can support greater desktop density with each desktop still providing good response times to remote users). In addition, RDSH technology has been supported for several years, and administrators are familiar with the management and maintenance of RDSH servers. In the past, application compatibility has been one of the main reasons for not using RDS, because many applications were not designed to run in sessions. Improved applications and use of App-V have removed most application compatibility and conflict problems for applications running in an RDSH session.

RDSH cons. The main reason for not using RDSH is that users with significant processing requirements may negatively impact the performance of other users, and there is less isolation in the event of some failure in a session versus the failure of a VM. VDI allows running VMs to be moved from one physical host server to another without any noticeable interruption perceptible to the user. Finally, VDI provides more capability for the user to personalize the desktop than RDS. (For more details on personalization of desktops in VDI, see the sidebar "Desktop Personalization in VDI".)

Organizations looking to centralize the delivery of desktops for management and data security reasons might do well to start by deploying RDSH pilots for specific groups of users, and only migrating to VDI in those specific cases where RDSH is inadequate for some business reason.

Client Decisions

Several decisions about the client will affect VDI deployment. For example, if the organization leaves distributed PCs in place rather than replacing them with thin-client terminals, each PC must still be updated with patches and antimalware signature files to ensure it does not become a pathway for malware into the organization or cause a security breach. While management should be simplified if each PC is only running the desktop OS and RDC, remote management requirements remain.

Deploying a zero-client terminal device may achieve the greatest reduction in remote administration, as these low-cost devices have no local storage or OS. When powered on, they connect to a server to download the most recent and up-to-date terminal (client) OS and an RDC. This occurs quickly because the OS has to support only the execution of the RDC. These components can be updated as needed on the central server. If a terminal device fails, the user can disconnect the broken one and plug in a replacement. Although a replacement PC could be sent to a user with a failed computer, the cost of maintaining spare or replacement PCs will be much higher.

Server Decisions

To be effective, VDI requires high-end server hardware. Because of the complexity of the server hardware, an organization should work closely with its server hardware vendor to determine the best equipment for a specific VDI deployment.

Microsoft's current guidance (provided at TechEd in June 2010) indicates that disk input-output (I/O) is the most likely bottleneck, followed by memory, and finally the processor. Disk I/O and processor affect both performance and density; memory affects density. The disk I/O, memory, and processor need to be sized to provide adequate I/O throughput and performance to handle the most demanding user connection scenario (typically the beginning of the workday when multiple VMs will be starting at the same time).

The server hardware where the VMs will be running needs to include storage that supports enough disk I/O and potentially Windows Failover Clusters to support migration of running VMs. Microsoft recommends storage area networks (SANs) using high-speed interconnects (iSCSI or Fiber Channel are both acceptable) and configured with a large cache to ensure disk performance is optimized. Network-attached storage is generally too slow to support VDI. Microsoft also recommends that, if possible, the SAN should support removal of duplicate files (deduplication).

In determining storage requirements, organizations have to consider not only the storage requirements of operating VMs but also where corporate and user data will be stored. For example, VDI deployment will be easier if the organization has already deployed folder redirection so that users can access data from any device and Roaming Profiles to manage each user's individually unique settings and preferences.

As is generally the case, more memory is better in VDI scenarios. For Windows 7 desktops, Microsoft recommends allocating at least 1GB of RAM per VM and adjusting the amount of memory upward as needed to prevent the VM from paging to disk. A good rule of thumb is that Windows 7 on a VM with 1GB of RAM will work like Windows 7 on a netbook with 1GB of RAM. Dynamic memory support, due with Windows Server 2008 R2 SP1, will make this easier to manage as memory will be configurable on the fly. The amount and speed of memory that can be installed in a server is determined by the number of physical memory slots and the type of memory they can use.

Processors should support AMD's Nested Page Tables or Intel's Second Level Address Translation (SLAT); Microsoft indicates that processors that support SLAT can provide a 25% improvement in density.

Microsoft guidelines for Hyper-V indicate approximately 8 VMs per processor core—this is not an architectural limit but rather reflects what Microsoft has tested and supports. Although the ability to move a VM from one host to another can be useful, it requires well-matched servers. The source and destination hosts must have processors from the same manufacturer (e.g., Intel or AMD), must be part of the same Windows failover cluster and must have access to shared storage. If the physical servers have different amounts of memory, it may be difficult to move all the VMs running on the server with more memory to the server with less memory.

No Silver Bullet

VDI is not a silver bullet that will cure all administrative problems when deploying user desktops in an organization.

According to Microsoft, VDI typically does not provide lower overall ownership costs, given the costs of server hardware to support the same number of users, particularly in comparison to RDSH. Microsoft indicates that if an organization has already implemented centralized management of the desktops, using technologies such as Group Policy, Folder Redirection, and Windows Server Update Services or System Center Configuration Manager, the effect on costs by implementing VDI could be minimal. However, many organizations report substantial savings from VDI related to lower desktop hardware, maintenance, and upgrade costs.

The best candidates for VDI are users who employ applications for which the organization must ensure that all data is adequately backed up and safe from inadvertent destruction or exposure; users of critical legacy applications that do not run on current OSs; or users with unique or temporary requirements, such as contractors, temporary employees, and permanent employees working from remote sites or connecting from home with a PC that's not managed by the organization.

Resources

For more information on Windows-based virtual desktop infrastructure (VDI), see www.microsoft.com/virtualization/products-desktop.aspx and www.microsoft.com/virtualization/resources.aspx.

Details of licensing Microsoft software for VDI are described in "Virtual Desktop Infrastructure Licensing Suite Available" on page 23 of the Jan. 2010 Update and "Licensing a Windows-Based VDI Infrastructure" on page 25 of the Jan. 2010 Update.

Licensing of Remote Desktop Services is covered in the Nov. 2009 Licensing Outline, "Windows Server 2008 R2 Packaging, Licensing, Pricing."

For more information on Remote Desktop Services, see www.microsoft.com/windowsserver2008/rds-vdi.aspx.

Details of the change from Terminal Services to Remote Desktop Services are described in "Terminal Services Renamed and Updated" on page 3 of the Sept. 2009 Update.

Additional information on Windows Server 2008 R2's hypervisor technology is available at www.microsoft.com/windowsserver2008/hyperv-main.aspx.

Details on improvements to Hyper-V in Windows Server 2008 R2 are described in "Hyper-V R2 Gains Live Migration" on page 3 of the July 2009 Update.