Mac Naming Conventions
About 2 years ago I took over a Windows NT 4.0 server that served an entire department. Most of
the client machines were Macs, and a Mac person had set up the NT server. The server was in bad
shape--poorly set up, with no service packs applied. When I took over, I learned that users
were having problems with backups and that no one had been able to perform a complete backup in
several months. I also discovered problems with the virus scanner. The scanner would get almost
to the end of a scan and lock up.
After much investigation, I discovered the problems' cause. Several Mac users were giving their files names such as Com1 and Com2. The Macs let users apply these names, but the names caused problems when the NT server saved the files. The backup program and virus scanner couldn't process the filenames.
I couldn't use my PC to remove the files. Instead, I had to use a Mac to rename the files.
Changing Printer Spool Directory Location
To change the printer spool directory location, most Windows NT resources recommend making changes via the Registry. Open a Registry editor (regedt32.exe or regedit.exe) and go to the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\ Print\Printers key. Double-click the DefaultSpoolDirectory subkey. Then, edit the drive and directory parameters as necessary, and click OK. Close the Registry editor, and restart the computer. (For more information about changing the printer spool directory, see Bob Chronister, Tricks & Traps, August 1997.)
I recently discovered an easier and safer trick for administering printer settings. From the Start menu, select Settings, Printers. In the Printers window, select File, Server Properties. (Alternatively, you can right-click in the Printers window's free space, and select Server Properties.) In the Print Server Properties dialog box that opens, select the Advanced tab. In the Spool Folder box, edit the drive and directory parameters as necessary. Click OK. You'll then receive the message You must shut down and restart this computer before the new settings will take effect. Click OK, and restart the computer.
NT Strikes Out Again
I recently had problems with one of Windows NT's "features." If you try to run an executable (.exe) file by launching a shortcut (e.g., whatever.exe) and NT can't find the file, the OS searches for an .exe file that closely matches the one you're trying to run. You receive the message Windows is searching for whatever.exe. To locate the file yourself click Browse. Then you receive the message The item whatever.bat that this shortcut refers to has been changed or moved. The nearest match based on size, date, and type is somethingelse.exe. Do you want this shortcut to point to this item?
Microsoft might think this feature is useful, but it has caused more than its share of headaches in my office. We recently took a network-based application offline so that we could upgrade it. Users who tried to run the application received the error messages I mentioned previously. Unfortunately, many users opted to replace the shortcut with the file NT suggested. The Help desk was busy for hours, and users were unable to work while we straightened out the mess that ensued.
In one user's case, NT replaced the file with deltree.exe. The command-line argument for the original shortcut was the directory that contained the data concerning users' read and write access. The replaced shortcut, with deltree, kept the original command-line argument. Thus, the user's shortcut ran deltree J:\sics\data. When the user tried to launch the application, NT asked if she wanted to delete J:\sics\data. The user didn't know any better, and she said yes.
Back in the IS department, we were surprised to see the data suddenly disappear. We scratched our heads and restored the data from backup. Ten minutes later, the data disappeared a second time when the user again tried to run the application and answered yes to the deletion prompt. We still didn't know what was going on, so we frowned and did another restore.
The user tried to run the program for a third time and received the same deletion prompt. This time she called the Help desk to find out what the prompt meant. Finally we understood why our data was disappearing, and we were able to solve the problem.
We probably spent 20 man-hours that day restoring data and resetting about 100 shortcuts. Our users also lost valuable time. Since then, we've tried to find a way to disable NT's nearest match feature, to no avail. If Microsoft insists on including the feature, the company could at least make it configurable to prevent the kind of problems we experienced.
NET VIEW Command Enhances the FOR Command with the /F Parameter
In "Use the FOR Command with an /F Parameter" (Reader to Reader, October 1998), Lavon Fischer and Terry Acker provide a task automation script that uses the FOR command with a separate list of servers. A better way to maintain the servers list is to use the NET VIEW command. Listing 1 shows an example of how to use this command, including the use of the skip, tokens, and delims constructs. The Task.bat parameter in Listing 1 is a variable. Listing 2 shows an example Task.bat script. By using the if exist construct appropriately, you can develop file filters to select many types of servers to copy files automatically.
CMDSTUB
In Windows NT, determining whether a shell script is running in the background is difficult. In UNIX, you can run a script called myscript and enter a ps command to see the commands in the process list. NT doesn't offer such an easy check. If you run a .bat file, you can see the cmd.exe command in the process list, but you can't tell what the command is doing.
You might wonder how crucial this type of information is. I have an application server with IBM's DB2 installed that runs several batch files all day long. The AT command starts the batch files, which typically run for several hours. These batch files perform simple actions, such as launching COBOL .exe files and checking return codes and loops. At any given time, I need to know which batch files are running, and I must be able to kill them if necessary. Viewing Task Manager's task list doesn't help, because I can see only some of the cmd.exe files. Killing a batch file without knowing whether it's the right one is risky on a production server.
The solution I use is cmdstub.bat, which Listing 3 shows. This simple batch file can launch another batch file and give it a distinctive name in the task list. Using the batch file is simple. To run a batch file called myscript.bat that is in C:\Util, type
cmdstub C:\util\myscript.bat
If you look at the process list, you'll see a command called myscript_cmd.exe that is running. This command name is a placeholder for the myscript.bat file. If you kill myscript_cmd.exe, you kill myscript.bat.
You can also use cmdstub.bat with the AT command. For example, to launch myscript.bat every weekday at 8:00 a.m., type
at 08:00 /every:m,t,w,th,f cmd /c "cmdstub C:\path\test.bat >C:\path\myscript.log"
(assuming that cmdstub.bat is in your path).
The cmdstub.bat command is short but complicated. The if command at callout A in Listing 3 checks whether the first command-line argument (%1) is null. If %1 is the empty string, the comparison is true. (Note that the if command differs from the if defined command.) The first two set commands use a little-known variable-substitution technique for command-line arguments that extracts the filename and the path from a full pathname. For more information about these commands, go to the command prompt and type
help call
The third set command might seem unnecessary. However, the TEMP variable is user-defined rather than system-defined; thus, when you call cmdstub from an AT command, TEMP isn't defined. NT Setup always creates a Temp directory in the installation drive, so I assume that such a directory is always available. The three lines in the script at callout B perform the magic: They copy cmd.exe (the system shell), rename it after the first command-line argument, append _cmd.exe, and run the .bat files through it. After the .bat file runs, the system deletes the newly created copy of cmd.exe.
Updating Roaming Profiles
In Windows NT installations with roaming profile implementations, you sometimes need to generate new desktop shortcuts or links to existing user profiles. When a user with a roaming profile logs on to an NT computer, the system checks whether the cached profile is more recent than the roaming profile. If so, the system doesn't reload the profile from the central server. The system bases this check on the last write time of the ntuser.dat file. If you modify the user's central profile and don't properly update the last write time of ntuser.dat, you will lose your modifications. (For more information about roaming profiles, see Glenn Grant, Phillip Carver, and Roger Bruist, "Troubleshooting with Microsoft: Common Windows NT Problems," April 1997.)
I used the Microsoft Windows NT 4.0 Resource Kit TOUCH utility to update the time stamp of the Perl script in Listing 4. The script in Listing 4 copies the required shortcut files to all the users' central profile directories and updates the date stamp on the ntuser.dat file to the current date and time. This script works for even long name implementations.
You need to run the script from the main server that stores the users' profile folders. For the script to run successfully, the touch.exe and users.txt files must be in the same directory as the script. To create the users.txt file, open a command prompt and switch to the users' profile directory (in this case, the directory is in D:\\Profile). Then, type
dir /B > users.txt
The users.txt file contains all the users' profile directory names.
In the script, the $source line contains the original profile folder with the shortcut file test.lnk. Replace the path and link with the path that applies to your environment. Don't forget the double slashes. The $destination line is the path to users' profile directories. Replace D:\\Profile with the directory for your environment. The default path in this script puts the shortcuts on the desktop. If you want to put the link elsewhere (e.g., Start Menu\Programs), change the path. Replace $var2 with your central user profile directory path.
Finally, your users need to log off before you can run the script. If you run the script while users are logged on, the system will set the date stamp back when the users log off.
Microsoft Certificate Server
Using x.509 digital certificates (or digital IDs) is an essential part of the modern enterprise information infrastructure. Microsoft's Certificate Server, included in the Microsoft Windows NT 4.0 Option Pack, makes deploying digital IDs quick and inexpensive. Certificate Server provides two important features.
First, you can configure Certificate Server to let you import digital client certificates that you exported from Internet Explorer (IE) 4.0. IE can export existing personal certificates to a .pfx file for use on another system. But if you used the basic Certificate Server enrollment procedure, you can't import the .pfx file. To solve this problem, you need to open the Certificate Enrollment Form (ceenroll.asp), go to Advanced options, and select the Allow Keys to be Exported check box. Internet Information Server (IIS) 4.0 lets you impersonate a digital ID owner to a domain account owner so that you can perform administrative tasks and send a .pfx file and the accompanying root certificate to an extranet user, regardless of the user's logon credentials. Thus, you can still use NT's integrated security while expanding your applications for extranet use. Use the IE certificate export feature to give your users (including external users) in-house generated digital IDs. (For more information about Certificate Server and IIS, see Ramon Ali, "Configuring IIS 4.0 Certificate Authentication," February 1999.)
Second, Certificate Server provides additional protection for private keys. If you use VeriSign for enrollment, you can select Additional Security for Your Private Key and thus set the security level. If you select high-level security, every certificate usage requires additional password input. In Certificate Server, a Certificate Manager update lets you set the security level for existing private keys. You can download the update from http://www.microsoft.com/security/downloads/certinst.exe. Certificate Manager runs on NT, Windows 98, and Win95. You must run the Certificate Manager executable, certmgr.exe, from the command line. You can change a certificate's security level only if the certificate has exportable private keys. To view information about certificates in your store and set their security levels, go to a command prompt and type
certmgr.exe -s MY -c -addui
You need to increase your command-prompt window screen buffer because certmgr gives highly detailed text information.
File Synchronization
As a systems administrator, you've probably experienced file synchronization problems. If your organization consists of workstations and laptops, you most likely have two data storage locations: local and network (for backups). Because my organization's users work with their own machines 95 percent of the time, we had to find an inexpensive and easy way to keep their local drives synchronized with the network drives and vice versa. An easy way to solve this problem was to use the xcopy command in both directions, with the proper switches, to copy only the newer or changed files. However, xcopy can't handle deleted files. If you delete a file in one location, it might reappear at the next file replication.
The Microsoft Windows NT 4.0 Resource Kit offers a powerful file-copy utility called Robocopy. Listing 5, which has only two lines of code, shows this utility. First, we copy all the new or modified files (archive bit set) from the network to the local drive and reset their archive bit (/m). If two copies of a file with the archive bit exist in both locations, /xo copies only the most recent one. The /s parameter excludes empty directories, and /log directs the output to log.txt, which is a new feature in Robocopy 1.95.
The second operation in Listing 5 copies only files that don't exist on the network drive or that are older than or different in size from the files that reside locally. The operation then deletes the network files that no longer exist locally. Finally, the output of the operation is appended to the existent log file.
For this utility to work, you must implement a backup policy that doesn't reset the archive bit after a backup. In my organization, we perform regular backups only by overwriting the tapes each time. Thus, only new or modified files have the archive bit set in the network location.
Our file synchronization process is limited because we assume that users work with their own computers 95 percent of the time. Local file synchronization works perfectly, and if users move, delete, or rename a local file, these changes replicate to the network. If users then decide to work at another computer, they access their network drives. Not any of the file operations users perform (e.g., move, delete, rename) replicate locally. Thus, previously performed file operations are lost at the next replication. Robocopy doesn't provide complete file synchronization, but it might still be beneficial in your environment.
More Heat Problems
Dianne M. Daniels' experience with a loose heat sink causing blue-screen-of-death errors (Reader to Reader, "An Unlikely Cause of Blue-Screen Errors," October 1998) reminded me of a problem I experienced more than a year ago. I had a new 200MHz Pentium Pro server with a 512KB cache. The server mysteriously crashed on a regular basis. The only way I could keep the server up for any length of time was to run it in a very cool room (below 60 degrees Fahrenheit) with the cover off and a 22" box fan blowing at the server. Obviously, heat was causing the problem.
The CPU heat sink fan was securely attached to the CPU with heat sink compound and properly clipped to the motherboard. Thus, I suspected a faulty CPU. I obtained a replacement CPU from the vendor and proceeded to move the heat sink fan to it. However, I discovered a small (0.2" * 1.2") plastic-coated bar-code sticker mired in the heat sink compound. I removed the sticker and put the heat sink and original CPU back in place. Since then, the machine has exhibited no heat-related problems.
