Publishing a network-isolated virtual machine with RemoteApp

Cloning isolated VMs vs. scripted installation

One of the challenges we’ve always faced with SharePoint development has been the tension between cloning actually identical environments versus automating the deployment across distinct environments (or worse, repeating the installation manually). In the first case we save time by eliminating reconfiguration and this ensures a consistent experience for each user. This is particularly beneficial for software development. These benefits can also be obtained by scripting installation/configuration/deployment but there’s a considerable overhead associated with developing and testing those scripts. As SharePoint 2010 is still quite new and we’ve been working on projects for some time now, we didn’t have the luxury of waiting for those refinements and we needed to take advantage of these efficiencies as we had done with SharePoint 2007 projects.

This cloning approach has one big drawback: it requires network isolation in order to prevent network, machine or SID duplication issues. We can make up for that partially by using Network Address Translation (NAT) so that we can get outbound connectivity from the VMs (we do this using Internet Connection Sharing to an internal network), but this doesn’t provide any inbound connectivity for Remote Desktop connections to the VMs or the SharePoint applications in them. Remote Desktop access may be desirable because of the limitations of the Hyper-V Virtual Machine Connection or because the users do not have permissions to Hyper-V itself. Alternately, it may be desirable to expose the virtual machine’s browser or another application directly, as I’ll describe later in this article.

Before I detail the approach to publishing a network-isolated remote desktop connection, I should note that it’s also possible to lock down the environment using Windows Firewall and Hyper-V networking so that inbound traffic is isolated enough that most duplication issues are accounted for – but this requires considerable planning, additional reconfiguration and it’s a large enough topic that it requires another post (I will try to revisit this soon). In short, I think each approach addresses different needs. For now, I’ll talk about RemoteApp.

RemoteApp to a Remote Desktop

It’s been some time since I looked at the new features in Windows Server 2008 R2. I spent most of last Summer getting to grips with them but have been living in a world of SharePoint 2010 since, so I never got a chance to revisit the interesting developments with Remote Desktop Services. Among them is RemoteApp, which allows us to publish applications (rather than a terminal session) on a server through Remote Desktop Web Access. That application could be Word, PhotoShop, SQL Server Management Studio, ULS Viewer or whatever might be useful.

In the last couple of weeks I’ve addressed a couple of requirements by publishing a saved Remote Desktop connection file through Remote Desktop Web Access. To give a brief overview of the solution, I’ve logged on to the Hyper-V host server and saved a Remote Desktop connection file pointed at the target Virtual Machine. This relies on the Hyper-V host’s internal network connection to the virtual machine and our LAN connection to the Hyper-V host (the VM does not have an external network connection). Then I published that saved remote desktop connection file using RemoteApp. Users launch the connection through the Remote Desktop Web Application. This is a very basic example of how RemoteApp can help us by bridging a network barrier that we have to maintain.

RemoteApp to a Remote Application

If we get slightly more complex we can also get to the real beauty of this approach. RDP connection files can now be customised so that you can expose an application inside of the target machine. This is like Windows 7’s XP Mode, except I’m able to take advantage of the remote machine’s applications through Remote Desktop Services without having to log on to either the Hyper-V server’s terminal or the virtual machine. Put another way, I can log on to my Hyper-V server’s Remote Desktop Web Application portal and launch an RDP file. That RDP file bypasses both terminals and provides me with the application that I’m really after – say, ULS Viewer, or a browser that can render the network-isolated SharePoint data. Here’s a more detailed scenario:

• A Hyper-V server on the network has a number of virtual machines that fully replicate our domain infrastructure.
  • Because this is an exact copy of our live environment we need to keep the test environment completely network-isolated.
• We’re testing Word 2010 on multiple operating systems before rolling it out across the network.
• The tester needs to be able to access the Word Application but should not have access to the rest of the infrastructure.
• We have XP, Vista and Windows 7 VMs on the Hyper-V server – all running Word 2010.
• We log on to the Hyper-V server and create saved RDP files to each of those VMs.
  • We modify those RDP files so that they expose only the Word application. This is a few lines of added or modified XML in the connection file and a change to the TsAppAllowList registry key on each virtual machine. More detail on that approach here.
• We add each of these saved RDP files as Remote Applications in the RemoteApp Manager Remote Desktop Services node on the Hyper-V server. To be clear, this is new Remote Desktop Services functionality. It only happens to be a Hyper-V server because we’re exposing Hyper-V guests.
• The tester logs on to the Remote Desktop Web Access site and launches the RDP files as needed. Each file will expose an instance of Word 2010 which is running in the remote (and isolated) virtual machine’s context.

This experience is improved if you install the Hyper-V server’s certificate for the Remote Desktop Web Application site. Also note, you will be prompted twice to authenticate – once to the Hyper-V server and once to the virtual machine. That’s not a great user experience, but it’s also not the worst. To be honest, I haven’t had the time to see if it can be improved with Kerberos or another approach. I’d be interested to hear more if others have deployed this approach for more critical loads or more demanding users.

Other uses

There are loads of potential uses for desktop virtualisation like this. One of the most obvious ways that it could be used would be to allow a team member to access an isolated development environment (or one of its applications) over the LAN. This wasn’t possible with my earlier design, and frankly, you don’t want to do a lot of this, but sometimes it can be really useful.

I realise this is conceptually difficult, so feel free to ask questions if this hasn’t been my clearest post. I’ve skipped some steps that are required to deploy the Remote Desktop Services. That’s another topic that is beyond the scope of this post. Again, I’m happy to answer questions about that, although I’d recommend hitting TechNet for a few hours before diving in. There’s loads of new functionality here and you may find another option suits your needs better. To the initiate, the Microsoft App-V, MED-V, MDOP story might look a bit “nice to have”, or possibly too complex, but this really isn’t complicated to implement and engaging with this new technology has opened my mind to other design options that I had previously shut out. Definitely worth a look.