IIS Command-Line Tips and Tricks for Network Problem Diagnosis, Part 1

Back when Windows 3.1 first shipped, rumors about the command line's death were greatly exaggerated. In this series of articles, I'll show you (and perhaps refresh your memory) some of the more important and powerful command-line utilities you can use to diagnose network problems on your IIS Web servers and IIS Web farms. Some of these tools' roots go back 20 or more years; some have roots in UNIX, and others are strictly Windows utilities.

More often than not, complaints about Web application latency are a result of network, not software, problems. The more complex your environment is, the easier it is to accidentally or inherently introduce network problems. Heterogeneous environments and platforms, multiple subnets, demilitarized zones, and internal firewalls within your network all can contribute to hard-to-diagnose network gremlins. You can use numerous command-line tools not only to diagnose problems when they occur but to identify potential bottlenecks before they become significant problems. These tools live in WINNTsystem32 and are consequently "pathed" so you can grab a command prompt and run them from anywhere.

Let's start with the basics. You can use the Ping.exe command-line tool to verify whether a local or remote TCP/IP system is available; you use it when your network resources stop talking. Consider a scenario in which you receive reports that a Web application is suddenly receiving SQL Server errors. First, you can verify that both the IIS box and SQL Server are up and running. If they are, a simple ping test from the IIS box to the SQL Server box is a quick way to test connectivity. You can ping using DNS name, NetBIOS name, or IP address. And you'd probably do it in this order:

A positive response from a ping resolved by DNS, such as in method 1, means the problem isn't a DNS one, and the basic connectivity between the boxes is functioning. A negative response (i.e., a "request timed out" message) means you can try both the NetBIOS and IP address methods to hunt down the problem. Let's say the DNS method failed in this manner:

C:WINNTsystem32>ping huckaby.tim.comPinging huckaby.tim.com [192.168.1.30] with 32 bytes of data:Request timed out.Request timed out.Request timed out.Reply from 192.168.1.30: Destination host unreachable.Ping statistics for 192.168.1.30:Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),Approximate round trip times in milli-seconds:    Minimum = 0ms, Maximum =  0ms, Average =  0msC:WINNTsystem32>

And let's assume a NetBIOS or IP ping method succeeds in this manner:

C:WINNTsystem32>ping 192.168.1.30Pinging 192.168.1.30 with 32 bytes of data:Reply from 192.168.1.30: bytes=32 time<10ms TTL=128Reply from 192.168.1.30: bytes=32 time<10ms TTL=128Reply from 192.168.1.30: bytes=32 time<10ms TTL=128Reply from 192.168.1.30: bytes=32 time<10ms TTL=128Ping statistics for 192.168.1.30:    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:Minimum = 0ms, Maximum =  0ms, Average =  0msC:WINNTsystem32>

The problem obviously lies with DNS, and you can fix it accordingly. I turned off my internal Windows 2000 DNS server to illustrate the problem above, and when I turned the DNS service back on, everything worked correctly again.

You can use the ping tool when you test your Internet connectivity to the world outside the firewall or to test Internet connectivity to servers you host from remote locations. We are currently having a devil of a time with our ISP. We host our static site from a computer room in our San Diego office. Ironically, as I write this (in the middle of the night from home), I know that Internet connectivity is down because I just grabbed a browser to take a peek at our site's new look and feel. It failed. I grabbed a command prompt and pinged http://www.interknowlogy.com and it failed miserably. So it's time to call our network guys—they dread hearing from me, and I guarantee they aren't happy with our ISP.

In next week's column, I'll discuss my two favorite command-line tools for identifying, diagnosing, and preventing network IIS server problems: TRACERT and PATHPING.