Questioning Terminal Services Behavior

I have a question regarding Windows 2000 Server Terminal Services. Let me first explain the situation: I have a shrink-wrapped application that, on a non-Terminal Services box, is coded to look in %systemroot% for an .ini file that the application needs. But 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 that I've configured for all users in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. (Each user also has a home directory path specified in the format \servernameusername$.)

I know that this behavior is typical for Terminal Services running in Application mode, but because I don't use any application-compatibility scripts and haven't set the rootdrive drive letter, the logon process skips all the Subst commands in the usrlogon.cmd logon script. Can I modify Terminal Services' behavior so that I can troubleshoot this logon problem and possibly modify the behavior (e.g., change the %homedrive%windows directory to %homedrive%wts because of a conflict with another application)?

With Terminal Services, Win2K 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, Win2K uses the profile directory. This behavior lets Win2K store per-user settings in .ini files and prevents contention between multiple sessions attempting to access an .ini file simultaneously.

You can't change the directory name for the user .ini files; the filename must always be windows. However, you can attempt to play with compatibility flags for the specific executable in question by following the instructions in the Microsoft article "Terminal Server Registry Settings for Applications" (http://support.microsoft.com/?kbid=186499). Specifically, you might be able to disable .ini file mapping for a specific application. To do so, open a registry editor and navigate to the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminalServerCompatibilityApplicationsMyApp registry subkey, where MyApp represents the name of the executable in question (e.g., MyApp.exe). Enable the Do not substitute user Windows directory bit of the subkey's compatibility Flags value (note that the Microsoft article incorrectly refers to this value as Flags of). How well this strategy works will depend on the application, so the trick might not work with all applications under Terminal Services.

Finally, be very careful when playing with this setting, as you might run into trouble if the users need write access to the .ini file or if the .ini file becomes locked when one user is accessing it. (Thanks to my colleague Greyson Mitchem for his input to this answer.)