Chapter 5: Application Strategies and Server Sizing

Previous chapters detailed necessary considerations for designing your Terminal Server environment. Terminal Server exists for one reason—to allow users to run applications. Clearly, it's important to build your Terminal Server design around the applications that your users require and the methods by which those applications are accessed.

We begin this chapter with a study of what it takes in install applications onto a Terminal Server. We'll then examine how to design load-balanced clusters, and close with a section on Terminal Server sizing and hardware selection.

Installing Applications

When installing applications onto a Terminal Server, the installation is more complex than on standard workstations. (You probably learned this the hard way when you stuck an Office 2000 CD into a Terminal Server and were informed that you needed MSTs and transforms and text editors and…) In Terminal Server environments, you must first prepare the server for a new application installation.

All this extra work is necessary due with the fact that when Microsoft Windows was designed, only one user could be locally logged onto a computer at any given time. With Terminal Server, hundreds of users can be simultaneously logged on "locally."

As an aside, a user is said to be logged on "locally" to a Windows computer if he is viewing that computer's screen and using its keyboard and mouse. In traditional network environments, users are "locally" logged onto their own workstations, but are not locally logged onto the servers because they are only accessing server resources through the network rather than using the server's keyboard and mouse and viewing its screen.

In older versions of Terminal Server, the term "interactively" was used in place of "locally." Now these two terms can be used interchangeably. Technically, to say that a user is logged on "locally" in Windows 2003 is deceptive. Terminal Server users are said to be logged on "locally" even though they're connecting through the network and not using a console session.

Either way, installing applications in multi-user environments such as Terminal Server is more involved than installing applications on regular computers. In this section, we'll take a look at some of the decisions you'll have to make and the problems that you'll likely encounter when installing applications.

Problems with Applications in Multi-User Environments

Prior to installing applications onto your Terminal Servers, you should understand how applications function in multi-user environments. Problems can arise that don't exist in traditional single-user workstation application installs. These problems derive from:

• Application configuration files being used incorrectly.

• The Windows registry being used incorrectly.

Problem 1. Application Config Files are not Used Correctly

A lot of older applications store their configuration options in .INI files located in common folders, such as c:\program files\old application name\appconfig.ini. This setup is acceptable if only one user will ever use the application (as in standard workstation-based computing environments), but it doesn't suffice when multiple users need to use the application on the same computer (i.e. the Terminal server). In Terminal Server environments, any configuration options that one user changes would affect users since they are all pointing back to the same .INI configuration files.

Applications that work this way are becoming increasingly rare, although there are still enough of them out there to keep your job interesting.

Problem 2. The Windows Registry is not Used Correctly

Some Windows applications do not properly make use of the Windows registry. Such applications are usually expensive industry-specific applications written by very small vendors (and coincidentally tend to be the types of applications most used in Terminal Server environments).

To understand how applications often incorrectly use the Windows registry, we should first look at how applications correctly use the registry. The Windows registry consists of several main sections, or "hives." Applications store their configuration information in two hives: the "machine" hive and the "user" hive.

• The machine hive (HKEY_LOCAL_MACHINE, or simply HKLM) contains settings and configurations for applications that apply machine-wide (for all users that log onto that particular computer).

• The user hive (HKEY_USERS, or HKU) contains application settings and configurations that apply to each individual user, allowing different users to have different settings. If these settings ever conflict with application settings as configured in the machine hive, the user-hive settings take precedence.

The HKU hive has a subtree (a registry folder) for each locally (or "interactively") logged-on user, named by the user's Security Identifier, or SID. Remember from your basic Windows training that a SID is a unique serial number (such as S-1-5-21-1993962763-920026266-854245398-1002) that is used internally by Windows to keep track of each user.

Each time a user logs on to a Terminal Server, his own subtree is added to the HKU hive. If you have two users logged onto a server then you will see two SIDs listed under the HKU hive and each user's unique settings stored in the registry structure under his SID. Fifty users logged in at the same time will appear as fifty SID folders listed in the HKU hive.

Incidentally, if you look in the registry (via regedit.exe), you will notice a hive called HKEY_CURRENT_USER, or HKCU. This hive does not contain any real data; rather, it is simply a pointer (or "alias") to the current user's SID in the HKU hive. This hive exists to allow an application that's running within a user's session to be able to read and write settings for that user. (Essentially, the application only has to request data from the HKCU hive, and the system will automatically sort out which SID folder in the HKU hive it will use.)

If you view the HKCU hive from an RDP session that is logged on as "Brian," you will see one set of data. Viewing the HKCU from another session logged on as "Ron" will reveal a different set of data. You can edit a user's registry settings in either place—the HKCU hive or the user's SID subtree in the HKU hive.

For an application to be properly installed onto a multi-user server, the application must store each user's personal configuration options in his personal registry keys in the HKU hive, not in the server-wide HKLM hive. Many of today's applications store configuration information in the HKLM hive, meaning that the same settings will apply to all users. Luckily, there are ways to avoid this scenario in Terminal Services environments.

How Terminal Server Addresses These Two Problems

The main problem introduced by these two application scenarios is that certain applications do not recognize user-specific application settings. Individual users cannot customize their own applications. Another way to describe this issue is that any changes one user makes to the application are suddenly applied to all users of the application.

In traditional, non-Terminal Server environments, whenever a user exclaimed, "I didn't change anything! It just happened," you always knew he was lying. However, with Terminal Servers, each user is essentially sharing his computer with several dozen of his closet coworkers. Suddenly the "I didn't do it" excuse seems not so ridiculous.

Windows Server 2003 includes features that can help you to alleviate these problems.

How Terminal Server 2003 Handles Application Installations

Put your Terminal Server into an application "installation mode" before attempting to install any applications. When you do this, your Terminal server captures all registry and .INI file changes during the software installation. These changes are all redirected to the HKLM\Software\Microsoft\WindowsNT \CurrentVersion\TerminalServer\Install registry location, which acts as a caching area for the current application installation session. This registry location contains two subkeys: software and machine. Any changes or additions made by the application's installation program to the current user's hive (HKCU) are copied to the software key. Changes or additions made to the machine hive (HKLM) are added to the machine subkey.

After the application installation is complete, take the server out of the installation mode. Subsequently, whenever a user launches an application, the server checks for the proper registry entries in the real HKLM and the user's HKCU and compares those to the entries that the system previously recorded from the software installation. If the entries to not exist in the proper HKLM and HKCU locations, the server will copy them from the install keys listed above to the proper locations in HKLM and HKCU.

Ordinarily, a Terminal Server operates in "execute mode." You can place a Terminal Server into "install mode" by installing new software via the "Add / Remove Programs" component of the Control Panel. When adding new software this way, you're given the choice as to whether you are installing the software for the current user only (causing the server to remain in execute mode) or for any user that logs on (temporarily setting the server into install mode). You can also manually set the server into install mode via the command "change user /install." Change it back to execute mode with the command "change user /execute." If you forget which mode your server is in, check it with the command "change user /query."

Install mode and execute mode work the same for both Terminal Services on Windows 2000 and Windows 2003. Both versions of Windows contain logic that attempts to "force" you to remember to use install mode for installing applications. If you try to run a program like setup.exe or install.exe, the system will display a pop up box asking you to click "next" once the installation is complete. When this happens, the server has basically forced the system into "install mode" just as if you have manually run change user /install from a command prompt. This is a nice feature, because there were many occasions with early versions of Terminal Server when people installed applications only to realize later that they forgot to place the server into "install mode." The only remedy was to uninstall the application, change the server to "install mode," and then reinstall the application.

Some applications need to wait for a reboot in order to complete certain installation. They do this by adding commands to the "runonce" registry key (HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce). Any program listed in this key is executed one time after the server is rebooted. Terminal Server is smart enough to use install mode for all entries that are listed in the "runonce" key, even after a reboot.

Dealing with configuration files introduces a whole other set of issues. Generally, 16-bit (and even some 32-bit) applications read a user's settings from some type of configuration files. The most common files are .INI files, but .CFG and .DAT are not unheard of. The problem resides not with the files themselves but with how the applications attempt to locate them.

If an application was hard-coded to look for its .INI file in the c:\Windows folder, multiple users logged onto the same system looking to use the same .INI file can be a problem. Most new applications avoid this difficulty by using the %WINDIR% system variable instead of containing the hard-coded path of c:\windows" In these cases, Terminal Server masks the real %WINDIR% from the application, instead redirecting the %WINDIR% path to a "windows" folder in the user's home folder. (Home folders are discussed in Chapter 6.)

With new applications, at worst you would have to copy the required INI files to the user's home directory. On the other hand, if the application is absolutely 100% hard-coded to use the "c:\Windows" directory and each user requires a unique .INI, you may be out of luck.

Windows Server 2003 Registry Changes

Microsoft made several changes to the registry in Windows Server 2003. (Technically these changes were introduced in Windows XP.) For example, the Windows 2003 registry has no size limit and doesn't consume nearly as much memory, but those attributes are more relevant to server sizing. We'll cover them in Chapter 13.

Relevant here is the fact that Windows 2003 changes the way "classes" are managed in the registry. In the Windows registry, "classes" (and their associated "class IDs") refer the filename associations and data associated with COM objects.

In prior versions of Windows, class information was stored in the HKLM\Software\Classes key—a shared location. (This key is an alias to the HKEY_CLASSES_ROOT hive.) Windows 2003 extends this key by writing additional class information to a personal key for each user—the HKCU\Software\Classes key. (This key is an alias to the HKU\<SID>_Classes key.)

Translation? Quite simply, it means that with Terminal Server 2003, individual users can each have their own class settings. This is important for two reasons:

• Prior versions of Terminal Server (even as recent as Windows 2000) would often show DCOM errors when shared registry keys couldn't be updated or when an application accidentally registered a class to another user's SID. This doesn't happen in Windows 2003.

• In Windows 2003, you can easily customize file associations on a peruser basis (since those associations are now stored in the HKCU hive instead of the HKLM hive). You can make the default application associated with .DOC files the free Word viewer instead of having to buy a full Microsoft Word license for each user. At the same time, you can have Word installed on the server and configured for only the users who need it. Not only does this save you money, but it also saves server resources, ultimately enabling more users to fit on a server.

• As you can see, the Windows Server 2003 registry has come a long way in terms of supporting multiple users in Terminal Server environments.

Installing New or Untested Applications

Now you can begin the actual process of installing your applications. Although installing an application on a Terminal Server is similar to installing an application on any standard workstation, adhering to some best practices ensures your application is installed properly:

• Install all of the application options that you think any user would ever need. Disk drive space is so cheap and plentiful these days that it really doesn't do any good to restrict certain application features by not installing them (unless you have business reasons to prevent users from using certain application features). For example, if you're installing Microsoft Office, perform a "custom" setup and select all the options.

• Check out the application's "readme" file. Because Terminal Server deals with applications differently from regular computers, there are often little tweaks and tricks that you will need to apply to applications to get them to run correctly. Terminal Server has been around for a while now, and most applications are written to support it. More often than not, Terminal Server-specific information is included in the application's readme file. The THIN online community ( http://thethin.net ) gets a few requests per week from novice administrators asking how to install Microsoft Office XP on a Terminal Server, even though the exact process is described step-by-step in the Office readme file.

• Refer to an online support community such as the THIN list. (See the appendix of this book for a complete list.) Whatever application you're trying to install, there's a good chance that someone else has already installed it on a Terminal Server. Visit http://thethin.net and search the THIN list archive for your application's name. (This archive grows by about 2000 messages each month.) If you don't find anything in the archive, try sending a message out to the group asking about your application.

Knowing Which Application Options to Use

Many applications used in Terminal Server environments have "workstation" and "server" install modes. These applications have two components: the server component and the workstation component. Since your Terminal Servers are essentially gigantic shared workstations, you need to perform a "standard" workstation install on your servers.

If there's ever a situation in which you don't know which installation options to choose for an application when you're installing it on a Terminal Server, choose the options that you would use if you were installing the application onto a standard user's workstation.

For example, some applications have a "thin client" mode of installation. At first this might seem like the perfect installation option to use on a Terminal Server. But for a lot of applications the "thin client" mode of installation indicates that the bulk of the application's client files have been preinstalled onto a file share somewhere, and that the local workstation install only needs to contain user configuration information. Lotus Notes, Baan, SAP, and PeopleSoft are all examples of these types of applications.

If your application offers it, there's nothing wrong with using this type of "thin client" installation option on your Terminal Server, but you shouldn't automatically use it just because you're using Terminal Services. Again, the bottom line is that you should install your application with the same options as if you were performing a standard end user workstation install.

Legacy Application Compatibility

Microsoft (well, technically Citrix) had to do quite a bit of engineering and redeveloping of many Windows components to allow multiple users to be simultaneously logged on "locally" to servers in Terminal Server environments. Even with the work that was done to the OS, the vendors who create software applications don't always take Terminal Server environments into consideration when writing their applications.

When Terminal Server first came out in 1998, just about every application in existence didn't quite work right when installed on it. To combat that, Microsoft (and the other vendors) created application compatibility scripts that "fixed" applications to work on multi-user servers. These scripts were nothing more than batch files that ran to change certain application settings (file locations, registry entries, etc.).

Fortunately, much has changed in six years, and these application compatibility scripts are largely a relic of the past. Terminal Server 2003 only ships with scripts for three applications (as compared to dozens in previous versions of Windows). However, even though Microsoft has decided it doesn't need to support many legacy applications, you might not be as fortunate in your own situation.

We won't take the time here to detail exactly how Windows uses the few remaining out-of-the-box application compatibility scripts, but it is important that you have at least a basic knowledge of how they work in case you need to design your own for the occasional misbehaving application.

Most application compatibility scripts are used in pairs. The first script is typically executed by an administrator just after an application is installed. The second is run once for each user, usually as part of a logon script. Let's consider a sample application. We'll use Lotus Notes, since it is widely familiar and is (was?) typical of an application that requires the use of compatibility scripts.

Once Notes was installed on the Terminal Server, you had to run the first application compatibility script. This script made several changes to Notes .INI files, changing the default options so to be saved on a per-user instead of per-server basis.

Next, you logged on as a dummy user and perform a Lotus Notes "node" install. This install configured Notes for the user and put a whole bunch of files in his home directory, including more .INI configuration files.

Then you logged on as an administrator and copied all the Notes files from the dummy user's home directory to a network share. The final step was to add the second application compatibility script to each user's logon script. Upon logon, this script would check to see if the current user had a "Notes" folder in his home directory. If not, the script would copy the default configuration files from the network share into the home directory, thus completing the "per-user" configuration of Lotus Notes.