Working With Terminal Services Remote Applications (Part 5)

by [Published on 23 June 2009 / Last Updated on 23 June 2009]

How to create traditional Windows Installer packages for remote applications.

If you would like to read the other parts in this article series please go to:

Introduction

This article concludes the series on Terminal Services Remote Applications by explaining how to create traditional Windows Installer packages for remote applications.

Back in Part 3 of this article series, I showed you how to create an .RDP file that you could use to connect a client computer to a remote application. Although this technique works pretty well, it is not entirely seamless. The user can take one look at the application’s icon and tell that the application is running remotely.

The fact that remote applications use a different icon than applications that are running locally might not seem like a big deal, but I have worked in IT long enough to know that some users will absolutely lose their minds if they come in one day and the icon for Microsoft Word has been replaced by an unfamiliar looking icon.

If you start deploying remote applications that are accessible to users through .RDP files, you will probably see a spike in help desk calls immediately after the deployment is complete, but the volume of helpdesk calls should soon go back to normal. Even so, there is another down side to using .RDP files to connect users to remote applications. .RDP files are not always as easy to deploy as traditional applications. Fortunately, there is a solution. Microsoft has designed Terminal Services RemoteApp so that you can create Windows Installer packages (.MSI files) for remote applications.

The procedure for creating an .MSI file is similar to the procedure that you used when you created a .RDP file. Since we have already defined some remote applications, the only thing that we have to do is to open the TS RemoteApp Manager, right click on a RemoteApp program, and then choose the Create Windows Installer Package option from the shortcut menu, as shown in Figure A.


Figure A

Right click on a RemoteApp Program and choose the Create Windows Installer Package command from the shortcut menu.

At this point, Windows will launch the RemoteApp Wizard. Click Next to bypass the wizard’s Welcome screen, and you will be taken to the Specify Package Settings screen that’s shown in Figure B.


Figure B: You must specify the settings that the installation package will use

In most cases, you will not have to change any of the default package settings. The name of the terminal server and the port number are detected automatically. If a TS gateway is in use, it should be automatically detected as well. The Wizard’s default behavior is to configure the remote application to require authentication, but this is usually going to be the desired behavior. If for some reason you do not want for the wizard to require authentication, you can certainly choose otherwise.

The only setting on this screen that really deserves some consideration is the Certificate Settings option. This option allows you to digitally sign the Windows Installer package that you are creating. Signing the installation package is by no means a requirement, but some organizations use Software Restriction Policies to prevent unauthorized software from being installed onto client computers. The Group Policy Object Editor allows you to create Software Restriction Policies based on several different criteria, but one of the most commonly used method is to allow or to prevent an application’s installation based on the installer package’s digital signature. If your organization restricts applications based on the application’s signature, then you will definitely want to use a certificate to sign the Windows Installer Package that you are creating.

After you have filled in the Specify Package Settings screen, click Next, and you will see a screen that’s similar to the one that’s shown in Figure C. As you can see in the figure, you can control where the application’s shortcut will appear once the link to the remote application is installed onto the client computer. As you can see in the figure, remote applications are placed in the Remote Programs folder on the client computer’s Start menu by default, but you have the option of creating a desktop icon and of selecting a different Start menu folder.


Figure C: You must choose the location where the shortcut to the remote application will be created

The last option on this screen is a check box that you can use if you want to take over client extensions. As I am sure you know, Windows associates certain file extensions with various applications. For example, Excel spreadsheets use the .XLS file extension. If you double click on an .XLS extension, then Windows will open Excel and load the file that you have opened.

Keep in mind that although it is possible for several applications to be able to use the same file extension, a file extension can only use one application by default. For example, both WordPad and Microsoft Word both use the .DOC extension. The .DOC extension is registered to WordPad by default, but if you install Microsoft Office then the .DOC extension is reassigned to Microsoft Word.

The use of file extensions works pretty well if applications are installed locally, but things can get a bit tricky if users use remote applications. Suppose for instance that a user is using a default Windows Vista installation, but has a link to a remote copy of Microsoft Word. If the user double clicks on a .DOC file, the file will be opened in WordPad, because Microsoft Word is not actually installed onto the system, and therefore the .DOC file extension has not been reassigned.

This is where the Take Over Client Extension check box comes into play. If you select this checkbox then the remote application will hijack any applicable file extensions on the client computer. In other words, if a user is using Microsoft Word remotely, and they double click on a .DOC file, then Microsoft Word will be opened instead of WordPad, even though Microsoft Office is not locally installed.

Although taking over client extensions may sound like a no brainer, it is important to keep in mind that doing so can cause problems for the user if they do not have connectivity to the Terminal Server.

After you have selected the desired options from the Configure Distribution Package screen, click Next. When you do, Windows will display a summary of the options that you have chosen for the package that you are about to create. Take a moment to glance over these options to make sure that everything appears to be correct. Assuming that everything looks good, click Finish and the package will be created. You can find your newly created installation package in the server’s \Program Files\Packaged Programs folder.

Conclusion

In this last part of my article series, I have explained that it is far easier to deploy traditional Windows installer packages than .RDP files. Windows installer packages also provide the end users with a much more seamless experience when working with remote applications.

If you would like to read the other parts in this article series please go to:

Featured Links