Troubleshooting Tips

Now that we have covered the basics of network troubleshooting, we should go over a few troubleshooting tips. These tips will give you more “ammo” while you’re hunting for network problems and using the various steps of the troubleshooting model discussed earlier.

Don’t Overlook the Small Stuff

If you’ll remember, the first thing we discussed in this chapter was small stuff. Often a problem is caused by something simple, such as a power switch in the wrong position, a card or port not functioning (as indicated by a link light that’s not lit), or simply operator error. Even the most experienced administrator has forgotten to turn on the power, left a cable unplugged, or mistyped a username and password.

Finally, make sure that users get training for the systems they use. That may seem like an extra bother, but an hour or two of training goes a long way toward preventing problems. The number of incidents of EEOC will decline with a little user training.

Prioritize Your Problems

It is unlikely that as a network administrator or technician, you will receive problem calls one at a time. Typically, when you receive one call, you already have three people waiting for service. For this reason, you must learn to prioritize.

You start this process by asking some basic questions of the person reporting the problem so that you can determine its severity. If the current problem is minor and you have two more serious problems already facing you, your priorities are obvious.

You establish priorities to ensure that you spend your time wisely. The order in which you attempt to solve your networking problems, from highest priority to lowest, might look something like this:

• Total network failure (affects everyone)

• Partial network failure (affects small groups of users)

• Small network failure (affects a small, single group of users)

• Total workstation failure (single user can’t work at all)

• Partial workstation failure (single user can’t do most tasks)

• Minor issue (single user has problems that crop up now and again)

Mitigating circumstances can, of course, change the order of this list. For example, if the president of the company can’t retrieve her e-mail, you’d take the express elevator to her office as soon as you hang up from the call. Also, a minor, persistent problem might move up the ladder.

Remember also that some simple problems may take more effort than larger problems. You may be able to bring up a crashed server in a matter of minutes, but a user who doesn’t know how to make columns line up in Microsoft Word may take up to an hour or longer to train. The latter of these problems might get relegated toward the bottom of the list because of the time involved. It is more efficient to solve problems for a larger group of people than to fix this one user’s problem immediately.

Some network administrators list all network service requests on a chalkboard or a whiteboard. They then prioritize them based on the previously discussed criteria. Some larger companies have written support-call tracking software whose only function is to track and prioritize all network and computer problems. Use whatever method makes you comfortable, but prioritize your calls.

Check the Software Configuration

Often, network problems can be traced to software configuration (as with our DNS configuration example earlier in this chapter). When you are checking for software problems, don’t forget to check configuration, including the following:

• DNS configuration

• WINS configuration

• HOSTS file

• AUTOEXEC.BAT (DOS and Windows)

• CONFIG.SYS (DOS and Windows)

• STARTUP.NCF, AUTOEXEC.NCF, and server parameter settings (NetWare)

• The Registry (Windows 95/98 and NT)

Software configuration settings love to hide in places like these and can be notoriously hard to find (especially in the Registry).

Additionally, in text configuration files, look for lines that have been commented out (either intentionally or accidentally). A command such as REM or REMARK or the asterisk or semicolon characters indicate comment lines in a file.

Tip 

The HOSTS file uses a # (pound sign) to indicate a comment line, as does NetWare’s NCF files.

Don’t Overlook Physical Conditions

As we discussed in Chapter 6, you want to make sure that from a network design standpoint, the physical environment for a server is optimized for placement, temperature, and humidity. When troubleshooting an obscure network problem, don’t forget to check the physical conditions under which the network device is operating. Check for problems such as the following:

• Excessive heat

• Excessive humidity (condensation)

• Low humidity (leads to ESD problems)

• EMI/RFI problems

• ESD problems

• Power problems

• Unplugged cables

Don’t Overlook Cable Problems

Cables, generally speaking, work fine once they are installed properly. Rarely is the cabling system the problem, unless someone has made some change to it. If you suspect that the cabling system is the problem, try replacing the patch cables at the workstation and hub first. These are easiest to get to (and replace). If that solves the problem, you know the problem was related to the patch cable. It was either faulty or the wrong type.

If the patch cable isn’t the problem, use a cable tester (not a tone generator and locator) to find the source of the problem. Wires that are moved can be prone to breaking or shorting. A short can happen when the wire conductor comes in contact with another conductive surface, changing the path of the electrical signal. The signal will go someplace else instead of to the intended recipient. You can use cable testers to test for many types of problems, including:

• Broken cables

• Incorrect connections

• Interference levels

• Total cable length (for length restrictions)

• Cable shorts

• Connector problems

Note 

As a matter of fact, cable testers are so sophisticated that they can even indicate the exact location of a cable break, accurate to within 6 inches or better.

Check for Viruses

Many troubleshooters overlook virus scanning because they assume that the network virus-checking software should have picked up any viruses. We’re reminded by the network virus-scanning software of the bio-filters in the transporter on Star Trek: The Next Generation. They work great as long as the computer has the latest information on what the virus is and how to eliminate it. On many occasions, though, the ship’s doctor or engineer had to reprogram the bio-filters to recognize some new virus that the crew of the Enterprise had come across.

The same thing happens with network virus-scanning software; to be effective, it must be kept up-to-date. Updates are made available almost daily. As we discussed in Chapter 9, “Fault Tolerance and Disaster Recovery,” you must run the virus definition update utility to keep the virus definition file current.

If you are having strange, unusual, irreproducible problems with a workstation, try scanning it with an up-to-date virus scan utility. You’d be surprised how many times people have spent hours and hours troubleshooting a strange problem, only to run a virus scan utility, find and clean one or more viruses, and have the problem disappear.