Q: Ever since I ran a compatibility script, I get a prompt window with an error mapping the W: drive when users log on. I thought I followed the directions for configuring the home and root drives correctly, but obviously I didn’t. What’s the correct way, and what’s the difference between a home directory and a Windows NT Server 4.0, Terminal Services Edition (TSE) Home Directory?
A: Vendors don’t write most applications with a multiuser environment in mind, so most applications use files to run that must be specific to each user or to a session. These files reside in a unique place for each user, typically a user's %HOMEDRIVE%%HOMEPATH%—by default, this is %SystemRoot%\Profiles\%USERNAME%.
The home directory appears automatically in the HOMEPATH called Windows with a subdirectory called System. These locations are critical. TSE refers any application requesting the system Windows directory to the user's Windows directory instead of the %systemroot%.
I prefer not to make user homes the same locations as their profiles for several reasons. First, most user home directories store files. When a user logs on, the entire profile parses and loads. If you use roaming profiles, the profile and the entire set of files in the home directory will copy to the profile cache at every logon attempt, which takes time and resources, especially if the roaming profile resides across the network. Second, sometimes an administrator needs to delete a user profile. This action can cause problems if the user has stored items in the profile.
In User Manager, a user’s HOMEPATH created under Home Directory will map whether the user connects as a thin or thick client. A home directory mapped in Terminal Server Home Directory will only map from a thin connection. A thin client will realize much better performance if its home is on a local drive or a drive on the same network segment; a home on another side of a WAN can kill thin-client performance.
With the home directory created, you can install applications and run application compatibility scripts. These settings store to the user’s Registry. You can’t set the Registry value to %HOMEDRIVE%%HOMEPATH% or X:\%USERNAME%; the Registry doesn’t understand either of these.
This issue surfaces the first time you run an application compatibility script, run rootdrv2, and set the ROOTDRIVE. This drive letter must be an unused drive letter—it can’t be the same as the HOMEDRIVE or any other mapped or fixed drive. This letter then maps to become the directory specified in User Manager that applies using rootdrv2. If the drive letter is already in use, you’ll see the error message you’re getting at logon. For example, for the rootdrv2.cmd file below, you would make sure not to use W: for anything, including HOMEDRIVE.
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=W:
The system connects ROOTDRIVE by running %systemroot%\system32\Usrlogon each time a user logs on. It calls this from HKEY_LOCAL_MACHINE\Software\Microsoft\ WindowsNT\CurrentVersion\Winlogon\Appsetup
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 in Usrlogon is a Net Use statement that deletes this drive if it currently exists. The second line is a SUBST command that deletes any substituted drive. The third line runs the Subst command for %HOMEDRIVE%%HOMEPATH% with the drive letter you chose for ROOTDRIVE. After running this script, you end up with two drive letters mapped to the same place.