Skip navigation

Tech Stories from the Trenches - 01 Oct 1997

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.

I powered the modem off and back on again and waited another 15 minutes. Lo and behold, the modem phoned home again. It never connected, and I had absolutely no idea where the call was being initiated. When someone commented the next day about how the modem had been dialing all day long, I had to power off the modem permanently.

A month later, on the same server, I installed Service Pack 3 (SP3) with the uninstall option, just to be on the safe side. After a clean upgrade, the system rebooted. All services started, no messages were in the system event log, the UPS service was running on COM2, and the modem dialed out on command and answered incoming calls.

Based on the previous month's experience, I waited to see whether SP3 corrected the problem of the modem phoning home. Sure enough, about 15 minutes later, the modem dialed. This time something new was on the screen: a small message box saying that the system was unable to connect to http:// and would I like to redial or cancel. Huh?

I dug around in NetShield and found an AutoUpdate option under the Tools menu. As Screen 2 shows, I had not configured this option, and the schedule box for hourly/daily/weekly/monthly updates was not checked. However, when I looked more closely at the dialog box, I saw the update default is to call out on the third day of the month at 8:46 p.m. The date just happened to be June 3, and it was 8:46 p.m.

Even though I had not asked for an AutoUpdate, NetShield decided to take on this task. To make matters worse, when the connection is not successfully established, NetShield retries the call every 15 minutes, producing an endless cycle of errors.

At last, the answer to a problem that had plagued me for a month. Only two explanations are plausible: Either I inadvertently had asked for an AutoUpdate during the original installation, or the modem truly was phoning home on its own (i.e., the NetShield software has a bug). Now all I had to do was find out how to turn off the stealth-mode AutoUpdate.

The next time the modem phoned home, I was able to capture the Dial-Up Networking (DUN) box in Screen 3, which shows that the system (quest) could not be reached. I started Task Manager and identified the process taking up CPU cycles. Its name was McUpdate.exe, which I located in the McAfee\Netshield directory. The only way to get rid of the stealth dialing was to rename the executable, which in turn caused the next dial-out attempt to fail.

How can someone avoid this problem in the future? Maybe the version I downloaded has this "feature" as a known bug. In any case, the whole idea of software dialing out and downloading updates in stealth mode is questionable at best. I can think of several possible security problems, and I remember the Big Brother syndrome that Microsoft was flamed for when Windows 95 first came out. Curious how developers or marketers think this auto-update feature is great, whereas I view it as a bug.

Does Your Fax Software Work Only Once?
Back at the home office, I discovered I needed to fax a proposal and remembered that my antique thermal fax died several months ago. Instead of spending $500 on a do-everything-but-make-your-lunch fax machine that probably won't work with NT, I found the free beta version of the Microsoft Personal Fax software a reasonable compromise. The software is 700KB, downloads quickly, and installs clean. You even get a little fax icon in the desktop's lower right corner, next to the RAS telephone icon. After the software is installed, the fax shows up as one of the devices in the print menu of my Office 97 applications.

I started Microsoft Word, created my proposal, and selected the fax device with very low expectations, because my experiences with the UPS and NetShield were fresh in my mind. Miraculously, the fax worked the first time.

My skepticism was soon justified, though, as telemarketers called my fax/modem line. The fax dialog box popped up and asked whether I wanted to take the incoming call (I'd selected manual answer). I said no, and after that incoming call, I could no longer send or receive a fax. So I removed and reinstalled the Personal Fax software. To be fair, I can't legally complain about the software's eccentric behavior. It's a beta version.

The second time I reinstalled, I could send and receive faxes just fine. I am left scratching my head as to why it failed the first time and then worked as advertised. But I don't have the time or patience to troubleshoot this beta product, so I decided to live with its eccentricities and move on.

Life Goes On
Nothing in my saga is new or unusual for any IS shop. In fact, techno-warriors in the trenches meet and face challenges like these--and even tougher ones--daily. On my bad days, when every software hiccup makes me see red, I truly believe software quality is an oxymoron. Why is it that, despite huge commitments to software quality, we always come up with the short end of the code? On my good days, I consider this lack of quality control a great omen for current and future job security.

Contact: APC * 800-800-4272
NetShield for Windows NT
Contact: McAfee * 408-988-3832
Personal Fax for Windows NT
Contact: Microsoft * 800-426-9400
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.