Ask the Doctor - 10 May 2000

SEND US YOUR TIPS AND QUESTIONS.For answers to more of your Windows 2000 and Windows NT questions, visit our online discussion forums at http://www.win2000mag.com/forums.

My office's various Windows NT workstations behave differently toward the Num Lock key's boot-up status. How can I control these behaviors?

On Windows 2000 (Win2K) and NT systems, a Registry value controls the Num Lock key's status at startup. You can manually set the value on a specific machine, or you can control groups of machines by using a group or system policy (i.e., the former for Win2K systems and the latter for NT systems) that contains a reference to the Registry value.

You can find this value in the HKEY_USERS.DEFAULTControl PanelKeyboard Registry key. The InitialKeyboardIndicators subkey is of type REG_SZ and can have a value of 0 (i.e., NumLock Off, the default value) or 2 (i.e., NumLock On).

Until recently, I've used the Microsoft Windows NT Server 4.0 Resource Kit's Scopy utility to preserve file and directory permissions when I migrate files between network servers. Scopy lacks features that I'd like to have for these tasks, but professional file-migration and replication packages are costly. Can you recommend any freeware or shareware utilities that can copy NTFS permissions, auditing, and ownership information?

Scopy lacks logging features and is occasionally unreliable during copy operations. For example, Scopy sometimes skips files for no apparent reason and without an accompanying error message. You can work around the utility's lack of logging features by piping the command's output to a text file: Simply place an output redirection symbol and filename at the end of the command line, such as

scopy *.* D: >

However, Scopy's limitations make the utility ill-suited for use with NTFS-based files on file servers or other mission-critical systems.

As an alternative, you can use the resource kit's Robocopy utility for individual copy and move operations or for ongoing directory replication. Robocopy supports the preservation of NTFS permissions, auditing, and ownership information during copy and move operations (if you run Robocopy with the /sec switch). The utility also offers several other useful features, such as the abilities to mirror entire directory structures, seed directory structures on a target drive without copying files, exclude files that meet certain criteria, and restart aborted copy operations at the point of failure. You can use the At command (or Task Scheduler, depending on your NT service pack level) to schedule Robocopy to perform particular file-copy or directory-mirroring tasks at various intervals during the day.

Because Robocopy provides superior flexibility and efficiency, you might even consider using Robocopy in lieu of NT's built-in directory-replication service for intraserver replication of the Netlogon folder's contents.

I'm responsible for managing my company's user accounts. One of my complaints about Windows NT is the amount of time and effort necessary to create user accounts and their associated resources (e.g., profile directories, home directories). NT's default administration model forces me to go through several tedious steps to complete this task. Can you help me find an easier way to get this job done?

Several solutions exist that can help ease your administrative burden. If you know how to write basic scripts, you can accomplish many otherwise tedious steps with a script or batch file. For example, you can create a simple batch file that accepts a username and password as parameters and uses this information to create the account, create and share the home directory, and set the appropriate directory permissions.

Makeuser.cmd is an example batch file that performs these functions. The script requires administrative privileges. Also, because the script uses several Microsoft Windows NT Server 4.0 Resource Kit utilities, access to the resource kit is necessary on the system from which you run the script. The batch file's syntax is

makeuser    

in which server is the name of the server that houses the user's home directory, drive is the drive letter on the specified server that houses user home directories, username is the NT username of the created user, and password is the user's password.

To create the home directory, share it, and set permissions, use the resource kit utilities Xcacls and Rmtshare (permissions are admin=Full, user=Change) as follows:

md \%1%2$Users%3xcacls \%1%2$Users%3 /t /e /g %3:C;C Administrator:F;Fxcacls \%1%2$Profiles%3 /t /e /g %3:C;C Administrator:F;Frmtshare \%1%3$=%2:Users%3

in which Users is the base user home directory folder on the server and Profiles is the user profile directory. The script assumes that Users and Profiles are on the same drive. If not, adjust the references accordingly before you run this batch file. If the server name and drive letter are always the same, you might also want to hard-code these within the script and remove them as variables.

Next, add the user and set the home directory paths in User Manager with a dollar sign ($) at the end (i.e., to hide the share):

net user /add /domain %3 %4 /homedir:\%1%3$

This script is only a simple example—you can certainly make the script more useful with some creative tweaking. For example, you can modify the script to accept additional parameters (e.g., other user property settings) or instruct the script to read user data from a file rather than from command-line parameters. For more information about NT shell scripting, see Tim Hill, Windows NT Shell Scripting (MacMillan Technical Publishing, 1998).

If you prefer using a GUI-based utility to manage users, the market offers several good solutions. My favorite inexpensive choice is Simac Software's UserManagemeNT Lite. This freeware utility, a light version of Simac's UserManagemeNT Professional, lets you quickly and easily create users and their associated attributes and resources. (Screen 1 shows UserManagemeNT Lite's GUI.) These characteristics include basic items such as home and profile directories and logon scripts, users' Microsoft Exchange Server mailbox properties, and NT Server 4.0, Terminal Server Edition (WTS) configuration settings. You can download UserManagemeNT Lite at http://www.tools4nt.com.

A similar shareware utility is Anders Wahlin's difficult-to-find NT Multiple Users Manager (NTMUM) utility. After some searching, I finally located the tool at http://www.chasque.apc.org/dsm/faecher/informat/technik/tools/nmum25.exe.

A third inexpensive utility is EnterNett's User Manager Assistant. You'll find a free trial version of User Manager Assistant (UMA) at http://uma.enternett.no.

Finally, you might require a full-featured user-management package that gives you delegation of administration and other enterprise-oriented capabilities. If you need such a package, check out the offerings from FastLane Technologies, Mission Critical Software, Entevo, and Aelita.

Although I'm happy with the reliability and performance of my Windows 2000 Professional (Win2K Pro) system, I'm having compatibility problems with some of my applications. One particular application runs fine on a system that I upgraded from Windows 98 to Win2K Pro. However, when I try to install the same application on a new Win2K Pro installation, the installation fails, stating that I need to have Windows NT 4.0 Service Pack 4 (SP4) or later installed. I also have a digital camera application that supports USB, but only on Win98. However, I know that Win2K Pro supports USB, and the OS recognized and loaded a driver for my camera. Can I trick these applications into thinking that Win2K Pro is an earlier version of NT or a different version of Windows?

These problems are common because many applications and installation utilities existed long before Windows 2000 (Win2K); many of the tools' version-checking methods consider Win2K to be an earlier version of NT rather than a successor. I've also discovered that many applications that claim not to be Win2K-compatible actually run smoothly under Win2K (if you can bypass the version-detection problem).

Microsoft included a utility on the NT 4.0 CD-ROM called setwin95.cmd, which lets you fool programs such as games into thinking that NT is Win95. Microsoft has taken this idea a step further in Win2K by introducing the Application Compatibility tool (apcompat.exe). Screen 2 shows the GUI of this utility, which is available on the Win2K CD-ROM and is part of Win2K's Support Tools. (Located in the CD-ROM's Support folder, the utility installs when you install the Support Tools.)

In some cases, you can use Application Compatibility to fool a legacy application into thinking that the application is compatible with one of several OSs: Win2K; NT 4.0 SP3, SP4, or SP5; or Win9x. The tool also lets you modify behaviors that sometimes cause problems for legacy applications; for example, you can prevent an application from seeing more than 2GB on a disk volume, use a pre-Win2K-style Temp directory, and disable Win2K's Heap Manager. If a specific application requires a particular set of changes to run, you can make the spoofing behavior permanent so that you don't need to launch Application Compatibility each time you run the application. Finally, you can use one command line to launch a program through the Application Compatibility tool and its various options.

The command's format and supported parameters are as follows. (Note: Don't put a space between the ­v or ­x options and their related parameter data, or they won't work.)

apcompat <-?> <-vVersion Name> <-xProgram Path> <-d> <-t> 
<-g> <-k>

in which -? displays the syntax for the command-line parameters, -vVersion Name specifies the name of the OS you want to return to the specified program (i.e., 1 returns NT 4.0 SP3, 2 returns NT 4.0 SP4, 3 returns NT 4.0 SP5, 4 returns Win98, and 5 returns Win95), -xProgram Path specifies the path and name of the .exe file for the program you want to run, -d disables the Heap Manager for the portion of memory reserved for the specified program, -t uses Temp for the Temp folder when running the specified program, -g corrects disk-space detection, and -k stores the specified Application Compatibility settings. For example,

apcompat -v4 -xc:myappmyapp.exe

would run an application named myapp.exe in the C:myapp folder and make the application believe it's running under Win98.

Occasionally, I need to install Windows NT 4.0 BDCs and other NT systems over a WAN connection, and the PDC is on the other side of the link. However, when I enter the third phase of Setup (i.e., the GUI part), an error message tells me that the computer can't find the domain controller; therefore, I'm unable to join the domain. I use an LMHOSTS file that contains the following lines:

10.10.10.1      MY_PDC  #PRE #DOM:MY_DOMAIN10.10.10.1      "MY_DOMAIN      x1b"  #PRE

According to the Microsoft article "How to Write an LMHOSTS File for Domain Validation and Other Name Resolution Issues" (http://support.microsoft.com/support/kb/articles/q180/0/94.asp), my method should work. What am I doing wrong?

I've encountered the situation you describe on several occasions. A potential workaround exists. First, I want to provide some clarification: I believe the Microsoft article you're referring to is "How to Install a BDC in a Routed TCP/IP Environment" (http://support.microsoft.com/support/kb/articles/q140/4/76.asp).

However, this article contains an apparent contradiction: The article states that the total length of the domain name string inside the double quotes in the LMHOSTS entry needs to be 20 characters. However, in the article's example, Microsoft lists a domain name that contains 10 characters (i.e., DOMAINNAME) followed by one space and the x1b hexadecimal code—a total of only 16 characters. The 20-character statement is correct, despite the typographical error.

The significance behind the 16-character length is that NetBIOS names (e.g., domain names, machine names) can contain as many as 15 characters, as well as a 16th character that indicates the NetBIOS suffix (representing the NetBIOS service type). In the case of your LMHOSTS entry, the suffix that the hex code x1b represents is that of the domain master browser. For a complete list of NetBIOS suffixes and their respective meanings, see the Microsoft article "NetBIOS Suffixes (16th Character of the NetBIOS Name)" at http://support.microsoft.com/support/kb/articles/q163/4/09.asp.

Creating an LMHOSTS file might resolve your problem, depending on whether the file existed before the system initialized the TCP/IP stack. If the file did exist, the domain name and domain master browser (i.e., PDC) name should be in the NetBIOS name cache. However, plenty of circumstances exist in which a perfectly good LMHOSTS file won't resolve your problem. In such cases, you can fool NT into opening a command-prompt session.

When you configure the TCP/IP stack during Setup, go to the WINS tab and click Import LMHOSTS. In the Open With dialog box, which Screen 3 shows, right-click any file that doesn't already have a file association and choose Open With from the menu. Next, click Other, browse to the %systemroot%system32 folder, and select cmd.exe as the command to use to open the file. Be careful not to select the Always use this program to open this file check box, because you don't want to create a long-term association for that file type with cmd.exe. After you click OK, NT drops you to a command prompt instead of opening the file.

Now that you have a command-prompt window open, you can take diagnostic and corrective actions that are otherwise impossible during Setup. For example, you can use Ping and Tracert to diagnose connectivity problems, and you can use Nbtstat ­R to reload the NetBIOS name cache (including any new entries in the LMHOSTS file) or Nbtstat ­c to list cached names and verify that the cache lists the PDC and domain names.

However, remember that NT Setup might not have copied to the hard disk all the utilities that you want to use during this session. In this case, simply copy the files you want to a 3.5" disk on another NT system. Then, either use the utilities from the 3.5" disk or copy the utilities to the hard disk of the system on which you're running the installation.