Net + Exam objectives

• 1. Identify the Problem


  Identification is often the easiest step.

  As troubleshooters, we want to be very careful to ensure we have identified the root cause of the error, misconfiguration or service interruption before making any changes.

  Specific steps here may include:

  • Gathering information from log files and error messages
  • Questioning users
  • Identifying symptoms
  • Determining recent changes
  • Duplicating the problem
  • Approaching multiple problems one at a time
  • Narrowing the scope of the problem
• 2. Establish a Theory of Probable Cause


  The cause is specific enough to begin troubleshooting.

  This stage may require significant research on your part. Vendor documentation, your organization’s own documentation and a good old-fashioned Google search may all be required to provide the basis for your theory.

  Specific steps here may include:

  • Questioning the obvious
  • Considering multiple approaches, including top-to-bottom or bottom-to-top for layered technologies (such as networks)
• 3. Test the Theory to Determine the Cause


  This step is also part of the “information-gathering” phase. It is not uncommon for experienced administrators to move very quickly and informally through steps one, two and three. Problems and symptoms are often familiar, making it simple to predict the likely cause of an error message or failed device.

  At this stage, you may find yourself circling all the way back to step one: Identify the problem. If you test your theory to discover the likely cause and find that you were incorrect, you may need to start your research all over again.
• Some fixes require reboots or other more significant forms of downtime.
• Changes to system's configuration may need to be tested in a staging environment before implementing the fix in production.
• Complex changes may require a series of steps, commands and scripts to be documented.
• Changes to system's configuration may put data at risk, therefore it's important to back up data before making changes.
• Changes to system's configuration may require approval from other IT staff members.
•  5. Verify Full System Functionality and Implement Preventive Measures


  When possible, have the users that rely on the system test functionality for you. They are the ones that really know how the system is supposed to act and they can ensure that it responds to their specific requirements.

  Depending on the problem, you may need to apply the fix to multiple servers or other devices.
• Documentation is a pet peeve of mine, coming from working as a network administrator for an organization with zero documentation.
• Documentation can be useful in the future when a similar problem arises or when the same problem turns out not to have been fixed after all.
• Documentation is also useful in communicating to others what you have tried so far.
• The first thing the tech said was, “What have you tried so far?” I had a three-page list of things we didn’t need to try again.
• Documentation is useful in case your changes had unintended consequences, as it makes it easier to reverse your changes or change configurations.
• Troubleshooting Methodology

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