Share via

Geek of All Trades

  • Article

Add Hyper-V to RDS for Inexpensive Virtual Desktops

Greg Shields

Hosted virtual desktops are not a solution for all of your application problems.

These virtualized desktops, which are hosted atop Hyper-V and transported to users via Remote Desktop Services (RDS), consume plenty of server resources.  They involve more steps to install and manage than traditional RDS.  You’ll need comparatively more server hardware to support the same number of concurrent users. Their additional storage requirements can add extra cost.

And yet, organizations both large and small seem to be exploring virtual desktops in greater numbers all the time. If 2008 and 2009 could be called “the years for server virtualization” in the IT media, then all signs point to 2010 and beyond as “the years of desktop virtualization.”

If many of the obvious markers suggest that hosted virtual desktops are more complex, more expensive, and involve more effort than traditional RDS, why are we still talking about them? Because, simply put, they work.

RDS, like its ancestor Terminal Services (TS), is an optimized solution for connecting users to their applications. Creating a TS or RDS server and installing applications to it has long been a mechanism to consolidate applications back into the datacenter. Server-based computing has its own long history in using the network as the transmission medium for rich access to applications and data.

Yet in both TS and RDS, one limitation has remained as a stumbling block for many environments. Simply put: some applications just don’t work well with remote services technology. Others might work, but require registry customizations or other hackery that goes beyond the experience of the jack-of-all-trades IT pro. Eliminating the session-based complexities of TS/RDS and installing applications on a one-to-one basis to virtual desktops skirts many of these issues.

Among all the reasons to augment RDS with virtual desktops, getting a handle on application conflict and performance management for problem applications is one of the best. Adding virtual desktops to your other mechanisms for connecting users to applications and data can be a very smart solution for your small business.

Virtual Desktops in a Box:  Four Role Services, One Server

The inclusion of virtual desktops in Windows Server 2008 R2 makes their installation compelling from a budgetary perspective. If you have a Windows Server license lying around, you’ve already got what you need to get started.

In this example, I’ll show you how to use that license to create a kind of “virtual-desktops-in-a-box.” You can use this single-server environment for evaluating the technology, or even for small-environment production use. Users who connect to their virtual desktops in this environment will do so via a Web page automatically generated by Remote Desktop Web Access. From that single Web page, users can select their Personal Virtual Desktop, a virtual desktop that has been specifically linked to their user account.

Creating such an environment requires the installation of the RDS role along with four of its role services, all to this single server:

  • RD Session Host.  This role service handles the session-based functionality that’s traditionally associated with RDS or TS. In this example, the RD Session Host will be used in “redirection mode” to transfer the virtual desktop’s screen, keyboard and mouse commands using the Remote Desktop Protocol.
  • RD Connection Broker.  In this environment, the connection broker’s primary job is to connect users to their correct virtual desktop.
  • RD Web Access.  This role service, which also installs components of IIS, creates and manages the Web page end users will access to connect to their virtual desktops.
  • RD Virtualization Host.  This role service adds functionality to Hyper-V, enabling it to serve virtual desktops to users. Installing this role service also installs the Hyper-V role if it is not yet installed. Remember in creating this “in-a-box” environment that the hardware of the selected server must support the minimum requirements of Hyper-V.

To get started, install each of these four role services along with their prerequisites onto the same computer. When prompted, select the defaults for each installation, and allow the computer to reboot.

Creating Your First Virtual Desktop

Once these services are installed, you’ll have a number of different configurations to complete in order to interconnect them. You’ll also need to build and specially configure a Windows 7 desktop computer that will eventually become your first virtual desktop. It’s best to start this process by installing and configuring that desktop’s virtual machine and OS, because you’ll need its information in a later step.

The process of creating a Windows 7 virtual desktop is much like any new virtual machine creation. You begin by navigating to the Hyper-V Manager and creating the virtual machine just like any other virtual machine. Assign the virtual machine an appropriate amount of RAM and hard disk space, as well as the correct network.  Connect its physical CD/DVD drive to your Windows 7 ISO file and proceed with the installation. Remember the unique name you assign to this virtual machine, because the RD Connection Broker will need this information to connect the user to his virtual desktop.

Give the new virtual desktop a name and IP address, and connect it to your domain.  Next, you’ll need to complete a few special configurations to prepare the OS to become a remotely accessible virtual desktop. Those special configurations are detailed here (each should be completed within the virtual desktop’s virtual machine OS):

  • Enable Remote Desktop. To allow remote connection to this computer, you’ll obviously need to enable it for Remote Desktop Services. Do this by viewing Computer | Properties , selecting the Remote settings tab, and clicking the radio button for Allow connections only from computers running Remote Desktop with Network Level Authentication.
  • Add the user to the Remote Desktop Users group. Users that aren’t administrators must be specifically added to the computer’s local Remote Desktop Users group. Do this in Local Users and Groups by adding the user’s domain user account to the Remote Desktop Users group.
  • Allow remote RPC for RDS. You will need to make a registry change to enable remote RPC for the desktop. In the virtual desktop’s registry path HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer, change the REG_DWORD value for AllowRemoteRPC to 1.
  • Enable a firewall exception. If your environment uses Windows Firewall, you’ll need to add a program exception for Remote Service Management.
  • Modify RDP protocol permissions. This final configuration requires you to enter a series of commands into an elevated command prompt on the virtual desktop. Those commands are listed here in order. In each, replace {domain} with your domain’s NetBIOS name, and {rdv_host} with the name of the Hyper-V server:
wmic /node:localhost RDPERMISSIONS where TerminalName="RDP-Tcp" CALL AddAccount "{domain}\{rdv_host}$",1

wmic /node:localhost  RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='{domain}\\{rdv_host}$'" CALL ModifyPermissions 0,1

wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='{domain}\\{rdv_host}$'" CALL ModifyPermissions 2,1

wmic /node:localhost RDACCOUNT where "(TerminalName='RDP-Tcp' or TerminalName='Console') and AccountName='{domain}\\{rdv_host}$'" CALL ModifyPermissions 9,1

When you’ve completed these configurations, reboot the computer and ensure that it remains powered on but logged off. With the computer logged off, your user will be able to log into her virtual desktop once the final configurations are complete.

Connecting the Four Role Services

Now that you’ve created and prepared your first virtual desktop, you’ve got a few final steps to interconnect the four role services. These steps involve making the RD Connection Broker and RD Web Access servers aware of each other, setting up the connection to the personal virtual desktop and, finally, assigning a user to it.

Step one entails telling the RD Connection Broker which computer you intend to use as your RD Web Access server. Do this by navigating to your server’s Local Users and Computers and adding its computer account to the TS Web Access Computers group.

 

Figure 1 Configuring RD Web Access

In step two, you configure an RD Connection Broker source within RD Web Access.  This process completes the connection between these two role services.  You can accomplish this by navigating to Administrative Tools | Remote Desktop Services | Remote Desktop Web Access Configuration.  This link will launch Internet Explorer and connect it to the local computer’s RD Web Access management page. After logging in with your administrator credentials, you should see a screen similar to Figure 1. There, ensure that the radio button next to An RD Connection Broker server is selected. Because the two roles are on the same computer, you can safely leave “localhost” in the Source name box.

Completing this second task creates the necessary connections so that your users can navigate to this server’s Web page to later find their virtual desktop.

Step three involves actually configuring the connection to your virtual desktop. This is accomplished in the new administrative tool named Remote Desktop Connection Manager (see Figure 2). As you can see, a number of settings have not yet been configured. We’ll configure those settings now.

 

Figure 2 Remote Desktop Connection Manager

This console comes equipped with a wizard that starts the process for connecting to virtual desktops. Click the link in the Actions pane titled Configure Virtual Desktops Wizard. The wizard first asks for the name of the RD Virtualization Host server. This server corresponds to the Hyper-V host that powers your virtual desktops’ virtual machines.

 

Figure 3 Configure Virtual Desktops Wizard

In the next screen, you’ll be asked for the fully qualified domain name of your RD Session Host server (see Figure 3). You’ll also see configurations for redirecting down-level clients—those that are not running version 6.1 of the Remote Desktop Connection client—to an alternate server. In the case of this “in-a-box” example, both this and the previous screen should be configured to point to the single server where all four of the role services have been installed.

Next up is configuring the RD Web Access server. This server may already be specified as part of previous configurations. Clicking Next and Apply will complete the configuration; however, one more setting is required to link the virtual desktop with the user. This console can be automatically launched in the final page of the wizard by ensuring the box marked Assign personal virtual desktop is checked.

 

 

Figure 4 The Personal Virtual Desktop Wizard

Personal virtual desktops are linked specifically to individual users on a one-to-one basis.  This means that any particular user will have exactly one personal virtual desktop, and each personal virtual desktop will have just one user. This link is created using the Assign Personal Virtual Desktop Wizard, shown in Figure 4.  There, a user name is associated with a virtual machine. In the figure, you can see how the administrator user has been linked with the virtual machine named w7-vdesktop.contoso.com.

 

Figure 5 Accessing a Personal Virtual Desktop via RD Web Access

Once the wizard is complete, your user can connect to the RD Web Access Web site (https://localhost/RDWeb) to access his personal virtual desktop. That virtual desktop will appear as an icon labeled My Desktop on the Web page after the user logs in (see Figure 5).

Personal Virtual Desktops Are Only the Start

While this article might have started off with some complaints about the pains of desktop virtualization, you’ve probably found that this process for creating personal virtual desktops really isn’t all that difficult. Microsoft’s solution for virtual desktops only begins with this “in-a-box” configuration. With extra effort, you can expand your environment to multiple Hyper-V servers as well as build different configurations that are better suited for certain needs.

One such configuration might eliminate the direct link between a virtual desktop and its user. With the same equipment, you can also create pooled virtual desktops, which are similarly configured desktops to which users are randomly assigned when they initiate a connection. These pooled virtual desktops are great solutions for applications that are problematic for RDS; however, they require special care as users are never guaranteed to connect to the same virtual desktop every time.

Notwithstanding the potential issues, the most valuable lesson you should take from this month’s column is that desktop virtualization dramatically increases the number of different ways you can connect users to their applications and data.  Finding the most nearly correct one for your needs is your next challenge.

Greg Shields*, MVP, is a partner at Concentrated Technology. Get more of Shields’ Geek-of-All-Trades tips and tricks at ConcentratedTech.com.*

Related Content