VIRTUAL DESKTOP MANAGEMENT TIPS
How to install Microsoft VDI and key deployment considerations
Greg Shields, Contributor
06.12.2009
Rating: -5.00- (out of 5)
Microsoft virtual desktop infrastructure (VDI) may be right for your environment, but if you choose to install it, you should consider the substantial hardware requirements to support it. And that can mean additional costs and management requirements as well.
This tip, the third in a four-part series on Microsoft VDI, outlines how to get started with VDI in Windows Server 2008 R2, how to install it in your environment and some of the considerations in installing Microsoft VDI.
If you're interested in reviewing the rest of the series, part one explores when Microsoft VDI is worth the cost investment , and part two discusses how Microsoft VDI, with Hyper-V and enhanced Terminal Services, can bring low-cost VDI closer to reality.
Prerequisite components for Microsoft VDI
As I've indicated already, if you're considering VDI, there are some caveats. First, you'll have to wait a few months to use Microsoft VDI in production environments. The necessary components are currently in the release candidate phase, with final versions expected later in 2009. In terms of servers, implementing Microsoft VDI requires Windows Server 2008 R2 for Hyper-V virtualization and the transport and orchestration capabilities of Remote Desktop Services (RDS).
On the client side, VDI requires Remote Desktop Client (RDC) v6.1 if users need to connect to hosted desktops through a Remote Desktop Web Access (RD Web Access) site. For environments that need Start Menu access to RDS applications and hosted desktops, Microsoft will eventually provide this capability as a new feature in Windows 7 that will be coupled with the next version of RDC. This expanded client functionality -- called RemoteApp and...
To continue reading for free, register below or login
To read more you must become a member of SearchVirtualDesktop.com
Desktop Connection -- enables administrators to alter available applications through the RDS console and have these changes automatically register on client Start Menus. If you're familiar with Citrix Systems Inc.'s XenApp Plugin for Windows, which was formerly known as Program Neighborhood Agent, Microsoft's technology provides similar functionality.
Implementing Microsoft VDI
With the resources currently available, getting started with Microsoft VDI is no easy task. At the most basic level, a single Hyper-V server for VDI requires at least four physical servers, such as the following:
- Remote Desktop Virtualization Host server. The first physical server required is installed with the RD Virtualization Host role, which has Hyper-V as a prerequisite, in order to host virtual machines (VMs). Several RD Virtualization Host servers can be pooled to create a larger array of virtual hosts.
- Remote Desktop Connection Broker. The second physical server hosts the RD Connection Broker service that identifies which users should be connected to certain RD Virtualization Host servers and, ultimately, the VMs hosted on them. For environments that create farms of Remote Desktop servers to host traditional Terminal Services applications, this server can also orchestrate users by sending them to RDS servers as well.
- Remote Desktop server. This server hosts the Remote Desktop server role and operates much like a traditional Terminal Server because its job is to redirect users to the correct VM. Unlike the RD Connection Broker server, which tracks users and their connections, this server transfers users to a specific VM. When you create an RDS server for VDI, you need to configure the server to operate in "Redirection mode." Once you set a server to this mode, it no longer operates as a traditional Terminal Server because it can be used only for redirecting users to hosted desktops.
- RD Web Access. For environments that haven't upgraded to Windows 7, users can access their hosted desktops by clicking-on the appropriate link in an RD Web Access server. The RD Web Access server can also be used to enumerate traditional Terminal Services applications in addition to hosted desktops.
Clearly, just getting started with Microsoft VDI requires a substantial server hardware infrastructure. A major percentage of hardware used to support Micrsofot VDI is dedicated to the creation of one or more RDS servers whose sole function is to redirect users to their assigned hosted desktops.
This initial investment in hardware becomes more costly when you consider the restrictions on the RDS server. Microsoft's documentation states that a single Remote Desktop server cannot provide redirection for both virtual desktop pools and personal virtual desktops. This means that if you want to deploy VM pools, as well as user-linked personal desktops, you must build two RDS servers to handle the redirection. In addition, each pool of VMs requires another RDS redirector. Depending on how you plan to assign VMs to users, this requirement can significantly increase the number of servers you have to manage.
If all of these requirements have your head swimming, Microsoft has written a comprehensive document on implementing VDI. The document details the necessary steps to install and integrate each of these components with one another.
Using Microsoft VDI
Once your components and hardware are properly configured, the next step is to create the VMs you need and enable them for users. When creating virtual machines, the following configurations are necessary to ensure that these VMs function correctly in a VDI environment:
- Every VM must be a member of the same Active Directory domain. VMs that aren't present in the domain or live in other domains -- even across trusts -- will not function.
- Enable and configure the Remote Desktop component. VMs must have Remote Desktop enabled because it provides the transport functionality to connect incoming users.
- Assign the correct permissions. The computer account for the RD Virtualization Host server must be added to Microsoft's local Administrators group of virtual machines. Also, any user that connects to the VM must be added to that machine's local Remote Desktop Users group.
- Prepare the machine for remote management and use. When completing this step, make sure that the machine has the latest version of Integration Services for Hyper-V installed. If the Windows firewall is enabled for on-domain connections, create an exception for Remote Desktop and Remote Service Management for the appropriate network locations. Finally, allow Remote Procedure Call connectivity by setting the registry value for AllowRemoteRPC to 1 in the location HKLM\System\CurrentControlSet\Control\Terminal Server.
Once you've created the necessary number of virtual machines, you can assign them to users as personal desktops or create a pool by using the RAD Connection Manager under Administrative Tools on the RD Connection Broker server. There, under the Virtual Desktops node, click to create a new virtual desktop pool. The wizard will provide a location for identifying the VMs to be added to the pool, the farm name and the RDS server that will be used for redirection.
Assigning personal virtual desktops
Personal virtual desktops are assigned in a different location from personal desktops. Assigning a personal virtual desktop to a user is done within the Active Directory Users and Computers node. To use this feature, you must use the Windows Server 2008 R2 version of the Active Directory Users and Computers node . Once there, right-click to view the properties of a user account and look for the Personal Virtual Desktop tab. You'll be asked for the computer name of the VM to assign and the Virtual Machine Name that corresponds to that VM's Hyper-V host.
Assigning personal virtual desktops requires Active Directory to operate at the Windows Server 2008 forest functional level. Also, there can be only a one-to-one connection between users and desktops. This means that a desktop can be assigned only to a single user and that a user can have only one personal virtual desktop.
Microsoft's VDI technology is basically made up of a bunch of moving parts. As I explained in part one of this series, this is crucial because VDI has a fairly limited set of situations where it is an essential solution. As such, implementing Microsoft VDI requires you to factor in the high expense of simply setting it up.
In creating this infrastructure though, Microsoft has included several extensibility points into the system where third-party components can be integrated to make things easier for admins and their users. The fourth and final tip in this series will highlight a few of these interoperability areas that are emerging.
[IMAGE]Greg Shields, MCSE, is an independent author and consultant based in Denver with many years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization. His recent book Windows Server 2008: What's New/What's Changed is available from Sapien Press.
|
|
|
|
|
|
