Windows Server 2008 R2: Understanding Microsoft VDI

There are a number of approaches and different technologies within the umbrella of Virtual Desktop Infrastructure.

Kristin Griffin

Virtual Desktop Infrastructure (VDI) can mean different things to different people. Having more than one definition can lead to some confusion, but fundamentally, it’s a way of using virtual machines (VMs) to deploy desktops in a datacenter. You can assign these VMs to a particular user (personal VMs) or a pool of available VMs shared among users with the appropriate permissions (pooled VMs).

The modern VDI typically has some built-in intelligence. Users often don’t even have to know the name of the VM they want to use. The connection broker confirms the user credentials upon connection and finds the most appropriate VM for that user based on the permissions and rules.

The closest analogs for VDI are sessions, unmanaged user VMs and blade PCs:

• VDI differs from sessions on a shared RD Session Host server because VMs are more isolated than sessions.
• Unmanaged VMs have no intelligence built in to route a user to the most appropriate VM. They rely on the user knowing the name of the VM they want.
• Blade PCs isolate users onto physical blades, not VMs.

Microsoft Remote Desktop Services supports desktops hosted from both sessions and VMs. You can extent the Microsoft RD Connection Broker with third-party tools to support other resource types, like blade PCs. Microsoft VDI uses the Hyper-V hypervisor and requires Windows Server 2008 R2 or later (some VDI features require Windows Server 2008 R2 SP1).

VDI or Sessions

Those new to desktop virtualization may wonder whether VDI or session-based virtualization is the better choice. Generally, sessions should be the default choice. Session-based desktop virtualization is less expensive than VDI, and you can support more people on the same server with sessions than with VMs. However, VDI is a good choice when sessions aren’t an option. For example:

• The applications you want to use don’t work or aren’t supported in a shared session, but are supported on a VM.
• The virtualized desktop needs to be assigned to the same person all the time (for example, if that person needs to install applications or otherwise make permanent changes to the VM).
• You need a feature only available to VDI (such as USB remoting available with RemoteFX).

You can use session-based desktops and VDI to complement each other when you have differing user needs. If only a few people require VDI functionality, you can save money by giving sessions to most of your users and using VDI only for those people for whom it’s important.

You can use RemoteFX enhanced bitmap remoting with sessions, but for USB redirection or a virtualized GPU, you’ll need to use VDI. Those RemoteFX features are available only on Microsoft VDI (for more information on using RemoteFX with RD Session Host, see the links at the end of this article).

Setting up VDI

To set up a simple Microsoft VDI deployment, you’ll need:

• A server running the RD Virtualization Host role to host client VMs
• RD Connection Broker to route connection requests to the right VMs
• A redirector (RD Session Host server in drain mode) to redirect incoming requests to the RD Connection Broker (you can also use the RD Connection Broker server as the redirector)
• Access to Active Directory to grant permissions to VMs
• Access to an RD License Server to provide VDI client access licenses once the grace period is over
• Client VMs running Windows XP SP3 or later (personal or pooled VMs)
• An RD Web Access server to simplify VM discovery through RemoteApp and Desktop Connections or RD Web Access Web site (optional, but recommended)

For a lab or small pilot deployment, you can put all these roles onto a single physical server (Greg Shields wrote about doing this). For a production environment, you’ll likely split the roles among more than one physical server to improve redundancy and scale.

Setting up Microsoft VDI involves the following steps:

1. Install the RD Virtualization Host (which installs Hyper-V and the VM Host agent to let the RD Connection Broker spin up VMs as needed)
2. Create the client VMs
3. Configure the client VMs (install patches/updates and enable access)
4. Configure the client VMs to allow remote procedure call (RPC) access and add needed exceptions in the firewall (there are scripts to do this)
5. Install RD Connection Broker and the redirector
6. From RD Connection Broker, organize the VMs into pools (for pooled VMs) or assign the VMs to individuals (for personal VMs)
7. From the RD Virtualization Host, configure rollback for the pooled VMs and configure licensing
8. If using RD Web Access to aid discovery, configure the RD Web Access role service to get the VM information from the RD Connection Broker

Size VDI Deployment

Sizing the VDI deployment is mostly a matter of sizing two servers: the RD Virtualization Host and the RD Connection Broker. The links at the end of this article point you to sizing guides for both RD Virtualization Host servers and the RD Connection Broker.

Sizing the RD Virtualization Host is like sizing other Hyper-V servers. The load depends on how many VMs you expect to be active, and each VM’s memory, processor and disk I/O demands. You can’t virtualize the RD Virtualization Host server because it’s a Hyper-V server.

Given the RD Connection Broker doesn’t proxy the connections to the VMs, sizing the RD Connection Broker is a matter of working out the number of simultaneous connections that the broker will need to handle. Once you’ve identified the target VM to the client, the broker is no longer involved. You can then virtualize the RD Connection Broker.

This covers what VDI is, and why you might deploy pooled or personal VMs. There are differences between sessions and VMs, and different times when each is the more appropriate virtualization choice. This ought to help you implement a simple VDI deployment. Next month’s article will cover the RD Connection Broker and its central role in VDI and RD Session Host farm deployments.

Kristin Griffin is a Remote Desktop Services MVP. She moderates a Microsoft forum dedicated to helping the server-based computing community (social.technet.microsoft.com/Forums/en-US/winserverTS/threads/) and maintains an RDS blog at blog.kristinlgriffin.com. She’s a contributor to Mark Minasi’s “Mastering Windows Server 2008” (Sybex, 2008) and “Mastering Windows Server 2008 R2” (Sybex, 2010), She also coauthored “Microsoft Windows Server 2008 Terminal Services Resource Kit” (Microsoft Press, 2008) and “Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit” (Microsoft Press, 2010) with Christa Anderson.

Related Content

• Sizing RD Connection Broker
• RemoteFX on RD Session Host
• Script to configure a VM for Microsoft VDI

Top 5 VDI Q&A