\[Editor's Note: Share your NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows NT Magazine readers (including Microsoft). Email your contributions (400 words or less) to email@example.com. Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
Disk Spanning Revisited
Regarding Brian Kowald's "Disk Spanning" (Reader to Reader, February 1999) about using the Xcopy command to copy a group of files onto several 3.5" disks, sometimes the simplest solution is also the best solution. I recommend using two DOS commands: attrib.exe and xcopy.exe. In the directory you want to copy, type
attrib *.* +a
This command sets the archive bit on each file in the directory. Then, type
xcopy *.* a:\ /m
The /m switch copies all files with the archive bit set and turns off the bit after the file copies. When the disk runs out of space, you receive the message Error copying file filename. There is not enough space on the disk. You simply insert another disk, press F3, and press Enter.
Selecting Groups of Files
You probably know how to select multiple objects in a window. For example, to select all the files in a Windows Explorer window, press Ctrl+A; to select a group of files, click the left mouse button at the beginning of the list, press Shift, and click the left mouse button at the end of the list; to select miscellaneous files, press Ctrl and click the left mouse button on the files you want to select. But you might not know how to select multiple groups of files in a directory. To accomplish this task, click the left mouse button at the beginning of the first group of files, press Shift, and click the left mouse button at the end of the first group; then press Ctrl, click the left mouse button at the beginning of the next group of files, press Ctrl+Shift, and click the left mouse button at the end of the group.
My company is planning to upgrade its PCs to Windows NT 4.0. However, several of the computers have Universal Serial Bus (USB) ports, as do most new systems. NT 4.0 doesn't support USB, which causes a problem with accessories such as printers and plotters. I'm wondering whether anyone offers a USB support patch for NT 4.0, or whether we're stuck waiting for Windows 2000 (Win2K).
Cloning an NT Server PDC or BDC
In the November 1998 Tricks & Traps, a reader wanted to know how to clone a PDC or BDC to upgrade software and hardware without causing downtime, and how to change the name of the domain controller and retain its status as a PDC or BDC. A coworker and I recently had an opportunity to attempt this task. We upgraded a 133MHz Pentium server with a 60GB SCSI RAID drive to a 350MHz Pentium II server with two 60GB SCSI RAID drives in volume. We cloned the server, renamed it, and connected it to the LAN. Our downtime was less than 15 minutes for the physical move and 4 hours for the volume creation. We could have avoided any downtime if we'd had two new RAID drives to use.
The server was a Windows NT 3.51 machine with Service Pack 5 (SP5) installed. It acted as a file server with FTP, and it spooled seven printers (mostly HP LaserJet and IBM Lexmark printers). We wanted to completely update the server's hardware and upgrade the software to NT 4.0 SP4, while retaining the accounts, access, shares, FTP, and printing resources.
Before performing the upgrade, we needed a suitable backup of the OS. We made sure the NT 3.51 server used NT's standard VGA driver and that the driver was set to 16 colors at 640 * 480 resolution, because NT always starts with the standard driver regardless of the video adapter you're using. (Before we checked the server's driver, we encountered the blue screen of death several times on startup.) We also made sure that pcANYWHERE was uninstalled, because this program prevents the server from starting. Because the upgraded server would have a different LAN adapter, we added the server's driver to the live server. Thus, the server would recognize the new card after the restore. If we'd had to use a different SCSI controller, we also would have had to install the SCSI controller's driver on the live server for the new server to start properly after the restore. We used Backup Exec to create two full backups of the OS and the Registry, and we created two Emergency Repair Disks (ERDs).
On a workbench, we prepared the new server with its LAN card, SCSI RAID controller, and new 60GB RAID drives. The RAID controller took several hours to perform a low-level format. We then installed NT 3.51 on the new server. We partitioned the RAID drive with 2GB for the OS and 58GB for the files that were a volume on the live NT 3.51 server's existing RAID drive. We used the same server and domain names on the new server as on the live server. We also used the same IP address because our company's servers have a static IP address.
Next, we performed a restore from one of the backups we made of the live server. When we rebooted, we received driver errors regarding the old LAN adapter and the VGA card. Thus, we opened Control Panel and disabled the LAN adapter and VGA card. We checked to ensure that all the accounts, access, shares, and printers were still available. We backed up our work, upgraded the OS to NT 4.0, and installed the Option Pack to enable FTP. This process went smoothly, and we then made another backup and applied SP4.
We renamed the server and changed the IP address so that we could connect the server to the LAN. We had to reboot before the changes took effect. We hooked up one PC and the server on a hub to start. The server retained its status as a PDC, and we were able to log on.
The real test came when we connected the server to the live LAN. We shut the server down, connected it to the live LAN, and powered it up. We were impressed that the new server became the BDC, and both servers continued to run all the resources. We configured and tested the new FTP service, and we tested all the printers. We had to reinstall only the Lexmark printers. We were happy with our results so far.
Our next task was to copy all the files and directories from the old server to the new server. We used the Microsoft Windows NT Server 4.0 Resource Kit utility Scopy, which gave the new server's hard drive access rights to the files and directories. The copy process took almost 24 hours, so we ran it after hours to avoid downtime. When the process completed, we were ready to move the old server's RAID drives to the new server.
When we were ready to perform the upgrade, we powered down the old server, disconnected it from the LAN, renamed the new server with the old server's name, and changed the new server's IP address to match the old server's address. We shut down and restarted the new server, and the server rebooted as the PDC, with all the resources running. We rebooted the old server and performed a differential backup and restore to refresh the new server's files.
We would have been finished at this point if we hadn't had to add the RAID, but we needed more disk space. We performed a low-level format on the old server's RAID drive so we could port to the new server and volume. We shut down the new server and moved the RAID drive to it. We were then finished with the old server, so we shut it down for the last time. We connected all the cables on the new server and started the server with the two 60GB RAID drives from the old server. The RAID drive appeared in the Disk Administrator and was ready to become the volume.
We waited a few weeks before creating the volume to be sure the server was stable and so that we could make a few backups. Finally, we created a 118GB volume. We had to wait 4 hours after reboot before the server was available.
Netscape Communicator Discovery
I recently installed Netscape Communicator 4.5 and had to specify whether to make Communicator my default browser. When you specify a browser as your default, the browser typically directs Windows Registry settings toward itself, so that when you click hypertext documents in Windows Explorer or other such programs, that browser opens them. Communicator goes a step further. The browser also changes Microsoft Internet Explorer's (IE's) home location to Netcenter (http://home.netscape.com).
NT's Secure Channel
I'm an MCSE and have been working as a Windows NT domain administrator for a software company in its client/server development facility. A few months ago, some of our mobile staff members were having trouble logging on to the domain after they'd been out of the office for a full week and thus hadn't logged on in-house for a week. I discovered two Microsoft articles that address this problem, which is a feature of NT domain security called a secure channel: "How to Disable Automatic Machine Account Password Changes" (http://support.microsoft.com/support/ kb/articles/q154/5/01.asp) and "Domain Secure Channel Utility—Nltest.exe" (http://support.microsoft.com/support/ kb/articles/q158/1/48.asp).
According to these articles, a computer that belongs to an NT domain has a unique encrypted link to the PDC—a secure channel—that occurs when the computer joins the domain. Every 7 days after the computer joins the domain, the password that identifies the computer to the PDC changes automatically and replicates to the PDC. If the computer isn't connected to the domain at the required time, the password expires and the computer no longer belongs to the domain. The user might receive an error message such as You cannot log on to the domain at this time because there is no trust relationship between this computer and the domain.
To disable NT's secure channel feature, open a Registry editor and go to the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ NetlogonParameters\ DisablePasswordChange subkey. Change the value from the default of 0 to 1, which disables the password change and lets the user be away from the domain for longer than 7 days without requiring an administrator to re-add the computer account to the domain. Because making this Registry change compromises NT domain security, you need to employ other methods to ensure user account password security.
Spotting an NT Evaluation Version
I've heard of several people encountering the problem of their Windows NT installations suddenly notifying them that the installation would expire in 1 hour and then proceeding to stack dump. Even if you use a full installation CD-ROM and a legitimate authorization code, your installation will expire if you use setup disks created from an evaluation CD-ROM.
Microsoft doesn't provide a tool to help you determine whether your NT installation is an evaluation version. I wrote a utility that will give you this information. You can download the utility for free from my Web site (http://www.savilltech.com/ download/wininfo.zip). If you run the utility on your server and determine that you're using an evaluation version of NT, you need to fix your NT installation. For information about how to fix your installation, see my NT FAQ Web site (http://www.ntfaq.com).
I enjoyed Tony Redmond's article "How to Rebuild Your Exchange Organization" (January 1999) and found the information about using the Microsoft Exchange Move Server Wizard useful. But I'd like to point out a simple way to move individual mailboxes between servers (in one site). In Microsoft Exchange Administrator, select the recipient you want to move, and select Move Mailbox from the Tools menu. You'll see a list of other servers in your Exchange site that you can move the recipient to. The beauty of this feature is that it requires no intervention by the user under Outlook 97.
Give NT a Facelift
If you're tired of the way the Windows NT shell looks, you can give it an easy facelift. To change the default background, replace the file winnt256.bmp in the \winnt directory with any .bmp file. Alternatively, you can edit the HKEY_USERS\.DEFAULT\Control Panel\ Desktop\Wallpaper Registry entry and enter a path to a file you want to use as a background. For either of these changes to take effect, you must restart the system.
To change the default color of the logon screen, edit the HKEY_USERS.DEFAULT\Control Panel\Colors Registry key. In the Background entry, enter a red-green-blue (RGB) value, with each value followed by a space (e.g., 0 0 0 for black). For this change to take effect, you must reboot.
To perform a major facelift, visit the following Web sites: Chunkymunky (http://www.chunkymunky.com), Customize.org (http://www.customize.org), DariusX (http://dariusx.cjb.net), DesktopzDotOrg (http://www.desktopz.org), Floach (http://floach.pimpin.net), Shell Extension City (http://members.primary.net/~robert), and Themes Central (http://liquid. lithium.com). These Web sites provide links to different shells and shell managers for NT. If you decide to try any of the programs, be aware that most of them are still in beta form.
Managing Desktop Shortcuts
In response to John Fitzpatrick (Reader to Reader, "NT Strikes Out Again," March 1999), I don't know how to modify the failed shortcut behavior, but I might have an alternative solution to John's problem. One way to manage shortcuts on Windows NT client desktops from any system is to have all users point to the same shortcuts, on a shared resource. To perform this task, you need Domain Administrator privileges.
First, create a folder to store all shortcuts, such as Desktop\NetApps, in the \\server\groupshare directory. Because this directory is available on the network, users can easily browse to the shortcuts. You need to give domain administrators full control, whereas other users and groups need only read permissions. Next, create shortcuts to your network apps from a Windows 95 machine and copy them to the NetApps folder. (Note that you need to use a Win95 machine to create the shortcuts because NT has another "feature" that inserts the Uniform Naming Convention—UNC—of the system creating the shortcut as part of the target path, effectively routing all execution through the system that created the .lnk file. Although the UNC isn't visible in the Target on the shortcut's Property Sheet, you can view the UNC by closely inspecting the .lnk file. A Microsoft Windows 95 Resource Kit utility, shortcut.exe, lets you turn off UNC tracking, but Microsoft doesn't support this method. I haven't tested the method with Win98 or Windows 2000—Win2K.)
Finally, start regedt32 and go to the HKEY_LOCAL_MACHINE\ SOFTWAREMicrosoft\Windows\Current Version\ Explorer\User Shell Folders Registry subkey. Select the Value entry Common Desktop from the right pane, and double-click it to edit the string data. The default string is %SystemRoot%\Profiles\All Users\Desktop. Change the string to the path of the directory you created (i.e., \\server\groupshare\Desktop). This Registry value is of the type REG_EXPAND_SZ, which lets you use environment variables to place the Desktop directory's contents (i.e., the NetApps folder) on your desktop. (Similar values affect the Programs folder, Start menu, and Startup folder.) You need to apply this Registry change to all clients. As always, create an Emergency Repair Disk (ERD) before you edit the Registry, and test your changes on nonproduction systems.
To make an app unavailable, remove users' permissions on the .lnk file, or simply remove the .lnk file. Users' shortcuts then disappear. You might want to use a .cmd or batch file to create a Temporarily Out of Service HTML page explaining the situation, and point the shortcut to the page. Use file permissions to limit which user groups can see specific shortcuts.
Every trick has a caveat. Be sure to log on with a non-Domain Administrator account when you install local apps on your system. If you're a domain administrator with write permission to the shortcut folder and you install an app on your system that places a shortcut in the All Users profile, the shortcut will be active on every desktop. In addition, if you lose your connection to the \\server\groupshare directory, your screen will be naked. You might be able to use Task Manager to restart Windows Explorer; otherwise, you must log on again.