RemoteApp for Hyper-V (Part 1)

If you would like to be notified of when Wilco van Bragt releases the next part in this article series please sign up to our VirtualizationAdmin.com Real Time Article Update newsletter.

Introduction

At the end of 2009 Microsoft released a new feature called RemoteApp for Hyper-V. In earlier beta stages the feature was given other names but every name so far given to the feature does not cover the real function of the feature. Let us start by discussing what this feature offers and why you would use it.

What is RemoteApp for Hyper-V

Microsoft introduced the name RemoteApp with the release of Windows 2008 Terminal Services. In the past, Windows 2008 TS Microsoft Terminal Services solutions only supported the publication of a full desktop using the RDP protocol. In Windows 2008 it was possible to start an application seamlessly from a Terminal Server so it looks as it is running locally on the client comparable with Published Applications from Citrix. Therefore, a RemoteApp is Microsoft offering an application running on a Terminal Server running seamlessly to the client.

So what’s RemoteApp for Hyper-V? Hyper-V does not run applications, so how can you publish applications on that platform? That’s why the name is not logical. A better name can be RemoteApp for Workstation Operating Systems, because that’s actually what this feature does. So you can offer an application seamlessly on your client, which is actually running on a workstation operating system on another platform. Mainly this will be virtualized workstations running on a hypervisor platform like Hyper-V. Probably this is the reason that Microsoft called the feature RemoteApps for Hyper-V. However for the feature there is no limitation for the hypervisor platform, you can also use for example VMware vSphere or a physical workstation.

Summarized the feature allows creating RemoteApps on workstation operating systems like Windows XP, Windows Vista or Windows 7.

When do you need to RemoteApp for Hyper-V

Now that we understand what the feature offers, we can talk about real-life scenarios for this feature.

  • To complete a Terminal Server infrastructure – In this scenario the organization is using Terminal Services as their main component to provide their users with applications. Unfortunately there are still applications that are compatible with Terminal Services, so such applications cannot run on Terminal Services. For such applications, RemoteApp for Hyper-V can be the solution to offer those applications in a similar way that the other application running on Terminal Services does.  
  • To support non Windows 7/Vista compliant software – In this case the organization has migrated to Windows 7 (or Windows Vista) and there are a few applications that are compatible with Windows 7 or Windows Vista. Those applications can be installed on Windows XP (or Windows Vista) and offered seamlessly to the Windows 7 workstations (or Windows Vista).
  • Testing purposes – For web developers it can be useful to have an older Internet Explorer version to test their application. As we all know, it is not possible to have more than one Internet Explorer version on one machine. With RemoteApp for Hyper-V it is possible to offer several versions seamlessly for testing purposes.
  • Applications that require full security – A last case scenario can be that one application is handling very sensitive data and the data flow should not leave the data centre. If this is the case and the organization does not have a Terminal Server infrastructure and just a few users need to have access to the application this can be a scenario where you can use RemoteApp for Hyper-V.

Requirements RemoteApp for Hyper-V

Now we know what the feature exactly does and when it can be used for, it’s time to show you how you can enable and configure RemoteApp for Hyper-V.

The host running the application can be Windows XP SP3, Windows Vista SP1/SP2 or Windows 7. For Windows XP and Windows Vista you need to install an update. For Windows XP the update is available here, for Windows Vista the update can be downloaded here. To access the RemoteApp you need to have the Remote Desktop Client 7 available.

Installing en Configuring RemoteApp for Hyper-V

For this article I will use a Windows XP as the host for RemoteApp, while the client is running Windows 7. As mentioned earlier, I need to install the update on the Windows XP workstation. The update is actually a hotfix installation, so after a few next buttons and a reboot the update is installed.


Figure 1: Installing the update on Windows XP

Logically you also need to enable RDP connections to the systems, so a RDP connection can be created.


Figure 2: Enabling RDP

Beside the update and the enabling RDP on the host, some other settings should be made and changed. Unfortunately MS (so far) does not supply any tools for these steps, so you need to edit the registry and configuration files manually.

The first step in this process is starting the registry editor and browse to the key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList].

Within this key a registry value can be found with the name fDisabledAllowList. The default data is REG_DWORD 0, the data need to be changed to a DWORD 1.


Figure 3: Changing fDisableAllowList

Secondly, a new key needs to be created with the name applications. Within this key an additional key needs to be created for the application. The name of this key is not important but I recommend giving it a logical name. Within this key at least two values should be created as a string value. The first value should be labeled name and the data should be the name of the application. The second value is labeled path and consists of the location of the executable of the application on the host system.


Figure 4: Adding the application parameters

With these steps the configuration on the host are finished. The next step is to create a RDP file to connect to the host system using RemoteApp functionalities. The easiest way to achieve this to start a Remote Desktop Client, configure the connection settings as you prefer and use the Save As button to create a RDP file.


Figure 5: Creating a RDP file

After the creation of the RDP file you need to (again) manually add this file.

Within the file you need to adjust the settings remoteapplicationmode from 0 to 1 (remoteapplicationmode:i:1) and add rdpinit.exe to the setting alternate shell:s:.

Finally the following settings should be added to the RDP file.

  • disableremoteappcapscheck:i:1
  • remoteapplicationprogram:s:<NameoftheApplicationRegistry>

The setting; disableremoteappcapscheck and alternate shell are necessary for Windows XP and Vista hosts, for Windows 7 those two are not needed (but does not break anything). Logically the setting remoteapplicationprogram should be configured with the name as specified within the registry of the host.


Figure 6: Configuring the RDP File for RemoteApp

When you have made these changes to the file, you are ready to start the RemoteApp by double clicking the RDP file. With Windows Vista and 7 hosts you can configure single sign on (as described in this article by MS RDS Team). Unfortunately Windows XP hosts do not support Single SignOn, so in my example I need to logon to the host via the details button before the RemoteApp is showed on the guest system.


Figure 7: Windows XP Paint running as RemoteApp on Windows 7 guest.

During my testing of this feature I found out that I can actually start any application available on the host system (in this case the Windows XP machine) by changing the remoteapplicationprogram setting in the RDP file with another executable name. Searching on the Internet I found one direction to this (caused by changing the data of registry value fDisabledAllowList), but I could not reproduce the solution (full program path) provided in that post.

In this way it’s also possible to start more RemoteApps from one host machine. Unfortunately there is (till now) no official documentation available for this feature from Microsoft. When I enquired at Microsoft, I found that this is the standard behavior for this feature; so actually, the settings in the registry keys are not checked/used. It’s not clear if this behavior is going to be changed, because this can cause security risks.

I also heard that integration of those RDP files in the RDS Web Access portal are possible by adjusting the code, but also for this part no documentation is available. After contacting Microsoft I heard that this is not supported and not advised by Microsoft.

Conclusion

In this article I explained what the RemoteApp for Hyper-V feature is exactly and described some real-life scenarios. We continued with the installation and configuration of the feature. It’s remarkable that there are a couple of manual steps involved. It’s a pity that Microsoft has no official documentation available for the features causing that’s it is not clear why all applications available on the host can be started.

If you would like to be notified of when Wilco van Bragt releases the next part in this article series please sign up to our VirtualizationAdmin.com Real Time Article Update newsletter.

About The Author

1 thought on “RemoteApp for Hyper-V (Part 1)”

  1. Wow… I was just forced to upgrade a windows 7 machine that was running a critical application in “XP Mode”, which is like remoteapp, but different. This allowed me to continue doing this in Windows 10 which does not support XP Mode. Thanks so much.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top