\[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 protected] Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
More About Removing Most Recently Used Items
In "Removing Most Recently Used Items from Windows NT, Windows 95, and Internet Explorer" (Reader to Reader, January 1999), Mark Norton presents a template file for removing document entries. To expand on Mark's script, I found a trick that prevents new items from appearing under the Documents menu. Start a Registry editor, and go to the HKEY_CURRENT_USER\Software\ Microsoft\Windows\CurrentVersion\ Explorer\User Shell Folders\Recent subkey. Then, redirect this subkey to a directory that the user doesn't have write permissions on. This trick works with NT and Novell NetWare back-end servers.
A Solution to NT Backup Stalling Out
I encountered the same problem that Jim Moore wrote about in "NT Backup Stalls Out" (Reader to Reader, January 1999): If a scheduled backup fails, the process hangs without notifying you. To solve this problem, I used the At command's /interactive switch (e.g., AT 23:00 /interactive ntbackup.exe #backup# c:). This switch causes the scheduled job to run in a visible window that closes after the backup completes successfully but remains open and waits for a response if the process stalls. The next person who logs on to the server sees this window and receives the Windows NT Backup error message. Responding to the error message closes the process and prevents the backup from tying up the machine.
Restoring a Print Server Quickly
When a print server crashes, restoring multiple printer shares and accompanying permissions can take hours. To restore a print server quickly, back up the \winnt\system32\spool\drivers directory or copy the directory to another server. This directory contains all the printer drivers for your installed printers. Next, save the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\ Control\Print Registry key to a 3.5" disk. Then, copy the files in the \winnt\system32\spool\drivers directory to the correct subdirectory, and restore the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\Print Registry key. Your print manager will list all your printers, with the proper permissions. You can use a logon script to map the printers for users. If you copied the files and Registry key to a new server, users can add printers from the new print server.
WinExit Screen Saver Policy
I agree with Mark Minasi's sentiment in "WinExit" (December 1998): You need to solve the problem of users leaving their machines unsecured. As a systems administrator of a large WAN, I've noticed that many users stay logged on to Web sites all day or leave their email programs open and unattended. This practice not only wastes network bandwidth but also threatens system security. In my organization, I used Windows NT's System Policy Editor (SPE) to implement the WinExit screen saver from the Microsoft Windows NT Server 4.0 Resource Kit. Listing 1, page 28, shows the template I used to deploy the screen saver. For this screen saver to work, you need to give all your users Set Value and Create Subkey permissions on the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows NT\ CurrentVersion Registry key. When the screen saver activates the first time, users' screens are blank. You must reboot the system for the screen saver to operate properly. For information about the Registry permissions that the screen saver requires, see the Microsoft article "Logoff Screen Saver Does Not Function in Windows NT" (http://support .microsoft.com/support/kb/articles/q156/ 6/77.asp).
I recently created a Windows NT security document and performed some systems tests on my event logs. I was surprised to find that the Application log was documenting virus occurrences as errors. I did some experimenting and discovered that this feature isn't restricted to a particular virus scanner; it seems to work with most 32-bit antivirus applications. Security professionals who tend to review only the Security log will find this feature useful because you can see an audit trail of virus activity and determine which systems suffer from infections without having to consult various antivirus logs.
I've experienced a problem recently when I save and restore the system partition of a networked Windows NT 4.0 workstation onto a different physical disk. Nonprivileged users can't use the shortcuts that link to the system disk. This problem affects not only the desktop shortcuts but also the Start button shortcuts. When you try to use a shortcut, the system prompts you for a username and password for the administrative share \\computer\C$.
The problem's cause isn't immediately obvious. If you examine the shortcut's properties, the path is relative (i.e., C:\pathname). Browsing to the location and starting an application works as easily as starting an application via an associated file extension.
Shortcuts hold two paths—the relative path and the full Uniform Naming Convention (UNC) path. The UNC causes the problem. Only the relative path displays; to verify the full UNC path, you can use Notepad to open an .lnk file.
To address the problem, Microsoft altered NT Explorer to ignore the UNC path and use the relative path instead. You need to apply Service Pack 4 (SP4), which updates the shell32.dll file, and add the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer (REG_DWORD LinkResolveIgnoreLinkInfo; value 1) Registry subkey. The Microsoft article "Shortcuts Created Under Windows NT 4.0 Resolve to UNC Paths" (http://support.microsoft.com/support/ kb/articles/q158/6/82.asp) explains this solution in detail, which you can apply on a per-shortcut, per-user, or per-machine basis. I've found the per-machine option to be the most useful, because it effectively suppresses the error and lets you use the workstation as before.
In the January 1999 Tricks & Traps, a reader asked how to use Rdisk to back up information on media other than a 3.5" disk. Dr. Bob recommended that the reader use a third-party utility. However, my company runs a scheduled command via the At command on all our Windows NT servers. The command is rdisk /s-.
This command runs Rdisk unattended, which copies the Registry to \%systemroot%\repair. Our daily backups then back up this directory, and a batch file copies the directory to a central repository server that houses our Emergency Repair Disks (ERDs) for easy access in case of a disaster. If a Registry corruption occurs, you need to copy your files from \%systemroot%\repair or your Rdisk repository to a blank 3.5" disk to use as an ERD to perform the usual NT repair process.
Alternatively, you can install a second copy of NT on the server, boot up with this copy of NT, and expand your files into \%systemroot%\system32\config, which houses the live NT Registry (e.g., expand SYSTEM._ to SYSTEM.ALT and SYSTEM, SAM._ to SAM). This method is faster than going through the complete repair process if the corruption is Registry related. You can also run regedt32 from the second copy of NT and use the load hive option to open the Registry, modify the values, and boot back into the original version of NT. Although these methods are effective, the Rdisk method is the safest procedure, and Microsoft supports it.
Haluk Yildirim's "Renaming a Domain" (Reader to Reader, January 1999) contains an error. When you try to rename a domain at the BDC, you receive the message You already have a connection to the domain. You must disconnect before joining the domain. This error doesn't occur because the BDC can't find the PDC. Instead, it occurs because the BDC has a drive mapped to a share on the PDC. If you disconnect this drive, the BDC has no problem changing the domain name. After you reboot the BDC, you can remap the share on the PDC. For more information about this error, see the Microsoft article "Unable to Change Domain Name of Windows NT BDC" (http://support.microsoft.com/ support/kb/articles/q139/4/71.asp).
ISA Device Resource Reservation
When you use old ISA devices, you need to reserve in the system's configuration the resources the device uses. Otherwise, you might experience a blue screen of death from the error STOP 0x0000000A IRQL_NOT_LESS_OR_EQUAL. Although a bad device driver commonly causes this STOP error, the error also occurs when two devices attempt to use the same resources. Suppose you install an ISA modem card in a Compaq ProLiant server. You must start the System Configuration utility and add the ISA modem card to the server's configuration. You can then reserve the resources the card uses (e.g., COM port, IRQ) and prevent other devices from using the resources and thus causing conflicts with the ISA device. Keep in mind that if you clear the system's nonvolatile RAM (NVRAM), you need to manually reconfigure the ISA device's resource allocations in the system's configuration. Although most systems can automatically reconfigure after an NVRAM reset, the system can't determine your ISA device's settings.
Resource Kit to the Rescue
Moving print queues from one server to another is usually a manual process that includes reloading the print drivers, recreating the print queues, and recreating the printer ports on the new server. In the December 1998 Tricks & Traps, Bob Chronister mentioned a method that includes stopping the spooler service, backing up and restoring Registry entries, and reloading the necessary print drivers. The Microsoft Windows NT Server 4.0 Resource Kit Supplement 3 provides an automated utility that doesn't require you to stop any services, open the Registry, or manually load any print drivers. My company has used the utility to move from 40 to 120 print queues at once.
Printer Migrator (printmig.exe) lets you back up a print server by copying data such as the defined NT Server print queues, the print monitor ports, the print drivers (e.g., x86, Alpha, MIPS), and all share point information to a file called pm.cab. The utility also lets you log copying process' status in a file called pm.log, which the utility stores in the \%systemroot%\system32\spool\pm directory.
The utility backs up only the defined ports—not the monitor. Printer Migrator recognizes and backs up the following ports: HP network ports, Lexmark MarkVision port monitor (IP/Data Link Control—DLC), HP Jet Admin, Line Print Remote (LPR) ports, local ports, Digital network ports, and Macintosh AppleTalk port monitor.
Before you run printmig.exe, you must install the appropriate protocol for your print monitors (e.g., TCP/IP for LPR ports, DLC for HP network ports). When you run the utility, it prompts you for the name of the server you want to back up and for a location for the pm.cab file. This file can become large, so choose its location carefully.
Printer Migrator lets you back up and restore over the network. Thus, you can back up print servers at remote locations and restore them to the new print server on your network. To restore a print server to the new server, select Restore under the Actions menu and enter the server name and the location of the pm.cab file. The pm.log file records the outcome of backup and restore procedures. The realtime status window also displays this information.
My company had to create smaller logon scripts for remote users who log on to the network from their laptops. We needed to determine whether users were logging on via LAN or RAS connections. We have a batch language tool called Kix32 that reads a computer's Registry and determines whether a user is using RAS. However, we couldn't use this tool because the interpreter is 64KB, which is too large to install on users' machines. In addition, Windows NT would have to download the interpreter every time a user logged on, thus causing increased logon time (1 additional minute over a 28.8Kbps modem connection).
We turned to the Microsoft Windows NT Server 4.0 Resource Kit's autoexnt.bat tool. This utility lets you run 16-bit commands before NT boots completely. You can link the tool to a specific hardware profile because the tool installs itself as a service. (For more information about this utility, see This Old Resource Kit, "AUTOEXNT," November 1998.)
Our laptops have two hardware profiles—Network (docked) and Remote. We bonded autoexnt.bat to the Remote profile and configured the utility to create a small file on the user's hard disk. When a user logs on via DUN, the general logon script checks for this file. If the file exists, the logon process runs a script that is smaller than the regular script. This process helped my company considerably reduce RAS logon times.
Y2K Testing Aid
I work as a technical analyst, setting up Windows NT Server and Microsoft BackOffice components such as SQL Server and Exchange Server for my company's clients. I'm working with several clients who want to verify that their software is Year 2000 (Y2K)-compliant. Because the clients' data is confidential, users are responsible for testing applications themselves. However, users don't have access to the servers, and we don't give them the administrative passwords. Therefore, we needed to find an easy way to let users change the NT Server time. We accomplished this task via the NT Scheduler service and some simple batch files.
First, we created the settime.cmd batch file that Listing 2 shows. We saved this file in C:\commands. Next, we created a directory called C:\time and shared the directory to let users copy the file time.cmd into the directory to run. Because this step creates a security hole, you might want to place the setto batch files in one location on an NTFS partition and use the Uniform Naming Convention (UNC—i.e., \\server\share) to give users only execute access. Finally, we wrote the setuptimesched.cmd batch file that Listing 3 shows to configure the NT Scheduler service to check for and run the time.cmd file every 30 minutes.
We created two simple batch files, which Listings 4 and 5 show, to rename and copy specific dates to the C:\time\time.cmd file. These batch files prevent errors because of users incorrectly entering the four-digit dates that are necessary to test applications for Y2K compliance.
We created three additional files, using the dates 02282000, 02292000, and 12312034. We then placed an icon on the desktop for each of the setto.cmd files.