Geek of All Trades: VM-Hosted RemoteApps - New Best Practice for Virtual Desktops?

Using virtual machine-hosted RemoteApps could be the necessary next step in remote application access.

Greg Shields

(This was written using the Windows Server 8 release candidate. All information is subject to change.)

In the beginning, there were Terminal Server desktops, and they were a good start. They delivered a “contained” type of experience. Remote applications lived within the Terminal Server desktops, but the experience was confusing. Applications and data could exist in either of two locations—on a user’s local desktop or on their remote Terminal Server desktop.

Then, one day, RemoteApp was born. This changed everything. Suddenly, remote applications could be delivered as applications. The need for double desktops disappeared. Confusion diminished.

Later, virtual desktops became popular. Leaning on successes in server virtualization, we sought to also virtualize desktops. It was a good start. These virtual desktops also delivered a “contained” experience. Remote applications lived within virtual desktops, but the experience was also confusing. Applications and data could exist in either of two locations—on a user’s local desktop or on their remote virtual desktop.

Then, one day, the virtual machine (VM)-hosted RemoteApp was born. Once again, everything changed. What’s different this time is where the applications are installed—on virtual desktops instead of Remote Desktop Services (RDS) hosts. Suddenly, remote applications could be delivered as applications again. The need for double desktops disappeared. Confusion diminished.

History certainly has a way of repeating itself. In fact, VM-hosted RemoteApp programs in Windows Server 2012 might have arrived at a key moment in IT history, just when we again see limitations in delivering yet another desktop.

Next Evolution in Virtual Desktops?

To appreciate VM-hosted RemoteApp programs, you must first recognize the problems server-hosted RemoteApp programs don’t solve. As you know, RDS provide a capable platform for hosting most remote applications. You can access apps installed to an RDS host (called an RDSH) as long as you have privileges and a network connection.

Sometimes, though, an application and RDSH just don’t mix. Maybe that application doesn’t work well atop RDSH, or perhaps there’s a licensing issue in the way. Occasionally, an errant application just won’t install onto Windows Server. Finding the fix can be a time-consuming chore. These are some of the situations that drive IT toward virtual desktops. That problematic application works just fine on Windows desktops, so why not just use a Windows desktop?

Windows Server 2012 offers that alternative with RemoteApp programs that source from either virtual desktops or RDSH servers. The process starts in the Server Manager Add Roles and Features wizard. You create an RDS installation that hosts a VM-based desktop deployment. The wizard (see Figure 1) will configure the RDS role services to kick-start those VM-hosted RemoteApp programs.

Figure 1 VM-based desktop deployment is the foundation for VM-hosted RemoteApp programs.

Begin by selecting Standard deployment, then a VM-based desktop deployment. Doing so installs the Remote Desktop Connection Broker, Remote Desktop Web Access and Remote Desktop Virtualization Host role services. You can install these on the same server or multiple servers. Click Deploy in the wizard’s final page to begin installation (see Figure 2). Your Remote Desktop Virtualization Host server will need at least two NICs for the wizard to automatically create the Hyper-V virtual switch.

Figure 2 Deploying Remote Desktop Services Role Services to a single server.

Next, you’ll need to create a template VM to serve as your master desktop image. You can base this image on either Windows 7 SP1 or Windows 8, but only the Enterprise and Ultimate Editions of either OS will support VM-hosted RemoteApp programs.

Create the template VM within Hyper-V Manager. Then install and configure either Windows 7 or Windows 8. You can also install any applications you plan on deploying. For this example, let’s create a Windows 7 SP1 VM with Microsoft Office 2010 to illustrate the backward compatibility.

You have to Sysprep both Windows 7 SP1 and Windows 8 as your final step in building the template VM. Run the correct System Cleanup Action and Shutdown Options settings for Windows 7 SP1 (see Figure 3). Windows 7 SP1 also requires an update to the Hyper-V Integration Components prior to Sysprepping the VM. Do this by clicking Action | Insert Integration Services Setup Disk in your template VM’s Virtual Machine Connection window. You should also disconnect any connected devices (particularly DVDs) in the VM’s Settings screen once it has completed Sysprep and shut down.

Figure 3 Sysprepping a Windows 7 SP1 template VM.

VM-hosted RemoteApp programs are created from collections of similarly configured VMs. RDS in Windows Server 2012 can automatically create these from your VM template. Return to Server Manager and navigate to Remote Desktop Services | Collections. Under Collections click Tasks | Create Virtual Desktop Collection to launch the Create Collection wizard.

The wizard will prompt for a collection name, and then ask for a collection type (see Figure 4). VM-hosted RemoteApp programs generally work with pooled virtual desktop collections. Doing so delivers VM-hosted RemoteApp programs from any available VM within the pool without directly assigning VMs. The checkbox instructs RDS to automatically create and manage virtual desktops in the pool.

Figure 4 Specifying the collection type in the Create Collection wizard.

Continue through the Create Collection wizard, selecting the VM template you created and providing unattended installation settings. You’ll be asked to identify the users and groups that should have access to connect to the collection, as well as how many VMs you want RDS to initially create.

You’ll also be asked to specify a VM storage location (see Figure 5). Hyper-V in Windows Server 2012 supports a broader range of ways to store VM disk files. Some of those new ways are outlined in my May 2012 Geek of All Trades column.

Figure 5: Specifying the virtual desktop storage location in the Create Collection wizard.

The last wizard page specifies whether this collection will use user profile disks (see Figure 6). User profile disks are another new technology in Windows Server 2012. They let you store user profile settings independently of RDS-hosted VMs or RDSH servers. They’re similar to Remote Desktop roaming profiles, but far superior. User profile disks let users bring their user settings along as they connect to different VMs within a pool.

Figure 6: Enabling user profile disks helps facilitate VM sharing.

Click Create in the wizard’s final page to create the collection and begin cloning VMs from your desktop template. Sit back. This process can take an extended period of time. Once the cloning process is complete, you’re ready to associate RemoteApp programs with installed applications.

In Server Manager, navigate back to the collection you just created. Under RemoteApp Programs, click Tasks | Publish RemoteApp Programs. This wizard will scan virtual desktops in the collection, locate installed applications and present you with a list of RemoteApp programs (see Figure 7). Select the programs and click Publish to complete the wizard and create the RemoteApp programs.

Figure 7 Publishing the RemoteApp programs in the Publish RemoteApp Programs wizard.

Connecting Start Menus with RemoteApps

With one or more RemoteApps ready for delivery, your final task is to populate each user’s Start Menu with the necessary connections. You can do this on each Windows 7 or Windows 8 desktop via the RemoteApp and Desktop Connections control panel. Select Access RemoteApp and desktops.

You can connect a user’s Start Menu to a feed of RemoteApp (see Figure 8). The server name entered in the box will be your Remote Desktop Connection Broker. The rest of the URL will generally remain the same. Windows 8 will ship with new Group Policy settings that let you define this connection URL via Group Policy User Configuration.

Figure 8 You have easy access to RemoteApp and desktops.

You’ll also notice the connection URL must be HTTPS, which requires a Web server certificate on the Remote Desktop Web Access server. RDS in Windows Server 2012 has eased this process by incorporating it into the collection deployment properties.

Back in Server Manager, navigate to Remote Desktop Services | Collections. Under Collections click Tasks | Edit Deployment Properties, then select Certificates. Select RD Web Access and then choose to create a new certificate or select an existing certificate that has already been installed (see Figure 9).

Figure 9 Configuring the deployment certificate level of your collection.

You can also choose to create a new certificate (see Figure 10). Provide the fully qualified domain name for the Remote Desktop Web Access server as well as a password. You might also want to store the certificate as a PFX file. Doing so allows you to later install the certificate into the Trusted Root Certification Authorities certificate store on desktops that will connect to RemoteApp programs via RemoteApp and Desktop Connection.

Figure 10 You can create a new certificate when you configure the deployment certificate level of your collection.

There’s a lot of history in Terminal Services and RDS, so much so that we’re beginning to see history repeat itself. Not every IT environment may be ready for seamlessly delivered RemoteApp programs. Then again, not everyone is ready for virtual desktops, either. However, these new enhancements to RDS in Windows Server 2012 give you complete flexibility over your users’ experiences.

Greg Shields,* MVP, is a partner at Concentrated Technology. Get more of Shields’ Jack-of-all-trades tips and tricks at ConcentratedTech.com.*

Related Content

• Geek of All Trades: Expand Beyond One
• Geek of All Trades: Cheating Isn’t Always Bad
• Geek of All Trades: Live Migrations