Workshop

Previous Table of Contents Next
Part II
“Black Box” Trouble-shooting Strategies
Hour
3 The Delta Method: Identifying Network Change
4 The Napoleon Method: Divide-and-Conquer
5 The Sesame Street Method: “One of These Things is Not Like the Other”
6 The SOAP Method: Subjective Data, Objective Data, Analysis, and Plan
7 The Simple Simon Approach
Hour 3
The Delta Method: Identifying Network Change
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 Fat Finger Factor
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