Troubleshooting from the Bottom Up

On the Windows NT exams, the most difficult questions are generally the ones that involve troubleshooting. Troubleshooting questions describe a problem and ask you to pick the solution. In some cases, the elimination strategy I detailed a few issues ago works well, especially when I'm not completely sure of the answer but know enough to determine which answers are obviously wrong. For other such questions—for example, those that ask whether a proposed solution meets a required objective and two or more secondary objectives—I usually do better when I keep a checklist to track which objectives have been met and which haven't. Either way, troubleshooting questions seem to require the most time and thought.

On the Windows 2000 and some MCSE elective exams—specifically the SQL Server 7.0 exams—Microsoft turns more often to troubleshooting questions. The difference, however, is that these questions require that you know more about a wider range of topics. In Question 3 of this week's Certifiable column, for example, you need to know all the things that a client does to acquire an IP address when it boots up, as well as how IP routing works.

Microsoft is posing these advanced troubleshooting questions more often to make your exam preparation more difficult—you can't simply memorize facts and hope to pass. Last week, a friend commented that you can't really study for the SQL Server 7.0 exams without using the product. Microsoft has written the questions in a way that rewards experience, not memorization. I like this approach because, as a result, passing an exam indicates what you can do with a product, not what you have read about it.

That said, there are strategies that help you troubleshoot problems in real life that you can also use to help improve your odds on exam questions. One such strategy is what I call "troubleshooting from the bottom up," and it applies to troubleshooting network problems.

If you haven't looked at the Open System Interconnection (OSI) model in a while, take a look at it again now. If you have a book or a course that shows how Microsoft's networking stack applies to the OSI model, take a look at that as well. (Click here for an illustration that shows how NT's network architecture maps to the OSI layers.)

Reviewing the OSI model and the network architecture should remind you that a problem at a lower layer prevents the upper layers from working properly. When I have a connectivity problem on a client computer, my first troubleshooting step is to check the network cable. This step translates into verifying that the bottom two layers of the OSI model are working. My next step is to run ipconfig /all to see the network settings. If I don't see a valid IP address, I know there's a problem in the IP layer. Next, I ping the loopback address (127.0.0.1) and then ping an IP address of a computer on the local subnet. These two tests verify that the code for the network stack loaded and that the IP layer works. You can go on from here on your own, but just recognize that you're really testing the network from the bottom of the OSI model to the top—troubleshooting from the bottom up.

This strategy applies to network troubleshooting exam questions too. As you work through a question, visualize the network stack and take note of the pieces of information you would need to make everything work from bottom to top. When you find a layer that has incomplete or wrong information, you've usually found the source of the problem. You can then look back through the symptoms to see whether it's reasonable for them to occur given the problem you've identified. If it is, you probably have your answer.

With computers, a methodical strategy works best. As you gain exam experience, develop your own strategies for preparing for different types of questions.