Article: Windows Server 2008 R2: Understanding Microsoft VDI | TechNet Magazine

Windows Server 2008 R2: Understanding Microsoft VDI | TechNet Magazine
http://technet.microsoft.com/en-us/magazine/hh407117.aspx

---

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

Top 5 VDI Q&A

Q: Do I need to secure both pooled and personal virtual machines (VMs)? A: You should lock down both pooled and personal VMs to ensure that users can only run the applications or access the file locations to which they should have access. It's also a good idea to have some kind of antivirus protection on the VMs to avoid attacks from in-memory viruses.     Q: What is rollback and why might I need it? A: Rollback is a Microsoft Virtual Desktop Infrastructure (VDI) feature that restores a VM to a saved state when a user logs off the VM. This feature relies on Hyper-V snapshot technology. Its purpose is to preserve the state of a shared VM so one person doesn't change the VM permanently. When a user logs off of a pooled VM, the VM is reverted to a state previous to user interaction, and the new user gets access to an untouched VM.     Q: How do users find their VMs? A: Connectivity is handled through settings found in a Remote Desktop Protocol (RDP) file that point to the type of resource desired (VM or session), type of VM (pooled or personal), name of the VM pool (if appropriate) and many other connection settings that define the user experience. RD Web Access provides an easy mechanism for VM discovery. A user will log in to the Web site and assigned personal VMs will be available via an icon. If the user has permission to access a VM pool, there will be an icon for the pool. Discovery is an optional component of VDI, but it can greatly simplify life for the VDI manager and the people trying to connect to their VMs. Without the RD Web Access role service to aid discovery, you'll need to share the RDP files explicitly with all users. Any changes to this access would require a re-dispersal of the RDP file.     Q: What happens if you request a pooled VM but it's turned off? A: If the VM to which the RD Connection Broker directs a user is powered down, the VM Host Agent on the RD Virtualization Host server will power on the VM. This is a process known as orchestrating the VM. When the VM is powered on, the VM Host agent will return the VM's IP address to the RD Connection Broker, which will send it to the redirector, which will send it to the client attempting to make the connection so it can connect directly to the VM.     Q: At what state should I snapshot my VMs for rollback? A:

A VM snapshot will take the machine back to a particular point in time. With that in mind, make sure the VM is in a clean state when you snapshot. No one should be logged on to the VM. If the VM is powered down, do so cleanly (you don't want the VM reverting to a state where it asks you if you want to enter safe mode).

—K.G.

 

---

(via Instapaper)

Brief message sent from a mobile device