Windows Server 2008’s RemoteApp

Executive Summary:

A big disadvantage of using Windows Terminal Services–based applications is the need to open multiple desktops on one computer. Especially for less-experienced users, connecting to another (remote) desktop to run an application while still using the host desktop for other tasks, such as reading email or surfing the Web, can be confusing. And the confusion grows if a user needs to run multiple terminal applications at once, or save files from remote applications. Moreover, users typically need to connect to a VPN to run terminal applications from a location outside the local network (e.g., from a hotel, from home)—which can be time consuming and in some cases impossible (e.g., if the VPN ports are closed on the user’s network). A new Windows Server 2008 feature, Terminal Services (TS) RemoteApp, solves these problems by letting you configure terminal applications to run in the same manner as locally installed applications.

Benefits
Rather than residing on the remote terminal server’s desktop, a RemoteApp program integrates with the client's desktop; it runs in its own window and has its own entry in the taskbar, just like a local application. Users can run RemoteApp programs simultaneously with local programs. If a user is running more than one RemoteApp program on a terminal server, the RemoteApp programs will share the same Terminal Services session and license. If RemoteApp is combined with Server 2008’s Terminal Services Gateway (TS Gateway) feature, users can run terminal applications from any Internet connection without first establishing a VPN connection because TS Gateway allows connection to a terminal server through port 443. For more information about TS Gateway in Server 2008, see “Terminal Services Gateway in Windows Server 2008,” http://www.securityprovip.com/articles/articleid/97209/97209.html.

In addition to providing the same user experience as with locally installed applications, RemoteApp provides several other benefits. Companies can use the feature to centralize application management and to overcome the problem of different client platforms and possible incompatibility with line of business (LOB) applications. Administrators don’t have to modify their network configuration because RemoteApp uses TCP port 3389 (the same as for classic RDP). Deploying RemoteApp programs is easier and less time consuming than deploying new applications, yet RemoteApp maintains the same level of functionality. Roaming and remote users especially benefit from this feature, because their applications are “installed” regardless of which machine they log on to. Finally, using RemoteApp rather than full Remote Desktop significantly decreases network usage because only the application window is shown instead of the entire terminal server desktop.

Installation
To use RemoteApp, you need at least one Server 2008 machine, configured as a terminal server. On the client side, you must have the latest Remote Desktop Connection software (currently, Terminal Services Client 6.0, which you can download from http://support.microsoft.com/kb/925876). If you want to be able to digitally sign RemoteApp programs, you need to have a proper certificate installed on the RemoteApp terminal server. You can obtain a certificate from your local Certificate Authority (CA), or you can buy one commercially.

The first step is to install RemoteApp on the terminal server, with the Terminal Services role. Start Server Manager from the Control Panel Administrative Tools applet, and click Add Roles in the console’s right-hand pane to start the Add Roles wizard. On the Select Server Roles page (which includes a list of available roles), select Terminal Services and click Next. On the Select Role Services page, click Terminal Server. You can also select the Terminal Services Web Access and/or Terminal Services Gateway options, because these services can be used with RemoteApp. The TS Web Access option lets users run remote applications from a Web interface—both Internet and intranet. TS Gateway makes remote applications available from the Internet in the same manner as from the local network.

On the Authentication Method page, select Do not require Network Level Authentication to allow a larger scope of clients to use the service—although with a somewhat lower level of security. (Network Level Authentication—NLA—is a new, more secure authentication method in Server 2008 and Windows Vista; NLA completes user authentication before a full Remote Desktop connection is established and the logon screen appears. NLA helps protect remote computers from hackers and malicious software.)

On the Specify Licensing Mode page, select Configure Later. (By default, you get a license that’s valid for 120 days—after that time, you have to buy licenses.)

Next is the User Groups page, where you select users or groups that will be allowed to use the terminal server. The default value is the Administrators group, which is fine for our purposes. You can add other users and groups at a later time.

Close Server Manager when the wizard completes. You might need to restart the server. After you install the Terminal Services role, you need to install any applications that will be used through terminal access. All applications that use Windows Installer for setup will detect the Terminal Services role on a server and will automatically install in terminal mode. For other applications, you must run the Control Panel Install Application on Terminal Server applet.

Configuration
To configure the RemoteApp service, start the Control Panel Administrative Tools applet, navigate to Terminal Services, and open TS RemoteApp Manager. First, configure the general Terminal Server options. In the right-hand Actions pane, which Figure 1 shows, click Terminal Server Settings.

On the Terminal Server tab, under the Connection settings group of options, you can configure the port on which the terminal server will work (the default is 3389), a server name that clients will use to connect, and the options for requiring server authentication. You need to enter a Fully Qualified Domain Name (FQDN) in the Server name box. If you don’t require a high level of security, leave the default port value.

The Require server authentication option is enabled by default. This setting increases security but requires Secure Sockets Layer (SSL) certificate installation. The SSL certificate is used for securing communication with Windows XP SP2 or Windows Server 2003 remote clients. If you have only Vista clients, you don’t need the SSL certificate—NLA is used instead. If you’re using the TS Web Access functionality (which lets you provide access to RemoteApp programs through a Web page over the Internet or via an intranet), you can configure the terminal server to appear in a TS Web Access home page.

You can also allow or prevent users from running unlisted applications on initial connection. The default setting (which is recommended) prevents users from running unlisted applications—that is, users can’t run any programs that aren’t on the list of RemoteApp programs. Note that programs from a remote host can be started indirectly. For example, suppose you publish Microsoft PowerPoint as a RemoteApp program. The client then runs PowerPoint and opens a presentation that contains URLs. Even though Internet Explorer (IE) isn’t listed as a RemoteApp program, IE will open inside the RDP session.

The TS Gateway tab contains options for configuring the TS Gateway feature for RemoteApp. You can specify a TS Gateway, as well as a logon method for it, for all remote applications installed on a server. The default setting is to let the client automatically detect TS Gateway settings from Group Policy (if the option is configured). You can also specify the TS Gateway address manually, or simply disable TS Gateway use.

On the Digital Signature tab, you can configure signing of .rdp and .msi files that are distributed to clients. This setting isn’t mandatory, but it increases security because it ensures that remote applications aren’t modified after being published from the server. To create a digital signature, you must have a proper certificate (with digital signing capability) installed on the server. You can obtain such a certificate from a local or commercial CA. Note that Vista SP1 is the only client platform that supports signed .rdp files.

The Common RDP Settings tab lets you configure options for device redirection within an RDP session. You can select or deselect types of client devices that can be used from a RemoteApp RDP session. This selection mostly depends on the application type you’re configuring. For example, if you want to make a word processing application available as a remote program, you’ll probably want to allow redirection of the clipboard and printers. You can also configure user experience options, such as color depth and font smoothing, for a RemoteApp session. Your settings for these options will typically depend on the client network connection speed because better user experience requires more bandwidth.

Finally, the Custom RDP Settings tab lets you specify additional RDP settings that aren’t included on other tabs, such as audio redirection. This tab has no configuration options—just an empty text box that you can fill with customized RDP settings. The syntax for those settings is the same as the syntax for .rdp files. So, the easiest way to specify custom RDP settings is to start the Remote Desktop Connection software (on Server 2008 or Vista), specify the settings you need, then save a connection to the .rdp file. Next, use Notepad to open the .rdp file, and copy all or part of the file to the Custom RDP settings text box, as Figure 2 shows.

A best practice is to export all terminal server settings after configuration to create a backup. You can easily accomplish this task by selecting Export Terminal Server Settings, in the right-hand Actions pane on the RemoteApp console.

Creating and Publishing Programs
To create and publish a RemoteApp program, go to the TS RemoteApp Manager and click Add RemoteApp Programs in the right-hand Actions pane to start the wizard for configuring applications as RemoteApp programs. Click Next on the Welcome page to go to the page that lists available programs. As Figure 3 shows, this page contains applications that are installed on the server and available to use with Terminal Server. If a desired application isn’t on the list, you can click Browse to locate the application’s executable file (if installed). The .exe file won’t necessarily be on the local machine—it might be on another server. Selecting an application and clicking Properties lets you configure additional command-line arguments, icons, and the TS Web Access option.

To configure an application for remote use, select the application and click Next. Review the information on the summary page, and click Finish. The TS RemoteApp Manager console will then list the application as a RemoteApp program. Next, you need to deploy the application to clients.

One way to deploy applications is to create an .rdp file for every configured RemoteApp program, then email the file to users or distribute it via file sharing. To use this method, select the RemoteApp program from the list, and click Create .rdp File in the Other Distribution Options section.

After the RemoteApp wizard starts, click Next on the Welcome page. On the Specify Package Settings page, you’ll see a set of configuration options. For the most part, these options are the same ones you already configured in Terminal Server Settings (e.g., port, server name, TS Gateway, certificate). However, this page lets you configure these options for a specific program. If you don’t configure the options here, RemoteApp will use the server settings. You can also specify the location (i.e., folder) for saving the packages that will be distributed to clients. After you configure the desired options, click Next to review the summary, then click Finish.

The folder that you specified as the location to save the packages will then open, showing the .rdp files for the RemoteApp programs. The .rdp files created in this manner are typically placed on a file share or emailed to clients. To run a RemoteApp program, the user must double-click the .rdp file and enter his or her credentials. Although this method is probably the easiest way to deploy RemoteApp programs to clients, it doesn’t fully utilize RemoteApp’s functionality—nor can it be used for deployment through Group Policy.

The other method for deploying RemoteApp programs is to create a .msi (Windows Installer) package for a terminal application. Unlike .rdp files, .msi packages must be installed on a user machine, just like ordinary applications. After installation, the user will have RemoteApp programs available in the Start menu or on the desktop. In addition (and the main difference between using .msi packages rather than .rdp files), the RemoteApp programs will be associated with the proper file extensions on the local computer.

For example, if you configure as a RemoteApp program WinRAR software that’s installed on a terminal server and then distribute the program to clients as a .msi package, after a user installs the package, all the compressed files on the user’s machine will be associated with the RemoteApp WinRAR program. When the user clicks a local .rar or .zip file, the remote program will run and open the compressed file.

Another benefit of using .msi packages for deployment of RemoteApp programs is the ability to deploy the programs via Group Policy. Centrally managed deployment can be very convenient in large environments.

To create a .msi package for a remote application, select the desired application from the list of installed terminal applications, as I already discussed, and click Create Windows Installer Package in the Other Distribution Options section. The first two pages of the wizard are the same as for creating .rdp files.

On the Configure Distribution Package page, which Figure 4 shows, you can configure the location for RemoteApp program shortcuts (i.e., desktop or Start menu). You can also associate client extensions with the RemoteApp program.

After you configure the package options, click Next, Finish. The folder will again open, this time showing the .msi package for the application you want to make available to clients.

You can use Group Policy to distribute .msi packages to clients, or you can use file sharing. Either way, the user must install the application like any other application. After installation, the user can select Remote Programs from the Start menu to open an application, as Figure 5 shows. Alternatively, the user can double-click the program from the desktop.

Benefits for All
Server 2008’s RemoteApp feature benefits both users and administrators. RemoteApp greatly enhances end users’ experience while using terminal applications. In addition, RemoteApp gives administrators more detailed control over terminal resources and security. Another benefit to administrators is that you can configure Server 2008’s Server Core command prompt as a RemoteApp program. Because the command prompt is the only way to administer Server Core, installing the command prompt as a RemoteApp program on a desktop OS gives administrators the full power of administration. You can also install the Windows PowerShell console as a RemoteApp program, which lets you use the program for server administration without having to install it on the client.