I have been working on implementing a VDI setup for a small to medium sized organization that desires the ability to publish Remoteapps via the RDS Farm. I have a session based deployment that can easily do this, but I also wanted the ability to leverage the Pooled Virtual Machine deployment to host Remoteapps. I am far from a VDI Jedi, so I went into the deployment and tried to query one of the provisioned VDI. I ran into the following:

After checking that the error message prerequisites were indeed satisfied on the VDI, I started digging a bit more on issues involving publishing apps. It turns out that the image I was using was a Windows 7 professional image that while currently patched…does not support acting as a RemoteApp host/source.  Initially I thought maybe the remote desktop protocol was out of date or mismatched with the 2012R2 Remote Desktop Services deployment.  Unfortunately, everything was patched and up to date.  I was even able to connect to the RDWeb Feed and launch the apps from the session based deployment.  This seems a bit off to me so I did a bit more digging and the long of the short of it is…use Windows 7 Enterprise if possible. All RemoteApp functionality is supported in this OS version and it will behave as expected.

If you are feeling adventurous, you can play around with the registry to actually configure the Windows 7 Professional box to be a RemoteApp host of its own. This is definitely not a production method for delivering Remoteapps, but I wasn’t really satisfied being unable to leverage my existing OS version… especially a Professional branded version.

In a lab, I spun up the same windows 7 professional image I had and went about carving up the registry in accordance with several articles I read talking about methods of making this work.  I ended up with the following registry edits to host applications on my test box:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications

Create two string values: Path and Name

Path should be the absolute path to the desired application executable or application format to be launched.

Name is the text/string value used to name the app when presented.

This process is pretty straight forward but its quite tedious to configure for multiple applications let alone multiple host devices.

Finally to share this with others, you can create a custom .RDP file you can distribute to give access to this unintended virtual app:

• disableremoteappcapscheck:i:1
• alternate shell:s:rdpinit.exe
• remoteapplicationprogram:s:||Application Name ie; Tester2009
• remoteapplicationname:s: Application Executable Name ie; Tester.exe
• remoteapplicationcmdline:s: You can specify command line switches for running the application here
• full address:s: IP ADDRESS

Throw those values into a blank notepad file and save it as .RDP and you should be off to the races.

In closing, Remote Desktop Services 2012R2 is a pretty flexible platform for providing both Virtual Machine/Operating System level experiences as well as publishing Remoteapps.  I am extremely anxious to see the upcoming Remote Desktop Services in Windows Server 2016.  Expanding on features like VDI, RemoteApp, RemoteFX, vGPU, OpenGL, and DirectX will allow administrators to provide a much more optimized experience for their users while requiring less client/device level hardware.  Imagine if and when Azure can provide things like vGPUs and other modern server features that are not readily available/cost prohibitive for most businesses?  One of the biggest detractors from widely used VDI is that certain power users don’t have the necessary hardware feature set to drive demanding applications and processes.  If you could essentially offload these hardware tasks to the cloud, VDI becomes a much more attractive solution for a lot more businesses.

It’s good to be excited about Virtualization again.

Dp