View Blog

This tip is a blast from the past, but I've re-tooled it for today, because this has been on my mind again recently.

But we all have troubles with computers. That's our job. But if you can follow these simple suggestions, you can troubleshoot yourself out of just about any computer problem Group Policy or otherwise.

So, let’s dig in and talk about the Zen of Enterprise Computer Troubleshooting.

First thing’s first: duplicate it.

Having one machine, in isolation does NOT a big problem make.

It FEELS like a big problem when Sally’s machine isn’t processing GPOs, or when my own laptop refuses to run Application XYZ today, but it did yesterday.

It’s frustrating, and infuriating, annoying, and .. well… that’s not the point.

The point is, my friend, it’s an "isolated issue." And honestly, isolated issues are just that. Isolated.

Until you can get another machine to do exactly the same thing, you really have no problem to troubleshoot at all, enterprise speaking.

Your problem feels big. But, honestly, until you can duplicate it, it’s shaky grounds for troubleshooting.

If the problem is in virtual world, like VMware, or HyperV, try to reproduce it in the physical world just to rule that out. Weird stuff can live inside those virtual worlds sometimes.

Second thing: Log Files — The application log and Windows Logs and the applications log

Next, let’s not forget about log files.

Many areas of the computer have various logging levels. When it comes to troubleshooting, 8 out of 10 times, I just lose my brain and forget to check the most obvious of places: the logfiles !

Start out by checking Windows Application and System logs. An application may quietly write the secret answer to your problem in those logs, and bingo.. problem solved.

Logs help you keep your sanity, because you can prove to yourself, after 20 hours of working on something (and you’re starting to see flying purple elephants)… that the thing  you think you’re seeing is something you’re actually seeing.

Many applications, themselves, have log files. Digging into those can sometimes be key gateway to figuring out what the problem is.

 

Third Thing: Shoot a video of the problem

If you're trying to reproduce a problem that you can't easily produce, use Camtasia or some other screen capture utility to actually watch yourself reproduce the problem. This is the ultimate tool to prove to the developer (or the boss) there really is a problem here.

It could get you a quicker repair, more time to troubleshoot, or the funding you need to take your problem to the next level.

In a recent case for me, I saw the problem.. got it on video .. then was never able to reproduce it again.

Having it on video was awesome to have, because at least I knew I wasn't crazy. After hours of trying to reproduce the issue again, at least I had something to prove I did get the problem to fire off one time. Closer inspection of the video (the next day) showed I had a different networking connection the first time, versus all the next times.

And.. Bingo. That was my problem.

 

Forth thing: Ask for help

Googling / Binging / Technetting for a solution can only take you so far. Don’t be afraid to ask a college or trusted friend for help, look over your shoulder, or help in troubleshoot. That's a good way to show someone what you've done so far and what did and didn't work.

(PS: This shouldn’t be blanket permission for everyone to just email me when they’re having their own personal Group Policy struggles.. For that we have the community forum at GPanwers.com, okay? ?

Additionally, give that "helper friend" permission to suggest WILD IDEAS. You’ve already thought of all the easy stuff. Now give them permission to "go a little crazy" and suggest some off the beaten path solutions to your problems.  In short, I’m saying to leverage the resources you have. I have my own "inner circle" to leverage when I need help, and you should foster yours. Know where to post and request help for issues when you need help, and learn the kinds of responses you can get from those systems.

Fifth thing: Learn to Give up.

Here’s something about me that you may not know. I do yoga.

I’m no "yoga superman" or anything. I’m 6 ft 2 and weigh, well, more than I should.

But the point is, that I really love it. And why? Well, beyond the health reasons, there’s  something more.

I get to understand my own limitations. Instead of stretching my body to a stupid level — where I might grab my legs behind my ears and actually hurt myself– I know to "give up" and do something else more productive during that time.
Even if I’m little embarrassed that the WHOLE CLASS can do the stretch (whatever it is), and I can’t – I don’t care. I try to put that whole "pride thing" behind me and learn to acknowledge my own abilities. Why? Because I’m 6 ft 2 "big guy", and not 5 ft 3 "Yoga gal." We’re going to have different limitations. I can’t stretch like she can, and she can’t lift two 5 gallon water bottles into her house up two flights of stairs at the same time.

Why bring this up now? Because after you’ve done all the proper troubleshooting you can, and after you’ve asked all the people in your inner circle, and after you’ve hit the books, and after you’ve Googled / Binged your brains out… it’s time to give up.

 

Learn to GIVE UP.

 

But learn to give up in the right way. Microsoft product support (PSS) is there for you to troubleshoot your Microsoft related stuff.

Heck, you might have free support incidents as part of a Microsfot Technet Plus subscription or other channel.

The point of all of our jobs, at its core is to SOLVE PROBLEMS with the TOOLS WE CHOOSE.

I can swing a hammer only so much before I need to call in a carpenter and show me what

I’m doing wrong.

It doesn’t help our companies or our personal sanity to keep swinging the hammer only to find we really needed a screwdriver and a blowtorch and a lesson in how to use those tools in the first place.

Not to get all "touchy feely" here, but there is a point we all need to find it within ourselves where we say: "I’ve done all we can. It’s worth X dollars in value to me to get the answers I need to continue being effective."

So I do personally call Microsoft Product Support Services when I'm at the end of my rope.  They do an AMAZING job and will not close the support call until YOU are satisfied the problem has been solved. I love that.

 

How does this tie in to Group Policy Troubleshooting?

I want you to think of the above steps as overall advice, and not specifically for Group Policy.

As for Group Policy troubleshooting, or troubleshooting in general, my (recapped) suggestions are to:

• Validate your findings on another machine. Just one machine in isolation does not a "problem" make (even if you’re tempted to feel that way.)
• Try similar and dissimilar machines. If the problem is happening on XP, does it happen with Windows 7 too? Vice / Versa?
• Have you been able to take screenshots or videos to share with others?
• Have you asked someone on your "inner circle" to look over your shoulder to make sure you didn’t just make a bone-headed mistake?
• Have you enabled all the logs you can? In GP, for instance, there’s at least three Windows event logs and also some auxiliary logs for "GP-related" functions like MSI packages, etc.

Of course in my class, you'll learn incredibly practical tips on troubleshooting Group Policy specifically, with precise step-by-steps using what I've learned over the years.

That will help you get out of hot water faster and back in business usually the same day.

See you in class.. !