Chapter 1 - Troubleshooting Methodologies

Troubleshooting Methodologies

Only the CWNP Troubleshooting method will be tested on. However the book goes into Cisco, Microsoft, and CompTIA's methodologies to compare and contrast them.

CWNP Troubleshooting Methodology:

1. Identify the problem.
1. Do this through asking multiple open-ended questions. Try to determine everything about it, where its happening, what device(s) the user is using, what application(s) its affecting, any recent changes, etc.
2. Discover the scale of the problem.
1. Is the issue isolated to just this one user? Is it an application issue that is causing issues across multiple devices and areas?
3. Define the possible causes of the problem.
1. As with everything in IT, there could be any number of causes for the issue. Narrowing down and defining these will help in the following steps. It could be anything from a wrong password, to a supplicant misconfiguration, to a down AP, to a down server hosting the application. Or it could be something random like the user changed departments, and their new role doesn’t allow them access to something they used to have access to and as such they are blaming it on the network.
4. Narrow to the most likely cause.
1. Using the list of possible causes, use what you know of the issue and of the environment to narrow the list to the most likely cause. Obviously some environments will be more prone to certain types of issues. Use your knowledge of these "traits" to figure out the most likely cause.
5. Create a plan of action or escalate the problem.
1. Now that you have identified what you think to be the issue. Create a plan of attack on how to fix the issue. If the cause of the issue is outside of your purview, then escalate the issue and potential cause to those who have the capabilities of fixing it. For example, if it’s a server issue, then escalate it to the team who handles the servers. Document the cause and course of action you plan on taking.
6. Perform corrective actions.
1. Execute on your plan established in Step 5.
7. Verify the solution.
1. If the plan did *not* work, then cycle through step 4 again for the next probable cause. Documenting everything.
2. Also ensure that roll back any steps you took during step a.
8. Document the results.
1. Really you should be documenting the entire thing.

Cisco Troubleshooting Process:

1. Define a clear problem statement with symptoms and potential causes.
2. Gather the facts to help isolate the possible causes.
3. Consider possible problems based on the facts discovered
4. Create an action plan based on the remaining potential problems and the most likely cause.
5. Implement the action plan.
6. As changes are made, gather results.
7. Analyze the results and determine whether the problem has been resolved.
8. If the problem is not resolved, create a new action plan based on the next most likely cause and proceed with steps 5-8. Repeat until resolved or escalated.

Microsoft Troubleshooting Process:

• Phase 1: Discovery - Gather information about the problem
• Phase 2: Planning - Create a plan of action.
• Phase 3: Problem Reproduction - Reproduce the problem, or determine that you cannot reproduce it. If you cannot reproduce the problem then you might not have enough information to confirm there is a problem.
• Phase 4: Problem Isolation - Isolate the variables that relate *directly* to the problem.
• Phase 5: Analysis - Analyze your findings to determine the cause of the problem.

CompTIA Troubleshooting Methodology:

1. Identify the problem.
2. Establish a theory of probable cause. - Question the obvious.
3. Test the theory to determine cause.
4. Establish a plan of action to resolve the problem and implement the solution.
5. Verify full system functionality, and if applicable implement preventative measures.
6. Document! Findings, actions, and outcomes.