Connectivity problems can be frustrating for both the user and the help desk staff. The user can't do his job until the problem is fixed, and the already overburdened help desk staff must take time out from whatever they are doing to help the user. In order to help expedite the diagnostic and repair process, Microsoft has created a new component called the Network Diagnostics Framework and included it in Windows Vista. In this article, I explain what the Network Diagnostics Framework is and what it does -- as well as addressing its shortcomings.
Before showing you Vista's Network Diagnostics Framework, I want to point out that Windows XP also had some self-help features that users could employ when network problems occurred. To access the self-help features, a user simply had to right-click on the malfunctioning network connection, then select the "Repair" command from the resulting shortcut menu, as shown in Figure A.
Figure A
You can repair a network connection in Windows XP by right-clicking on the connection and choosing the "Repair" command from the resulting shortcut menu.
Although this technique looks simple, there are two main problems with it. The first is that the "Repair" command is geared toward end users. I have yet to see a seasoned IT professional use this command. There is nothing wrong with creating a self-help feature for the users, but they may never even know this option is available to them. After all, how many of your users know how to get to the "Network Connection" screen?
The other problem that I have with the Windows XP repair feature is that it is so simplistic. If you choose the repair option, Windows presumably performs a few tasks in the background, but it never actually tells you what it is doing or gives you a chance to interact with the operating system. Instead, when the process completes, you simply see a message similar to the one shown in Figure B.
Figure B
Windows XP displays this message after supposedly repairing the network connection.
When creating Windows Vista, Microsoft decided to do things a little bit differently. The new approach involved creating something called the Network Diagnostics Framework. The basic idea behind the Network Diagnostics Framework is that the troubleshooting process can be context-sensitive. By looking at the situation in which the problem occurred, Windows can provide information about the circumstances that led to the problem. From there, Windows can run the appropriate tests and display information that helps users help themselves.
For example, suppose a network problem is preventing a user from browsing the Internet. In Windows XP, Internet Explorer would simply display an error message stating that "the page cannot be displayed," or something similar. In Windows Vista, Internet Explorer will display the error message, but it will also ask users whether they want to diagnose the problem, as shown in Figure C.
Figure C
Internet Explorer asks users whether they would like to diagnose the problem.
In this particular example, I just happened to be using Internet Explorer. The Network Diagnostics Framework is designed to function across the entire operating system. Users may therefore receive diagnostic prompts in any number of situations, not just when using Internet Explorer.
In this case, I simply unplugged my computer's network cable to simulate a connectivity problem. I then told Internet Explorer I wanted to diagnose a problem. Upon doing so, Windows spent a couple of minutes analyzing the system and then displayed the dialog box shown in Figure D. As you can see in the figure, the Network Diagnostics Framework produced a prompt telling me that I needed to plug a cable into the network adapter.
Figure D
The Network Diagnostics Framework produces a prompt telling me that I need to plug a cable into the network adapter.
At first glance, it seems that the Network Diagnostics Framework is an answer to prayers. Unfortunately, it simply does not work as well as it initially appears to do. In researching this article, I spent a considerable amount of time simulating various types of network problems in an effort to see whether the Network Diagnostics Framework would diagnose the problems correctly. Although I halfway expected to have problems with the more difficult problems, I was stunned by the fact that the Network Diagnostics Framework often misdiagnosed even simple problems.
One example of this is that I changed my computer's TCP/IP configuration so that the preferred DNS server setting was pointing to a nonexistent server. Rather than telling me that my DNS settings were incorrect or that there was a communications problem with the DNS server, Network Diagnostics Framework sent an error message telling me that my firewall settings were incorrect, as shown in Figure E.
Figure E
The Network Diagnostics Framework incorrectly diagnosed a DNS issue as being a firewall problem.
At first, I thought that Windows perhaps assumed a firewall problem was to blame because I had pointed the operating system toward a nonexistent server. That being the case, I changed my TCP/IP configuration so that the settings for my preferred DNS server pointed to a server on my network that was configured correctly but was not running DNS services. After doing so, I continued to receive the same error message.
Conclusion
In my opinion, the Network Diagnostics Framework is a step in the right direction for Microsoft. For the most part, I find it irrelevant for IT professionals because conventional network troubleshooting techniques tend to yield superior results. Although users lacking networking knowledge may in some cases benefit from the Network Diagnostics Framework, I would tend not to recommend its use for the simple reason that it often produces an incorrect diagnosis.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.
