Terminal Server application integration information

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: To 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.

If it is not possible to back up these files, use the following commands: 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 Integration

If you integrate an application into a Terminal Server environment, your primary areas of consideration are:

• Application installation and configuration
• Application network communications
• Application video performance

Some applications have characteristics that, although relatively benign in a single-user environment, may lead to decreased performance, or application incompatibilities, in a Terminal Server multiuser distributed presentation environment. Understanding and avoiding (if possible) these characteristics helps ensure the smooth integration of an application into a Terminal Server environment.

As a rule, follow these application guidelines when you select or develop applications:

• Win32 (32-bit Windows) applications are preferred over Win16 (16-bit Windows) applications. Terminal Server runs Win16 applications through a process called "Win16 on Win32," which causes Win16 applications to consume about 20 percent more resources than comparable Win32 applications.
• The Windows INI files must be accessed by using the proper Windows APIs so that the INI file synchronization features of Terminal Server work correctly.
• Applications (primarily MS-DOS applications) that poll a hardware device or the keyboard, instead of waiting for an event, can have an adverse effect on system performance. You can use the DOSKBD command to tune MS-DOS applications that perform excessive keyboard polling. Whenever possible, use the Windows APIs instead of building custom code. Many Windows APIs have Terminal Server MultiWin enhancements to seamlessly support a multi-user environment.
• Avoid hard-coding paths and network identifiers.
• NetWare applications must be able to run in bindery mode.
• MS-DOS graphics are not supported on Terminal Server clients.
• Avoid using bitmaps in graphics. Use vector-based graphics instead. Use the raster operator to brush graphics on the screen for best performance.
• VxDs are not supported in a Windows NT, Windows 2000,or Terminal Server environment.

The following sections discuss some of these guidelines in greater detail.

Application Installation and Configuration

In 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:

1. Log on as an administrator and start User Manager for Domains.
2. If you are logged on to the domain and want to change local users, on the User menu, click Select Domain, and then type the name of the Terminal Server computer that the user accounts are on.
3. Click the user accounts that you want to change. To select multiple user accounts, press and hold the SHIFT key while you press the UP ARROW and DOWN ARROW keys. To select all of the user accounts in a specific group, on the User menu, and then click Select Users.
4. On the User menu, click Properties.
5. Click Profile.
6. Click the Local Path option, and then type the following command:
   drive:\Users\%Username%
   Where drive is the drive on which Terminal Server is installed (usually drive C) and Users is the directory that was created by the system for home directories.
   
   Note: Although Users is the directory that is created for home directories, any directory can be created and used.
7. Click OK to return to the User Properties dialog box.
8. Click OK to return to User Manager for Domains.

MS-DOS and OS/2 text applications can generally be installed and used without modification. MS-DOS applications that perform keyboard polling may have to be modified with the DOSKBD command to avoid excessive resource consumption.

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 Installation

User-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-Global

Microsoft 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:

1. Log on to the Terminal Server computer as an administrator.
2. Click Start, point to Settings, and then click Control Panel.
3. Double-click Add/Remove Programs.
4. Click Install. If Add/Remove Programs cannot find a setup program, locate, and then select the setup program.
5. Select to install for all users or for only the user who is currently logged on. If you install for all users, the system is put in installation mode and permits Terminal Server to keep track of the user-specific application registry entries, INI files, and DLL files that the application adds to the Terminal Server system during installation.
   
   
6. Follow the installation instructions for the application.
   
   If you are prompted to type your name during the installation process, you may want to use a generic name because the name will be the default for all users.
7. Configure the default program settings that you want all users to have.
8. When the installation is complete, click Finish, which returns the system to execute mode. Restart the server if you are prompted to, and then continue to the "Steps that Are Common to Both Installation Modes" section.

To perform a user-global installation by using the command prompt, follow these steps:

1. Log on to the Terminal Server computer as an administrator.
2. Click Start, point to Programs, and then click Command Prompt.
3. At the command prompt, type change user /install. This command puts the system in installation mode and permits Terminal Server to keep track of the user-specific application registry entries, INI files, and DLL files that the application adds to the Terminal Server system during installation.
   
   
4. Follow the installation instructions for the application.
5. Configure the default program settings you want all users to have.
6. After the installation is complete, switch to the command prompt, and then type change user /execute, which returns the system to execute mode.
7. Restart the computer if you are prompted to, and then continue to the "Steps that Are Common to Both Installation Modes" section.

Steps that Are Common to Both Installation Modes

1. Verify that any icon groups that the application created are located in the All Users profile (the equivalent of common groups in Citrix Winframe or Windows NT 3.51), which is located in the %SystemRoot%\Profiles directorySpecifically. Check that the icons were created in the Profiles\All Users\Start Menu\Programs directory. Icons that are created in the Profiles\All Users\Start Menu\Programs directory are displayed on the lower (common) portion of the user's Programs submenu (click Start, and then point to Programs). Icons created in the user's profile, or in the Default User profile, are displayed on the upper (personal) portion of the user's Programs submenu. Some applications are hard-coded to write to the user's profile only. Simply copy the icons to the All Users profile.
   
   
2. Log off and then log back on as a user to verify that the application works correctly. Make sure that any shared resources, such as network drives or printers, are set up for each user before you run the application. Check the software documentation for any notes that may apply to the installation or the use of the application.
3. Write-protect the application's directory from all non-administrator users. This permits users to read the program files and protects the files from inadvertent changes or deletion.

Note: If you installed to an NTFS partition, the security options in Windows Explorer permit you to set the security for a wide array of options. They restrict access only to specific users or groups. If the application was installed on a FAT partition, you can use the ATTRIB command to mark the files and directories as read-only, but you cannot use the advanced security features of NTFS. For this reason, Microsoft recommends that you install Terminal Server, and all applications, on NTFS partitions. Although the use of NTFS is not required, it does provide a wider range of security options. If the applications reside on a NetWare file server, use the FILER program to set the security options.

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 Mode

If 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:

• All registry entries that are created for the current user are shadowed in the following subkey:
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install
• Registry keys that are added by an application to the HKEY_LOCAL_MACHINE hive are copied in the following subkey:
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Machine
• If an application queries the WINDOWS directory by using the GetWindowsDirectory API, Terminal Server returns the %SystemRoot% Directory. If any INI file entries are added by using the WritePrivateProfileString API, they are added to the INI files in the %SystemRoot% directory.
• If the application does not use these APIs for modifying INI files, the results cannot be predicted and can cause performance or usability problems.

Execute Mode

Execute 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.

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: If there are multiple users on the Terminal Server computer, HKEY_CURRENT_USER points to the HKEY_USERS path for the current user.

While an application is running, the following actions occur:

• If an application tries to read a registry key under HKEY_CURRENT_USER that does not exist, Terminal Server checks for the key in the following location:
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install
• If an application tries to read a registry key under HKEY_CURRENT_USER that exists, the key and its subkeys are copied to the appropriate location in HKEY_CURRENT_USER.
• If an application uses the GetPrivateProfileString API to read an INI file that does not exist in the user's home Windows directory, Terminal Server checks for the INI file in %SystemRoot%.
• If an application uses the GetPrivateProfileString API to read an INI file that exists in %SystemRoot%, the INI file is copied to the user's home directory.
• If an application uses the GetWindowsDirectory API to query the Windows directory path, Terminal Server returns the user's home directory.

Controlling Application Execution in Execute Mode

Several 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.

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.

1. Start Registry Editor.
2. Locate the following subkey:
   HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\Myapp
3. On the Edit menu, click Add Value, and type the following information:
   Value Name: Flags
   Type: REG_DWORD
4. Type the hex value of 11C (add 0x00000004 for 16-bit Windows applications, add 0x00000008 for 32-bit Windows applications, add 0x00000010 to return the user name instead of the computer name, and add 0x00000100 to disable registry mapping).

Applications

The 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:

Compatibility Bits

• DOS application: 0x00000001
• OS/2 application: 0x00000002
• Windows 16-bit application: 0x00000004
• Windows 32-bit application: 0x00000008
• Return user name instead of computer name: 0x00000010
• Return Terminal Server build number: 0x00000020
• Disable registry mapping for this application: 0x00000100
• Do not substitute user Windows directory: 0x00000400

Use the "Return user name instead of computer name" bit for applications that use the computer name as a unique identifier. This bit returns the user's name to the application and gives a unique identifier to each user of the application.

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 Files

The following compatibility bits control INI file propogation. They are located in the following registry key, where <Inifile> is the name of the INI file:

Compatibility Bits

• Windows 16-bit application: 0x00000004
• Windows 32-bit application: 0x00000008
• Synchronize user INI file to system version: 0x00000040
• Do not substitute user Windows directory: 0x00000080

If the "Synchronize user INI file to system version" bit is set, it adds new entries from the system master INI file when the application is started, and does not delete any existing data in the user's INI file. If this bit is not set, the default action is to overwrite the user's INI file if it is older than the system master INI file.

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 Paths

The 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:

Compatibility Bits

• Windows 32-bit application: 0x00000008
• Disable registry mapping for application: 0x00000100

If the "Disable registry mapping for application" bit is set, it adds new entries from the system master registry image when the application is started. It does not delete any existing data in the user's registry. If this bit is not set, the default action is to delete and write over the user's registry data if it is older than the system master registry data.

Required API Usage for Application Compatibility

To 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 Applications

The 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 Applications

The 32-bit applications must use the registry APIs to update registry keys. These APIs include:

• RegOpenKeyEx
• RegCloseKeyEx
• RegEnumKeyEx
• RegDeleteKeyEx
• RegQueryValueEx
• RegSetValueEx

In installation mode, these APIs time-stamp the entry and update each user's registry settings the next time that they log in. If the registry is manually edited, the time stamp for the registry entry is not updated, and the changes are not propagated to users when they log on.

Application Network Integration

In 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
• Novell NetWare NDS requirements

Unique Network Addresses

Some 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/IP

Some 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.

IPX

Some 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 NetBIOS

Some 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.

Gateways

Some 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 Requirements

Terminal 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 Considerations

For 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 Clients

Microsoft'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:

• Graphical Windows application screen presentation
• Keyboard and mouse input
• Session control
• Error detection and recovery
• Encryption
• Data compression
• Multiple security levels
• General purpose Terminal Server browsing

Citrix ICA clients add the following features:

• Full-screen text presentation
• Framing for asynchronous connections
• File system redirection
• Print redirection
• COM port redirection
• Multiple generic virtual channels
• Cut and paste across clients and servers
• Multiple operating system platforms, including MS-DOS, Windows 3.1, Macintosh, UNIX

To use the Citrix ICA client with Terminal Server, install the Citrix add- on service, code-named Metaframe, which is currently in beta. Metaframe also allows administrators to define SPX, NetBEUI, and asynchronous connections in Terminal Server Connection Configuration. The initial release of Terminal Server uses only a TCP/IP connection (RDP is encapsulated and uses TCP for transport and connecting at port 3389).

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:

• Use vector graphics instead of bit-mapped images for graphics.
• Use the raster operator to brush graphics to the screen.

Bitmaps require more bandwidth than vector graphics because all of the image data for each unique bitmap must be transmitted from the server at least one time. RDP and ICA clients compensate for this by caching each unique bitmap on the client system. If a bitmap is to be displayed, it is compared with the client's locally cached bitmaps. If the displayed bitmap matches one that is already cached at the client, a command is sent that tells the the client to display the local copy instead of sending the image over the network.

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 comments

The following reasons are the key reasons that this propagation may not be working:

1. The client or server is not accessing the .ini file with the appropriate APIs.
2. The Terminal Server is not in /install mode when its .ini file is being written to by the correct APIs. For example, when in /install mode it writes to the server C:\%systemroot%\Win.ini file instead of the Administrator user's home drive copy of the file that is located in the administrator user profile.
3. The correct registry setting is not made in the following key:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Inifiles\

How to make the master .ini file overwrite the profile .ini file

1. On the server, follow these steps:
   1. Put the Terminal Server in /install mode.
   2. Write the .ini file with the WritePrivateProfile APIs.
   3. Start /execute mode.
2. On the client, follow these steps:
   1. Log on to the client computer.
   2. The .ini file will not exist in the profile.
   3. Read the .ini file with GetPrivateProfile APIs.
   4. The .ini file will be copied to the profile.
   5. Log off the client computer.
3. On the server, follow these steps:
   1. Put the Terminal Server in /install mode
   2. Update the .ini file with the WritePrivateProfile APIs.
   3. Start /execute mode.
4. On the client, follow these steps:
   1. Log on to the client computer.
   2. The .ini file will have been renamed to a .CTX file extension.
   3. Read the .ini file with GetPrivateProfile APIs.
   4. A new copy of the .ini file will be copied to the profile.

How to make the master .ini file merge with the profile .ini file

1. On the server, follow these steps:
   1. Put the Terminal Server in /install mode.
   2. Write the .ini file with the WritePrivateProfile APIs.
   3. Start /execute mode.
2. On the client, follow these steps:
   1. Log on to the client computer.
   2. The .ini file will not exist in the profile.
   3. Read the .ini file with GetPrivateProfile APIs.
   4. The .ini file will be copied to the profile.
   5. Update the .ini file with WritePrivateProfile APIs.
   6. Log off the client computer.
3. On the server, follow these steps:
   1. Put the Terminal Server in /install mode.
   2. Update the .ini file with the WritePrivateProfile APIs.
   3. Put the server in /execute mode.
4. On the client, follow these steps:
   1. Log on to the client computer.
   2. Read the .ini file with the GetPrivateProfileString/Int APIs.
   3. A new copy of the Inifile.upd file will be created in the profile.
   4. The profile .ini file will be merged with the server version of the .ini file.