Networking

Using the Windows 2000 Network Diagnostics tool

Solving a network problem can sometimes be tricky, to say the least. In this Daily Drill Down, Brien Posey introduces you to the Network Diagnostics tool, a command-line utility designed to test the functionality of your network client.


Anyone who's ever managed a large network knows that sometimes solving a network problem can be a little tricky, to say the least. In the past, Windows NT network administrators had to rely primarily on third-party tools for troubleshooting. However, Windows 2000 contains several brand-new networking tools. In this Daily Drill Down, I'll discuss the Network Diagnostics tool. I'll explain what this tool does and show you how to use it.

Network Diagnostics
The Network Diagnostics tool is a command-line utility designed to test the functionality of your network client. One of the best things about this tool is that although it's powerful, it's very easy to use. Therefore, when problems occur, you can get right down to business without having to waste time learning how to use a new tool. There are a few command-line switches that go along with the Network Diagnostics tool, but not nearly as many as you’d expect from such a powerful tool.

The Network Diagnostics program examines all aspects of a client's network configuration. For example, it can analyze a client's TCP/IP configuration. If you happen to be running NetWare, you can test the NetWare client along with the IPX/SPX protocol.

Installation
To install the Network Diagnostics tool, log on as Administrator and run the 2000RKST command from the \Support\Tools directory of your Windows 2000 CD. Doing so will launch the Windows 2000 Support Tools Setup Wizard. There's also a Setup program in this directory, but it doesn't appear to actually do anything. When the wizard completes, it will have installed a plethora of new tools under the Start | Programs | Windows 2000 Support Tools | Tools menu. For this Daily Drill Down, we'll stick to the Network Diagnostics tool that is only available via the command prompt.

Using the Network Diagnostics tool
As I mentioned, the Network Diagnostics tool must be run from the command line. The executable program is called NetDiag.exe. The command syntax is:
NETDIAG [[/Q | /V | /DEBUG] [/L] [/D:DOMAIN NAME] [/FIX] [/DCACCOUNTENUM] [/TEST:TEST NAME | /SKIP:TEST NAME]]

The switches that go along with the executable include:
  • /Q—Lists only tests that return errors.
  • /V—Displays detailed information as tests are performed.
  • /DEBUG—Displays a very high level of detail.
  • /L—Stores errors in NetDiag.log in the current directory. (I recommend you always use the /L switch since the program's output is almost always more than a screenful.)
  • /D:domain name—Finds the domain controller.
  • /fix—Fixes DNS errors on the domain controller.
  • /DCAccountEnum—Enumerates computer accounts on the domain controller.
  • /TEST—Performs a single test.
  • /SKIP—Skips a test.
  • Test Name—Provides the name of the test to perform or skip.
  • /?—Provides help.

Now that I've examined the Network Diagnostics tool's syntax, it's time to explain a little bit about each test. In the sections that follow, the name of the test is listed in the heading, followed by a description of the test and a sample test output. You specify these test names if you want to skip a test or run a single test. In most cases, I’ve abbreviated the sample output because it was often scattered throughout the log file and because many of the test results were long.

NDIS
The NDIS test is the first test that's performed by default. The NDIS test checks the status of your network adapter. If the test fails, then all other tests are aborted. The NDIS test checks such things as your network adapter's name, configuration, GUID, media type, and statistics. Below is a sample of the output you can expect to see from this test:
Netcard queries test . . . . . . . : Passed

 Information of Netcard drivers:

—————————————————————————————————————-

 Description: Realtek RTL8139(A) PCI Fast Ethernet Adapter
 Device: \DEVICE\{73EABE7A-930F-4312-BEB6-824C21596E69}

 Media State:      Connected

 Device State:     Connected
 Connect Time:     00:12:05
 Media Speed:      100 Mbps

 Packets Sent:     474
 Bytes Sent (Optional):   0

 Packets Received:    1292
 Directed Pkts Recd (Optional): 414
 Bytes Received (Optional):  0
 Directed Bytes Recd (Optional): 0

 —————————————————————————————————————-
 [PASS] - At least one netcard is in the 'Connected' state.

Per interface results:

 Adapter : Local Area Connection
  Adapter ID . . . . . . . . : {73EABE7A-930F-4312-BEB6-824C21596E69}

  Netcard queries test . . . : Passed

  Adapter type . . . . . . . : Ethernet
  Host Name. . . . . . . . . : CARTMAN
  Description. . . . . . . . : NDIS 5.0 driver                
  Physical Address . . . . . : 00-E0-7D-75-78-9F
  DHCP Enabled . . . . . . . : No
  DHCP ClassID . . . . . . . :
  Autoconfiguration Enabled. : Yes
  IP Address . . . . . . . . : 147.100.100.34
  Subnet Mask. . . . . . . . : 255.255.0.0
  Default Gateway. . . . . . :
  Dns Servers. . . . . . . . :
  IpConfig results . . . . . : Passed

  AutoConfiguration results. . . . . . : Passed
   AutoConfiguration is not in use.

  Default gateway test . . . : Skipped
   [WARNING] No gateways defined for this adapter.

  NetBT name test. . . . . . : Passed
   NetBT_Tcpip_{73EABE7A-930F-4312-BEB6-824C21596E69}
   CARTMAN  <00> UNIQUE  REGISTERED
   CARTMAN  <03> UNIQUE  REGISTERED
   CARTMAN  <20> UNIQUE  REGISTERED
   BUD   <1E> GROUP  REGISTERED
   INet~Services <1C> GROUP  REGISTERED
   IS~CARTMAN.....<00> UNIQUE  REGISTERED

   NetBios Resolution : Enabled

         Netbios Remote Cache Table
   Name   Type    HostAddress   Life [sec]
   ———————————————————————————————-
   TALAINIA  <20> UNIQUE  147.100.100.25  510
   SCOOBY   <20> UNIQUE  147.100.100.31  587
   BUD   <1B> UNIQUE  147.100.100.31  580
   BUD   <1C> GROUP  147.100.100.31  567
   TITANIUM  <20> UNIQUE  147.100.100.30  510

  WINS service test. . . . . : Skipped
   There is no primary WINS server defined for this adapter.
   There is no secondary WINS server defined for this adapter.
   There are no WINS servers configured for this interface.
  IPX test : IPX is not installed on this machine.


IPConfig
The IPConfig test is nothing short of fantastic. It combines several manual TCP/IP diagnostic techniques into one easy test. The IPConfig test displays most of the information you’d normally expect to see if you ran the IPConfig/All command-line utility. In addition, it pings DHCP and WINS servers and tests for the correct location of the default gateway. Below is a sample of the output you can expect to see from this test. Although you can’t see the results of the pings in this particular segment of code, the tests were conducted earlier.
IP General configuration
 LMHOSTS Enabled. . . . . . . . : Yes
 DNS for WINS resolution. . . . : Enabled
 Node Type. . . . . . . . . . . : Broadcast
 NBT Scope ID . . . . . . . . . :
 Routing Enabled. . . . . . . . : No
 WINS Proxy Enabled . . . . . . : No
 DNS resolution for NETBIOS . . : No


Member
The Member test outlines the terms of your domain membership. For example, it tells your server’s role in the domain, as well as the domain’s GUID and SID. You can also see which domain you’re currently logged in to, along with the user account you’re using. Here’s a sample of the output you can expect to see from this test:
Domain membership test . . . . . . : Passed
 Machine is a . . . . . . . . . : Member Server
 Netbios Domain name. . . . . . : BUD
 Dns domain name is not specified.
 Dns forest name is not specified.
 Domain Guid. . . . . . . . . . : {00000000-0000-0000-0000-000000000000}
 Logon User . . . . . . . . . . : Administrator
 Logon Domain . . . . . . . . . : CARTMAN


NetBTTransports
The NetBTTransports test lists NetBT transports that are managed by the redirector. If your computer isn’t set up to use NetBT transports, it’s normal for this test to generate an error. Here’s a sample of the output you can expect to see from this test:
NetBT transports test. . . . . . . : Passed
 List of NetBt transports currently configured:
  NetBT_Tcpip_{73EABE7A-930F-4312-BEB6-824C21596E69}
 1 NetBt transport currently configured.


Autonet
The Autonet test checks to see whether any adapter in your machine is using automatic IP addressing. Here’s a sample of the output you can expect to see from this test:
Autonet address test . . . . . . . : Passed
 PASS - you have at least one non-autoconfigured IP address


IPLoopBk
The IPLoopBk test is useful for testing to see whether the various TCP/IP components are functional. This test pings the address 127.0.0.1. If this ping fails, there’s a problem with the way TCP/IP is installed. Your best bet in such a situation is to uninstall TCP/IP from the computer, reboot, and reinstall it from scratch. Below is a sample of the output you can expect to see from this test:
IP loopback ping test. . . . . . . : Passed
 PASS - pinging IP loopback address was successful.
 Your IP stack is most probably OK.


DefGw
The DefGw test pings each network card’s default gateway. As you can see from the sample output below, this test failed on my test server. Normally, a failure in this area would indicate that the computer would be unable to communicate with other subnets. However, because of the way my Proxy Server is configured, this server doesn’t have a default gateway. Thus, the test results are normal and don’t actually point to a critical failure.
Default gateway test . . . . . . . : Failed
 [FATAL] NO GATEWAYS ARE REACHABLE.
 You have no connectivity to other network segments.
 If you configured the IP protocol manually then
 you need to add at least one valid gateway.


NbtNm
This test checks the NBT names to make sure they aren’t in conflict. It compares the workstation service name to the computer name to make sure they’re the same. It also compares the messenger service name and the server service name to ensure they don’t conflict. Here’s a sample of the output you can expect to see from this test:
NetBT name test. . . . . . . . . . : Passed
 No NetBT scope defined

 PASS - The NetBT is properly configured.
  There is at least one interface where the <00> 'WorkStation Service',
  <03> 'Messenger Service', <20> 'WINS' names are defined and they are
  not in conflict.


WINS
The WINS test takes the NBT names determined earlier and sends NBT name queries to the WINS server, to make sure that the WINS server is functional. Because a WINS server isn’t used on my test network, I don’t have any sample output for this test.

Winsock
The Winsock test looks at Windows Sockets to determine which transport protocols are available. This test is useful when trying to diagnose TCP/IP problems in which some TCP/IP ports work and others don’t. For example, you might use this test if you can connect to the Web but can’t connect to your mail server. Below is an abbreviated sample of the output you can expect to see from this test:
Winsock test . . . . . . . . . . . : Passed
 The number of protocols which have been reported : 10
  Description: MSAFD Tcpip [TCP/IP]
   Provider Version :2
   Max message size : Stream Oriented
  Description: MSAFD Tcpip [UDP/IP]
   Provider Version :2
  Description: RSVP UDP Service Provider
   Provider Version :4
  Description: RSVP TCP Service Provider
   Provider Version :4
   Max message size : Stream Oriented
  Description: MSAFD NetBIOS [\Device\NetBT_Tcpip_{73EABE7A-930F-4312-BEB6-824C21596E69}] SEQPACKET 0
   Provider Version :2
  Description: MSAFD NetBIOS [\Device\NetBT_Tcpip_{73EABE7A-930F-4312-BEB6-824C21596E69}] DATAGRAM 0
   Provider Version :2
  Description: MSAFD NetBIOS [\Device\NetBT_Tcpip_{67EFB851-D60A-4DC6-BEFE-6846B81647EC}] SEQPACKET 1
   Provider Version :2
  Description: MSAFD NetBIOS [\Device\NetBT_Tcpip_{67EFB851-D60A-4DC6-BEFE-6846B81647EC}] DATAGRAM 1
   Provider Version :2
  Description: MSAFD NetBIOS [\Device\NetBT_Tcpip_{5077D5BE-A8E7-4918-8642-7EBFFBA04477}] SEQPACKET 2
   Provider Version :2
  Description: MSAFD NetBIOS [\Device\NetBT_Tcpip_{5077D5BE-A8E7-4918-8642-7EBFFBA04477}] DATAGRAM 2
   Provider Version :2

 Max UDP size : 65527 bytes


DNS
This test looks to see whether the DNS server is running and whether the computer in question is correctly registered within the DNS. If the computer you’re testing is a domain controller, the test checks to make sure all computers listed in the NetLogin.dns file are actually registered within the DNS database. If the entries appear to be incorrect, you can use the /FIX switch that I discussed earlier to correct the problem. As you can see by the sample output, the computer that I tested wasn’t attached to a DNS server.
DNS test . . . . . . . . . . . . . : Failed
[FATAL] Cannot get the DNS Adapter Information from the registry, error 0x267c DNS_ERROR_NO_DNS_SERVERS


Browser
The Browser test actually tests the redirector and the browser. As you can see from the sample test below, the Browser test checks to ensure that the browser is bound to all NetBT transports and that the computer can send Mailslot messages.
Redir and Browser test . . . . . . : Passed
 List of transports currently bound to the Redir
  NetbiosSmb
  NetBT_Tcpip_{73EABE7A-930F-4312-BEB6-824C21596E69}
 The redir is bound to 1 NetBt transport.
 List of transports currently bound to the browser
  NetBT_Tcpip_{73EABE7A-930F-4312-BEB6-824C21596E69}
 The browser is bound to 1 NetBt transport.
 Mailslot test for BUD* passed.


DSGetDC
The DSGetDC test checks for a generic domain controller, a primary domain controller, and a Windows 2000 domain controller. This test can compare the GUID located in the LSA (Local Security Authority) to the GUID actually stored on the domain controller. If the numbers don’t match, you can correct the problem by using the /FIX option. Here’s a sample of the output you can expect to see from this test:
DC discovery test. . . . . . . . . : Passed

 Find DC in domain 'BUD':
 Found this DC in domain 'BUD':
  DC. . . . . . . . . . . : \\TITANIUM
  Address . . . . . . . . : \\TITANIUM
  Domain Name . . . . . . : BUD

 Find PDC emulator in domain 'BUD':
 Found this PDC emulator in domain 'BUD':
  DC. . . . . . . . . . . : \\SCOOBY
  Address . . . . . . . . : \\SCOOBY
  Domain Name . . . . . . : BUD
  Flags . . . . . . . . . : PDC WRITABLE

 Find Windows 2000 DC in domain 'BUD':
  [WARNING] Cannot find Windows 2000 DC in domain 'BUD'. [ERROR_NO_SUCH_DOMAIN]

  This isn't a problem if domain 'BUD' does not have any Windows 2000 DCs.


DcList
This test is designed to compile a list of domain controllers within a given domain. The test begins by examining the directory service on an active domain controller. If this information is unavailable, another type of query is run against the directory service. If necessary, this test will also use the browser to get a list of domain controllers. Once the list has been compiled, the Network Diagnostics tool will add the controllers to the list to be tested. Below is a sample of the output you can expect to see from this test:
DC list test . . . . . . . . . . . : Passed
 List of DCs in Domain 'BUD':
  TITANIUM
  SCOOBY
  TALAINIA


Trust
The name of the Trust test is a bit deceptive since the test doesn’t look at trust relationships between domains. Rather, it looks at inner domain trusts, such as the relationship between workstations or member servers and domain controllers. This test checks the SID that it uses to access the domain controller for accuracy. It then tests for a secure channel between itself and the domain controllers. Here’s a sample of the output you can expect to see from this test:
Trust relationship test. . . . . . : Passed
 Test to ensure DomainSid of domain 'BUD' is correct.
 Secure channel for domain 'BUD' is to '\\TALAINIA'.
 Secure channel for domain 'BUD' was successfully set to DC '\\TITANIUM'.
 Secure channel for domain 'BUD' was successfully set to DC '\\SCOOBY'.
 Secure channel for domain 'BUD' was successfully set to DC '\\TALAINIA'.


Kerberos
The Kerberos test runs only if the computer is a member computer or a domain controller in a Windows 2000 domain. The test logs into the LSA and checks the Kerberos package. It then gets the ticket cache of the Kerberos package and verifies whether Kerberos has a ticket for the local computer and for the primary domain controller. Notice in my sample test that I was unable to run this test because I wasn’t logged into a Windows 2000 domain.
Kerberos test. . . . . . . . . . . : Skipped
 This machine's membership domain is not a Windows 2000 domain.
 Kerberos cannot be tested.


LDAP
The LDAP test is effective only if the computer is a member of a domain that’s running directory services. When active, LDAP connects to the domain controllers and searches the LDAP directory, testing all three types of authentication (unauthenticated, NTLM, and negotiate). In my sample test below, you can see that I wasn’t running Active Directory.
LDAP test. . . . . . . . . . . . . : Passed
 DC '\\TITANIUM' isn't running the DS. Cannot test LDAP.
 Cannot test LDAP to 'TITANIUM' since it isn't running the DS. [Test skipped.]
 Cannot test LDAP to 'SCOOBY' since it isn't running the DS. [Test skipped.]
 Cannot test LDAP to 'TALAINIA' since it isn't running the DS. [Test skipped.]


Route
Anyone who’s ever done extensive TCP/IP work over a large network is familiar with the Route command. The Route test prints much of the same information normally associated with the TCP/IP Route command. As you can see in the abbreviated sample below, the Route test checks static and persistent routes. It also displays the subnet mask, gateway, interface, and metric for each route.
Routing table test . . . . . . . . : Passed
Active Routes :
Network Destination  Netmask   Gateway   Interface Metric
  127.0.0.0   255.0.0.0   127.0.0.1   127.0.0.1  1
  147.100.0.0  255.255.0.0 147.100.100.34 147.100.100.34  1
 147.100.100.34 255.255.255.255   127.0.0.1   127.0.0.1  1
 147.100.255.255 255.255.255.255 147.100.100.34 147.100.100.34  1
  224.0.0.0   224.0.0.0 147.100.100.34 147.100.100.34  1
 255.255.255.255 255.255.255.255 147.100.100.34 147.100.100.34  1
No persistent route entries.


NetStat
The NetStat tool is very valuable. I haven’t included a sample output from the NetStat test because the NetStat test generates so much information. It includes such information as protocol statistics and the current TCP/IP network connections. This is one of the best tests for troubleshooting a really tricky problem because you get such detailed information on your network connections.

Bindings
As you’re probably aware, the Windows 2000 network infrastructure depends on various layers of the operating system working together. The way that some of these layers attach to each other is called bindings. For example, a protocol might be bound to a network card. If you’re having a network problem, you can use the Bindings test to view an exhaustive list of all of the bindings within your computer. Here’s an abbreviated sample of the output that you can expect to see from this test:
Bindings test. . . . . . . . . . . : Passed
 Component Name : Point to Point Tunneling Protocol
 Bind Name: mspptp
 Binding Paths:

 Component Name : Layer 2 Tunneling Protocol
 Bind Name: msl2tp
 Binding Paths:

 Component Name : Remote Access NDIS WAN Driver
 Bind Name: NdisWan
 Binding Paths:
  Owner of the binding path : Remote Access NDIS WAN Driver
  Binding Enabled: Yes
 Interfaces of the binding path:
  -Interface Name: ndiswanasync
   Upper Component: Remote Access NDIS WAN Driver
   Lower Component: RAS Async Adapter

  Owner of the binding path : Remote Access NDIS WAN Driver
  Binding Enabled: Yes
 Interfaces of the binding path:
  -Interface Name: ndiscowan
   Upper Component: Remote Access NDIS WAN Driver
   Lower Component: WAN Miniport (L2TP)


WAN
The WAN test displays the settings and information related to current remote access connections. As you can see from the sample test, no one was dialed in to my RAS server at the time of the test. However, it struck me as interesting that Microsoft chose to include a test for RAS connections in the mix of traditionally LAN/WAN-oriented connections.
WAN configuration test . . . . . . : Skipped
 No active remote access connections.


Modems
Under normal circumstances, the Modems test queries all of the modems within your system. It then displays any available information about each modem’s configuration. My test machine doesn’t contain a modem, so I didn’t include a sample output from this test.

NetWare
The NetWare test examines your connection to a NetWare network. It begins by determining if you’re connecting to a NetWare server through a bindery connection or a directory service connection. It then determines your default context or default server. I haven’t included sample output because NetWare isn't present on my test network.

IPX
Like all of the TCP/IP tests, the IPX test provides you with a wealth of information. If IPX is installed on your network, this test will tell you the internal network number, the frame type, and the router MTU. The IPX test will also tell you whether packet burst and source routing are enabled. I haven’t included a sample output of the IPX test because IPX isn't present on my test network.

IPSec
One of the new features in Windows 2000 is the ability to create and enforce an IP security policy. The IPSec test checks to make sure that the IP Security Policy Agent is functional. If it is, then the test goes on to see which policy, if any, is currently active. Here’s a sample of the output you can expect to see from this test:
IP Security test . . . . . . . . . : Passed
 IPSec policy service is active, but no policy is assigned.

 There are 0 filters


Conclusion
Diagnosing network problems can be a real pain in the neck. In this Daily Drill Down, I've shown you several tests that are built into the Windows 2000 Network Diagnostics program. I’ve also explained how each of these tests works, and I’ve shown you what type of results you can expect.

Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it's impossible for him to respond to every message. However, he does read them all.)

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox