Troubleshooting Steps

In the Network+ troubleshooting model, there are eight steps:

  1. Establish symptoms.

  2. Identify the affected area.

  3. Establish what has changed.

  4. Select the most probable cause.

  5. Implement a solution.

  6. Test the result.

  7. Recognize the potential effects of the solution.

  8. Document the solution.

To facilitate our discussion of the troubleshooting steps, let’s assume that a user has called you, the network administrator, to complain about not being able to connect to the Internet.

Step 1: Establish Symptoms

Obviously, if you can’t identify a problem, you can’t begin to solve it. Typically, you need to ask some questions to begin to clarify exactly what is happening. In our example, we should ask the user the following:

  • Which part of the Internet can’t you access?

  • A particular website? A particular address? Any website?

  • Can you use your web browser?

We find out that the user cannot access the corporate intranet or get to any sites on the Internet. He can, however, use his web browser to access the corporate FTP site, which he has bookmarked (by IP address 10.0.0.2). We can, therefore, rule out the web browser as the source of the problem.

Step 2: Identify the Affected Area

Computers and networks are fickle; they can work fine for months, suddenly malfunction horribly, and then continue to work fine for several more months, never again exhibiting that particular problem. And that’s why it’s important to be able to reproduce the problem and identify the affected area. Identifying the affected area narrows down what you have to troubleshoot.

One of your goals is to make problems easier to troubleshoot and, thus, get users working again as soon as possible. Therefore, the best advice you can give when training users is that when something isn’t working, try it again and then write down exactly what is and is not happening. Most users’ knee-jerk reaction is to call you immediately when they experience a problem. This isn’t necessarily the best thing to do, because your response is most likely, “What were you doing when the problem occurred?” And most users don’t know precisely what they were doing at the computer because they were primarily trying to get their job done. Therefore, if you train users to reproduce the problem first, they’ll be able to give you the information you need to start troubleshooting it.

In our example, we find out that when the user tries to access the corporate intranet, he gets the following error message:

click to expand

We’re in luck—we can re-create this problem.

Tip 

It is a definite advantage to be able to watch the user try to reproduce the problem, because you can determine whether the user is performing the operation correctly.

Step 3: Establish What Has Changed

If you can reproduce the problem, your next step is to attempt to determine the cause by determining what has changed. Drawing on your knowledge of networking, you might ask yourself and your user questions such as the following:

Were you ever able to do this?  If not, then maybe this is not an operation the hardware or software is designed to do. You can inform the user that the system won’t do the operation (or that she may need additional hardware or software to do it).

If so, when did you become unable to do it?  If the computer was able to do the operation and then suddenly could not, the conditions that surround this change become extremely important. You may be able to discover the cause of the problem if you know what happened immediately before the change. It is likely that the cause of the problem is related to the conditions surrounding the change.

Has anything changed since you were last able to do this? This question can give you insight into a possible source for the problem. Most often, the thing that changed before the problem started is the source of the problem. When you ask this question of a user, the answer is typically that nothing has changed, so you might need to rephrase it. For example, you can try asking, “Did anyone add anything to your computer?” or “Are you doing anything differently from the way you normally proceed?”

Were any error messages displayed? This is one of the best indicators of the cause of a problem. Error messages are designed by programmers to help them determine what aspect of a computer system is not functioning correctly. These error messages are sometimes clear, such as “Disk Full” (indicating that the disk cannot store any more files on it because it is full). Or they can be cryptic, such as “A random bit has been flipped in the I/O subsystem of memory junction 44FA380h” (this is a fictitious error, but you may encounter those just as complex). If you get a cryptic error message, you can go to the software or hardware vendor’s support website and usually get a translation of the “programmerese” of the error message into English.

Are other people experiencing this problem? This is one question you must ask yourself. That way you might be able to narrow down the problem to a specific item that may be causing the problem. Try to duplicate the problem yourself from your own workstation. If you can’t duplicate the problem on another workstation, it may be related to only one user or group of users (or possibly their workstations). If more than one user is experiencing this problem, you may know this already because several people will be calling in with the same problem.

Is the problem always the same? Generally speaking, when problems crop up, they are almost always the same problem each time they occur. But their symptoms may change ever so slightly as conditions surrounding them change. A related question is, “If you do x, does the problem get better or worse?” For example, you might ask a user, “If you use a different file, does the problem get better or worse?” If the symptoms become less severe, it might indicate that the problem is related to the original file being used.

These are just a few of the questions you can use to isolate the cause of the problem.

In our example, we find out that the problem is unique to one user, indicating that the problem is specific to his workstation. When we watch him as he attempts to reproduce the problem, we notice that he is typing the address correctly. The error message leads us to believe that the problem has something to with DNS (Domain Name Service) lookups on his workstation.

Step 4: Select the Most Probable Cause

After you observe the problem and isolate the cause, your next step is to select the most probable cause for the problem. Trust me, this gets easier with time and experience.

You must come up with at least one possible cause, even though it may not be correct. And you don’t always have to come up with it yourself. Someone else in the group may have the answer. Also, don’t forget to check online sources and vendor documentation.

In our example, we determined earlier that the cause was improperly configured DNS lookup on the workstation. The correction, then, is to reconfigure DNS on the workstation.

Step 5: Implement a Solution

In this step, you implement the solution. In our example, we need to reconfigure DNS on the workstation by following these steps:

  1. Choose Start Ø Settings Ø Control Panel Ø Network to open the Network dialog box.

  2. Click the TCP/IP binding for your network card (indicated by TCP/IP Ø name of network card).

  3. Click Properties to open the TCP/IP Properties dialog box for that binding.

  4. Click the DNS Configuration tab.

As you can see in Figure 10.1, DNS has been disabled on this workstation. At this point, it doesn’t matter how it was disabled. We could probably assume that the user did something by accident to cause this to happen or that it was the result of a software installation, but anything is possible. To re-enable DNS, click the Enable DNS button. You may have to reboot the workstation to get the changes to take effect.

click to expand
Figure 10.1: TCP/IP DNS properties for the misconfigured workstation

Step 6: Test the Result

Now that you have made the changes, you must test your solution to see if it solves the problem. In our example, we’d ask the user to try to access the intranet (since that was the problem reported). In general terms, ask the user to repeat the operation that previously did not work. If it works, great! The problem is solved. If it doesn’t, try the operation yourself.

If the problem isn’t solved, you may have to go back to step 4, select a new possible cause, and redo steps 5 and 6. But it is important to make note of what worked and what didn’t so that you don’t make the same mistakes twice.

Step 7: Recognize the Potential Effects of the Solution

The fundamental flaw of any network technician is the ability of the technician to solve only the one problem and not realize what other problems that solution may cause. It is possible that the solution may be worse than the problem. As the saying goes, “Sometimes the cure is worse than the disease.”

Before fully implementing the solution to a problem, make sure you are completely aware of the potential effects of the solution and the other problems it may cause. If it causes more problems than it fixes, the solution isn’t probably the best solution for the problem.

Step 8: Document the Solution

As you learned in Chapter 6, “Network Installation and Upgrades,” network documentation is very important. You’ll definitely want to document problems and solutions so that you have the information at hand when a similar problem arises in the future. With documented solutions to documented problems, you can assemble your own database of information that you can use to troubleshoot other problems. Be sure to include information such as the following:

  • A description of the conditions surrounding the problem

  • The NOS version, the software version, the type of computer, and the type of NIC

  • Whether you were able to reproduce the problem

  • The solutions you tried

  • The ultimate solution




Network+ Study Guide
Network+ Study Guide
ISBN: 470427477
EAN: N/A
Year: 2002
Pages: 151

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net