The information in this article applies to:
IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe. SUMMARYThis 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. MORE INFORMATION
Log on as an Administrator to the Terminal Server computer, to install
applications. 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 attempt to put their own DLL files
into these directories.
-OR- -AND- -OR- If 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 IntegrationWhen you integrate an application into a Terminal Server environment, your primary areas of consideration are:
As a rule, follow the application guidelines below when selecting or developing applications:
Application Installation and ConfigurationIn a multiuser environment such as Terminal Server, it is essential that all users be able to 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, slowing the logon process, and increasing 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, perform the following 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 his or her 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 the DLL and INI files 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 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 doing 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 copies the required INI files to their 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 using the user-global method of installing 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 Control Panel Add/Remove Programs tool, or type "change user /install" (without quotation marks) at the command prompt to place the session into installation mode. Either of these methods will ensure that any INI files are installed to the Terminal Server system directory, instead of the user's home Windows directory.When the installation is complete, click FINISH if you used the Add/Remove Programs tool, 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. Most Win32 applications install in a pseudo user-global fashion by default, 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 using installation mode so that multiple users have separate copies of these files. It is recommended that you always install any Windows application, whether 16-bit or 32-bit, 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 using one of the two methods that follow. Microsoft recommends installing applications through the Control Panel Add/Remove Programs tool. To perform a user-global installation using the Add/Remove Programs tool, complete the following steps:
To perform a user-global installation using the command prompt, complete the following steps:
It is okay to shut down and restart the computer if you are prompted to. When the server restarts, it always starts in execute mode. Proceed to step 6, below. Steps Common to Both Installation ModesIf you need to determine whether the system is in execute or installation mode, type the following at the MS-DOS command prompt: You can tune the exact actions performed when a user-global application is started and optimized by creating and setting compatibility bits in registry variables associated with the application. The following sections describe what happens in installation mode and execute mode. Installation ModePutting a user's session in installation mode before installing an application causes the application to be installed in the %SystemRoot% directory, rather than in the user's home directory. Whenever a user's session is in installation mode, all changes made to an application's INI files are written to this central location. Placing the session in installation mode allows Terminal Server to keep track of the user-specific application registry entries and any INI files that the application may install during installation. This allows Terminal Server to automatically propagate these registry keys and files to each user as they are needed by applications while in execute mode. After an application has been installed, return the user's session to execute mode. This avoids writing user-specific data to the initial user-global installation. When a session is in installation mode, the following happens when installing an application:WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT, you should also update your Emergency Repair Disk (ERD).
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. What happens when a %SystemRoot% INI file is newer than the INI file in the user's home directory is controlled by the 0x00000040 bit of the registry value for the file, which is located in the following subkey:NOTE: The registry path above is one address. It has been wrapped for readability. If the bit is 0 (zero), or 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. 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 his or her user profile (or from the default profile, if no user profile exists for them), and are stored in HKEY_USERS\SID, where SID is the security identifier for the user's account. The values are then compared with the system values stored in the following subkey: NOTE: The registry path above is one address. It has been wrapped for readability. 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 is set to 1 for the following subkey: NOTE: The registry path above is one address. It has been wrapped for readability. HKEY_CURRENT_USER will point to the HKEY_USERS path for the current user, when there are multiple users on the Terminal Server computer. While an application is running, the following occurs:
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:NOTE: The registry path above is one address. It has been wrapped for readability. There are three separate keys for applications, INI files, and registry entries under this registry path. The default settings work for most applications, but can be further tuned, using the compatibility bits described below. WARNING: These compatibility bits should only be changed if an application is not working properly. The first set of compatibility bits indicates the version of the application that the settings are for. Not all combinations are useful; for example, an MS-DOS application will never 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), specifying the application type will help ensure that the compatibility settings do not affect other applications that have the same filename. Add the values of the bits you want to set, to get the String Value. 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 in the following location: WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT, you should also update your Emergency Repair Disk (ERD).
ApplicationsThe compatibility bits below affect the application when it is running. They are located in the following registry subkey:NOTE: Appname is the name of the application's executable file (for example, if the executable file name for an application is Prog1.exe, the appname would be PROG1). Compatibility Bits
Use "Disable registry mapping for this application" to retain only one global copy of the registry variables used by the application. The "Do not substitute user Windows directory" bit, when set, retains the SystemRoot directory for GetWindowsDirectory API calls. The default action, if this bit is not set, is to replace all paths to the Windows directory with the path to the user's Windows directory. INI FilesThe compatibility bits below are located in the following registry path. They control INI file propagation.NOTE: Inifile is the name of the INI file (for example, if the INI file name for an application is Prog1.ini, the Inifile would be PROG1) Compatibility Bits
When set, the "Do not substitute user Windows directory" bit 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 compatibility bits below are located in the following registry subkey, and control registry propagation.NOTE: Pathname is the registry path in the HKEY_CURRENT_USER\Software key (for example, if the registry variable path for an application is HKEY_CURRENT_USER\Software\BrandX\PROG1, the pathname would be Brandx\PROG1). Compatibility Bits
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:RegOpenKeyEx RegCloseKeyEx RegEnumKeyEx RegDeleteKeyEx RegQueryValueEx RegSetValueExUsing these APIs in installation mode will time stamp the entry and cause an update of each user's registry settings on his or her next logon attempt. Manually editing the registry does not change the time stamp for the registry entry, and the changes will not be propagated to users when they log on. 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 addresses Gateways NetWare NDS requirements Unique Network AddressesSome applications are designed to require a unique network interface card (NIC) address, for each instance of the application. An example of this design is a client/server application that requires a unique IP address for each client connecting to a server. An application designed to communicate in this way allows 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 must be able 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 will not run in a Terminal Server MultiWin environment. For an application to properly communicate in a MultiWin environment, the application must be able to negotiate a private socket. This allows the client and server to communicate using a unique IP/PORT/SOCKET address.IPXSome applications that use IPX use a hard-coded socket for communications, relying on a NIC address as the unique identifier. These applications will not run in a Terminal Server MultiWin environment, because all users communicate over the same NIC address, causing incorrect program operation.NetBEUI and NetBIOSSome applications that use NetBEUI or NetBIOS use a specific name as the unique identifier. These applications will not run in a Terminal Server MultiWin environment, because all users communicate using the same specific name, causing 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, allowing 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 running in the NDS environment do not use the NDS-specific APIs. They run exactly as they would if they were in a NetWare bindery (NetWare 3.x) environment. Applications running on a Terminal Server computer must be able 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 rather than a server environment. It may be helpful to think of Terminal Server as a collection of virtual computers running Windows NT Workstations. For example, computers running Windows NT Workstation allow processes only a few cycles of CPU time before switching to other waiting processes. This enhances the multitasking of user applications. Terminal Server is tuned to handle processes the same way that Windows NT Server is tuned differently, allowing server application (for example, SQL Server or Microsoft Exchange Server) processes to use the CPU for much longer periods of time before switching to other queued 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 Servers (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:
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: Graphics and Font Considerations:
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, an entire font set must be downloaded, because TrueType fonts cannot be used. This would cause performance to degrade severely, so 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 that allow the blinking cursor to be disabled, are preferred. This can be configured with the Control Panel tool. Additional query words:
Keywords : |
|
Last Reviewed: February 24, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |