Before we get started, I must stress that this is my process. I’ve spent over 10 years troubleshooting network and desktop issues both software and hardware. And without further adieu.
Step 1: Verify the Problem (Trust but Verify)
This may be common sense for some and for some maybe not. A user calls in with “Our Internet is down” or my personal favorite “There’s something wrong with this computer, I think it’s broken” may very well end up being they forgot their password or they don’t know how to locate a particular file. Yes, that happens.
This is why my first step is always, to see the issue for myself. Usually through a remote session if off-site or just a quick glance over the shoulder. Have the user recreate the problem. Through the step, you can either do one of three things. You can get some sort of error code or behavior and continue on to step two, or you can immediately correct the issue if it’s just a user knowledge issue (training helps combat this!), or if the user can’t seem to reproduce the problem you can chalk up to a fluke.
For the sake of this article, let’s say that this the user actually did have a legitimate error. Let’s say it was in Office 2010 and the error was a “Operation Failed” error. Something like this:
Step 2: Research The Problem
I recently received a ticket with this exact error but due to the way the ticket came in, through two other people I didn’t get to see the exact error message. It’s important to point out that no matter what stage a ticket comes in, you must always start at Step 1. Without knowning exactly what you’re looking for, you’ve just lowered your chances of resolving the issue greatly. Don’t blindly shoot into the air. Take aim, breath and pull the trigger.
Now, back to our error message. What makes this error unique? Is it the “The operation failed”? Nope, try again. Is the the “Microsoft Exchange”, nope again. It’s the error code: “0x8004010F”. To the average person, this doesn’t mean dittily. Hell, to me it doesn’t mean squat either. Ah but to Google, it gives a specfic search term. Before I go over to Google though, it’s important to note that most all of Microsoft’s products produce errors like this when it is a software error. This will also give you a base to start from. This is also why it’s SO important to start at Step 1 and get that error code!
Judging from our Google results, this is fairly common issue amongst the world so Microsoft has written up a knowledge base article on it Google has given us that as our first result. As the article states, this particular problem tends to come from a corrupt Outlook profile. If you’ve spent any time doing tech work, you probably see this at least once or twice a week. So we now have our first potential resolution to the problem. Let’s move onto Step 3.
Step 3: Implement the Potential Fix
As we found in Step 2, we now have a potential fix for the reported and verified issue from Step 1. This potential fix comes from Microsoft in the form of a knowledge base article. It’s worth pointing out here that not all fixes will come from Microsoft. They may come from a community forum or a random person’s blog, it’s up to you to match the symptoms you’ve observed as closely as you can to what the fix is attempting to resolve. The closer the better. I can’t count how many times I ran across a solution to an obscure problem on another sysadmin/tech’s blog. If you are going this route however, judge the site before you go implementing fixes. If anything on the site looks like spam or junk, it’s probably best to move on. Not all fixes are created equal.
I want to also mention that there is a difference in a workaround and a fix. A workaround simply gets the job done but possibly not the intended or best way. A fix addresses a bug in the software and should always be the recommended method. Never implement a workaround AS a fix!
Now, back to our knowledge base (KB) article from Microsoft. Love them or hate them, Microsoft should be considered a reputable source though I’ll admit that their KB articles do not always solve the issues, the issue just may be exhibiting similar symptoms. In our potential fix, it states to recreate the Outlook profile.
Let’s say that we’ve just completed that and the problem seems to be resolved for the user. But what if that didn’t resolve the issue? Don’t lose heart, simply start back at Step 2 and research more. If you feel that you’ve come to a dead end, go back to Step 1 and generate more data. See if you can get another error code. Remember to check the logs (Event Viewer) as well. Often times these errors will be logged there with some additional information either before or after this particular error.
Step 4: Let the User Verify
When I resolve a problem for a user, I ALWAYS let them verify the fix. This accomplishes a couple of items that are important to me. First, it allows to user to see that we actually fixed the issue. I’ve had several techs go out and resolve tickets for people without verifying with the user to only have that user call back and ask why no one has came out to resolve the problem.
Secondly, this allows the user and the tech to see if there are any other issues that might pop up after that initial resolution. I’ve fixed a few issues that just generated another one for the user. It’s important to the user to accomplish whatever task they’re on without issue. It’s even more frustrating for them to have an issue, have the issue fixed and then have to call again for a different issue that still is prohibiting them from completeing their task.
Lastly, some users are interesting in how you actually resolved their issue. Believe it or not, some users just want to fix it themselves and personally, I have no issues with this. If the user knows how to resolve it next time, it frees me up to do more important things. Though, let me warn you that most users really shouldn’t be poking around in the registry or trying to recreate an Outlook profile. Use your own judgement on this.
Step 5: Document your fix
If I’ve learned anything throughout my time a tech, it is to document how I resolve an issue. Even though you think you may never see the issue again, you just never know. It’s better to have it documented than to have to research and implemented incorrect fixes all over again. If nothing else, use something like DokuWiki or even better a ticketing system to keep track. Most importantly, make sure it’s searchable.
So that it, that’s my secret formula to troubleshooting.