Distribution of Remote Apps and desktops in Windows Server 2012

by [Published on 6 Nov. 2012 / Last Updated on 6 Nov. 2012]

In this article, the author discusses the distribution of Remote Apps and Desktops using Windows Server 2012 Remote Desktop Services.

Introduction

With the Release To Manufacturing (RTM) version of Windows Server 2012 being available (September 4th) many people have been test-driving Windows Server 2012, or will do so in the near future. Windows Server 2012 has been improved in many different areas, Remote Desktop Services being one of them. In this article, we’ll take a look at a common action while using Remote Desktop Services in Windows Server 2012, which is the distribution of Remote Apps and Desktops. In this article, we’ll discuss what has changed, what the consequences of those changes are compared to Windows Server 2008 R2, what’s possible with Windows Server 2012, and what’s not.

Distributing Remote Apps and Desktops with Windows Server 2008 R2

Let us first take a look at what the situation was before Windows Server 2012. Remote Apps have been around since Windows Server 2008. As you will probably know, a Remote App is an application that runs seamlessly next to other local applications on the end-users desktop. Therefore a Remote App does not use a full desktop session on the RD Session Host server serving a user session. The key difference here is the fact that a full desktop session uses Explorer.exe and Userinit.exe, and Remote App sessions use Rpdshell.exe and Rdpinit.exe. In Windows Server 2008, and later R2, Remote Apps are managed using the Remote App Manager. This is a MMC snap-in available on a server running the RD Session Host role and is launched from the Administrative Tools sections of the Start menu.


Figure 1:
Remote App Manager

Using the Remote App Manager, Remote Apps are initially created and updated. Using the App Remote App Program wizard, an application running on this RD Session Host Server can be published as Remote App, meaning users are able to launch that application as a Remote App. After initially creating a new Remote App, additional settings could be configured per Remote App by editing its properties. For example, the location, path and name could be changed. In addition, you were also able to add a parameter if needed, and use the User Assignment tab to publish the Remote App to a specific group of people.


Figure 2:
Properties of a Remote App

Distribute using RD Web Access

One of the ways to distribute a Remote App to the end users was to make it available in RD Web Access. This could be done by selecting the option “RemoteApp program is available through RD Web Access”, which could be done on a per Remote App level. That would result in the Remote App being available to the assigned users in RD Web Access.

Distribute using Web Feed URL in the control panel

Another way to distribute the Remote Apps was by using the Control Panel on the client. Opening the Control Panel item called “RemoteApp and Desktop Connection” resulted in the screen below.


Figure 3:
Remote App and Desktop Connections - Windows 7

Here, you had the option to enter a so called Web Feed URL. This URL would point back to the server running the RD Web Access role. Doing so would create several shortcuts to the Remote Apps and Desktops that were assigned to that user.


Figure 4:
Remote App assignment confirmation

These Remote Apps and Desktops would become available in the users local Start Menu. They were in fact shortcuts to .RDP files stored in the users roaming profile.


Figure 5:
Remote App inside the Start Menu

Manual distribution

The third option to distribute Remote Apps to end users was by making use of the manual distribution options in the Remote App Manager. Right-clicking a Remote App in the Remote App manager showed two distribution options.


Figure 6:
Remote App Manager manual distribution options

There was the ability to create an .RDP file. This would simply get all the parameters needed to successfully launch the Remote App and create an .RDP file, which you could then manually (or e.g. by using GPO) distribute to your end users.

Then, there was also the ability to create a Windows Installer Package. Using this wizard, we would be able to set the path where we would like to store the .RDP files upon installation, and also configure the destination RD Session Host Server as well as the RD Gateway and certificate settings. Furthermore, you would have the option to configure where you would like to place shortcuts to the .RDP files created. For example, you would be able to place them on the end users’ Desktop and/or Start Menu.


Figure 7:
Remote App Manager manual distribution options

Finishing the wizard would result in an .MSI file inside C:\Program Files\Packaged Programs. You could then distribute that to your users using several different techniques like e.g. GPO, SCCM or any other software distribution mechanism.

The downside of manual distribution is obviously the fact that a change to any of the Remote Apps would again have to be manually distributed to the end users, whereas, using RD Web Access or the Web Feed URL would automatically update this. (Although the Web Feed URL does have a periodic update schedule).

Now, that we have seen distribution of Remote Apps in Windows Server 2008 R2 and have refreshed our memory, it’s time to take a look at Windows Server 2012 to see how this changed and evolved.

Distributing Remote Apps and Desktops with Windows Server 2012

The way Remote Apps are managed using Remote Desktop Services in Windows Server 2012 has changed a lot compared to Windows Server 2008 R2. Remember that in Windows Server 2008 (R2) you had to use the MMC snap-in called Remote App Manager on every individual RD Session Host server. The Remote App Manager no longer exists in Windows Server 2012. Management of Remote Apps in Windows Server 2012 has been moved to the central Server Manager console as part of the Remote Desktop Services section.


Figure 8:
Remote App Manager management in Windows Server 2012

So, instead of having to configure Remote Apps per RD Session Host (either manually or by using the export function) in Windows Server 2008 R2, we can now centrally manage our Remote Apps. The configuration for these Remote Apps will then automatically be pushed to all RD Session Host servers that are members of the Session Collection. This improves manageability a lot.

So let’s look at the ways Remote App programs and Desktops can be distributed.

Distribute using RD Web Access

As with Windows Server 2008 R2, Window Server 2012 also has the ability to distribute to RD Web Access. Besides some improvements in RD Web Access, the mechanism stayed the same there. You’re able to assign Remote Apps to users based on Groups per Remote App and per Session Collection (new to Windows Server 2012).

Distribute using Web Feed URL in the control panel

In Windows Server 2012, there have been two updates to this way of distribution. We saw earlier that users were able to connect using the “RemoteApp and Desktop Connection” in the control panel providing a Web Feed URL. This is still possible with Windows Server 2012. In addition to providing a Web Feed URL, Windows Server 2012 and Windows 8 as a client also support providing a corporate e-mail address. This makes the setup more user-friendly as the user can simply provide his e-mail address instead of an unfriendly URL.


Figure 9:
RemoteApp and Desktop Connections Windows 8

In addition, the new Remote Desktop App available for Windows 8 has a “metro-style” equivalent, which can be accessed by opening the Remote Desktop App.

Another improvement here is a GPO object that can be applied to Windows 8 clients to configure a default Web Feed URL. This GPO is available under

User Configuration / Administrative Templates / Windows Components / Remote Desktop Services / RemoteApp and Desktop Connections.


Figure 10:
Default connection URL GPO

If you’re using Windows 8 as a client, the Remote Apps and Desktops assigned will be available in the new “Metro-style” start screen as well as inside the Remote Desktop App itself. Windows 7 as a client will obviously still use the same location in the users’ local Start menu.

Manual distribution

The third option available for Windows Server 2008 R2 was manual distribution. Recall that we were able to create .RDP and .MSI files for manual or automated distribution. This option is no longer available for Windows Server 2012. Remote App management in the new Server Manager console does not include functionality to create .RDP or .MSI files per Remote App. The fact that the option is no longer available indicates that Microsoft advises you to use the Web Feed method for all distribution actions. There is however, a way to extract the .RDP files that the Control Panel generates on the client. If you would browse to the following path on a client that signed up for Remote Apps you can find those .RDP files.

C:\Users\<username>\AppData\Roaming\Microsoft\Workspaces\<workspace ID>\Resource


Figure 11:
.RDP files in user profile

Theoretically, you would be able to distribute these .RDP files the old way. However, Microsoft would probably advise you to use the new Web Feed method since it creates more flexibility and provides central management.

Conclusion

To conclude, if you have been using the manual distribution options as discussed in this article, and they worked well in your specific scenario, you will probably be somewhat disappointed that this option no longer exists in Windows Server 2012. However, I do believe that the new possibilities using the Web Feed method and the way Remote Apps are now managed centrally, really helps in adopting the Web Feed method. It creates great flexibility and is now much more user friendly.

Advertisement

Featured Links