In the first part of this article series you were introduced to Terminal Services Remote Programs and walked through the installation of the Terminal Server role on a Longhorn Server. In this article, we will continue the discussion by leading you through the rest of the configuration process.

Application Installation

Now that the Terminal Server role has been installed, it’s time to install any applications that you want to make available remotely. There really isn’t anything special that you have to do when installing applications beyond what you do in any other terminal service environment. The only exception to this is that you may need to make a few special considerations if you have multiple terminal servers that will be hosting remote programs.

Generally speaking, you want to use multiple terminal servers to host remote programs if the anticipated workload would overwhelm a single server. You might also want to use multiple servers if there are compatibility issues with the applications being hosted that would prevent them from coexisting on a common server.

If you do decide to use multiple servers, Microsoft recommends placing any applications that are related or that have dependencies upon each other onto a common server. For example, the various applications in Microsoft Office are designed to work together. As such, if you wanted to run Microsoft Office remotely, you would want to install the entire Microsoft Office suite onto a single server rather than installing Microsoft Word on to one server and Microsoft Excel onto another server.

Configuring Remote Programs

Simply installing an application onto a terminal server will not make the application available remotely. You must specifically designate a program to run remotely. To do so, open the Terminal Services Remote Programs console. You can find a link to this utility on the Administrative Tools menu.

When the console opens, click the Add Remote Programs link that’s found in the Actions pane. This will cause Windows to launch the Remote Programs Wizard. Click Next to bypass the wizard’s welcome screen. At this point, you’ll see a screen that displays a list of all of the applications on the server that are available to be run remotely. Select the check boxes next to each application that you want to make available for remote execution and click Next. You will now see a summary screen that allows you to review the programs that you’ve selected for remote execution. Assuming that everything on a summary screen is correct, click the Finish button. The selected applications will now be listed on the console’s Remote Programs list, as shown in Figure A.

Technically, this is the only thing that you have to do to flag an application for remote usage. Before I move on though, I want to show you how you can customize applications that you have made available for remote use. If you look at Figure A, you’ll notice that the lower right hand corner of the console contains options related to the selected application. If you click the Properties link, you’ll see a properties sheet similar to the one that’s shown in Figure B.

Figure B: An application’s properties sheet allows you to customize a remote application

As you can see in the figure, there aren’t a lot of customization options but I wanted to take a minute and show you what options are available. Probably the main areas of interest are the ability to control whether or not the application is available through TS Web Access, and to control command line arguments. In case you’re wondering, TS Web Access allows you to run a remote application over the Internet through Web browser. It is even possible to make an application function as a part of a website that you create.

By default, remote users are forbidden from using command line arguments with remote applications. You do however have the option of allowing command line arguments, or of specifying a certain set of command line arguments that should always be used with the application.

This properties sheet also allows you to change the location of the hosted program, and to change its name or its icon.

Preparing for Deployment

When users run an application through a normal Terminal Service session, there is nothing special that you have to do to make an application available to the users. The user is simply using the RDP protocol to attach to the Terminal Server and is basically using the server’s operating system as their own. Because the server’s operating system already knows about applications that are installed on the server, you don’t have to do anything special to rollout applications to Terminal Server users.

Running remote programs works a little bit differently though. While it’s true that the remote programs are running on the server’s operating system, the users are not using the server’s operating system as their own operating system. Instead, the users are running their own individual copies of Windows which contain links or menu icons to remote programs. Just as you would have to install applications on user’s desktops in a traditional client/server environment, you’re going to have to distribute links to the remote programs to any user who is going to be running them.

Before you actually begin the distribution process you need to verify that users will be able to communicate with the server that is hosting the remote programs. The necessary connection settings should be in place by default, but because they are so important I recommend taking a moment to verify that everything is in order.

Begin by opening the Control Panel and double clicking on the System icon. When the System screen loads, click the Remote Settings link in the upper left-hand portion of the screen. When you do, Windows will open the System Properties sheet. Click on the properties sheet’s Remote tab.

As you can see in Figure C, Windows is configured by default to allow connections from computers running any version of Remote Desktop. This default option is sufficient for allowing users to run remote programs that are hosted on the Terminal Server. More security conscious organizations may wish to use the option to allow connections only from computers running Remote Desktop with Network Level Authentication.

Figure C: Make sure that the server is configured to allow connections from remote users

In case you’re wondering, Network Level authentication is a new authentication method that is designed to complete a user’s authentication before that user establishes a full remote connection. In addition to being more secure than traditional authentication methods, it has the added benefit of requiring fewer system resources during the authentication process. Network Level Authentication will be a standard feature in Windows Vista. Supposedly though, Network Level Authentication will eventually also be available for Windows XP.

The last thing that you need to do is to click the Select Users button and add the users who should have access to remote programs. Domain administrators have access by default.

Conclusion

In this article, I have explained how to designate an application to be run remotely. In Part 3, I will conclude the series by showing you how to deploy remote applications.

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

Featured Links

Office 365 CON 2015

Registration is now open for Office 365 CON 2015, an annual gathering of IT Strategists, Domain Experts and Microsoft MVPs, presenting the latest technologies, challenges and solutions facing the Exchange and Office 365 community of professionals.

Join Michael Osterman from Osterman Research as he kicks-off the conference by sharing his insights into recent trends and challenges obtained through survey research within the Office 365 and Exchange user communities.

Following the kick-off presentation, you can choose from multiple breakout focus sessions, including: