Truth & Tech

We can take certifications as IT professionals, and quickly lose a good portion of what we learned from it. It’s because we are tested on a breadth of knowledge and don’t always have a breadth of knowledge required in our respective roles. But there are usually some good takeaways that are worth trying to hold onto. I want to start sharing some of the things I’ve learned from the CompTIA A+ Certification because it’s been a while since I reviewed the material.

The CompTIA A+ Certification was one that taught me a lot. One of the main things I learned was a systematic method of troubleshooting. This was something that was so valuable to me that I wrote it out in multiple places because it was so helpful in thinking through problems. Having a systematic way of troubleshooting a problem helps ensure consistent patterns to try to resolve an issue and will help prevent further issues.

So, here are the six steps of the troubleshooting method that I learned that could be applied not only to a helpdesk role, but to a programming, security, or even network administrator role. Think through how this might help you in your current role and see if it may help you to review this from time to time. I felt like it was important enough to write a blog post on it, so hopefully it’ll be helpful to you.

1. Identify – The first step to resolving a problem is knowing what the problem is. For my role, this often involves asking probing questions of the end user that are open ended rather than closed. For other roles, end users may not be available so getting all the clues together and using those to identify what the issue really is, is important.
2. Guess – Once you know what the issue is, continue troubleshooting by guessing what all the potential causes are, and then narrowing in on the most likely culprit.
3. Test – Once you have a working theory/hypothesis, start testing the most likely guess and seeing if it makes sense. Try isolating the root cause of the problem and seeing if replacing, restarting, or bypassing the suspected cause fixes the issue. If so, you’re likely onto the problem.
4. Plan/Implement – Once you have identified the problem, you have to figure out how to plan and implement a permanent fix to the solution. This often involves identifying any purchases necessary, any potential issues that would cause down-time for other employees, and trying to figure out what additional problems may come from the intended solution.
5. Verify – Once you have gotten this far in the troubleshooting process, you have to verify that the fix you implemented leaves everything operable and hasn’t caused any additional problems. If so, you’re almost done!
6. Document – Once the issue has been fixed, most people will want to move on to the next issue. But documenting the process and what the final fix was will help in a variety of ways. Documentation provides a starting point for troubleshooting future related issues, can help train future employees, and if documented in a ticket that the end user will receive, could provide them the information to fix the problem on their own if that’s possible.

Here’s an example…

An end user’s power-over-ethernet (PoE) phone shows offline in the management console. The user is in another office when working, but is out of the office on paid time off.

1. Identify the problem: Is the problem with the actual phone, the management console, perhaps the switch that the phone is connected to or the internet connection at the branch? Check the management console for another user at that same location to see if their phone shows offline. If so, check one or two more and see if perhaps their seems to be a trend. Email another user at the branch to ask some questions or call someone’s cell phone at that branch.
2. Guess what the problem is: Once you have more info, start guessing to what the problem could be. You identify that all the phones at the branch are down. So you know that this is likely an internet issue or a switch issue.
3. Test – If it is an internet issue, getting ahold of anyone at that branch may be tough. Start by trying to call someone’s cell phone. Send an email copying multiple people at that branch and ask why phones are down. Then you can call the Internet Service Provider (ISP) or the Managed Services Provider (MSP) first to see if there is any information they can provide. If there is no indication of a problem on their end, it may be a switch issue. A manager indicates that the switch for all the PoE phones is not acting like it is getting any power to it. There are no lights turned on for it. After checking the power cord and outlet, and turning it off and on again, there are still no lights on the switch. But you know the switch is over 20 years old. The switch is likely dead.
4. Plan/Implement a Solution – Now that the problem has been identified, a plan on what switch will replace it, when it’ll get replaced, and how are all important factors. But it should also include considerations for other potential problems. Could you bring the whole network down by replacing the switch? If the switch is replaced with a lower-grade switch, will you slow down the voice traffic?
5. Verify – Once the switch has been replaced, verify that the phones are all working, but also make sure that all other internet based systems are functioning properly. Check to make sure PCs, printers, etc. are all working.
6. Document – When done, document the results of everything. Think about documenting as an exercise in presenting “just the facts” of what happened. Write from a perspective of walking through the problem with someone else, and include details as to how the hypothesis was tested, what the issue was, how it was repaired, and that everything was fixed, it could even help prevent confusion on what may have happened when a future error with the same system occurs. In this case, you would start with identifying that a single phone was done, progress to identifying multiple phones were down, talking to a branch manager, who gave permission for replacing the switch (and purchasing one if one had to be purchased), what the process was in replacing the switch, and how you verified everything was working at the end.