- An application writes user specific information to HKEY_LOCAL_MACHINE, thus making this information global for all users who use this application.
- An application writes user specific information only to the installer's HKEY_CURRENT_USER, thus making this information available only to the installer.
- An application uses a single .ini file stored in the Windows directory for user-specific settings.
- An application adds menu shortcuts only to the installer's menu, rather than adding these to the ALL USERS profile.
- An application may fail when multiple users try to access the same file at the same time, resulting in a sharing violation.
One important concept to understand before implementing these scripts is ROOTDRIVE. To illustrate this idea, consider a fictional word processing application, called ApplicationA:
When UserA installs ApplicationA on a Windows NT Workstation, it adds an entry in the registry for the path to UserA's documents. To do this, the installation program queries for the value of %HOMEDRIVE%%HOMEPATH%. The value returned is entered into the registry, and when a user clicks File and clicks Open inside ApplicationA, the browser window that opens defaults to X:\UserA. This is UserA's home directory, specified in User Manager as Connect X: \\Server\Share\UserA.
When an administrator installs ApplicationA on Terminal Server, the same entry for the path to his or her documents is entered. When 30 different users run ApplicationA, an administrator is not going to want them all to save their documents to the same location. There needs to be a unique location for all users to store their files.
The logical place to store a user's personal files is in his or her home directory. By default, a user's home directory is:
This value is referred to as %HOMEDRIVE%%HOMEPATH%. If Terminal Server is installed to drive C in the default directory \WTSRV, when a user (UserA) logs on who does not have a Home Directory specified in User Manager, his or her home directory will be C:\Wtsrv\Profiles\UserA. This can be seen by typing SET at a command prompt:
When a user who has a Home Directory or Terminal Server Home Directory specified in User Manager (Connect X: \\Server\Share\UserA) logs on, the following information is seen when typing SET at a command prompt:
Although this is the logical place to store a user's files, there needs to be a way to address this unique path for all users in the registry. The registry entry for the User's documents path in ApplicationA is:
The value of the path cannot be set to %HOMEDRIVE%%HOMEPATH%. Likewise, the value cannot be X:\%USERNAME%. ApplicationA does not understand either of these entries. To work around this issue, ROOTDRIVE is used.
The first time an application compatibility script is run, Rootdrv2.cmd is run, and the person installing the application is presented with the following information:
REM Before running this application compatibility script, you must
REM designate a drive letter to be mapped to each user's home
REM directory. Update the "Set RootDrive" statement at the end of
REM this file to indicate the desired drive letter. If you have
REM no preference, the drive W: is suggested. For example:
REM Set RootDrive=W:
REM Note: Make sure there are no spaces after the drive letter and
REM When you have completed this task, save this file and exit
REM NotePad to continue running the application compatibility script.
The application compatibility script that was originally run is now called, and all appropriate changes contained within the script are implemented. In this case, the value of
is now set to W:\, because this is the drive letter chosen to be ROOTDRIVE. The easiest way to think of this is ROOTDRIVE = %HOMEDRIVE%%HOMEPATH%. When UserA logs in, his or her drive W = \\Server\Share\UserA. When UserB logs in, his or her drive W = C:\WTSRV\PROFILES\UserB, because he or she does not have a home directory specified in User Manager. When UserA starts ApplicationA, he or she stores all of his or her documents in drive W, as does UserB. Both users' documents, however, are in different places, which is the original issue that needed to be addressed.
ROOTDRIVE is connected by using the Usrlogon.cmd script. This script is run each time a user logs on to the Terminal Server. The script is called from the following location:
NOTE: The above registry key is one path; it has been wrapped for readability.
Listed below is the portion of Usrlogon.cmd that connects ROOTDRIVE:
Rem Map the User's Home Directory to a Drive Letter
Net Use %RootDrive% /D >NUL: 2>&1
Subst %RootDrive% /d >NUL: 2>&1
Subst %RootDrive% %HomeDrive%%HomePath%
As illustrated, ROOTDRIVE is an important feature of Windows NT Server version 4.0, Terminal Server Edition. Because of the fact that most applications written to date were not written with a multiuser environment such as Terminal Server in mind, some issues can be addressed by using application compatibility scripts in conjunction with ROOTDRIVE.
Article ID: 195950 - Last Review: Jun 22, 2014 - Revision: 1