Keep It Simple

You’re probably starting to see that a key component of successful troubleshooting is keeping things simple. This is exactly what you do when you start with the “highest” level object when you begin determining which thing is not like the others (see Figure 5.1). In the previous example, why even start investigating the workstation configuration before you can rule it out? Also, why start messing with the PC’s video card or network card when you know there’s nothing wrong with the PC?

Figure 5.1  Look at high-level objects first.

It’s useful to think of these items as being in high-level containers that have lower-level containers within them. Until you rule out (or rule in) an upper-level container, it’s silly to even look at its subcontainers. You can think of a typical network setup as a “box of workstations” (which contains motherboards, memory, hard drives, and so on), a “box of networks” (which contains wiring, hubs, and so on), and a “box of users” (which contains user IDs, login scripts, and various security attributes).

Thinking of these high-level components in boxes allows you to concentrate on the task at hand without getting distracted, and it will make you a better troubleshooter. If you discover that the network is the problem, you won’t get distracted by workstation subcomponents, for example. In other words, once you figure out that the network is the problem, you should only concentrate on the network subcomponents.

To Shotgun or Not to Shotgun?

When you’ve identified, in general, where the problem lies, the fastest way deal with it is to use the “shotgun” effect—that is, to simply make a problematic object identical to one that’s working.

This means that you should point your “troubleshooting shotgun” in the general direction of the target. Have you ever seen a shotgun in use? It’s pretty hard to miss your target when shooting with a shotgun, because the shot scatters widely. Anything in front of the muzzle tends to get holes in it. “Shotgunning” a particular object means that you replace everything in that subcontainer in the same indiscriminate way—without spending time analyzing which component is the troublemaker.

Drive duplication can be a big help here, because it’s fairly easy to “shotgun” a known “good” hard drive setup to a hard drive setup that’s having configuration difficulties (see Hour 16, “Where Do I Start?” for more information). Remaking the user’s home directory is another good method of “shotgunning” a problem once you’ve identify the general target. For example, because UNIX programs are dependent on multiple configuration files in a user’s home directory, I sometimes rename a user’s home directory, make a new home directory for that user, and then copy a known “good” user’s home directory contents into it (see Figure 5.2).

Figure 5.2  Shotgunning a user’s home directory.

For those times when you can’t use this technique (for example, when crucial information would be overwritten), you’ll want to consider the following components, listed from the highest level (to the left) to the lowest level (to the right):

- Workstation
    - BIOS / Manufacturer
    - Hard drive
        - Operating system configuration (startup files, Registry)
        - Operating system components (DLLs)
        - Local applications (versus network)
        - Virus? Or not!
    - Network card
        - Cable
    - Video card
    - RAM
    - Power
        - UPS
        - Surge suppression
- User login on server
    - Login script
    - Permissions
    - Application configuration files (user-oriented access list?)
    - User files (home directory)
    - Application itself (versus on hard drive)  
- Port on the switch or hub

---

Most folks don’t realize just how much trouble bad AC power can cause—it’s really worth trying to rule out the power of a PC that, for example, is locking up as it gets into the network by plugging the PC into a different wall outlet or adding a power conditioner. A power conditioner is a special filtering device that acts to get rid of the jitters and brownouts that can plague AC power (particularly in rural areas).

---

Again, beware of chasing the low-level components. For example, operating system components can be an adventure in and of themselves; you can literally spend days doing comparisons of these lowest level objects. This might be worth it sometimes, but for most small areas of trouble, keep in mind that information you don’t need is information you don’t want. This is known as information hiding. Keep the fuel pump image from the introduction of this book firmly in mind when you’re about to dive into more internals than you really care to deal with. Do you really need to learn all the icky details of what various Windows DLL files do if you can simply copy somebody’s known “good” Windows configuration to solve the problem?

On the other hand, if an email program is complaining that it can’t load MAPI32.DLL, it’s usually worth looking at the MAPI32.DLL file on the hard drive. Sometimes the file is damaged, (it might show a size of 0, for example). Also, you might compare it to a known “good” MAPI32.DLL and realize that it’s much shorter than it should be. In this case, copying one file from a known “good” workstation is faster than reloading and reconfiguring the entire workstation. It’s a bit of a balancing act—you just need to look at the given situation, see what information you have, figure out how much time it would take to change something out, and take what seems like the quickest and most effective action.