Windows Server 2012 RemoteApp and Desktop Connections: Default Connections and File Type Associations

Windows Server 2012 RemoteApp and Desktop Connections: Default Connections and File Type Associations

Rate This
  • Comments 17

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.

Default connections

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:

  • On a given machine, a user can only have one default connection.
  • Default connections cannot be removed by using the Control Panel UI (the “remove” button does not exist for default connections). The only way to remove them is by changing the Group Policy setting.
  • Default connections are able to install file type associations.

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.

File type associations support: what does it mean?

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?

Publishing file type associations using UI

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).

Publishing file type associations using the Remote Desktop Services module for Windows PowerShell

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:

import-module RemoteDesktop
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:

Set-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint -FileExtension .bmp -IsPublished $true
Get-RDFileTypeAssociation -CollectionName Test -AppAlias mspaint -FileExtension .bmp

CollectionName       AppAlias   FileExtension  IsPublished
--------------       --------   -------------  -----------
Test                 mspaint    .bmp           True
Test                 mspaint    .dib           False
Test                 mspaint    .emf           False
Test                 mspaint    .rle           False
Test                 mspaint    .wmf           False

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.

Leave a Comment
  • Please add 5 and 5 and type the answer here:
  • Post
  • 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.

  • robincm2,

    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?

  • I have been looking into the issue with Windows 7 clients and file associations not working using a 2012 RDS environment when using RemoteApps.  When pointing the computers to the RemoteApp and Desktop Connections using control panel the apps would pull through but when then trying to open a file directly would not work.  This is not an issue with Windows 8 clients and works perfectly fine without any issues.

    Previously to get around this issue with Windows Server 2008 R2 RDS environments, using the RemoteApp Manager MMC you could create MSI packages and distribute these to clients using group policy.  Unfortunately creating the MSI’s has now been removed on Windows Server 2012 Session Hosts.

    After trawling the internet and also logging a call with Microsoft they have said this is by design (yeah right) and the only workaround is to script the applications.  I tried these scripts using this very site and many other suggestion I found online but none of them worked.  Microsoft did also confirm this scripted approach has limited success.

    I have managed to get the RemoteApps working with file associations using Windows 7 Clients whilst connecting to a 2012 RDS Farm by doing the following.

    • Build and 2008 R2 Server;

    • Add the Session Host Roles to it ( I guess you could just add the relevant MMC snapins to any 2008 R2 server would also work);

    • Install the same SSL certificate used on your 2012 Session Hosts onto the 2008 R2 Session Host in RemoteApp Manager;

    • Using the RemoteApp Manager MMC connect to anyone of your 2012 Session hosts and you will see the RemoteApps will then appear;

    • Notice the RemoteApp Manager will not bring the relevant icon file over with it but you can change it by clicking the properties of the RemoteApp as below and clicking change icon;

    • When clicking change icon I specify the farm name.  In the above case it is word we are trying to fix so I used.  \\\C$\Program Files (x86)\Microsoft Office\Office15\WINWORD.exe.  This will pull the icon files in for you to select;

    • Once that has been done you can create you MSI packages but ensure the following is correct whilst creating them;

    o RD Session Host Server Settings (This needs to be whatever your 2012 RDS Farm name is internally);

    o RD Gateway Settings (The name of your gateway is externally);

    o Certificate Settings (The same certificate is used to create the MSI files as is used on your 2012 RDS session Hosts;

    • Once you have created your MSI files then the deployment of the files is just the same as you would do in a 2008 RDS environment.

    I hope this helps others because I was about to have nervous breakdown.

  • Nathan,

    We tried publishing file type associations for Adobe Acrobat on one of our lab machines, and it worked for us. One common reason to get the error you saw is if you have a typo in the file type association - a common one is specifying "pdf" instead of ".pdf".

    Are you able to look at the file type associations for the app via the Server Manager UI? Do you see any entries for .pdf there?

  • Hi- just my 2 cents- you REALLY need to allow publishing of default connections to RDSH Desktop collections.  Without this capability, as Mess said, you can't manage the access to applications (and allow them to be seamlessly instantiated) from RDSH desktops.  Do you want to make us pirates?  I'll have to mostly scuttle my RDSH 2012 R2 plans, as this is EXACTLY how I envisioned allowing access on the Desktop collection to applications that not all of my remote desktop users are licensed for.  This really needs to change.  And the more I think about it, having this capability is the ONLY reason I can envision utilizing this capability.  If I want my full Win8 desktop/laptop users to access an application, I'll INSTALL it.  I'm clearly already licensed for that install if I'm running it on that pane of glass in RDS.  If they need to run it remotely for whatever reason, you'd want them to manually run the remoteapp, NOT set the remoteapp as the default for particular file types...  This makes NO sense.

  • We also can't understand why Microsoft is doing this (Remote-App URL within a VD). I think it's absolutely logical to publish further apps via RDSH to a Pooled Virtual Desktop Environment. We are currently (trying) to deploy Windows 8.1  as a VDI Infrastructure without Citrix and only want to use Windows Server 2012 R2 RDS and came across this limitaion (beneath many other little big things) . We can not understand why MS don't know how their customers want to use their software products and makes things so hard for us.

  • Trying to deliver RemoteApps to my Session Based Desktops:

    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.

    Any solution on this, instead of going back to Citrix?

  • I would just like to bring this again to the forefront.  As the many posters above me have stated, we are also trying to allow a base image to all users as a managed pooled published desktop, then use RDSH servers to individually publish apps.  I guess that isn't an option?  I've done this with Citrix, and this seems to be a pretty core feature.  Seriously, I try and defend Microsoft as much as possible (in my Linux-heavy corporate environment), but its decisions like this that just make me scratch my head and sigh.

    Come on guys, this is core functionality, and something offered by your competitors.  Lets take this solution seriously!

  • I am a retail business user. My IT guy has been equally challenged by the use of VDI with the RemoteApps and Desktop Connection and the publication applications outside of RDSH. The install and build was a pain that could have been avoided by having ability to publish the VDI from a pooled resource within RDSH. Again, as a retail business consumer smitten with MS's pre-sale hype and glowing self-reporting, I can say that the Server 2012 R2 installation has been far more time consuming than expected. A full load of rodent excrement.

  • Don't suppose it's possible to set up file associations for RemoteApps on Mac?

Page 1 of 2 (17 items) 12