Basic Troubleshooting 101
- Dont’t assume you understand the problem based on the users description. However document and attempt to understand what they are saying:
- Document the symptom(s)
- Document when did it first occur, has it occured before, who does it affect, what is all affected, what have you already tried to resolve it, can you make it occur again?
- Watch the user make the problem happen (this will help you reproduce the problem to test your resolution, it also provides the opportunity to observe operator error)
- From a reboot state, you try to reproduce the problem
- Collect auxillary data from the system:
- Application error messages, error logs, window event viewer, etc.
- Check for application/vendor logs, as well as hidden logs
- Evaluate other external sources which may be interfeering
- Attempt to determine the cause of the problem.
- Document newly discovered, relevant information, including source and symptoms
- Consult resources – technet, web, other staff, vendor resources
- Plan to isolate problem using the half-way method
- Make one change at a time. Be sure to reboot systems as necessary. Many appliciations do not appear to need this step, but many times in troubleshooting this will help.
- Determine a reasonable amount of time an issue should be resolved in, and then escalate as necessary
The last step is perhaps the most critical step, and while all are very important, failure to realize when you’re in over your head is essential. And while the inner “geek” in most IT people push them to figure it out on their own, many times the right choice is to escalate the issue. This may be escalating to a higher skilled technician, contacting the vendors fee-based technical support, or contacting a third party IT firm. Of course, it would be in your best interet to try and glean as much information from the next person in line and advance your own skills.