Send us your tips and questions. You can also visit Bob Chronister's online Tricks & Traps at

The Value of Backing Up Files
A colleague once asked me to diagnose a problem he was having with his 1GB Western Digital EIDE hard disk. A boot-sector virus had infected the disk, and he had run fdisk /mbr to fix the problem. He then used a virus checker to analyze the hard disk for any other viruses. However, he could no longer access the hard disk when he booted the machine. Unfortunately, he needed to access a program on the hard disk that contained 5700 references that would have taken a lot of time and money to recreate.

Like my colleague, I found no available boot device when I tried booting the system. I booted to a 3.5" disk with fdisk, and I discovered that the hard disk contained no partitions. When I asked my colleague which version of DOS he used to run fdisk /mbr, he told me DOS 5.0.

I noticed a tape drive on the machine, and I asked for the latest backup tape so I could restore the reference program to a new drive. To my amazement, my colleague had never used the tape drive. On the hard disk, I also found a reference-dump utility for the program. This utility could copy the references to diskette, but no one had ever run this program.

As a last resort, I called Ontrack ( data-recovery services to determine the feasibility of salvaging the hard disk. After I ran the Data Advisor diagnostic software which I downloaded from Ontrack's Web site, I sent the drive to the company. I asked Ontrack to copy the hard disk's contents to CD-ROM. The company retrieved all the data from the drive for $1100 and sent me the CD-ROM. I copied the reference program to a new hard disk, and used Windows NT Explorer to change the read-only permissions on the program files (NT had labeled all the files as read-only because they came from the CD-ROM). The reference program is now completely functional, and the total restoration time took about 5 minutes. If you prorate those 5 minutes at $1100 to an hour's worth of work, the cost would be $13,200. Restoring the program and reference database was all that mattered, and a simple backup would have prevented this expensive lesson.

Moving Printers Between Servers
Several readers have asked me how to easily move printers from one server to another. One reader, Colin Hart, shared a method he used to migrate 150 printers from one server to another without having to add each printer to the new server separately.

The major consideration is making sure you save Registry keys for all printers and then restoring the keys on the new system. (If you are saving files from a remote machine, I suggest you map one of your drives on that machine so you can save to that drive without any problems.) Begin by stopping the spooler service and opening regedt32.exe on the machine that contains the Registry keys you want to copy. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print, and highlight the Printers key. Select Save Key from the Registry menu, and choose a filename and location for the file (I typically use printerlist.txt). If you have added TCP/IP printer ports, you need to go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\LPR Port, and highlight the Ports key. Next, select Save Key from the Registry menu, and choose a filename and location for the file (I typically use portlist.txt). Restart the spooler service if you want.

After you save the files, you can easily restore them to the new print server. Stop the spooler service, and open regedt32.exe on the machine that you want to copy the Registry keys to. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print, and highlight the Printers key. Select Restore from the Registry menu, select the name of the file (e.g., printerlist.txt) where you saved the Printers key from the original print server, and click OK. If you have TCP/IP (LPR) ports, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Monitors\LPR Port, and highlight the Ports key. Select Restore from the Registry menu, select the name of the file (e.g., portlist.txt) where you saved the Ports key from the original print server, and click OK. Restart the spooler service, and install the needed printer drivers on the new print server. Colin points out that you can also use this process to save the list of user shares by saving and restoring the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares key.

Moving User Profiles to New Domains
In my September 1998 column, a reader asked how to move user profiles from one domain to another. Several readers replied with detailed instructions. The following procedures come from Mike Reid, Aaron Blosser, and David Rogers. I have combined their comments and appreciate the detail they provide.

Understanding the problem. Suppose you've been using the same domain account for the past 6 months, and you've finally set up your desktop the way you want. Your domain administrator makes a mistake and informs you that you must install a new Primary Domain Controller (PDC) to rectify the situation. As a result, the systems administrator creates a new domain. Although the new domain might have the same name as the existing domain, it is a new domain because the new PDC has a new security ID (SID). All Windows NT workstations and member servers must rejoin the domain. NT considers all user accounts, even if they have the same name, to be new accounts because they also have new SIDs.

When a user logs on to a new domain for the first time, NT creates several entries in the Registry. The operating system (OS) places keys in the Registry for the user's SID with a value that contains the path to the user's local profile (i.e., ProfileImagePath). Together, this information records the profile NT needs to use for that user.

Applying general fixes. If users need their own profiles, NT will create a new SID for each user profile when the users log on to the new domain. To work around this situation, the systems administrator can log on to each workstation and copy the old user profile (using the copy-profile tool in the System applet in Control Panel) over the new user profile. This remedy presupposes that the user has full permission access for the original profile file.

If all users use the same profile, the systems administrator can have all new users access a default profile. Before a new user logs on for the first time, you can use the copy-profile tool to copy the old default user profile into the %systemroot%\profiles\default user directory, giving the Everyone account access. Users who log on with their new domain accounts inherit the default user profile, which is actually the old default profile.

Besides using the copy-profile tool in the System applet, you can manually copy the user profile files by editing the Registry. The Ntuser.dat hive in HKEY_CURRENT_USER contains all the Registry settings for the current user profile. You load this hive into the regedt32 Registry editor and give the Everyone account permission to the entire hive. Then you can use NT Explorer to copy the entire profile directory (including hidden files) to the new location (I have used this approach many times for new workstation installations).

Addressing specific problems. Occasionally NT will add a new user profile despite the fact that you want to maintain an existing user profile. For example, if a jdoe user profile already exists, NT might add a jdoe.000 or jdoe.001 user profile. These profile extensions can be confusing, but you can easily fix the problem by editing the Registry to point the logon to the original user profile. Start regedt32.exe, and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Locate the appropriate user profile SID, as Screen 1 shows, and double-click the ProfileImagePath listing on the right. When the String Editor window opens, remove the extension (e.g., .000 or .001) from the path string to point the user's new logon to the original profile. Repeat this process for all other user profiles.

Also, you can manage a user profile through the Registry when a user moves from an old domain to join a new domain. Make sure the user is not logged on when you perform this procedure; otherwise, NT will overwrite the changes you make with the user's preferences because the OS saves user profile settings when the user logs off. Start by locating the original user profile that you want to modify, which is the profile that was in use before the user joined the new domain (e.g., c:\winnt\profiles\jdoe or c:\winnt\profiles\jdoe.000). Open regedt32.exe, and select the HKEY_USERS on Local Machine window. Highlight the HKEY_USERS root key. From the Registry menu, select Load Hive. Browse the local hard disk for the directory that contains the original user profile, and select the ntuser.dat file in that directory. A dialog box will prompt you to enter a Key Name (i.e., a name you want to assign to the hive you're loading). You can use any value, but you must remember this value so that you can select it when you unload the Registry hive. For this reason, I recommend that you use the username for this value. Click Enter to add the user profile Registry hive as a subkey to HKEY_USERS, which Screen 2 shows. Select Permissions from the Security menu. Remove the unknown account, as Screen 3 shows, and add the domain\user account with Full Control. Click Add, select the Replace Permission on Existing Subkeys check box, and click OK. After completing the changes, highlight the root of the user's profile Registry key, and select Unload Hive from the Registry menu. This last step saves the changes to the user's profile. Have the user log on and verify profile settings (i.e., desktop settings, wallpaper, sounds).

If you've installed Internet Explorer 4 (IE4), you have to make a manual security adjustment because IE4 installations will disable the copy-profile tool. For more information on this problem, see Microsoft Support Online article Q175667, "Error Message: Copy Profile Error," at Pay attention to the HKEY_CURRENT_USER\Software\Microsoft\Protected Storage System Provider key. IE4 modifies the permissions on this key, causing an error to occur when you try to copy the user's Registry settings.

Start by logging on as the user on the old domain and running regedit.exe (regedt32.exe won't work as described here). Save the HKEY_CURRENT_USER Registry key and all the subkeys to a file by selecting Save from the Registry menu. Add the user's account from the new domain into a privileged group (i.e., any group that you have given full permission) that will let the user import this Registry key once the user logs on to the new domain. Log on as the user in the new domain to create the username.000 directory. Find the Registry key you exported from the old domain, and double-click it. You'll see a message confirming that NT imported the Registry key into the new domain. Log off the system and log back on as the local administrator. Copy the contents of the username profile directory to the username.000 profile directory. Log on as the user in the new domain to ensure that the old user profile settings appear. I've had success with this method, but the Microsoft Office toolbar occasionally will not carry over correctly. This problem is an easy fix--all you have to do is recreate the toolbar.

Q: I recently installed Windows 95 OSR2.5 on a FAT32 partition. When I tried to install Windows NT 4.0 Workstation, it wouldn't install. I have a 300MHz Pentium II with two hard disks (one 6GB IDE drive and one 9GB Ultra Wide SCSI drive). I want to install Win95 on one hard disk and NT on the other. How can I accomplish this, and where can I find documentation about this installation issue?

NT 4.0 does not recognize FAT32 partitions. You can find FAT32 drivers for NT 4.0 (see, but these drivers won't help you install NT on a system that's already booting off a FAT32 partition. Currently, you can't install NT from a FAT32 boot partition without first removing and reinstalling Win95 and the FAT32 partition.

Q: I keep getting the following message every time I log on to my small network at home: A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on may not be available. How do I resolve this problem?

Systems that can't locate a domain controller are typically having trouble initializing the NIC drivers. For example, I had a notebook that always gave me the message you are receiving. I realized that I had to wait a while to log on because the system wasn't properly initializing the driver for my NIC. I eventually replaced the NIC to remedy the problem. Try booting onto the network, and then do a soft reboot (do not turn the machine off). If the NIC and the driver are the problem, this procedure will let you log on with no error. Also, check all cables and hubs or switches.

Q: My users are complaining that they can't change the status of a print job on a particular printer even though I have granted the Manage Documents right to all users. What is the problem?

The description of the Manage Documents right in the NT Concepts and Planning Guide that comes with Windows NT Server might mislead you to believe that any user with this permission can control any print job. In fact, the Manage Documents right lets you manage only documents you submit to print. Unfortunately, to manage all jobs in the print queue, you must have Full Control as a right.

Q: Can I maintain the entire Temporary Internet Files (including history) directory in a location other than the Windows NT user profile folders?

Yes, you can maintain the Temporary Internet Files directory in a location other than the user profile folders. Create a storage directory for the files (e.g., c:\cache). Open your favorite Registry editor, and go to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. NT places the temporary Internet files in the directory that the Cache value name--a type REG_SZ entry--specifies. If the Cache value doesn't exist, add the value and type in the path using the String Editor, as Screen 4 shows. If the Cache value does exist, double-click Cache and type in the path to the directory you created. You can perform the same steps with the history directory (e.g., c:\history). Make certain that the cache and history locations are also correct in the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ex-plorer\Shell Folders Registry key.

Q: On several occasions, I have had Windows NT systems crash when users run 16-bit applications and the operating system (OS) doesn't properly update time stamps. What's causing this type of error?

This question is interesting. The only factor I can imagine contributing to your problem is the way that NT holds deleted file meta-information (i.e., the file's structures) in cache.

Some applications use the file system to hold on to meta-information for a short period so they can delete, create, or rename an object and still have the original short filename and time stamp intact. When you remove a filename from a directory, NT creates the cache containing the meta-information. When you add a filename, the OS searches the cache. This process is particular to FAT and NTFS when 16-bit applications use files to ensure that the file system retains long and short filenames. Caching the meta-information typically causes no problems, but you can stop caching entirely or change the time parameters by modifying the Registry.

Open your favorite Registry editor and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem. To adjust the amount of time that the meta-information remains in cache, add the MaximumTunnelEntryAgeInSeconds value of type REG_DWORD. Set this value to the number of seconds from 1 to 30 (the default is 15). To disable meta-information caching, add the MaximumTunnelEntries value of type REG_DWORD and set this value to 0.

Q: How do I keep the File Delete Confirmation dialog box from displaying?

Right-click the Recycle Bin on the desktop, and click Properties. Clear the Display delete confirmation dialog check box, and click OK, as Screen 5 shows.

Q: I manage a large network and need to track account lockout or incorrect password logon attempts to a key database server. Can you recommend an easy way to do this?

Assuming you have a heterogeneous environment, Windows NT records non-NT clients in the event log of the domain controller that validated the account and records native NT logon attempts locally. You can install the netlogon.dll file from the checked (i.e., debugged) Service Pack 3 (SP3) files on your Primary Domain Controller (PDC) where you maintain a log file for all logon attempts. (If you are not running SP3, you need to be.)

Download the checked build of SP3 from nt/winnt-public/fixes/usa/nt40/ussp3/Checked/, and extract the netlogon.dll using the command SP_Name.exe /x. Using NT Explorer, go to the %systemroot%\system32 folder, and rename net logon.dll to something like netlogon.old. Copy the checked version of netlogon.dll to the %systemroot%\system32 directory.

Using a Registry editor, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\ParametersDBFlag. Change the DBFlag value to 0*04 to record the logon, or to 0*20000004 to record the logon and a time stamp. Shut down and restart the PDC. After rebooting the system, make certain that you have a %systemroot%\debug folder containing a netlogon.log file. The log file can contain any of the error codes you see in Table 1. Only the 0*C0000234 and 0*C000006A entries are important for account lockouts.

Q: I'm having trouble compressing directories and files on an NTFS partition of a new server. Do you have any recommendations?

The likely cause of your problem is that you created a very large partition and formatted it with a cluster size greater than 4096 bytes. The maximum cluster size that Windows NT allows for compression is 4096 bytes.

To check the allocation unit, run




at the command prompt. If the cluster size is larger than 4096 bytes, you must back up, reformat, and restore the partition. The formatting syntax is

Format /FS:NTFS /A:4096 \[/V:Label\]

NTFS compression must process 16 clusters at a time. The largest paging allocation unit that NT can write to is 64KB, which equals 4KB per cluster

(i.e., 64KB / 16 clusters = 4KB per cluster).

Q: When I use Windows NT Explorer, the System attribute is grayed out when I view File Properties. Am I doing something wrong?

You've happened upon an NT 4.0 glitch. Do as I do: Use Winfile, or at the command line type

attrib +s \folder\[\file.ext\]

to add the System attribute, or type

attrib -s \folder\[\file.ext\]

to remove the System attribute.