Phone Home! Phone Home!
For any Windows NT professional, occasionally getting down in the trenches
with new hardware and software is a great reality check. In fact, I think time
in the trenches needs to be mandatory for IS management every six months. I have
two reasons why this idea is good. First, IS managers find out they have not
forgotten how to work with technology--once the task has been accomplished,
managers share in the pride of accomplishment, of hurdles successfully overcome.
Second, trench time is the only way to ensure that managers understand the
pitfalls and frustrations of working with technology.
When you're not in the trenches, slick, glossy ads and smooth-talking technoids convince you the solution to your current problem is fast, easy, and achievable by the end of the day. But my recent experience installing and
configuring three products provided a hard dose of trench reality. I configured an American Power Conversion (APC) uninterruptible power supply (UPS) connected to a serial port on an NT server, installed McAfee's NetShield virus scanner for NT Server, and tested the beta version of Microsoft's Personal Fax for Windows NT software.
Does Your UPS Answer the Phone?
Installing the UPS, one of the last tasks I performed for a small network
rollout at a real estate company, produced bizarre and hilarious results. The
APC Smart-UPS was delivered with a black cable and PowerChute software, which
provides a graphical interface for managing the UPS, checking the battery
status, and other meaningful functions. I connected the power cords, installed
the serial cable, and plugged the cable into the second serial port on the
server because the first port already had an external modem installed.
From here, everything went downhill at a screaming pace. The native NT UPS
service sometimes started and sometimes didn't, and I read messages warning of
line failure or low battery in the event log until I nearly went blind. Who
would expect something as simple as a serial device with a nine-pin connector to
be so complicated?
Hours of shutdowns, reboots, switching devices on the serial ports,
deleting and adding serial ports, unloading and reinstalling Remote Access
Service (RAS), and stopping and starting the UPS service failed to produce the
desired results. In desperation, I decided to hard-code serial port data in the
NT Registry hoping that the UPS service would finally start. This measure was in
response to a long-shot guess that the Plug-and-Play (PnP) BIOS was not
recognizing the serial ports correctly. At last, I thought, after one more
reboot (I'd already booted more than 50 times), the solution was at hand.
Screen 1 shows the UPS configuration I used.
Just to make sure the UPS service was not confused about which COM port to
use, I turned off the modem before I rebooted. When the system was up and
running, I checked the event log and saw that the native UPS service had
started. Cool! Next, I needed to verify that the modem would dial out, so I
powered on the external modem.
This step immediately initiated a system shutdown. Hmm, this wasn't exactly
the result I was looking for.
I then unchecked the Uninterruptible Power Supply is installed on
box and rebooted again with the modem powered on. Just for grins, I decided to
call in to the modem to see whether it answered the phone. Not exactly. I saw
the light blinking on the modem, but it never answered. Apparently, the call was
being sent to the UPS and not the modem.
If you have fought similar battles, the answer to this behavior is simple.
When I hard-coded the serial port parameters, I accidentally reversed the IRQ
and address settings for the COM ports, so the UPS service was actually
listening to the modem port and RAS was listening to the UPS. I corrected the
serial port settings, rebooted, and again the UPS service whined about a low
battery or a line failure.
Thus, I was off to APC's Web site to look for answers. My research revealed
I needed a different serial cable, which APC sent out second-day air. When the
cable arrived, it was exactly the same as the cable I already had. I called APC
and asked the vendor for the correct cable, which APC sent overnight. I
reconnected everything, and miraculously the UPS service started. I dialed out
on the modem, and the modem actually answered incoming calls. Hooray, problem
solved!
During the UPS troubleshooting process, I tried many great ideas that
turned out to be dead ends: attempting to install a 1995 version of the software
that shipped with the battery backup; adding a switch /NoSerialMice on the NT
bootup line in the boot.ini file; disabling first in, first out (FIFO) buffering
on the UPS COM port; setting the COM port to 2400 baud; ad nauseum. Each dead
end took time, and I probably spent a total of 30 hours fighting the NT UPS
service with a bad cable.
How could I have prevented this scenario? The Smart-UPS should have come
with the correct serial cable for NT (part number 924-0020b) and a newer version
of the software. APC's Web site needs to have a direct link to an NT
troubleshooting section that clearly identifies the two possible cables and when
each is required, describes known problems with NT 3.51 and 4.0, and provides a
URL for the latest release and a current version of the PowerChute software.
Does Your Modem Phone Home by Itself?
My next installation challenge was McAfee's NetShield for NT Server. The
software I received from the vendor was at least two versions outdated, as I
found out from browsing the McAfee Web site. I did not receive a password with
the initial order from McAfee, so I had to call and wait 15 minutes for someone
to give me a password and URL to download the latest version.
I installed the new release, easily configured time-based scanning and
logging of the server's hard drives, and sat back thinking that the project was
finally done. I rebooted once more to make sure everything was okay before I
left. I waited for half an hour and, for some strange reason, I heard the modem
dial. What? I have no email running on the server and no dial-out connections
scheduled on a fixed interval.