Like This Blog 3

Added by Mike Danseglio November 5, 2012

Like many IT professionals, I did my time in technical support. In call centers, in data centers, in corporate IT, and as a consultant, I spent lots of time chasing down and resolving computer problems. I got my start working in Microsoft’s Product Support Services (PSS) troubleshooting early versions of Windows and Microsoft Word for MS-DOS, Windows, and OS/2.

Whenever I approached a problem, be it on a support call, in person, via email, or even BBS message, I followed a simple and straightforward methodology. This article shows the way this methodology works and how it functions as a troubleshooting framework for almost any computer problem.

The best methodologies are simple, flexible, and work towards a goal. The methodology I use is all of those things, and is summed up with one diagram.

Figure 1. MikeDan’s Quick and Dirty Troubleshooting Methodology.

Here’s a summary of the three steps. Subsequent articles will explore each in depth.

Identify the Symptom
What’s really happening? Vague symptoms like, “The server is slow” or “The Internet is broken” aren’t really useful. But they are a common starting place. Narrowing down specific symptoms like error messages, affected systems and applications, or time of day helps move to the next step.

Determine the Cause
What’s causing the symptom to occur? This step is often overlooked when IT professionals just jump right from “The server is slow” to “Reboot and defrag it.” I never just randomly reboot a computer or purge the Internet Explorer cache, because those “fixes” are just random steps that may temporarily alleviate the symptoms. Finding the root cause of the symptom is the only way to actually resolve the issue permanently.

Plan, Implement, and Verify the Resolution
Once the actual root cause is found, I can figure out how to fix it. From a minor software update to a complete system rebuild, I always at least write a quick plan to follow. Then I step back for a moment and consider whether this plan will address the root cause and therefore resolve the symptom. If so, I implement the plan and then verify that the symptom is gone.

Conclusion
Take a look at this methodology and how it can be used as a framework for virtually any troubleshooting effort. This is the best one I’ve used because it is a simple, effective, and flexible methodology for finding and fixing Windows issues.

Stay tuned for future articles on symptom identification and enumeration, root cause analysis, and creating, testing, implementing, and verifying a resolution.

Mike Danseglio -CISSP
Interface Technical Training – Technical Director and Instructor