Daily Archives: June 30, 2010

MCITP, mcitp certification, MCITP Training, MCSE, MCSE Certification, MCSE Training, Microsoft, Uncategorized, Windows 7

TEC 2010 and the Wook Lee Challenge

Leave a comment

TEC 2010 and the Wook Lee Challenge
One of the TEC conference’s unique traditions is the annual Wook Lee Memorial MVP Pro-Am Challenge. I’ve provided some background about it before. The Challenge is a unique combination of left-brain and right brain activity, with about 24 hours to put it together and present it. It’s always fun to work with a typically high-powered brain trust engaged in creative yet geeky activities. This year Stewart Kwan was unable to make it (though we hope that will change next year), so Gil Kirkpatrick provided the Challenge – and thus neatly sidestepped getting himself involved in such shenanigans MCTS Training.

Challenge #1, assigned to Pamela Dingle, was to “Compose and recite haiku regarding claims-based authentication, federation, and PKI.” Here’s the Powerpoint slide show we cooked up in response. (Should you feel an overwhelming desire to have one of these on your desk as an inspirational poster, a PDF is available here.)

Challenge #2, assigned to Laura Hunter, was to write and perform a short play regarding an Active Directory forest melt down and recovery. Due to time pressures (she had actual real presentations to work on – go figure) Laura opted to write two sonnets instead. (You really need to see her performing them to get the full effect, and we’re working on that.)

Challenge #3, assigned to Brad Turner, was to simulate the function of the Forefront Identity Manager (FIM) sync engine using cardboard, duct tape, and string. Brad and his team did a great job; you definitely need to see the video when it becomes available to appreciate the degree of silliness these otherwise responsible adults engaged in. I’m sure it will become a mainstay of the FIM instructional curriculum MCITP Certification.

MCITP, mcitp certification, MCITP Training, MCSE, MCSE Certification, MCSE Training, Microsoft, Uncategorized, Windows 7

Why AD Replication Troubleshooting Is Hard

Leave a comment

Why AD Replication Troubleshooting Is Hard
A couple of weeks ago at TEC 2010, I gave a session called Active Directory Replication Troubleshooting. Rather than just demonstrate a bunch of REPADMIN tricks (which I’ll certainly do here!), I focused on what I think are the core reasons IT pros have a difficult time troubleshooting replication problems. Half of them don’t have anything to do with replication.

The way I see it, there are four main reasons why troubleshooting AD in general, and AD replication in particular, is difficult:

* You aren’t really trained in a formal troubleshooting methodology.
* You don’t approach the problem logically and rigorously.
* You don’t really understand how replication works.
* You don’t understand how the tools work.

How much each of these applies to you depends on your background and your job. If you come from the scientific or engineering fields before you were an AD admin, you may be pretty good on the first two. If you’re a full time AD admin for a big company, or a hotshot AD consultant, you’re probably pretty good on the last two. But very few of us are good at all four. And you need all of them to be good at the really tough AD problems. Let’s take a look at the first point MCTS Training.

You aren’t really trained in a formal troubleshooting methodology. Most of us learned how to troubleshoot from our coworkers that were already working in our area. My undergraduate degree was in Electrical Engineering (though I can barely screw in a light bulb now), so I had developed a fair amount of rigor. But in my experience, IT pros aren’t consciously aware of following a formal methodology. Fortunately, there’s a good one lying around for you to simplify and use – the scientific method. Here’s a boiled-down version:

1. Use Your Experience. For example, a DC can’t communicate with its partners. Have you seen this before? Does this fit in a framework? What does the problem “smell like”?
2. Form a conjecture. Could a network firewall rule have changed?
3. Deduce a prediction from that explanation. Some, or all, connectivity will be lost between the DC and systems outside (but not inside) the firewall.
4. Test. Use ping and tracert to map out the connectivity.

This may sound overly simplistic, but what I’m trying to point out is that most troubleshooters aren’t actively aware of using a method. When you’re working through a complex problem, instinct will only take you so far; you need to consciously use a troubleshooting methodology MCITP Certification.

Next time I’ll lay out my favorite troubleshooting principles that fit into this methodology.