\[Editor's Note: Share your Windows 2000 and Windows NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows 2000 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.\]
SMS SP1's Huge Download
My company recently evaluated Microsoft Systems Management Server (SMS) 2.0. At a Microsoft TechNet conference that I attended, Microsoft advised downloading and updating SMS installations with Service Pack 1 (SP1).
In my company, we use individual 56Kbps dial-up modem connections rather than a direct connection. Thus, I looked for the service pack's size when I went to Microsoft's SMS Web page to download the file. The size wasn't listed, so I started the download. When I realized that the service pack was larger than 10MB, I decided to download the file at home over my cable modem connection.
At home, I watched the download progress from 10MB, to 40MB, to 90MB, and I wondered whether Microsoft made a mistake and posted the entire SMS 2.0 CD-ROM online. Finally, the service pack downloaded, totaling 107MB. After I downloaded the service pack, I had to copy the SMS 2.0 CD-ROM to the hard disk, apply the service pack, then reburn the SMS 2.0 SP1 CD-ROM.
Based on the size of the file and the number of steps I had to go through to download it, perhaps Microsoft needs to make the service pack a new version—SMS 2.1 rather than SMS 2.0 SP1. The lesson I learned is to make sure you have a fast connection before attempting to download so-called service packs.
Quick VirusScan Installation
I administer a small, simple Windows NT domain that has 13 clients and 2 servers. To quickly upgrade all my clients to the latest release of Network Associates' VirusScan software, I log on to one of the machines as domain administrator, run the installation, select the remote installation option, enter domainname\administrator, and select the machines I want to update.
To use this method, you must have administrator rights on all the machines. The software then configures the client machines and performs the upgrade. When a computer reboots the next time, the latest version of the software splashes its logo.
Hating the Registry
In the old days of Windows 3.5, most applications kept their setup data in .ini or .pif files. Almost all data and supporting files were in the application's home directory. Sometimes the Windows directory stored a few shared .dll files, but some applications kept their .dlls in their own directory. If Windows became corrupt or you needed to upgrade a system, you simply had to reinstall the OS. Occasionally, you needed to replace a lost .dll file. In addition, after you configured an application to behave the way you wanted it to, you could simply copy the application's directory to each workstation.
Windows NT's Registry complicates these tasks. If NT becomes corrupt and you need to reinstall the OS, you must reinstall every application. Repairing or restoring the Registry often isn't an option because doing so might reintroduce the bug that caused the corruption. Moreover, restores sometimes just won't work. In addition to reinstalling each application, you must add updates, bug fixes, and service packs. You must also reenter user data. Although some applications create and maintain their own .reg files, most don't.
The theory that the Registry keeps all data in one easily backed-up place is false. The idea that the Registry limits illegal copying and piracy is laughable. If you've ever edited the Registry, you've noticed the large number of duplicated entries. Finally, removing or uninstalling an application doesn't always remove all the application's Registry entries, which leads to incredible bloat over time. I absolutely hate the Registry.
Remotely Manage Your Network
If you want access to your favorite administrative tools (e.g., dhcpadmn.exe, dnsadmin.exe, rasadmin.exe, srvmgr.exe, usrmgr.exe, winsadmn.exe) from any computer on your network, put the files somewhere on the network that you can always access (e.g., your home directory). Then, create desktop shortcuts in your roaming profile. Be sure to include the .dll files that the .exe files require to run (i.e., utildll.dll, regapi.dll, ipadrdll.dll, winsrpc.dll, and winsta.dll).
Alternatives for Creating Network Printers
Three methods exist for creating a network printer. The first method, which most people use, is to select Settings, Printers from the Start menu. Then, double-click the Add Printer icon and select the Network printer server option. Although this method is complete, you must click Next several times to finish the process of creating a network printer.
A second method is to double-click the Network Neighborhood icon on your desktop, find the printer server computer, and double-click the printer. You'll receive a message that says the driver must be installed locally (i.e., Before you can use the printer '\\servername\printername,' it must be set up on your computer. Do you want Windows to set up the printer and continue this operation?). This method is easier than the first method, especially for a server with many printers, because you don't need to click through several Next buttons.
The third method, which is my favorite for installing many printers from a network printer server on a local machine, is to click Start, Run, and enter
(or double-click the Network Neighborhood icon) to find the remote printer server. Then, drag all the printers from the remote system to the Printers folders on your local machine. If your local computer is running Windows NT, the remote printers will install locally in a few seconds without requiring you to answer any prompts. If you're running Windows 9x locally, you must install the printer driver for Win9x on the printer server.
Minimizing Logon Scripts
I support a site in which Windows NT workstation users click the close button in the upper right-hand corner of the logon script window in an attempt to minimize the window. This action causes the logon script to stop, and the workstation doesn't completely set up. Then, users run into various problems because the logon script didn't run to conclusion.
Unfortunately, Microsoft hasn't provided a way to run a logon script in minimized mode. Thus, I changed the logon script to the one that Listing 1 shows. On NT workstations, my script starts a second script (i.e., the logon script) in a minimized window. Users don't see the logon script window and therefore don't close it.
Booting the Unbootable
A customer recently contacted me with the following problem. The C drives on the company's servers were 2GB, which didn't leave much free space after the OS and associated utilities' installation. The company's disaster-recovery plan to rebuild a server required the systems administrator to install a temporary copy of Windows NT on the C drive and restore all the data. But the temporary copy of NT on the C drive prevented the restored data from fitting on the partition, so the restore didn't work. The company tried installing NT on other available partitions, but NT wouldn't boot from the partitions because they all had at least 4GB of data on them.
According to the Microsoft article "Windows NT Does Not Boot to a Partition That Starts More Than 4 GB into Disk" (http://support.microsoft.com/ support/kb/articles/q197/2/95.asp), an NT Loader (NTLDR) calculation error prevents NT from booting if you install the OS on a partition in which the first 4GB of disk space is already in use. You receive the error message Windows NT could not start because the following file is missing or corrupt:
To apply SP5 to a machine with a system partition that won't start, you must boot past the first 4GB on the disk. First, replace NTLDR on the system partition (usually the C drive). On a FAT system partition, simply use a DOS-bootable 3.5" disk and replace NTLDR on the disk with the SP5 NTLDR.
Replacing NTLDR is more involved on an NTFS system partition. You must create a custom repair disk so that you can replace files on an NTFS partition during a repair session. To create a custom repair disk, you must first obtain or create the three 3.5" NT setup disks. Then, replace the setupdd.sys file on disk 2 with the SP3 setupdd.sys file. The SP3 version of this file lets you replace files during a repair process. (For more information about this file, see the Microsoft articles "Replacing System Files Using a Modified Emergency Repair Disk" at http://support.microsoft.com/ support/kb/articles/q164/4/71.asp and "Files Not Replaced When Running Emergency Repair on X86 Intel Systems" at http://support.microsoft.com/ support/kb/articles/q168/0/15.asp.)
Next, obtain or create a repair disk. (You can use a repair disk from any system.) Delete all the files on this disk, except setup.log. Use Notepad to edit setup.log; delete all the file listings under the Files.WinNt section. Then, replace the NTLDR line in the Files.SystemPartition section with the line ntldr = "ntldr","99999","\","ERD disk","ntldr". Finally, copy the NTLDR file from SP5 to your new custom repair disk. The setup.log file on your repair disk will look like
TargetDirectory = "\WINNT"
TargetDevice = "\Device\Harddisk0\partition1"
SystemPartitionDirectory = "\"
SystemPartition = "\Device\Harddisk0\partition1"
Version = "WinNt4.0"
ntldr = "ntldr","99999","\","ERD disk","ntldr"
NTDETECT.COM = "NTDETECT.COM","b69e"
Use the three-disk method to start the boot process. When the system prompts you, select the repair option. On the repair screen, clear all the options except Verify Windows NT system files, and start the repair process. When the system prompts you, insert your custom repair disk and press Enter. You'll receive a prompt to replace the existing NTLDR file; press Enter to accept. Finally, reboot the machine.
After you replace NTLDR on the failed machine with the SP5 NTLDR, NT will boot without a problem. You also need to apply SP5 to your system to ensure full compatibility with the new version of NTLDR. Although the Microsoft article "Windows NT Does Not Boot to a Partition That Starts More Than 4 GB into Disk" discusses an easier solution than the one I outline, Microsoft's solution works only for SCSI systems, whereas my solution works for SCSI and IDE systems.
Speeding Up Ifmember
I enjoyed Mark Minasi's August 1999 column about Ifmember (This Old Resource Kit, "Group-Aware Logon Scripts"). Administrators who use this tool know that it can be slow if you're running it against many groups. My solution to this problem is to pipe the ifmember /l command to a text file and parse it with the For statement, as Listing 2 shows. I use Ifmember against about 50 groups, and my logon scripts now run in seconds rather than minutes.
Peculiar NT Problem
I recently installed Windows NT 4.0 with Service Pack 3 (SP3) and Microsoft SQL Server on an IBM Netfinity 3500 server. Although I could log on to the NT server and run applications, shutting down the server took longer than 30 minutes. I removed all the unnecessary protocols, but the problem continued. Then, I tried shutting down the server without launching any applications (i.e., starting the server and immediately shutting it down). Still, the server took longer than half an hour to shut down. As a last resort, I upgraded the BIOS for the Netfinity 3500 server. Voilà—the system shut down within 3 minutes.