DECK GOES HERE
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.
—Rose M. Delckum
rdelckum+@andrew.cmu.edu
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.
—Pavel Shchekotov
pagan@khsu.khakassia.ru
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.
—John Fitzpatrick
john.fitzpatrick@zurichre.com