Virtual desktop infrastructure is all the rage these days -- and for good reason. VDI can significantly reduce hardware and management costs for desktop computers. While many IT professionals know of VDI's benefits, since the technology is still relatively new, they don't know how to get started with it. The good news is that almost everything you need to deploy VDI is built into Windows Server 2008 R2. (I say almost because you also...
need a desktop operating system like Windows 7 for each virtual desktop.)
The server architecture
A typical VDI deployment uses four servers, each running Windows Server 2008 R2. This isn't counting infrastructure servers, like domain controllers and domain name servers, since these servers should already exist on the network.
The first required server must be configured as a Remote Desktop Web Access server. If this server role is completely foreign to you, it may be because Microsoft renamed Windows Terminal Services as Remote Desktop Services. The RD Web Access role was previously Terminal Services (TS) Web Access.
With the Web Access server users can access a Remote Desktop session through either the start menu or a Web browser. In this case, the user won't be using an interactive Remote Desktop session, but rather a full-blown virtual PC. Regardless, several of the server roles related to Remote Desktop are used to facilitate the connection.
After the user has established a connection to the Remote Desktop Web Access server, the server passes the request to a Remote Desktop Session Host server, as shown Figure 1. Normally, a Remote Desktop Session Host server hosts the applications run by Remote Desktop (Terminal Services) clients. However, in this case the session host server must operate in redirection mode.
Redirection mode prevents a user from running apps that live on the server (unless the user has established an administrative session). In addition, the session host server knows that the user is trying to request a virtual machine (VM) rather than attempting to run a hosted application. As a result, the server forwards the user's request to a Remote Desktop Connection Broker server.
The connection broker server determines if the user has already established a virtual desktop session. If the user has an active session, the connection broker server sends the name of the user's current VM to the session host server. Otherwise, the connection broker server contacts the Remote Desktop Virtualization Host server.
Note: Microsoft's documentation is inconsistent in describing how the session host server and the connection broker server should be configured. Some of the documentation indicates that Microsoft recommends hosting the session host and the connection broker on the same server. Other documentation indicates that separate servers should be used. While it is unclear which configuration is preferred, both configurations are supported.
The final server in this VDI configuration is the Remote Desktop Virtualization Host server, which maintains the pool of virtual desktops, and uses Hyper-V.
When the connection broker sends the request to the virtualization host, the virtualization host server initializes a VM on behalf of the user who made the request. The virtualization host then provides the connection broker with the name of the VM that will be used for the user's session. The connection broker passes the VM name to the session host, which provides the VM name to the client that requested it.
The virtual desktop pool
As shown in Figure 1 above, the virtualization host server hosts a pool of virtual desktops. Each virtual desktop in the pool is an independent VM.
Normally, VMs from the pool are dynamically allocated to users. And since users don't know which VM they will be connected to, make sure every VM in the pool is configured identically to maintain a consistent user experience. Also, it is important to design the user's profiles so that data is saved to a network location rather than to a VM's local disk resources.
But identically configuring every VM isn't always practical. After all, users may require varying sets of applications depending on their job functions. For example, someone in the finance department needs a different set of apps than someone in IT.
In these situations, the solution is to create multiple desktop virtualization pools. Each pool should represent a different virtual desktop configuration -- but all the VMs in a pool should be configured identically.
Occasionally, administrators (and power users) require more flexibility than the standard user. Rather than creating a separate pool for such users, build a set of personal virtual desktops. A personal virtual desktop is a VM that has been dedicated to a specific user through an Active Directory setting. Such a configuration ensures the user will have with the same VM in every session.
Deploying VDI and providing users with a pool of virtual desktops is a fairly easy process. For additional help, download Microsoft's step-by-step configuration instructions.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities and was once a network administrator for Fort Knox. You can visit his personal website at www.brienposey.com.