As often mentioned in this chapter, how applications are installed under Windows Server 2003 depends on whether the server is configured as a terminal server or a normal server. The reasons were outlined previously in this chapter: the two types of servers differ in their handling of the registry and .ini files.
Before you install an application, you should block user access to the server. You can completely disable the RDP protocol using Terminal Services configuration or selectively block certain user groups from accessing RDP. Once that is done, an administrator can perform the required work on the console. If the RDP protocol is blocked to selective users, an administrator may use a remote RDP console session.
What problems can occur in the registry as the central instance of system configuration?
If an application is installed and configuration data that all users need is written to the installing user’s individual area instead of to the global area of the registry, then the application will work perfectly for that user, but not for anyone else. Important application data will be stored in that user’s profile only (usually an authorized administrator).
When an application is installed, user-specific data may be deliberately omitted from the user-specific area of the registry. Instead, the data is entered when the user opens the application for the first time. Some values, however, might have to be predefined by the administrator.
Creating .ini files can also cause massive problems during installation. True INI (initialization file) mapping allows redirection of individual .ini files to any user’s profile. (See Chapter 4.) Yet this approach makes sense only when the terminal server is in normal mode. During an installation, the administrator should be able to store a default .ini file in a central location. If a user later starts the application for the first time, the central .ini file can be used to initialize the user’s own .ini file, which is then saved in his or her profile.
These problems should no longer arise with .NET programs because they do not use .ini files and therefore do not access the wrong areas in the registry. Nonetheless, we recommend using the following procedures for Framework applications, too.
To overcome the above-mentioned problems, you need to change the terminal server from normal execution mode to special installation mode before installing an application. You can use the Add or Remove Programs Software tool in the Control Panel or type the following command at the prompt:
change user /install
If the terminal server is not running in installation mode, it automatically switches to installation mode when the default Setup.exe command executes the installation program. However, this offers no real protection against installation errors. If the installation routine naming convention does not use the Setup.exe command, the installation will probably run in the wrong mode. We recommend using the Add or Remove Programs Software tool in the Control Panel because this insures that the terminal server will be in proper mode during application installation.
You can check the terminal server’s current mode at any time using the change user/query command.
Figure 5-1: Changing a terminal server to installation mode and checking the mode from the command prompt.
After you switch to installation mode, install the application as usual, which involves several processes. All user-specific registry entries are automatically mirrored to a system-wide registry area. The path is HKLM\Software\Microsoft\Windows NT \CurrentVersion\Terminal Server\Install\Software. (See Chapter 6.)
If a user other than the administrator needs the information, the data is supplied through the previously mirrored, system-wide registry path. This is called registry mapping. The data saved in the Terminal Server\Install registry path are overwritten by the user profile. Only Terminal Services running in application mode activates these minor modifications to the Windows kernel. This easily solves the first of the two registry problems discussed earlier.
If the application requests the Windows directory during installation (for example, using system requests such as GetWindowsDirectory), the terminal server returns the system’s root directory. This directory is clearly defined in the %WinDir% environment variable. If you add entries to existing .ini files (with system requests such as WritePrivateProfileString), you access the .ini files in the system’s root directory if the system is running in installation mode. The same goes for creating new .ini files. INI mapping is disabled while the terminal server is running in installation mode. This modification to the Windows kernel takes effect only if the system is a terminal server.
The previous explanation of the installation mode points us to the solution to the second registry problem: How do we create central application parameters in the registry when the application is used for the first time? In execution mode, all registry entries are saved in the administrator’s profile—after all, the terminal server is designed to keep user data separate. The solution is that the administrator installing the application should invoke it for the first time with the terminal server still in installation mode. Mirroring the user-specific entries saves the application configuration to the registry’s system-wide area. These entries are then copied to each user’s profile when the system resumes running in execution mode.
It is now clear why applications might not function correctly if they were installed before Windows Server 2003 was made a terminal server. Neither registry mapping nor INI mapping work properly in this instance.
If the administrator has already invoked the application in execution mode, a temporary administrator should be set up to launch the application in installation mode and configure it such that all users later have access to the needed information (such as path, colors, font size, and so on). When other users launch the application for the first time, the associated data are also saved in the system-wide registry hive named HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install. Once this process is complete, the administrator account can either be deleted or temporarily disabled until it is needed again for similar tasks. If entries containing the user name were made in the system-wide registry area when the application was first used, the name might need to be globalized. You can use the %UserName% environment variable to modify the registry manually. (See Chapter 6.)
When installing an application on a terminal server, never start a previously installed application, such as Microsoft Internet Explorer, unless absolutely necessary. In installation mode, all changes to your personal settings will be mirrored to the system-wide registry area and included in other users’ profiles. Many applications change their registry settings when they are started, or, at the latest, when they are terminated. The settings you unintentionally bequeath to other user sessions on the terminal server might have unforeseen ramifications.
Once an application is installed, you need to return the system to normal execution mode. If you used the Add or Remove Programs tool in the Control Panel or Setup.exe to install the program, you will be prompted to do so in the final dialog box.
Alternatively, you can reset the system to execution mode by entering the following command at the command prompt:
change user /execute
You should always finalize an installation properly, even if it was unsuccessful. Use the dialog box shown in Figure 5-2 or the command prompt. Otherwise, the system will remain in installation mode and therefore mirror individual settings by the administrator to the system-wide area of the registry.
Figure 5-2: Final dialog box after installing an application on a terminal server.