After you’ve installed Windows 2000 Support Tools, chances are good that you’ve experimented with the Network Connectivity Tester (Netdiag.exe) and discovered that it can be an extremely useful troubleshooting tool. The Network Connectivity Tester gives you a set of 25 individual tests that you can use to isolate networking and connectivity problems. Unfortunately, the Network Connectivity Tester runs from the command line, which means that reaping the benefits this tool provides can be very time-consuming and frustrating; it involves a lot of typing, it’s difficult to keep track of results, and you can develop severe eyestrain from staring at a Command Prompt window for long periods.
I’ve discovered a way to simplify the use of the Network Connectivity Tester and bring it into the GUI interface by automating it with Windows Script Host and VBScript. I’ll show you how to create a straightforward VBScript that will automate the Network Connectivity Tester and make it much easier to use. I’ll also give you some basic information on Windows 2000’s Network Connectivity Tester.
This script is specifically designed for Windows 2000. It won’t run in Windows XP because this new operating system has a new and improved version of the Network Connectivity Tester, which is now called Network Diagnostics. For more information, see the article ”Use Windows XP Pro's Network Diagnostics tool for comprehensive troubleshooting.”
When Microsoft released Windows 2000 SP2, it also released an SP2 update of the Support Tools. Only a few of the Support Tools were updated; the Network Connectivity Tester was one of them. Begin by downloading and installing the Windows 2000 SP2 Support Tools update. If you have the original Support Tools installed on your Windows 2000 system, download the Windows 2000 SP2 Support Tools Patch. If you've never installed the original Support Tools, but have installed Windows 2000 SP2, you need to download the full Windows 2000 SP2 Support Tools package.
To reliably run this script on a Windows 2000 system, you should also download and install the Windows Script Host 5.6 package. This new version was introduced with Windows XP, but is available for Windows 2000.
You can download the Windows Script Host 5.6 package from the Microsoft Windows Script section of the MSDN site. Scroll down the tree in the left pane until you see the Windows Script 5.6 section. The Windows Script 5.6 package includes Windows Script Host 5.6, VBScript 5.6, JScript 5.6, the Windows Script Components, and the Windows Script Runtime. Note that there are two versions of the Windows Script Host 5.6 package: one for Windows 2000 and one for Windows 95/98/Me/NT. Make sure that you download the Windows 2000 version.
Breaking down the Network Connectivity Tester
Using Windows 2000’s Network Connectivity Tester involves deciding which options you want to invoke and then providing the appropriate switches and parameters on the command line. After studying the switches and how they’re applied, I discovered that using the Network Connectivity Tester could be broken down into four distinct steps. Before we move on to the script, let’s take a closer look at the four steps to using the Network Connectivity Tester. Doing so now will help you to understand the basic outline of the script.
Select a test scheme
The first step in using the Network Connectivity Tester is to decide which test scheme you want to run—you can run the Network Connectivity Tester in three ways. First, you can have the utility run all of its tests—the default method of operation. Second, you can choose to only run specific tests. Or, third, you can choose to skip specific tests.
Select report detail
The second step is to decide on the amount of detail that you want in the report. When you run the Network Connectivity Tester, it will by default create a basic report that lists the results of each test. You can reduce the amount of detail by configuring the Network Connectivity Tester to only show error messages. You can increase the amount of detail by choosing verbose mode, which provides you with even more detail than the default report. If you want a really detailed report, you can choose the extremely verbose mode.
Select special options
The third step is to decide whether you want to use any of its three special options. You can use two of them to obtain additional information for troubleshooting connectivity problems; the first special option allows you to locate a domain controller and the second allows you to enumerate domain controller computer accounts. You can use the third to automatically fix minor problems.
Select tests to run or skip
The fourth step is optional and will depend on what choice you made in the first step. If you chose to have the utility run all the tests, you’ll bypass the fourth step altogether. If you decided that you only want to run specific tests or to skip specific tests, you’ll need to specify exactly which tests you want to run. You can choose from 24 specific tests to run and 21 specific tests you can skip.
Once I discovered that using the Network Connectivity Tester could be broken down into four distinct steps, I decided to implement this script using a wizard format, with each step appearing on its own page. The script emulates a wizard to prompt you to choose which options you want to use to run the Network Connectivity Tester. As the wizard progresses, the script will save your selections.
As you know, the Network Connectivity Tester is a command-line utility for which the executable file is Netdiag.exe. After the wizard portion of the script prompts you to make selections on how you want the Network Connectivity Tester to run, the next portion of the script shells out to a Command Prompt and launches the executable file along with the options that you’ve chosen.
Once the Network Connectivity Tester runs, the script will create a custom header and append it to the report that the utility automatically generates. The header will contain the exact date and time that the test was run and give you the contents of the command line, including all switches and parameters. This will make it easy for you to tell at a glance exactly when the tests were run and which tests were run, and identify the results contained in the report.
To create the pages in the Network Connectivity Tester Wizard script, I employed the DialogBox function technique that I described in great detail in this series of articles:
”Create your own reusable dialog box for Windows Script Host”
”Design Windows Script Host dialog boxes for any occasion”
”All together now: Four dialog box function controls in one easy script”
”Take your pick: These three script dialog boxes make it easy to interact”
Creating the wizard pages
The DialogBox function is designed to work as an intermediary between two other files. The main file is a Windows Script File, which will incorporate the stand-alone DialogBox function as an include file. The script commands in the Windows Script File will then be able to access the DialogBox function as if it were a native VBScript function.
Just like many native VBScript functions, the DialogBox function requires a set of parameters to be sent to it. These parameters will essentially tell the DialogBox function how big to make the dialog box and what to put in it. The name of an HTML document which contains information on what to put in the dialog box will be passed to the DialogBox function as one of the parameters.
Since the DialogBox function, which is contained in the FdialogBox.vbs file, is designed to be universally reusable, it doesn’t need to be altered in any way to be used for Network Connectivity Tester Wizard script. I won’t cover the FdialogBox.vbs file in any detail here and will refer you to the detailed description in the TechProGuild articles listed above.
As I mentioned, I broke down the use of the Network Connectivity Tester into four steps and implemented it as a wizard. This script uses five HTML documents, one for each page in the wizard. Keep in mind that the fourth step involves choosing either a set of tests to run or a set of tests to skip, so there are actually two pages for the fourth step.
Each one of these pages uses the same basic format as the example files described in the articles listed above. The only difference is the information contained in each dialog box and the order and organization of the form tags used to create the controls. Since these files are very straightforward and don’t introduce any new techniques, I won’t cover them in any detail here and will again refer you to the previous articles for more detailed information. I will include screenshots of each page when I describe the operation of the Network Connectivity Tester.
The FdialogBox.vbs and the five HTML documents—NetConWiz-1.htm through NetConWiz-4b.htm—are included in the download.
Creating the Windows Script file
The main file for the Network Connectivity Tester Wizard script is a Windows Script File called NetConWiz.wsf, shown in Listing A. As I go over this script, I’ll bypass or briefly describe the standard scripting techniques I’ve covered before and focus on the scripting components that pertain to this technique.
As you can see, this script is quite long—161 lines. To make it easy to keep track of each distinct phase of the script, I compartmentalized the script into the main routine and 11 subroutines. If typing in lines of code isn’t your cup of tea, don’t worry; the NetConWiz.wsf script is available for download. To download this script, along with the other six files mentioned earlier, click here.
Right off the bat, you’ll notice that Lines 1 through 5 contain a strange set of commands. As you may remember from the article ”Uniting the VBScript and JScript scripting languages with Windows Script Files,” a Windows Script File is basically an XML document that contains a script. The main benefit of using a Windows Script File is that it allows you to incorporate the stand-alone function as an include file, which is done in line 4. You’ll also notice that the last three lines in the file contain the closing XML commands. Lines 6 through 9 handle the standard scripting task of initializing the variables that will be used throughout the script. Lines 10 through 12 initiate the object variables.
The Main Routine
The Main Routine consists of lines 13 through 24. As you can see, this section begins by setting the Cancel flag variable to False, which will be used throughout the script to indicate a situation when you click the Cancel button in the dialog box. Lines 15 through 18 basically run the wizard portion of the script by using the Call statements to sequentially launch the subroutines that create each individual dialog box. Once the wizard completes, lines 19 and 20 close the dialog box and reset the IEDbx object variable. Then, lines 21 and 22 use Call statements to launch the subroutines that run the actual executable and then compile the report.
The WizScreen1 subroutine creates the first page of the Network Connectivity Tester Wizard, which corresponds to the test selection scheme step described earlier. To do so, it assigns the DbxFile variable to the name of the HTML file containing the dialog box controls for the first page. Line 27 uses a Call statement to transfer control of the script to the DialogBox function along with the list of required parameters. These parameters include the dimensions for the dialog box, the Cancel flag, and the DbxFile variable.
Line 28 uses a Call statement to launch the CheckCancel subroutine, which simply checks to see if you clicked the Cancel button rather than the Next button. If you did click the Cancel button, the script terminates. If you selected some options and clicked the Next button, the script continues.
Lines 29 through 35 use a For…Next looping structure to cycle through each option presented in the dialog box and determine which one was selected. In the case of WizScreen1 subroutine, the script cycles through a set of radio buttons that indicate which type of test you selected and then assigns the result to the TestType variable.
The WizScreen2 subroutine is almost identical to the previous subroutine, but creates the second page of the Network Connectivity Tester Wizard. This page corresponds to the report detail selection step described earlier. In the case of WizScreen2 subroutine, the script cycles through a set of radio buttons that indicate which type of report you selected and then assigns the result to the OutTyp variable.
The WizScreen3 subroutine is also nearly identical to the previous subroutine, and creates the third page of the Network Connectivity Tester Wizard. This page corresponds to the special options selection step described earlier. In the case of WizScreen3 subroutine, the script cycles through a set of check boxes that indicate which special options you selected. It then assigns the result to the SpcOpt variable.
Since it’s possible that you might not select any of the check boxes or might select multiple check boxes, this variable is initially set to an empty string value in line 57. I then use a concatenation technique in line 61 to build a string variable that could potentially hold several of the Network Connectivity Tester’s switches.
This subroutine also contains a text box that allows you to enter a specific domain name. If you were to select the corresponding check box, but forget to include the domain name, an error would occur. To prevent such an error, the script calls the CheckSelect subroutine, whose job is to check for the domain name. If no domain name was provided, an error message is displayed and the script terminates. If you correctly selected some check boxes or left all the check boxes blank and clicked the Next button, the script continues.
The WizScreen4 subroutine corresponds to the select tests to run or skip step and analyzes the contents of the TestType variable to determine which type of test you selected. To perform this analysis, the script uses a Select Case statement.
If you chose to run all the tests, this subroutine ends and the script then runs the Network Connectivity Tester. If you chose to run specific tests or to skip specific tests, this subroutine will call the appropriate subroutine to handle that operation.
The RunSelect subroutine will create a dialog box that contains 24 check boxes—one for each of the specific tests that the Network Connectivity Tester allows you to individually run. The script cycles through the set of check boxes that indicate which tests you selected. It then uses the concatenation technique to assign the result to the RunTest variable.
If you were to get to this page in the wizard, but fail to select any check boxes, an error would occur. To prevent such an error, the script calls the CheckSelect subroutine, whose job is to check for at least one selected check box. If none of the check boxes are selected, an error message is displayed and the script terminates. If you selected some check boxes and clicked the Next button, the script continues.
The SkipSelect subroutine will create a dialog box that contains 21 check boxes—one for each of the specific tests that the Network Connectivity Tester allows you to individually skip. The script cycles through the set of check boxes that indicate which tests you selected. It then uses the concatenation technique to assign the result to the SkipTest variable. The SkipSelect subroutine also calls the CheckSelect subroutine to avoid a possible error condition.
The RunTests subroutine uses the Run method to shell out to a Command Prompt window via the Cmd.exe /c command. Here, Cmd.exe starts a Command Prompt session and the /c parameter configures the command interpreter to carry out the commands that follow it and then exit. In this case, the command line that follows it is:
NetDiag.exe & OutTyp & SpcOpt & RunTest & SkipTest
This command line launches the executable file along with the switches and parameters stored in the appropriate variables. Again, the command line is assembled via a concatenation technique. If any of the variables are empty due to the fact that you didn’t choose the corresponding options, the variable will simply be skipped and the command will run as it is supposed to.
The CreateReport subroutine begins by calling the CreateHeader subroutine which, as I describer earlier, will create a report header that contains the exact date and time that the test was run as well as give you the contents of the command line. Once the header file, Header.txt, is created, the script again shells out to a Command Prompt and uses the Copy command to append the Header.txt file to the beginning of the default report file, which is named NetDiag.log. In the process, the Copy command creates a new file called NetDiagWiz.log.
As soon as the report file has been created, the script uses the Run method to launch Notepad and open the report in a maximized window. The script then cleans up after itself by deleting the Header.txt and NetDiag.log files. Once the report displays, control returns to the Main Routine and the script gracefully exits via the Wscript.Quit method.
Running the Network Connectivity Tester Wizard
Running the Network Connectivity Tester Wizard is a snap. To begin, you need to copy all seven of the files that make up the wizard to the C:\Program Files\Support Tools folder. Then, create a shortcut to the NetConWiz.wsf and place it on the desktop or Start menu.
When you launch the Network Connectivity Tester Wizard, you’ll see the screen shown in Figure A.
|The first screen in the wizard prompts you to select the test scheme that you want to run.|
As you progress through the wizard, you’ll see the screens shown in Figures B and C.
|The second screen in the wizard lets you choose how much detail you want to see in the report.|
|The third screen in the wizard gives you several special options to choose from.|
If you chose to run specific tests, you’ll see the screen shown in Figure D. If you chose to skip specific tests, you’ll see the screen shown in Figure E.
|The first optional fourth screen allows you to select those tests that you want to run.|
|The second optional fourth screen allows you to select those tests that you want to skip.|
Once the test is complete, you’ll see a report displayed in Notepad similar to the one shown in Figure F.
|The header in the report will allow you to tell at a glance exactly when the tests were run and which tests were run, and help you identify the results.|
Greg Shultz is a freelance Technical Writer. Previously, he has worked as Documentation Specialist in the software industry, a Technical Support Specialist in educational industry, and a Technical Journalist in the computer publishing industry.