We have a number of users accessing our software using Windows Terminal Services. We do not endorse this method of using our software (although we have some experience in setting up and using Terminal Services for other people's software that we also support). We know that some people have had troubles getting our software to work under terminal services and this information may help.

Our applications are ALL installed totally into their own folder. Our installation process doesn't write to any other folders other than the application's own folder and sub-folders. However the programs themselves access an INI file (normally in the main Windows folder). If this ini file doesn't exist or if it has been deleted it will be created when the program is next run. The ini file is used to store various settings such as which database to open for each user of the system and so every user must have their own ini file in their own windows folder. This doesn't normally happen with Windows Terminal Services.

Sometimes different versions of DLL and/or VBX and/or OCX files exist in our program folder compared to the Windows or Windows System folders. This can cause problems but generally it is safe to locate the latest version of the duplicated DLL/VBX/OCX file and copy this over any earlier versions. We sometimes copy all of these files to the C:\Windows\System and C:\Windows\System32 folders just to be sure - but the installation program doesn't do this itself. Sometimes other software uses different versions of the same DLL and VBX files that we use and these may be stored elsewhere on the system and the same thing generally applies here - replace the earlier versions of these files with the latest versions - everywhere they exist.

How Terminal Services uses INI files

On a non-Terminal Services box, applications are coded to look in %systemroot% for any .ini files that the application needs. %systemroot% is normally the C:\Windows folder (or in some cases like Windows-2000 the C:\WinNT folder). In a Terminal Services session, the application looks for the .ini file in \%homedrive%\windows or some other path that resolves to the \windows folder under the home directory drive. Each user has a home directory path usually C:\Documents and Settings\UserName (eg C:\Documents and Settings\Fred or C:\Documents and Settings\Ethel) and so, if there is a C:\Documents and Settings\Fred\Windows folder then Windows will look for the INI files in that folder first and if they don't exist there then it will look in the C:\Windows folder. Actually Windows may just look in the C:\Documents and Settings\Fred folder and not the C:\Documents and Settings\Fred\Windows folder - we're not exactly sure about this.

With Terminal Services, Windows directs all calls to .ini files to the user's home directory even when the rootdrive drive letter isn't set. If the user doesn't have a home directory, Windows uses the profile directory. This behaviour lets Win2K store per-user settings in .ini files and prevents contention between multiple sessions attempting to access an .ini file simultaneously.

Change User Command

The Change User command is used to Change the setting for WTS .ini file mapping.

Syntax: change user { /execute | /install | /query }

/executeEnables .ini file mapping to the home directory. This is the default setting.
/installDisables .ini file mapping to the home directory. All .ini files are read and written to the system directory. You must disable .ini file mapping when installing applications on a terminal server which we think is the INSTALL mode that Windows insists on you using when you attempt to install new software.
/queryDisplays the current setting for .ini file mapping.
/?Displays help at the command prompt.


Use change user /install before installing an application to create .ini files for the application in the system directory. These files are used as master copies for user-specific .ini files. After installing the application, use change user /execute to revert to standard .ini file mapping.

The first time you run the application, it searches the home directory for its .ini files. If the .ini files are not found in the home directory, but are found in the system directory, Terminal Services copies the .ini files to the home directory, ensuring that each user has a unique copy of the application .ini files. Any new .ini files are created in the home directory.

Each user should have a unique copy of the .ini files for an application. This prevents instances where different users might have incompatible application configurations (for example, different default directories or screen resolutions).

When the system is in install mode (that is, change user /install), several things occur. All registry entries that are created are shadowed under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TerminalServer\Install. Keys added to HKEY_CURRENT_USER are copied under the \SOFTWARE key, and keys added to HKEY_LOCAL_MACHINE are copied under \MACHINE. If the application queries the Windows directory using system calls, such as GetWindowsDirectory, the terminal server returns the systemroot systemroot The path and folder name where the Windows system files are located. Typically, this is C:\Windows, although you can designate a different drive or folder when you install Windows. You can use the value %systemroot% to replace the actual location of the folder that contains the Windows system files. To identify your systemroot folder, click Start, click Run, type %systemroot%, and then click OK.directory. If any .ini file entries are added using system calls, such as WritePrivateProfileString, they are added to the .ini files under the systemroot directory.

When the system returns to execution mode (that is, change user /execute), and the application tries to read a registry entry under HKEY_CURRENT_USER that does not exist, Terminal Services checks to see whether a copy of the key exists under the \TerminalServer\Install key. If it does, the keys are copied to the appropriate location under HKEY_CURRENT_USER. If the application tries to read from an .ini file that does not exist, Terminal Services searches for that .ini file under the system root. If the .ini file is in the system root, it is copied to the \Windows subdirectory of the user's home directory. If the application queries the Windows directory, the terminal server returns the \Windows subdirectory of the user's home directory.

When you log on, Terminal Services checks whether its system .ini files are newer than the .ini files on your computer. If the system version is newer, your .ini file is either replaced or merged with the newer version. This depends on whether or not the INISYNC bit, 0x40, is set for this .ini file. Your previous version of the .ini file is renamed as Inifile.ctx. If the system registry values under the \TerminalServer\Install key are newer than your version under HKEY_CURRENT_USER, your version of the keys is deleted and replaced with the new keys from \TerminalServer\Install.