Hi all, I’m Travis Howe, a developer on the Remote Desktop Virtualization team. Today I’d like to talk about a few improvements that we made to the RemoteApp and Desktop Connections feature in Windows Server 2012: support for default connections and file type associations.
When we added the RemoteApp and Desktop Connections feature in Windows Server 2008 R2 and Windows 7, many administrators wanted to be able to push connections to their users by using Group Policy. To help enable this, we supported a “silent install” API that allowed a user to be signed up for a connection without any prompts. Administrators had to push something like this script on Script Center to their users by using Group Policy.
In Windows Server 2012 and Windows 8, we improved this scenario. We have added a new Group Policy container under “Remote Desktop Services” called “RemoteApp and Desktop Connections,” and within that container have defined a new policy setting called “Specify default connection URL.” Enabling this policy setting causes users to be subscribed to RemoteApp and Desktop Connection at the specified URL. RemoteApp and Desktop Connections that have been installed by using this policy setting have a special name: default connections.
There are a few differences between default connections and ordinary connections:
Support for file type associations is a somewhat deep subject, so I’ll spend the rest of this post talking about it in more detail.
One more note about default connections: they are unfortunately not supported on pre-Windows 8 clients. That means, if you want to push a RemoteApp and Desktop Connection to end-users running Windows 7 PCs, you must continue to use the script-based approach.
So what do I mean when I say that default connections are able to install file type associations? When an administrator is publishing RemoteApp programs, they can also choose to publish file types that should be associated with that program. Then, when the RemoteApp program is installed as part of a default connection, we associate the RemoteApp program with those file types on the client machine.
The next time the user tries to open a file of that type, the standard Windows 8 file type association behavior will be used to determine which of the registered programs should be used to open the file. Often, the user will be given a choice. For example, if Microsoft Paint has been published as a RemoteApp program with the .bmp file type association, the user is presented with the following options.
There is one caveat with this feature: when deciding which file type associations to publish for a RemoteApp program, administrators can only choose from a list of available file types for that app. We calculate this list based upon the file types that the app is associated with on the collection endpoints (Remote Desktop Session Host servers in a session collection, or virtual desktops in a virtual desktop collection). This is necessary because when you double-click a file that is associated with a RemoteApp program, the endpoint also needs to know how to open that file type with that program. As a rule, it doesn’t have that information for arbitrary file types. As a result, we do not support associating RemoteApp programs with arbitrary file types on the client.
So, how exactly does one publish file type associations?
As I mentioned earlier, when a RemoteApp program is published, we calculate the list of file type associations that it can support when running as a RemoteApp program. To see this list, open up the properties of a published RemoteApp program in the new Server Manager UI, and navigate to the File Type Associations tab:
In the previous screenshot you can see the list of file types that Paint is capable of launching as a RemoteApp program. To publish file type associations for this RemoteApp program, simply select the file types that you want to be made available to end-users and click OK or Apply.
After you have published file type associations for your apps, they will automatically be installed for all users who are subscribed to the RemoteApp and Desktop Connection as a default connection. That installation will happen the next time the user’s client updates the connection (by default it updates every night around midnight).
This feature can also be managed by using the Remote Desktop Services module for Windows PowerShell. After loading the RemoteDesktop module by typing import-module RemoteDesktop, you can get the list of file type associations available to be published for a RemoteApp program by using the Get-RDFileTypeAssociation cmdlet:
PS C:\Windows\system32> import-module RemoteDesktop
PS C:\Windows\system32> Get-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint
CollectionName AppAlias FileExtension IsPublished
-------------- -------- ------------- -----------
Test mspaint .bmp False
Test mspaint .dib False
Test mspaint .emf False
Test mspaint .rle False
Test mspaint .wmf False
In the previous code sample we again see the list of file types that Paint is capable of launching as a RemoteApp program. To publish a file type association for this RemoteApp program, use the Set-RDFileTypeAssociation cmdlet:
PS C:\Windows\system32> Set-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint -FileExtension .bmp -IsPublished $true
PS C:\Windows\system32> Get-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint -FileExtension .bmp
CollectionName AppAlias FileExtension IsPublished
-------------- -------- ------------- -----------
Now we have published the file type association for “.bmp” files.
I hope this overview has been helpful and that now you have a better understanding of what makes the default RemoteApp and Desktop Connection different, and how you can leverage it to publish file type associations for your RemoteApp programs.
Hi Travis, Have not been having any luck getting the GPO to set the default connection url to work, and then found event 1026 in the Microsoft-Windows-RemoteApp and Desktop Connections/Admin log:
The installation of the default connection has been cancelled. A default connection cannot be used on a system that is part of a Remote Desktop Services deployment.
Am I getting that because I'm sharing the connection broker between the RDSH collections that are publishing the desktop and that are publiushing the RemoteApp applications, or because you just can't use RemoteApp within a published RDSH desktop?
If the latter, why is this? Will this restriction be removed in Server 2012 R2 (or via a hotfix)?
I've setup server 2012R2 RDS and i have published Office 2013 and set the file associations as mentioned in this article. On my clients (win8.1 and win7) i've setup the webfeeds. however its still not working. The clients continue to prompt for the application that should be launched.
Launching of the remoteapps themselves work perfectly fine.
Any suggestions? It seems as though there is some non-documented steps.
This is a limitation of default connections that I forgot to mention in the article - they are blocked on machines that are an endpoint on an RDS collection (RDSH servers and VMs that are part of a Virtual Desktop collection). This is due to some technical limitations in the way the file type associations feature works. We don't currently have any plans to remove this limitation. That said, we're always open to hearing feedback, and if we get enough on this issue it is something we can revisit.
It sounds like you had users manually subscribe to the webfeeds. As noted in the article, file type associations are only supported for default connections (i.e. pushed by GP). Default connections are unfortunately not supported on Windows 7.
Hope that helps.
Our application allows you to export to Word, Excel and Adobe Acrobat. Anyway to have them launch the local client versions of those applications? Users will want to save those documents, and when run remotely, it defaults to the RDS Server file system. Good article. Thank you!
Hi Travis / robincm2,
Warning while accessing RemoteApp and Desktop Connection via GPO on VDI collection.
"The installation of the default connection has been cancelled. A default connection cannot be used on a system that is part of a Remote Desktop Services deployment."
Did you guys get any workaround or fix for this know issue.
Absolute rubbish, why on earth would M$ leave out such a killer feature as being able to launch a published application from within a hosted session, be it client VDI or Session based, Looks like we will be throwing our money (4000 users) back at Citrix. As nested RDP sessions are now supported natively there is no reason at all to not allow this feature.
What if I want to have all 4000 users on a hosted RDS desktop but only allow 200 of them access to Excel for example, surely this is what "collections" are designed for? I would install Excel on 4 servers (instead of 40). It makes perfect sense from an enterprise point of view to have every user in the same farm for standardization and then publish the application to only the users who require it. Why would I want potentially 900 little islands of data (remote sites) on the *** end of a DSL connection when I can host them all at HQ over an RDP 8.0 connection.
So, I am trying to associate .pdf files with Adobe Acrobat. Seems pretty standard. The operating system sees the file type association with no problem, but unfortunately, the RDS collection does not. I followed your guide here, but when trying to use the Set-RDFileTypeAssociation command, it is telling me "The specified file type association cannot be modified because it does not exist."
This confuses me because the association is known to Windows, but not known to RDS. Is there a command that is needed to define the file type before actually applying it to an association?