Article ID: 186498 - View products that this article applies to.
This article was previously published under Q186498
NoticeThis article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center
(http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fwin2000)is a starting point for planning your migration strategy from Windows 2000. For more information see the Microsoft Support Lifecycle Policy
This article describes the process of installing applications for multiuser use on a Terminal Server computer. This article includes guidelines for application integration, descriptions of installation and execution modes, and registry settings for application control.
Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756To install applications, log on to the Terminal Server computer as an administrator. Back up the SYS and DLL files in your SystemRoot directory (SystemRoot is the directory you selected to install the Terminal Server) operating system and in %SystemRoot%\System32 directories before installation because some applications try to put their own DLL files into these directories.
(http://support.microsoft.com/kb/322756/ )How to back up and restore the registry in Windows
If it is not possible to back up these files, use the following commands:
DIR\%SystemRoot% \System32 Sys32dir.txt
DIR \%SystemRoot% Winntdir.txtIf the installation replaces any of the original Terminal Server files that specifically address the Terminal Server operating system, it could be the source of application problems. After the installation is complete, compare the directories and, if necessary, copy back some of the files.
Application IntegrationIf you integrate an application into a Terminal Server environment, your primary areas of consideration are:
As a rule, follow these application guidelines when you select or develop applications:
Application Installation and ConfigurationIn a multiuser environment such as Terminal Server, it is essential that all users can make use of the same applications concurrently, without interfering with each other's preference settings or data.
The first and most important step is to assign each user a unique home directory (for example, C:\Users\%Username%). Although a default home directory is automatically created for each user in the user's profile, this can cause the user's profile to grow tremendously, which slows the logon process and increases system resource use.
To avoid this problem, and to allow applications to work properly, use User Manager for Domains to assign a separate home directory to each user.
To configure existing users to use separate home directories, follow these steps:
Windows applications often use Windows features, such as the system registry and INI files. Some of the information in these files is common to all users, and some information is user-specific, which may require some application customization.
There are two ways to install 16-bit or 32-bit Windows applications in a Terminal Server environment: user-specific and user-global.
User-Specific InstallationUser-specific means that a specific user installs the application for their own use. The default installation is user-specific. Any INI files or other files that the application tries to place in the default Windows directory are installed to that user's home Windows directory. Even if the application is installed to a network or shared directory, other users may not have access to all of the DLL and INI files that are needed to run the application. The user must do a user-specific installation. In short, a separate installation must be done for each user who wants to use the application. If an application is installed by using the user-specific method, no special considerations regarding the storage and retrieval of data are needed. However, because each application must be completely installed for each user, this method can consume a large amount of disk space and adds to administrative overhead in larger environments.
Some applications offer the option of performing a network installation. This process copies the installation disks or CD-ROM files to a common directory on the network from which individual users can then run a setup or installation utility. This process copies the required INI files to the user's home Windows directory. Although this process uses less space on the Terminal Server computer than multiple user-specific installations, it still requires that a separate process be run for each user.
User-GlobalMicrosoft recommends that you use the user-global method to install Windows Applications. With this method, an application is installed one time by an administrator and can be run by anyone who logs on to that Terminal Server computer. To perform a user-global installation, use the Add/Remove Programs utility in Control Panel, or type change user /install at the command prompt to place the session into installation mode. Either of these methods ensures that any INI files are installed to the Terminal Server system directory, instead of to the user's home Windows directory.
When the installation is complete, click Finish if you used Add/Remove Programs, or use the Change User or Execute command, to place the session back into execute mode. When a user starts the application for the first time, the required user-specific files are automatically copied to the user's home directory.
By default, most Win32 applications install as user-global, even when the session is not in installation mode. These applications make use of Terminal Server's registry, where each user can have a unique set of registry settings. Win16 applications use INI files for configuration settings. They must be installed by using installation mode so that multiple users have separate copies of these files. Microsoft recommends that you always install any Windows application, whether 16-bit or 32-bit, by using installation mode.
Note: The most common mistake in application installation is to insert an application compact disc, let it start with AutoRun, and bring up its installation options, and then install it from the CD's startup options. This installs the application only for the currently logged on user.
Reinstall the application by using one of the following two methods. Microsoft recommends that you install applications by using Add/Remove Programs in Control Panel.
To perform a user-global installation by using Add/Remove Programs, follow these steps:
Steps that Are Common to Both Installation Modes
If you need to determine if the system is in execute or installation mode, type change user /query at the command prompt.
You can configure the exact actions that are performed when a user-global application is started and optimized by creating and setting compatibility bits in registry variables that are associated with the application.
The following sections describe what happens in installation mode and execute mode.
Installation ModeIf you put a user's session in installation mode before you install an application, the application is installed in the %SystemRoot% directory instead of the user's home directory. If a user's session is in installation mode, all changes that are made to an application's INI files are written to this central location. Putting the session in installation mode permits Terminal Server to keep track of the user-specific application registry entries and any INI files that the application may install during installation. This permits Terminal Server to automatically propagate these registry keys and files to each user as they are needed by applications while they are in execute mode. After you install an application, return the user's session to execute mode to avoid writing user-specific data to the initial user-global installation. If a session is in installation mode when you install an application, the following steps occur:
Execute ModeExecute mode is the default mode when a user logs on. Terminal Server compares the INI files in %SystemRoot% to the INI files in the user's home Windows directory. If a %SystemRoot% INI file is newer than the INI file in the user's home directory, the 0x00000040 bit of the registry value for the file is used. This registry value is located in the following subkey:
If the bit is 0 (zero), or if the value does not exist, the user's INI file is over-written with the newer version of the INI file in %SystemRoot%. If the bit is 1, the user's INI file is merged with the newer %SystemRoot% INI file.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles
The user's previous version of the INI file is renamed to Inifile.ctx (where Inifile is the name of the INI file).
Warning: You can read INI files with a text editor but do not save any changes. Terminal Server has no way of knowing that the file has been updated. The changes may be lost and the file may be damaged.
The user's registry values are loaded from the user profile or from the default profile, if no user profile exists. These values are stored in HKEY_USERS\SID, where SID is the security identifier for the user's account. The values are compared with the system values that are stored in the following subkey:
If the user's keys are older, they are deleted and replaced with the system versions. Registry mapping is disabled if the 0x00000100 bit of the registry value for the following subkey is set to 1:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install
If there are multiple users on the Terminal Server computer, HKEY_CURRENT_USER points to the HKEY_USERS path for the current user.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications
While an application is running, the following actions occur:
Controlling Application Execution in Execute ModeSeveral compatibility bits can be set for an application, registry path, or INI file to change how Terminal Server handles the merging of application initialization data when a session is in execute mode. These compatibility bits are set in the registry in the following subkey:
There are three separate keys for applications, INI files, and registry entries under this registry path. The default settings work for most applications, but they can be customized by using the following compatibility bits.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility
Warning: These compatibility bits should only be changed if an application is not working correctly.
The first set of compatibility bits indicates the version of the application that the settings are for. Not all combinations are useful; for example, MS-DOS applications do not make any registry calls. Because the path to the file is not specified and multiple applications may use the same filename (for example, Setup.exe and Install.exe are now regularly used for installation programs), specify the application type to help make sure that the compatibility settings do not affect other applications that have the same filename.
To get the String Value, add the values of the bits you want to set. For example, to return the user name instead of the computer name for both 16- bit and 32-bit versions of Myapp.exe, create a registry key. To do so, follow these steps.
ApplicationsThe following compatibility bits affect the application when it is running. They are located in the following registry subkey, where <Appname> is the name of the application's executable file:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\<Appname>
Use the "Disable registry mapping for this application" bit to retain only one global copy of the registry variables that are used by the application.
If the "Do not substitute user Windows directory" bit is set, it retains the SystemRoot directory for GetWindowsDirectory API calls. If this bit is not set, the default action is to replace all of the paths to the Windows directory with the path to the user's Windows directory.
INI FilesThe following compatibility bits control INI file propogation. They are located in the following registry key, where <Inifile> is the name of the INI file:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles\<Inifile>
If the "Do not substitute user Windows directory" bit is set, it retains the SystemRoot directory for file paths in the INI file when the system master version of the INI file is copied to the user's Windows directory. If this bit is not set, the default action is to replace all paths to the Windows directory with the path to the user's Windows directory.
Registry PathsThe following compatibility bits control registry propagation. They are located in the following registry subkey, where <Pathname> is the registry path in the HKEY_CURRENT_USER\Software key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\RegistryEntries\<Pathname>
Required API Usage for Application CompatibilityTo fully use the user-global installation feature of Terminal Server, an application must use the proper APIs to read and write INI file and registry information.
16-bit ApplicationsThe 16-bit applications must use the GetPrivateProfileString API to read an INI file and the WritePrivateProfileString API to write to an INI file.
32-bit ApplicationsThe 32-bit applications must use the registry APIs to update registry keys. These APIs include:
Application Network IntegrationIn addition to the Windows NT environment requirements, the following considerations may apply to network-aware applications in a Terminal Server environment:
Unique Network AddressesSome applications require a unique network interface card (NIC) address for each instance of the application (for example, a client/server application that requires a unique IP address for each client who connects to a server). These applications permit only one concurrent instance of its client to run on a Terminal Server computer. For an application to properly communicate in a Terminal Server MultiWin environment, the application has to negotiate a unique socket.
The ability to negotiate a unique socket is a key component in the design of a compatible network application. Hard-coding any part of the address scheme may lead to incompatibilities. If two applications try to communicate through the same address, incorrect operation and application failure may result.
TCP/IPSome applications that use the TCP/IP protocol to communicate use the IP address as a hard-coded identifier of the client. Multiple instances of these applications do not run in a Terminal Server MultiWin environment. For an application to correctly communicate in a MultiWin environment, the application has to negotiate a private socket. This permits the client and server to communicate by using a unique IP/PORT/SOCKET address.
IPXSome applications that use IPX use a hard-coded socket for communications and rely on an NIC address as the unique identifier. These applications cannot run in a Terminal Server MultiWin environment because all users communicate over the same NIC address, which causes incorrect program operation.
NetBEUI and NetBIOSSome applications that use NetBEUI or NetBIOS use a specific name as the unique identifier. These applications do not run in a Terminal Server MultiWin environment because all users communicate by using the same specific name, which causes incorrect program operation.
GatewaysSome mainframe connectivity products use the network address of the NIC as a session and user identifier. These products are limited to one concurrent user on a Terminal Server. In these cases, the only solution is to use a data communications gateway between the Terminal Server and the minicomputer. The terminal emulator can then use a virtual socket-based protocol (for example, IPX) to communicate with the gateway, which permits multiple users on the Terminal Server to use the product.
Novell NetWare NDS RequirementsTerminal Server users can be authenticated by, and use resources in, a NetWare NDS (NetWare 4.x) environment. Most applications that run in the NDS environment do not use the NDS-specific APIs. They run like they do in a NetWare bindery (NetWare 3.x) environment. Applications that run on a Terminal Server computer have to operate in a NetWare bindery environment because NDS-specific APIs are not supported.
Other Networking ConsiderationsFor best performance, do not install the server component of client/server software, such as Microsoft SQL Server, on the Terminal Server computer. These components are very resource-intensive and may affect the performance of multiple Terminal Server user sessions. Terminal Server is tuned to run multiple user environments, not a server environment. It may be helpful to think of Terminal Server as a collection of virtual computers that run Windows NT Workstation. For example, computers that run Windows NT Workstation permit processes only a few cycles of CPU time before they switch to other waiting processes. This improves multitasking for user applications. Terminal Server is tuned to handle processes the same way that Windows NT Server is tuned differently, which permits server application (for example, SQL Server or Microsoft Exchange Server) processes to use the CPU for much longer periods of time before the computer switches to other waiting processes.
If you use a COM server application for Terminal Server clients, the server portion of the application cannot be installed on the same Terminal Server computer to which clients connect. It can be placed on other Terminal Server computers (if necessary) or on other non-Terminal Server resources ( which is recommended). The limitation of COM applications is that the client and server portions cannot run on the same Terminal Server computer.
Terminal Server RDP Client and Citrix ICA ClientsMicrosoft's Remote Desktop Protocol (RDP) client and Citrix ICA clients have many common features. Both are designed for high-performance Windows presentation services over low-bandwidth connections.
Microsoft's RDP client and Citrix ICA clients include the following features:
Both the RDP and ICA clients are designed to efficiently transmit keyboard, mouse, and video information. Microsoft and Citrix recommend the following guidelines for graphics:
The use of TrueType fonts is preferred because these fonts are stored on the client. If an application must use custom or Adobe fonts, make sure the fonts are configured as embedded Windows NT fonts to allow faster display. More font technology is now being embedded in the Windows NT kernel; this will improve performance in future versions of Terminal Server. For RDP clients, fonts are the reason why full-screen MS-DOS mode has been disabled. To enable full-screen MS-DOS mode, an entire font set has to be downloaded because TrueType fonts cannot be used. Because this severely degrades performance, the feature has been disabled.
Blinking cursors cause unnecessary bandwidth use because every blink requires data packets to be transmitted. Applications that do not use a blinking cursor or permit the blinking cursor to be disabled are preferred. This can be configured in Control Panel.
Additional commentsThe following reasons are the key reasons that this propagation may not be working:
How to make the master .ini file overwrite the profile .ini file
How to make the master .ini file merge with the profile .ini file