With MetaFrame XP, application installation is a bit more complex than on standard workstations. You must prepare your MetaFrame XP servers (or any Terminal Servers) for a new application before it can be installed. The reason for this is that when Microsoft Windows was designed, only one user could be interactively logged onto a computer at any given time. With Terminal Server, hundreds of users can be logged on "interactively" at the same time.
By the way, a user is said to be logged on "interactively" to a Windows computer if he is viewing that computer's screen and using its keyboard and mouse. In traditional network environments, users are "interactively" logged onto their local workstations, but they are not interactively 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. Logging onto a server "interactively" is Windows NT 4.0 terminology. In Windows 2000, the term logged on "locally" is used. These two terms can be used interchangeably. Technically, to say that a user is logged on "locally" in Windows 2000 is a bit deceptive, because Terminal Services or MetaFrame ICA users are said to be logged-on to a server "locally," even though they are connecting through the network.
Either way, installing applications in multi-user environments like MetaFrame is more complex than installing applications on regular computers. In this section, we're going to take a look at some of the decisions you'll have to make and the problems that you'll likely encounter when installing these applications.
Problems with Applications in Multi-User Environments
Before you think about installing any applications onto your MetaFrame XP servers, you should examine how applications function in multi-user environments like Terminal Server and MetaFrame. There are a few problems that can arise that don't exist in traditional single-user workstation application installs. The two main problems are:
- Application configuration files are not correctly used.
- The Windows Registry is not correctly used.
Let's take a more detailed look at each of these problems and why you need to be concerned with them when you install applications onto your MetaFrame XP servers.
Problem 1. Application Config Files are not Correctly Used
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 is usually okay if only one user will ever use the application (like in standard workstation-based computing environments), but it doesn't work when multiple users need to use the application on the same computer (i.e. the MetaFrame XP server). In MetaFrame XP environments, any configuration options that one user changes would affect all of the users because they are all pointing back to the same .INI configuration files.
Problem 2. The Windows Registry is not Correctly Used
Some applications that you might need to install will not properly use the Windows registry. Usually these are expensive industry-specific applications written by small companies (which coincidentally tend to be the types of applications most used in MetaFrame XP 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 has 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.
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 (like S-1-5-21-1993962763-920026266-854245398-1002) that is used internally by Windows to keep track of each user.
Every time users logon in a Terminal Services environment, their 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 with each user's unique settings stored in the registry structure under their SID name. Fifty users logged in at the same time will mean that there are fifty SIDs listed in the HKU hive.
Incidentally, if you look in the registry, 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 to the current user's SID in the HKU hive. The only reason that this hive exists is to make it easier for you to know which HKU hive belongs to the active user. If you view the HKCU hive from an ICA session that is logged on as "Brian" you will see one set of data. Viewing the HKCU from another session logged on as "Holli" 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 their personal registry keys in the HKU hive, not in the server-wide HKLM hive. Unfortunately, many of today's applications store configuration information in the HKLM hive, which means that the same settings will apply to all users. Fortunately, there are ways to avoid this scenario in Terminal Services environments.
How Terminal Services Addresses These Two Problems
The main problem that these two application scenarios cause is that certain applications do not recognize user-specific application settings. Individual users cannot customize their own applications. Another way to describe this problem is that any changes one user makes to the application are suddenly applied to all users who use the application.
To prevent this from happening, you need to put your Terminal Server into an application "installation mode" before you attempt 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 that the application's installation program makes 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 application installation is complete, you need to take the server out of install mode. Then, whenever a user launches an application the server will check for the proper registry entries in the real HKLM and the user's HKCU and compare them 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 then 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 you add new software this way, you are 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. You can change it back to execute mode with the command change user /execute. If you forget which mode your server is in, you can check it with the command change user /query.
Install mode and execute mode work the same way for both Terminal Server 4.0 and Windows 2000 with Terminal Services enabled in application mode. The only small difference is that Windows 2000 includes additional logic to "force" you to remember to use install mode for installing applications. Basically, if you try to run a program like setup.exe, Windows 2000 will pop up a dialog box saying that the server must be in install mode before the application can be installed. When this happens, you can quickly jump to a command prompt, type change user /install, and then rerun your setup program. This is a nice feature, because there are many occasions with Terminal Server 4.0 where people install 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.
If an application needs to wait for a reboot in order to complete certain installation tasks then the application installation programs can add scripts to the "runonce" 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 if it's after a reboot.
Installing New or Untested Applications
Now that you know about placing your servers in install mode you can begin to install your applications. Even though installing an application on a MetaFrame XP server is like installing an application on any standard workstation, there are some best practices that you should follow to ensure 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 applications "readme" file. Because Terminal Server deals with applications a bit differently than regular computers, there are often little tweaks and tricks that you will need to apply to applications to get them to run right. Terminal Server has been around for awhile 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 list online community 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 community, such as the THIN list at http://thethin.net. Regardless of the application that you're trying to install, there's a good chance that someone else has already installed it on a MetaFrame server. Visit http://thethin.net and search the THIN list archive for your application's name. (This archive grows by about 2000 messages every 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 MetaFrame XP environments have "workstation" and "server" install modes. These types of applications have two components: the server component and the workstation component. Since your MetaFrame XP servers are basically nothing more than gigantic shared workstations, you need to perform a "standard" workstation install on your MetaFrame XP servers.
If there's ever a situation in which you don't know which installation options you should choose for an application when you're installing it on a MetaFrame XP server, just 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 MetaFrame server. However, for a lot of applications the "thin client" mode of installation means 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 for an application on your MetaFrame server-but you shouldn't automatically use this option just because you're using Citrix. 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 and 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. However, the people who write the software applications often create applications that were only meant to be used in old-fashioned (i.e. 1998) single-user environments where only a single user is logged on "locally." This means that many applications installed onto a Terminal Server might not realize that multiple users will be accessing the application simultaneously.
"Application compatibility" is a dying term used to describe the process of making applications that were never intended for use in multi-user environments. This term is mainly used for applications that were released prior to Terminal Server 4.0 (Summer 1998). Out of the box, Windows 2000 with Terminal Services and Terminal Server 4.0 have some default logon scripts that run and are very confusing. You've probably noticed that an empty DOS box titled "usrlogon.cmd" pops up each time a user logs onto the server (this pops up minimized in Windows 2000). This logon script (which is launched from the registry) is used for legacy application compatibility purposes.
"Application compatibility" is achieved through scripts that run in order to "fix" any problems that specific applications have in Terminal Server environments. Application compatibility scripts are located in the folder "%system root%\application compatibility scripts\." You will find that this folder comes populated with dozens of scripts, most of which are useless because they are for applications that are now so old nobody uses them anymore. Most applications released after 1998 are Terminal Services-savvy and do not require application compatibility scripts.
Most of these old application compatibility scripts contain two parts. The first, located in the install subdirectory, is a script that is meant to be executed just after the application has been installed. It "fixes" the application to work in a Terminal Server environment by changing locations and permissions of registry keys and ensuring that custom settings are saved per user instead of per machine.
The second part of an application compatibility script, located in the logon subdirectory, is executed at the time a user logs on. It creates the application's directory structure and .INI files in the user's home directory. For example, the Microsoft Word 97 application compatibility script creates several items, including the user's custom dictionary and a folder for storing clipart.
These application compatibility scripts create a system variable called %ROOTDRIVE%. The %ROOTDRIVE% variable is a drive letter that is created and used by legacy applications when local home drives are used. The drive letter specified by the %ROOTDRIVE% variable is mapped to a user's home drive. By doing so, an application can refer to the %ROOTDRIVE% drive letter in the registry, allowing each user to have a different drive location because the drive letter is mapped to a different location.
Figure 4.1 details the Terminal Services default logon scripts, how they're run, and when they are called. If all of the applications that you're using were written after 1998 then you can probably ignore this entire chart. However, it is worth being familiar with this application compatibility process because there are times when it comes in handy for use with tricky, newer applications.
Figure 4.1: The application compatibility logon script process