Deploying Applications with Terminal Services
At a Glance:
- The benefits of RemoteApps
- Making applications available to users
- Evaluating a terminal services implementation
- Ensuring a positive user experience
You can find a lot of instruction on the Internet and in your local bookstore on exactly how to install and use Terminal Services. But what's sorely lacking in many of those outlets is information on how best to get remote applications to your users. With minimal effort, you can quickly deploy a terminal server in your environment that hosts your set of needed applications. Yet doing so in a way that meets your users' expectations definitely requires a little extra thought.
If you are a terminal server administrator, take a step back from your remote applications infrastructure and consider the following: How are you deploying applications? Do you supply users with remote desktops or TS RemoteApps? Do users access their apps via static Remote Desktop Protocol (RDP) files, a Web page, or desktop shortcuts?
Greg Shields demonstrates how you can deploy applications with Terminal Services.
In the end, how are you evaluating the experience your users undergo when they use terminal services applications? With the improvements to Terminal Services now available with Windows Server 2008, the best answers to these important questions might surprise you.
Goodbye Desktops, Hello RemoteApps
Windows Server 2008 takes some of the pain out of terminal services administration through a significantly expanded set of services and capabilities. That list of what's new and what's changed was discussed in the November 2008 issue of TechNet Magazine, where Joshua Schnoll detailed the new features gained through the move to Windows Server 2008 ("Presentation Virtualization with Enhanced Terminal Services"). Of those features, arguably the most significant is terminal server's new ability to deploy individual applications to users instead of full desktops.
Called TS RemoteApps, these individual apps appear to users as if the application were installed directly to their local desktops. When a user clicks to launch a RemoteApp, he sees only the application itself on his local computer. No extra Start bar or double desktops intrude to make it plain you're interacting with a non-local system. Depending on the implementation and the expectations of your users, a TS RemoteApp can be superior to deploying an entire desktop simply because it makes these applications seem like a normal part of the local desktop experience.
With Windows Server 2008, creating a new TS RemoteApp is a simple process using the TS RemoteApp Manager console found under Administrative Tools. Clicking the Add RemoteApp Programs link in the Actions pane launches the RemoteApp Wizard, which interrogates the Terminal Server's Windows Management Instrumentation (WMI) store to identify a list of potential applications already installed on the server. An example of this list is shown in Figure 1.
Figure 1 The RemoteApp Wizard enumerates applications installed on the Terminal Server
Select from the list those applications you want to create as RemoteApps and click Next. If your desired application isn't available, click the Browse button and locate its primary EXE file. This will be the EXE file you normally use to launch the application. Complete the wizard and your remote application is ready for deployment.
If you right-click to view the properties of your new RemoteApp, you'll see that a few options can be adjusted. Besides being able to modify the name, location, icon, and alias information, you can also enter command-line arguments. This is handy for applications that require a set of arguments at launch time to function correctly, but it can also be used in conjunction with some applications to create links to remote content.
What a lot of administrators may not immediately realize is that the move to TS RemoteApps enables more than merely presenting applications on a user's screen. With a little sleight of hand, you can use RemoteApps to automatically launch preconfigured content as well.
For example, suppose that instead of deploying an application to users, you want to deploy a specific document. Rather than creating a RemoteApp that links users to an empty Microsoft Office Word or Access application, for example, you want to connect them to a specific Word document or Access database. In such cases, you can do so by entering the name of that document as an argument after the application's primary EXE. Thus, if you want to create a connection to your Access 2007-based PTO (paid time off) database stored at \\fileServer\fileShare\CompanyPTO.accdb, simply create a new RemoteApp called "PTO Database" and enter the document's location as a command-line argument. Now, when a user double-clicks to launch the PTO Database application, they'll automatically be directed to Access with the correct database already preloaded.
As you can see, creating connections to remote content is another way to expand the usefulness of RemoteApps. Yet with all RemoteApps, your users must still be presented with links to the icons to get started. In the next sections, I'll discuss a few ways in which terminal services in Windows Server 2008 makes this happen.
Launching Apps from the Web
The new TS Web Access role service allows the hosting of application shortcuts on a preconfigured Web page. This role service integrates with terminal servers in the environment to provide a single location where users can go to find and launch their applications. Figure 2 shows how this Web page looks to users.
Figure 2 The TS Web Access Web page enumerates deployed RemoteApps
To create such a page, install the TS Web Access role to an existing IIS server, then add the computer account for the TS Web Access server to the TS Web Access Computers Global Group in the domain. Note that for small environments, you can install TS Web Access to an existing terminal server for a single-server solution.
Once you've installed a RemoteApp, enabling it for TS Web Access is done by right-clicking the configured RemoteApp in the TS RemoteApp Manager and selecting Show in TS Web Access. Users with version 6.1 or later of the Remote Desktop Client can then navigate to http://serverName/ts to view a list of application shortcuts. Clicking any of the presented shortcuts automatically launches the RemoteApp.
TS Web Access is an easy way to present a friendly interface for finding and launching applications. It is particularly useful when applications or versions change regularly; updating the Web site involves simply hiding the link to the old application or version in TS Web Access and then showing the new link once it has been installed.
This tool does have some limitations, however. First, there is no built-in mechanism to limit the applications a user can access. Any RemoteApp that has been created on the terminal server and made visible in TS Web Access will be seen by every authenticated user.
The second problem has to do with the way in which users commonly work with their applications. When you want to start an application such as Word, how often do you actually click on the shortcut to the application? Not very often, I'll bet. It's more likely that you double-click an existing Word document to start the application with the document preloaded.
Unfortunately, TS Web Access does not support this method of launching applications. For those who are used to double-clicking documents to launch the linked application, TS Web Access may not be an acceptable solution. Never fear, though, as another much more useful option for this situation is discussed next.
Launching Apps from the Desktop
For users who want to double-click documents to launch the application, terminal services now provides the ability to "install" the remote application's link to the desktop. This process effectively wraps the RemoteApp's RDP file into a Windows Installer package—an MSI file—that is later installed to desktops in the environment.
At the same time, the installed MSI can modify the file extension associations on the desktop to reroute a double-clicked file to its associated RemoteApp on the terminal server. Figure 3 shows how the file extension associations have been modified on a client system after a Word RemoteApp is installed. Now, double-clicking any of the common Word file extensions will launch Word via the Remote Desktop Connection.
Figure 3 File extension associations that have been altered to launch the Remote Desktop Connection
To create a Windows Installer package out of an existing RemoteApp, first navigate to the TS RemoteApp Manager. Right-click the RemoteApp of interest and select Create Windows Installer Package. By default, all created Windows Installer packages are stored in the location C:\Program Files\Packaged Programs, but this location can be changed from within the RemoteApp Wizard. Also configurable within the wizard are the name and port for the server that will host the RemoteApp, as well as server authentication, certificate settings, and TS Gateway settings.
Settings that relate to the application's location after installation to a candidate desktop are shown in Figure 4. As you can see, it is possible to create a shortcut on the desktop as well as to a location within the Start menu folder. The most important checkbox on this screen is at the very bottom. It's the checkbox for Take over client settings, and it re-associates any file extension associations for the RemoteApp from the local desktop to the terminal server. This checkbox must be selected if you want users to be able to double-click documents to launch their TS-hosted application. Click Next and Finish to complete the wizard.
Figure 4 Creating a Windows Installer package enables the association of client file extensions
As is obvious, the upside of using desktop installation for connecting users to applications is that it doesn't require a change in users' behavior. Once the applications are installed, users can double-click documents to launch applications as they've always done.
However, this approach comes with its own downside in the form of extra desktop administration. Each RemoteApp used in this way must be installed to each desktop that requires access. This process is made easier through Group Policy Software Installation—which will be discussed next—but it's still an added management headache. Also, when applications change, it is likely that the installed RemoteApps at each desktop will need to be updated as well.
Once you've created a Windows Installer package, the process to install it via Group Policy Software Installation is not difficult to set up. First, create a file share that can be accessed by Group Policy. A good place for this file share in a single terminal server scenario might be the default C:\Program Files\Packaged Programs folder on your terminal server. Ensure that rights have been appropriately assigned to the folder and the share so that clients will be able to access the share during Group Policy processing. Then, create a new Group Policy Object (GPO) and navigate to Computer Configuration | Policies | Software Settings | Software installation. Right-click Software installation and choose New | Package. In the resulting dialog box, locate the MSI file created for the RemoteApp. When asked for the deployment method, choose Advanced.
At this point you have a choice. Because RemoteApps are extremely small installations that install little more than RDP files and icons to the C:\Program Files\RemotePackages folder, you may want to select the option to Uninstall this application when it falls out of scope of management. By selecting this option, any time the GPO is deleted or if the computer is moved to a new OU where the GPO no longer applies, the RemoteApp will be automatically removed from the computer. Enabling this option makes the process of removing a RemoteApp very simple as computers and applications move in and out of your scope of management.
The User Experience
Deploying applications through any of these mechanisms is great, but there's more to terminal services administration than creating and deploying applications. Ensuring that your implementation is meeting the needs of your users is equally important. With any discussion of application delivery, it is essential to consider a subjective performance metric to capture the quality of the user experience. While difficult to quantify using hard metrics, effective terminal services deployments must look at the aggregate satisfaction of the users as a measure for defining success.
To explain, users can be a particularly troublesome lot, especially when they're sharing resources on the same server. With terminal services, multiple users gather on a single server to share applications installed on that server. The aggregation of large numbers of users onto small numbers of servers eases the management of applications by reducing the count of applications. Fewer applications to manage means less patching, a more controlled environment, and fewer administrative touch points.
This consolidation of users requires the terminal server administrator to play the role of system babysitter. The successful administrator manages the terminal server farm by watching user behaviors on the system and proactively enacting change. Changes arrive as reconfigurations and lockdowns to ensure that one user's bad behavior doesn't impact the experience of other users.
As an example, effective terminal server administrators will configure performance alerts to notify them when processor utilization has spiked to and remains at a very high level. Such behavior often indicates that a process has spiked a processor or that a user has initiated an action that uses too many resources on the shared system. Tracing down and killing the offending process is only the first step in resolving the incident. Finding out why that process behaved in the way it did is the long-term solution to the problem.
In such situations, the idea is to ensure that a remote application performs at least as well as would be expected on the local desktop. The sidebar, "Key Terminal Services Performance Counters," illuminates some PerfMon metrics that will get you on the right track.
RemoteApps = Predictable Performance
A RemoteApp is effectively a terminal services session where the width and height of the session is exactly the same as that of the application being launched. The result is that the remote application appears local because the boundary of the session never expands beyond the boundary of the app itself.
The Microsoft implementation of RemoteApps is actually quite a bit smarter than the previous explanation might suggest to you. A deployed RemoteApp is not the same as a deployed full desktop from the perspective of the resources needed to get it up and operational. To launch a remote desktop requires the instantiation of explorer.exe to operate the desktop shell, plus all the processes configured to start with explorer.exe, such as system tray applications, helper applications, or any services or processes that accompany a standard desktop.
In contrast, the launching of a RemoteApp does not require the full explorer.exe shell or all the add-ons. In fact, RemoteApps replace explorer.exe with two other processes named rdpshell.exe and rdpinit.exe. It is these two slimmed-down processes that operate as the alternative shell and shell logon application used to bootstrap a RemoteApp into existence.
Figure 5 shows a simplistic example of a terminal server where two users have connected and launched the calculator application. User1 has logged in via a full desktop, while User2 has connected to a pre-created RemoteApp instance of calc.exe. Although you'll note that User2 has a larger count of running processes required to launch the calc RemoteApp, the sum total of memory use of those processes is less than what is required for User1's explorer shell, as you can see in Figure 6.
Figure 5 Task Manager shows the differences in resource use between desktops and RemoteApps
|Figure 6 Examples of memory use|
|Running Processes||User1–Full Desktop||User2–RemoteApp|
This reduced RAM consumption is only one part of the performance discussion. The impact of user behavior on processor use must also be considered. When a user is deployed with a full desktop, he is in effect being given the ability to run any application that is installed to the terminal server.
Without proper lockdowns in place, a lightweight user who leverages terminal services for writing documents in Word can, at any point, become a heavyweight user by launching another more powerful application with higher resource needs. This behavioral unpredictability makes the planning of resources per user challenging. It also complicates administration of the terminal server, increasing the possibility that one user's behavior will impact the experience of other users.
There is perhaps no better example of this unpredictability than with Internet Explorer. Installed to every instance of Windows Server, this application typically does not require many resources to run. Yet when Internet Explorer is used to render a poorly written Web site that requires numerous plug-ins, its resource use can increase dramatically. A user who inappropriately and unexpectedly runs Internet Explorer while in a desktop session can accidentally over-consume available resources on the terminal server, causing the performance of others to slow.
In contrast to full desktops, the structure of RemoteApps tends to grant them more predictability in resource use. A user who launches a RemoteApp can work only with that specific application and others spawned by the initial application. Thus, the user's behavior tends to be more predictable from a performance standpoint.
You Have Options
Ultimately, the goal of this article is to let you know about the options you have for deploying remote applications to your users. The new features available with terminal services in Windows Server 2008 provide multiple paths for users to connect to applications. Some combination of desktop-hosted and Web-hosted plus full desktop versus RemoteApp will be the correct configuration for your individual environment.
Key Terminal Services Performance Counters
While measuring the experience of the user is often a subjective activity that involves personal interviews more than metrics, there are some useful performance counters whose measurement can help you determine terminal server performance—which impacts user satisfaction. You should consider measuring the following counters on your terminal servers:
Memory\Available MBytes When this counter shrinks to a very low number, it means that processes on the terminal server are consuming much of the available physical memory. Low numbers here aren't necessarily bad, but when combined with a high thread count and high pages/sec, low numbers can mean too many users attempting to do too many things on one terminal server.
Memory\Pages/Sec This counter relates to the rate in which memory is being read from or written to disk. A high count here in combination with a low count for Available MBytes can mean that available memory is not sufficient for the load being placed on the server and can therefore result in a poor user experience.
Processor\% Processor Time This counter effectively shows how much the processor is being used by productive work. You should watch this metric closely, especially in multiprocessor systems, as it can indicate a hung or spiking processor.
System\Threads Each process being run by the server is made up of a number of threads. The Threads counter is an integer that is the sum total across all processes on the system. Terminal servers tend to have high thread and process counts due to the number of people simultaneously using system resources. When this count grows high, it is reasonable to assume that a large number of activities are being attempted simultaneously on the server. A high thread count often results in a high count for Context Switches as the server attempts to handle the needs of each process.
System\Context Switches/Sec A Context Switch occurs each time the processor changes the thread it is currently processing. There is a slight overhead associated with each context switch, so a high count here—as with a high thread count—can mean that many users are attempting to do many things at once.
System\Processor Queue Length When the processor cannot keep up with the load, the requests begin to line up. The counter for that line is called the Processor Queue Length. When this counter grows high, you can assume that the server's processors are being overloaded with requests—which can also indicate an impact on the user's experience.
Terminal Services\Active Sessions and Terminal Services\Total Sessions These two metrics can help to effectively assess resource use against the number of users working on your terminal server. The first counter measures users who are actively working with the session, while the second counter includes users who are idle or have disconnected. These two counters, in combination with the others, are useful in helping you identify the maximum number of users your server can handle before it becomes overloaded and the user experience diminishes as a result.
The actual numbers you see will depend on your hardware composition, installed applications, and count and type of users on the system. Providing exact numbers as thresholds can therefore be misleading. Instead, you should look for variations in your own numbers or times when your metrics are far from their normal operations as an initial guide to determine when the user experience may not be good.
Greg Shields, MVP, is a co-founder and IT guru with Concentrated Technology. His latest book, Windows Server 2008: What's New/What's Changed, is available through SAPIEN Press. Get to know Greg at www.ConcentratedTech.com.