Tweaking Applications for a Multiuser Environment

Improve the Way Single-User Applications Work with Terminal Server

One tricky part of setting up server-based (i.e., thin-client) computing is making applications designed for one user work for multiple users. If you're using Windows NT Server 4.0, Terminal Server Edition, you might have trouble with some applications. As I wrote in "Can a Hybrid Network Work for Your Enterprise?" October 1998, not all applications work well in a thin-client environment. Some use up too many CPU cycles or too much memory, some can't tell whether to apply settings to a user or a computer, and some store information in locations inappropriate to a multiuser OS. Sometimes you're stuck with these problems; if you use such applications, you need to run them from the client desktop. However, some problems are fixable if you take a little time.

Not every application works with Terminal Server, but the following tips will help you tweak those that do. (For information about tweaking DOS applications, see the sidebar "Performance Tuning for DOS Applications," page 72.)

How Applications Install into Terminal Server
To work properly in a multiuser environment, applications need to edit the HKEY_CURRENT_USER branch of the Registry rather than the HKEY_LOCAL_MACHINE branch. Otherwise, per-user settings apply to everyone using the application. Sometimes this condition is merely annoying, and sometimes it's a security violation because users can see or overwrite one another's personal settings. Well-behaved Terminal Server applications make their settings apply to users, not to machines.

However, you can't install applications into HKEY_CURRENT_USER. This key applies to only the current user, and the identity of the current user changes. Thus, you can install applications on Terminal Server in one of two ways: globally, for everyone who logs on to the server, or singly, for the exclusive use of the person logged on during the application's installation. Unfortunately, you can't install an application for a user while you're logged on with another account. Nor can you specify a subset of users who have access to a particular application. If you want only a couple of people to have access to an application, you need to install it for each user separately. After you've installed the application, you can use NTFS permissions to lock it down, and you can create custom profiles that don't provide shortcuts or Start Menu options for the application.

Installing Applications for Multiple Users
How does Terminal Server know how to install an application? Each Terminal Server session has two operating modes: Execute and Install. The names are descriptive of each mode's purpose—Execute mode is for running applications, and Install mode is for installing applications. The mechanics of installing an application depend on which mode you're in when you're running the application's Setup program.

When a session is in Install mode, it creates Registry entries and Terminal Server copies all those Registry entries under the HKEY_LOCAL_MACHINESOFTWARE MicrosoftWindowsNTCurrentVersionTerminalServer Install Registry key. Whenever an application adds keys, Terminal Server copies those keys to HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE under the HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionTerminal ServerInstallMachine Registry key.

You don't have to know all this in regard to Win32 applications. What you do have to know is that when the session is in Execute mode (the usual mode unless you specify otherwise), if an application attempts to read an HKEY_CURRENT_USER Registry entry that doesn't exist, Terminal Server looks under HKEY_LOCAL_MACHINESOFTWARE MicrosoftWindowsNTCurrentVersion Terminal ServerInstall for the missing key. If it finds the key, Terminal Server copies the key and its subkeys to the appropriate location under HKEY_CURRENT_USER and copies any .ini files or user-specific .dll files to the user's home directory. If the user doesn't have a home directory, the files go to the user's personal folder in %systemroot%profiles.

You can put Terminal Server into Install mode with either the Change User command-line utility (if you're installing applications with Run or with the installation program that comes with the application) or a switch in the Add/Remove Programs applet in Control Panel. Change User lets you choose from three options:

Before running a setup program, open a command prompt and run Change User/install. The system will copy all entries to the appropriate Registry key for later copying to each user's Registry settings when the users run the application within their sessions.

If you put a Terminal Server session into Install mode with Change User, the session will stay that way until you run Change User again to revert the session to Execute mode. Therefore, if you want to be sure that Terminal Server goes into Execute mode when you're finished installing an application, the best way is to use the Add/Remove Programs applet.

Add/Remove Programs will put the session into Install mode for the duration of the setup procedure, then automatically revert to Execute mode when setup completes. After prompting you for the location of the installation files, the installation wizard will ask whether you want to give all users the same initial settings (the default option) or whether you want the application settings to apply to only the user from whose workstation you're installing the application. If you choose the default option, you'll put Terminal Server into Install mode. When the application's Setup program finishes running, you'll go back to the wizard, which will prompt you to click Next. Finally, you'll see a dire-looking dialog box telling you to click Finish or Cancel when the installation process is complete but warning you in capital letters not to click before the process is finished. Clicking Finish or Cancel returns the session to Execute mode.

Install mode can help you with more than the installation process. You can use Install to configure an application with general settings that apply to all users. For example, run an application in Install mode to edit any Save File paths so that the paths point to each user's home directory (mapped to a drive letter). Also, you can disable any animations that usually appear in the application. Just bear in mind that any changes you make to an application while in Install mode will copy to the Registry and therefore apply to all users.

For example, take Microsoft's TechNet, a searchable monthly subscription of OS patches, white papers, and Knowledge Base articles. One feature of TechNet that I find especially handy is that it remembers the last page you looked at and the results of the last query you made. Install TechNet in Install mode, and you'll make the application available to all users of that terminal server.

However, suppose Jane runs TechNet while the session is in Install mode, and the last page she views is "Debugging and Profiling Java Applications." The first time that Fred logs on to his terminal server session and runs TechNet, he'll see that article instead of the "Welcome to TechNet" screen that usually displays the first time a user runs TechNet after installing it. If he clicks the Query Results tool, Fred—and any other new user of TechNet on that terminal server—will also see the results of the last query Jane made in Install mode, as well as the history list of all articles Jane viewed and any bookmarks she made. This behavior isn't permanent. In Fred's Registry settings, Terminal Server will store the last article that Fred reviews, so the next time he runs the application, he'll see his article, not Jane's. However, the first time other users run this application, they'll get Jane's original Registry settings stored for TechNet.

In the context of TechNet, this situation isn't terrible. Letting someone else see what technical articles you were looking at when you first opened an application isn't too embarrassing. However, with a more personal product, such as a Web browser, this result can be quite embarrassing. Before running applications in a multiuser environment, check the session modes and make sure that you're running in Execute mode if you're using the application rather than setting the application up for others to use.

Editing the Registry to Make Your Applications Work Well with Others
If working with a Registry editor makes you uncomfortable, you need to back out now. However, at this point, regedt32 is the only tool that will let you make the necessary changes. Just in case, though, back up the Registry before you make any changes, and remember two things. First, be sure to put all values in hexadecimal, not decimal, form. For example, F hex equals 15 decimal, but 15 hex equals 21 decimal. Confusing the two notations can get ugly. Second, when restoring keys, make sure that you select the correct application key. Importing a key wipes out all previous values for the receiving key and replaces them with the new key's values. For example, if you import a key to replace the current values of MYAPP, a subkey of Applications, but accidentally have Applications selected when you choose Restore from the menu, you'll wipe out every Applications subkey. This error is serious because the Registry Editor has no undo feature.

Now that you're properly intimidated, let's make some changes. Because you're making global changes that apply to all instances of an application in all sessions, you can work in Execute mode.

Bad! Bad Application! Go to Sleep!
Not only do CPU-hogging applications underperform in a multiuser environment, they hurt the performance of other applications by denying them cycles. You can edit the Registry to make Terminal Server keep a closer eye on Windows application management, thus denying CPU cycles to applications that use too many cycles (known to NT as Bad Applications). Doing so gives more cycles to the other applications that the CPU-hog was starving, but also makes the errant application less responsive.

To make this edit, open regedt32 and go to the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NT CurrentVersionTerminal Server CompatibilityApplications Registry key. In the Applications subkey, you'll see a long list of subkeys for installed applications. First, check to see whether the application you want to configure is listed (it will be listed by its program name, so Microsoft Windows Word's key will be WINWORD). If it's listed, select the corresponding subkey. If the application isn't listed, or if the application subkey doesn't include the values you need to edit, you'll need to get the values elsewhere. To do so, find the Setup key, designed for Win32 applications, or Setup1, which is similar but designed for both Win16 and Win32 applications. Open Setup and look at the values it contains, which I've described in Table 1. You must save the Setup key, import the key to a new or existing key for the application, then edit these imported settings.

First, highlight Setup, then choose Save Key from the Registry menu and save the Setup key to the default directory with a name of your choosing and a .reg extension. Highlight the Applications subkey and choose Add Key from the Edit menu. Give the new subkey the filename of the application you're configuring, minus the extension (e.g., name wordstar.exe's subkey Wordstar). Leave the Class field blank, and click OK. The new subkey will appear below Applications.

Now, highlight your new key, pick Restore from the Registry menu, and select the .reg file you created earlier. The Registry editor will warn you that you're about to replace the contents of the selected key with the contents of the file you're importing. When you're sure that you're replacing the correct key, click Yes.

Finally, double-click value data entries to make your edits, bearing in mind what those edits will do. Make sure that you've set the flags properly according to whether the application you're editing is a 16-bit or 32-bit application.

Ending the Identity Crisis
Some messaging applications identify users by the computers the applications are running on, not by username. In a single-user environment, this characteristic is irksome because it means you have to know which computer Jim is using to find him. In a multiuser environment, this characteristic means that the application doesn't work among people who try to send messages between sessions. It can't work, because all instances of the application are running on the same computer. Try it yourself—you can't make Windows Chat work on a terminal server to communicate between sessions, because the application references computers. Chat sessions with yourself get dull.

Fix this problem by editing the Flags value that tells you what OS an application is written for. You can apply several compatibility flags to make the application return the version number or tell the application to use the root system directory instead of the user's system directory. The important flag for our purposes is the value 0x10, which tells the application to look for users by their usernames, not their computer names.

To apply more than one flag to an application, add the values of the flags you want to use. To use Windows Chat, for example, add 10 hex to the present value of Flags in WINCHAT under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrent VersionTerminal Server Compatibility Applications Registry key. The normal value for Flags is 8 hex, because Windows Chat is a Win32 application and all Win32 applications have this value. Add to that value 10 hex, specifying that Windows Chat needs to reference usernames, and you get 18 hex.

You don't need to log off or shut down the computer; the new settings take effect as soon as you restart the application. When you click Dial Computer, you'll still see only the list of computers, but you'll be able to type in the username of any person who's logged on to the domain and connect to their computer.

A Little Work for a Lot of Value
The foibles of applications that you can ignore in a single-user environment are often intolerable in a multiuser environment. With a little care, you can take advantage of the Install and Execute modes to set up applications for multiple users, then edit the Registry to make sure those applications stay in line. Installing applications properly in Terminal Server is a little more work than installing applications under single-user NT, but taking a few minutes to do so will really pay off.