SUMMARY
A common issue that is encountered with Terminal Server is that most
applications written to date were not written with Terminal Server in mind.
In other words, these applications are not natively multiuser. This is not
to say that these applications were poorly written, it just illustrates
that most applications were written to accommodate a single user running
them at one time. Listed below are some of the reasons an application may
fail in a multiuser environment, such as Terminal Server:
- 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.
To work around problems such as these, Terminal Server uses application
compatibility scripts. These scripts are essentially batch files that
address scenarios such as the ones previously mentioned. Microsoft includes
several application compatibility scripts with Terminal Server, located in
%SystemRoot%\Application Compatibility Scripts. However, keep in mind that
these scripts are examples, and may need to be modified by an administrator
for certain environments.
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:
%SystemRoot%\Profiles\%USERNAME%
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:
HOMEDRIVE=C:
HOMEPATH=\WTSRV\PROFILES\UserA
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:
HOMEDRIVE=X:
HOMEPATH=\UserA
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:
HKEY_CURRENT_USER\Software\CompanyA\ApplicationA\DefaultPath
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
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
REM Set RootDrive=W:
REM
REM Note: Make sure there are no spaces after the drive letter and
REM colon.
REM
REM When you have completed this task, save this file and exit
REM NotePad to continue running the application compatibility script.
REM
Set RootDrive=
The installer is required to select a drive letter. Any drive letter may be
chosen, but it is important that it not be the drive letter specified in
User Manager for either the Home Directory or Terminal Server Home
Directory (in this example, X was used for UserA's home directory).
Furthermore, the installer should not choose a drive letter that is used in
a logon script. In this scenario, the person installing ApplicationA
decides to use the suggested drive letter W:.
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
HKEY_CURRENT_USER\Software\CompanyA\ApplicationA\DefaultPath
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:
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion
\Winlogon\Appsetup
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
Rem Map the User's Home Directory to a Drive Letter
Rem
Net Use %RootDrive% /D >NUL: 2>&1
Subst %RootDrive% /d >NUL: 2>&1
Subst %RootDrive% %HomeDrive%%HomePath%
The first line is a NET USE statement that deletes any drive letter that
currently exists that is using the drive letter that was chosen for
ROOTDRIVE. The second line is a SUBST command with a /d switch that deletes
any substituted drive you have that has the same letter as the drive letter
that was chosen for ROOTDRIVE. Finally, the third line runs the SUBST
command for %HOMEDRIVE%%HOMEPATH% with the drive letter that was chosen for
ROOTDRIVE.
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.