Chapter 17: Using a Structured Troubleshooting Strategy
Chapter Outline
1. On the Test
4.9: Given a network problem scenario, select an appropriate course of action based on a general troubleshooting strategy. This strategy includes the following steps:
1. Establish the 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
2. Understanding Troubleshooting
a. Troubleshooting is the process of taking a large, complex problem and, through the use of various techniques, excluding all potential elements until only the actual cause remains.
b. Once the actual cause is identified, it can then be fixed.
c. Good troubleshooting skills require a commonsense, structured approach.
3. Establish the Symptoms
a. At this stage of the process you are primarily working with symptoms of the actual problem.
b. Most symptoms manifest themselves as a failure of some type.
c. Failures may or may not be accompanied by one or more error messages.
4. Open-Ended Questions
a. Open-ended questions are designed to elicit additional information. The plan here is to engage in a dialog with the user.
b. Examples of open-ended questions are:
i. What did you observe when the problem happened?
ii. What were you doing when the error occurred?
5. Closed-Ended Questions
a. With closed-ended questions, you are looking for a specific answer. Many times the answer will be yes or no, or a selection or one or more options.
b. Examples of closed-ended questions are:
i. Is there an error message?
ii. What does the error message say?
iii. Is your computer plugged into the wall?
iv. Is anyone else having this problem?
v. Have any recent changes been made to the computer?
6. The Basic Questions
Always remember to answer the essential questions: Who, what, when, where, why, and how. Here are a few examples.
a. Who
i. Who reported the problem?
ii. Who found the actual problem?
iii. Whom does the problem affect?
b. What
i. What are the symptoms to this particular problem?
ii. What type of device is having the problem?
iii. What was the user doing when he or she first noticed the problem?
c. When
i. When was the problem first noticed?
ii. When did the problem actually start?
d. Where
i. Where is the affected device?
ii. Where was the device when the problem occurred? (Used primarily with laptop computers).
e. Why
i. Why was this problem noticed?
ii. Why is this problem occurring?
f. How
i. How did this problem occur?
ii. Can you make this problem reoccur? If so, how?
7. Is There a Problem?
One of the questions you must always answer is, “Does the problem really exist or is the system simply operating the way it is intended?”
8. Identify the Affected Area
a. This section is concerned with the scope of the problem.
b. A common question to ask at this point is, “How widespread is the problem?” That is to say, is the problem limited to a single user, group, computer, server, subnet, or an entire network?
c. If one user calls the help desk to report a problem, you can usually deduce that it affects only one user or computer.
d. On the other hand, if your phones start ringing off the hook with multiple users reporting the same problem, you can be fairly certain that the problem is more widespread.
e. The importance here is how you will focus your troubleshooting efforts.
9. Establish What Has Changed
a. A good question to ask is if anything has changed recently. For example, has any new software been installed on the computer?
b. A dialog with other departments within the IT department will help you determine what software upgrades or repairs have been made to user workstations.
c. Always keep in mind that users may have made changes on their own, but have decided not to tell you about them.
10. Could You Do This Before?
a. It is important to determine if an employee has been able to perform a task in the past.
b. Many times, a user will have certain expectations of a computer system based on home use or past job experiences.
11. Recreate the Problem
It is always a good idea to see if you can recreate the problem.
12. Select the Most Probable Cause
a. Once you have asked a sufficient number of questions, you should have a fairly good idea of where the problem is, although you may not be able to describe what the problem is.
b. The problem here is that you rarely have only one possible answer to the problem.
c. At this point, you will start using some more techniques. For example, you may need to make a trip to the users’ computers, if possible, and run some diagnostics or utilities to eliminate some of the possibilities.
d. Always keep an open mind and avoid jumping to conclusions when it comes to troubleshooting.
13. What Can You Eliminate?
a. By testing one thing at a time, TCP/IP, DHCP, router, and DNS, you have systematically eliminated one problem after another, until only the actual problem remains.
b. Through the use of the process of elimination and basic troubleshooting utilities, you have been able to quickly identify where the problem exists.
c. Now you must determine what the problem is. That is to say, you know the problem rests with DNS, you just don’t know what the problem is with DNS.
14. Troubleshooting Tools
a. Always use all of the troubleshooting tools that are available to you.
b. Most computers provide either a utility or log files with which to view system problems. These files log or document everything that happens at the server.
c. Looking through these log files might direct you to the problem, or at least identify for you the area where the problem is occurring.
15. Event Viewer
The Windows Event Viewer contains three logs: Application, Security, and System.
a. Application: The application log contains events that are caused by applications or programs.
b. Security: The security log records events that relate directly to system security, such as valid and invalid logon attempts.
c. System: The system log contains events that are reported by system components.
The log indicates three different types of entries: Information, Warning, and Error.
a. Information: Describes a successful operation. For example, when an application, driver, or service loads successfully, an Information event will be logged.
b. Warning: An event that may be an indicator of a possible future problem. For example, if a system begins to get low on disk space, it will issue a Warning.
c. Error: Indicates a significant problem. This problem may result in a loss of data or loss of a functional. For example, if a device driver fails to load during system startup, an Error will be logged.
In order to view additional information for a specific event, double-click on the entry in the right pane.
16. Log Files
a. Most log files are simple text files that can be viewed through a text editor such as Notepad.
b. These log files normally monitor one particular item or process and report on the successes and failures of that item or process.
c. Each operating system contains a number of log files. The easiest way to locate them is to use the search utility for your particular computer.
17. Formulate a Solution
a. Once you have a good idea where the problem is, you can begin formulating a plan of attack to fix it.
b. This plan should be based on your knowledge of the way the system is supposed to operate, and any ancillary factors that affect the operation of that particular object.
c. Always consider consulting a technical reference when troubleshooting.
d. Most major manufacturers of computer hardware and software have a Web site loaded with support information for their products.
e. Many times, the problem has already been identified by the manufacturer and it can provide the information or software necessary to correctly fix the problem.
f. Based on your knowledge of the systems and your understanding of the problem, you will start to develop one or more solutions to fix the problem.
18. Implement a Solution
Always try not to make the problem worse.
19. One Thing at a Time
a. Implement only one solution at a time. There are two reasons for this.
i. First, if you do three things and the problem is corrected, you really don’t know which of these actions fixed the problem.
ii. Conversely, if your actions made the problem worse, you really don’t know which one of the actions made the problem worse; therefore, you have to undo all three actions.
b. Each step should build on the previous step. For example, if restarting the server does not correct the problem, what is the next most logical step to try that is not destructive? Continue working through these steps until you have resolved the problem.
20. Consider the User
a. While you are working to resolve the problem, it is easy to forget about the person who is actually experiencing the problem, the user.
b. When possible, always try to accommodate the user to the fullest extent possible.
c. In all cases, keep the user informed on your progress. If you believe that it will take two hours to fix the problem, be sure you communicate that information to the user.
d. Be realistic with your time estimates. If you try to fudge the time required, it will reflect badly on you as a technician and the IT department as a whole.
21. Test the Result
a. Testing the result means simply, did it work?
b. Keep in mind that you should implement only one potential solution at a time.
c. After you implement that one solution, try it to see if it works. If not, try another possible solution and then test it.
22. Recognize the Potential Effects of the Solution
a. Will the “fix” that you developed “unfix” something else?
b. Occasionally, you will repair one problem only to cause another.
c. This is especially prevalent when working with several companies that make competing products.
d. Some “side-effect” problems are not as obvious
e. The best way to head off these problems is to consider all of the factors involved and to conduct extensive research prior to implementing a new software solution.
f. Independent discussion groups and good technical references are a great place to start.
g. When working with discussion groups, in most cases, real users or administrators of a product moderate these groups. Since these folks have no vested interest in the product, they tend to be more honest about the problems that they have experienced with different manufacturers’ software.
h. A good technical reference will inform you of how all network components work together.
23. Document the Solution
a. Once it is fixed, write it down. Most problems reoccur at some time.
b. Once a problem has been successfully resolved, document the problem and the solution in a format that is available to others.
c. The documentation can be stored in some type of formal, structured facility or as simply as a notebook of loose-leaf papers.
d. Many companies use a knowledge base to document their troubleshooting efforts.
24. Knowledge Base
a. A knowledge base is generally a computerized system that allows you to log reported problems along with the steps a technician took to repair them.
b. A knowledge base can range from the very simple to the elaborate.
c. The simplest type of knowledge base might be a series of folders or binders containing technical notes that are compiled and maintained by technicians.
d. A knowledge base can also be a very sophisticated database-based system that can be queried by keyword or simply asked a question in the form of a text string
25. Frequently Asked Questions (FAQs)
Another simple knowledge base might consist of one or more Web pages made up largely of text that users or technicians can browse for frequently asked questions (FAQs).
5