Terminal Services RemoteApp

Let’s move on now and discuss some other new features and enhancements of Terminal Services in Windows Server 2008. One of the biggest improvements in the area of experience features is Terminal Services RemoteApp, which enables users to access standard Windows-based programs from anywhere by running them on a terminal server instead of directly on their client computers. In previous versions of Terminal Services, you could remote only the entire desktop to users’ computers. So when a user wanted to run a program remotely on the terminal server, she typically double-clicked on a saved .rdp file that the administrator previously distributed to her. This connected her to the terminal server, and after logging in (or being automatically logged in using saved credentials), a remote desktop would appear on her computer with a pin at the top pinning the remote desktop to her local (physical) desktop. The user could then run applications remotely on the terminal server from within her remote desktop, or she could minimize the remote desktop if she wanted to run applications on her local computer using her physical desktop.

In other words, the user had two desktops. Needless to say, some users found this confusing, and I can hear the tired help desk person responding to the user’s call by asking, “Which desktop are you looking at now?” and the user responding “Huh?”

TS RemoteApp solves this problem (and makes the lives of harried help desk staff easier) by allowing users to run Terminal Services applications directly on their physical desktop. So instead of having to switch between two desktops, the user sees the RemoteApp program (the program that is running remotely on the terminal server instead of on her local computer) sitting right there on her desktop, looking just like any other locally running program. Figure 8-3 shows an example of two programs running on a user’s desktop: one of them a RemoteApp program, and the other one running locally on the user’s computer.

Figure 8-3: Local and RemoteApp programs running simultaneously on a user’s desktop

Can you tell which program is the remote one running on the terminal server and which is running locally? I’ll give you a clue-the Desktop Experience feature that we mentioned earlier in this chapter hasn’t been installed on the terminal server.

Figured it out yet? That’s right, the client computer is running Windows Vista. The left copy of Microsoft Paint is running locally on the computer, while the right copy of Paint is running on the terminal server as a RemoteApp program. Both copies of Paint (the local program and the RemoteApp program) are running on the same desktop, which is the user’s normal (that is, local or physical) desktop-the new TS RemoteApp feature of Windows Server 2008 Terminal Services at work! Let’s see how we can make this work.

Using TS RemoteApp

First, we’ll open Server Manager and select the TS RemoteApp Manager node under Terminal Services. (We could also open TS RemoteApp Manager from Administrative Tools.)

TS RemoteApp Manager lets us specify which programs our Terminal Services users will be able to run remotely on their normal desktops. Right now, we have no programs on the Allow list, so let’s click Add RemoteApp in the Action pane at the right. This launches the RemoteApp Wizard. Clicking Next presents us with a page that allows us to choose which installed programs we want to add to the RemoteApp programs list. We’ll choose Paint.

Clicking Next and then Finish causes Paint to be added to the RemoteApp programs list with default settings. (We’ll examine these defaults in a moment.)

If we select Paint in the center (Details) pane and click Properties in the Action pane, we see the default settings for running this RemoteApp program:

What these default settings indicate are that users will not be allowed to add their own command-line arguments when running Paint. (This is usually a good idea, though as far as I know, Paint doesn’t have any command-line switches.) The settings also indicate that the RemoteApp program will automatically be made available to users through Terminal Services Web Access (though we actually haven’t added that role service yet to our terminal server). In addition, we could change the name of the RemoteApp program to something other than “Paint” if we want users to know that they’re running the RemoteApp version of the program and not the version installed on their local computer-let’s not do this though as it’s more fun to confuse the user. (I’m talking like a jaded administrator here.)

Anyway, once we’ve added Paint to the RemoteApp programs list, how do we actually enable the user to run the RemoteApp program? To do this, we need to deploy a package containing the RemoteApp information for Paint to our users. We can package our RemoteApp program in two ways: as a Windows Installer file or as a Remote Desktop Protocol file. Let’s use the Windows Installer file approach because as administrators we’re used to deploying Windows Installer packages to client computers using Group Policy.

Start by selecting Paint in our RemoteApp programs list, and then click Create Windows Installer Package in the Action pane. This starts the RemoteApp Wizard again, but after you click Next the wizard displays the following page instead of the previous one:

By default, we see that our Windows Installer package (which will actually be created with the extension .rap.msi, with RAP presumably standing for RemoteApp Package) will be saved at C:\Program Files\Packaged Programs. We could elect to save it there, or we could save it on a network share instead, which is likely the better choice. This page of the wizard also lets us customize the terminal server settings (server name, port, and authentication settings), specify that the package is digitally signed to prevent tampering, or specify Terminal Services Gateway settings if we’re using this feature. (We’ll talk about this later.)

Accepting the default and clicking Next brings us to this wizard page:

Note that by default the RemoteApp program is going to be added to the user’s Start menu in a folder named RemoteApps. (We’ll see that in a moment.) By selecting the check box at the bottom of this page, we can also cause the RemoteApp program to launch whenever the user double-clicks on a file extension like .bmp that is associated with the program. Click through now to finish the wizard.

Now we just need to deploy the .rap.msi package by using Group Policy. I won’t show the details because we’re all pretty familiar with this procedure, so let’s just say we’ve deployed our package to our client computers and the package has been installed on these computers. Now when the user clicks Start and then Programs, the RemoteApp program can be seen on the Start menu:

Now we select Paint under RemoteApp, and the following appears:

We’re also prompted for our user credentials because it’s the first time we’re running this RemoteApp program from our terminal server. After having our credentials authenticated, the following appears:

Once the RemoteApp is running, if we also start a copy of Paint locally from Accessories, then we’ve come full circle to our earlier screen shot, where we had two copies of Paint running, one showing the Vista theme (local mspaint.exe) and the other Classic Windows (remote mspaint.exe). We’re done!

One more thing-what if we did have the Desktop Experience feature installed on our terminal server? In that case, both copies of Paint on our desktop would look identical. How could we tell then whether or not we’re using TS RemoteApp to run one of these copies? Try Task Manager-opening Task Manager displays the two copies of Paint that are running:

Notice that the remote version of Paint is clearly marked this way. Now right-click on the remote Paint application and select Go To Process. The Process tab now opens, and we see that mstsc.exe (in other words, RDC 6.0) is the actual process hosting our remote copy of Paint:

What do you think would happen if we start another remote copy of Paint? We’d have three Paint windows on our desktop, one local and two remote-but how many mstsc.exe processes would we see running on the Processes tab? Take a guess and then try it yourself to see whether you guessed right. See Chapter 13 for more information on trying out Windows Server 2008 for yourself.

Benefits of TS RemoteApp

Now that we’ve examined the new RemoteApp feature of Terminal Services in Windows Server 2008, what do you think the benefits are? Several come to my mind:

• No more user confusion over why they need to have two desktops instead of one. And that’s not to forget the gratitude your help desk staff will have for you.

• A great new method for easily deploying new applications to users-that is, using small (generally less than 100-KB) .rap.msi files deployed using Group Policy software distribution.

• Less work for you as administrator because you no longer have to configure entire remote desktops for users but only RemoteApp programs, and this you can easily do using a wizard.

• No more getting caught up in the argument of whether Terminal Services is for rich clients or thin clients-RDP 6.0 together with RemoteApp makes every client rich.

What are some best practices for using TS RemoteApp? Well first, if you have some programs that are intended to work together-that is, they share data by embedding or linking using DDE-it’s a good idea to run these RemoteApp programs from the same terminal server instead of dividing the programs up onto different terminal servers. That way, the experience for users will be enhanced, and they will see better integration between different programs when they run them. And second, you should put different programs on different terminal servers if you have application compatibility issues between several programs or if you have a single heavy-use application that could result in users filling the capacity of one of your terminal servers. (Use the x64 architecture instead of x86, however, if you want much greater capacity for your terminal servers.)