| Previous | Table of Contents | Next |
It can seem like gremlins are lurking in every server, wire center, and particularly in every Windows 95 PC. Usually, however, what we attribute to gremlins is actually the result of a user who has changed something and subsequently forgotten (or denied) making the change.
We all do this; we’re our own worst enemies. For example, say you install a new browser, decide you don’t like it, forget to delete it, and then have trouble accessing your company’s intranet the next day. If you’re lucky, you won’t forget you installed the new browser, and you might be fine after uninstalling it. But what happens if you have a really great weekend in between and forget? You might “spin your wheels” for hours while trying to figure out what’s wrong.
The same principle applies when you’re fixing servers and routers. You might make a change to a router or server in order to offer a new service or to fix a problem. If the change seems to work at first, it might be the last thing you think of if a problem surfaces later. For example, if you see that the startup file for your IntranetWare server does not automatically make a certain volume available, you might fix this by editing the file. The next day, you find that Windows NT—but not Windows 95—users are complaining that their time is off by five hours. Related? Couldn’t be! Has to be the NT configuration, right? It can’t be the server.
However, when this scenario happened to me recently, it was, in fact, the server. This is what I call the fat finger factor—while editing any configuration file (no matter how benign your changes are), you might introduce a stray character or two that makes a key command or parameter unintelligible to the server. In my case, the problem was that I had edited the IntranetWare startup file for something quite innocuous and hit a random key by accident at the top of the file. The first line of the file was responsible for setting the time zone. Instead of reading
SET TIME ZONE=EST5EDT
the line as accidentally edited to read
\SET TIME ZONE=EST5EDT
When I saved the file with my “benign” changes, all of the sudden the server had no idea what time zone it was in, because it didn’t understand the \SET command. Because Novell-connected Windows NT synchronizes the time from the server and relies heavily on time zones, my fat finger threw every NT workstation on our network off by five hours (we’re in the Eastern time zone, which is five hours off from universal time). Ouch!
The lesson is this: Always point the finger at yourself first. Always be thinking, “What have I done lately”? Then, be prepared to undo your changes. As I discussed last hour, keeping good notes—particularly a formal logbook—is a really good idea. That way, you can compare the date when the problem started to the dates of changes entered in your logbook.
Of course, others in your organization may be equally at fault—particularly if you share responsibility for your network. A logbook helps here, too, but don’t solely rely on the logs—it helps to talk to each other and discuss what you’ve been working on.
When starting to troubleshoot a problem, you should go around and ask everyone if they’ve changed anything.
It’s particularly troublesome when you (or your vendor) do a “fat finger” on a device and don’t immediately restart it. When the device does finally get restarted, the change is no longer recent and is therefore hard to point to as the culprit. Of course, when you consider this, it makes sense to think of any device that has been recently restarted as a suspect device.
In general, you should always restart a device after a change has been made to it. A variation on this theme is when another user fat-fingers something and doesn’t restart the device. You, then, come along and change something else and are totally innocent of wrongdoing, but when you restart the device, a problem occurs. I combat this problem by restarting a device before I start changing things. This way, I know that I am about to change a device that isn’t broken.
Your vendor probably does have your best interests at heart. However, remember that in addition to wanting to help you out, your vendor also has a schedule, doesn’t like to pay people to do more than necessary to get the job done, and has a vested interest in selling you new stuff. Also, because your vendor probably has various projects scheduled, this can mean that someone might show up on your doorstep at a random time (not necessarily when it’s convenient for you). You have a right to insist that changes to your network—no matter how necessary—must be scheduled according to your needs. You wouldn’t let your plumber walk into your house at any time and fiddle with your water heater, would you?
For larger projects, you should also insist on a rollback plan (also known as bailout plan) in case of problems. A rollback plan is executed when things go seriously wrong—that is, when you’re worse off when you finish than when you started. You’ll have to decide how much this is worth to you: Sometimes, rolling a change back can cost a lot in terms of time and money. For example, if you’re converting from a Windows NT server to an IntranetWare or UNIX server, a technician might need to go around to each workstation. Rolling this back can be time intensive and therefore costly. Because a vendor might ask you to eat the cost of rollback, it pays to negotiate this up front for a major project. The cost for “making it work and putting it back if it doesn’t” might be a different price than “throwing it in and then dealing with it if it’s a problem.” It pays to look out for yourself, and if you’re dealing with a reputable vendor, he or she won’t mind if you bring these types of things up during project negotiation.
Don’t be a pushover, but don’t be a pit bull either. Having a good relationship with your vendor is really important; your vendor can either be a cause of trouble or a troubleshooting partner—you want to shoot for the latter.
| Previous | Table of Contents | Next |