Informational Commands

If the problem is more thorny than a configuration issue, it can be useful to know the perspective of the problem workstation; that is, what the workstation can see, what it cannot see, and the state of various informational commands as run from that workstation. You can use various informational commands, as listed in Table 11.1, to see the workstation’s perspective on the network (these commands apply for both Windows 9x and NT).

All these commands (except nbtstat) are more or less lifted from UNIX; see Hour 12, “UNIX Networking Basics,” for examples of their use in basic TCP/IP troubleshooting. Hour 18 provides some in-the-trenches techniques.

net

You should also be familiar with the net command. Type

net | more

at the command prompt. This will show you the multitudinous net commands you can run. These are mostly file and print related; some relate to networking configuration in general, as well. Some of these functions do not have a graphical equivalent, so set aside about a half an hour when you’ll be undisturbed to check ’em out.

Friendly, Mon, Real Friendly

Say what you like about any other part of Microsoft networking, but I will defend the built-in statistic-gathering features to the death. Far and away the most wonderful thing about Microsoft networking, the statistic-gathering features in the server and client programs, along with SysMon (the affectionate term for the System Monitor), enable you as Joe User to see how you’re doing in terms of performance at any given time. This means you can quickly and easily profile a particular server or network segment. This is something that used to take a network expert and a $10,000 piece of equipment to do, yet Microsoft has now enabled everyone to do it. (Did I mention that I like this feature?)

In all seriousness, this really allows you to do some powerful troubleshooting cheaply. Let’s look at a quick example: Suppose we have an application that’s for some reason running very slowly for a given person. Other folks are running the application just fine, but our confidence level is pretty low concerning how alike each workstation is. We discover that the user can log into someone else’s workstation and work just fine.

Somebody suggests that we nuke the user’s hard drive and make it just like a setup that works. This is greeted with stony silence by the user, who happens to be a big shot in the company. Apparently, this is not the path that we will take.

The user says that he runs like molasses, and he seems right from what we can tell of other people’s workstations. What’s going on? Is it the client or the server? Is this subjective slowness, or is there an objective way of measuring this?

We could break out the $10,000 network analyzer to measure the network throughput by attaching it to the network segment and capturing each packet between the client and server and then doing the math of amount captured divided by number of seconds to get the amount per second. However, because network throughput is easy to measure with the Windows 95 System Monitor, we install this to the user’s workstation and add the Microsoft Network client’s Bytes Read/Second statistic to our chart. Figure 11.8 shows a monitor session; it reveals that the Microsoft file and print session is running reasonably fast: 625KB–991KB per second. You can’t expect much faster than that on a 10Mbps Ethernet network. You can tell that the workstation is working hard keeping up (look at the CPU utilization and free memory). Both drop when this file transfer is happening. In this example, we would see normal output like this when running the application on a different server.

Figure 11.8  A monitor session.

We keep the System Monitor minimized and run the problem application. Yes indeed, it’s slow. We’re seeing wide-area speeds on a LAN connection. Right away we know that there’s truly a speed problem on the network; it has nothing to do with his workstation.

Or does it? We have a different server that runs another department’s stuff, so we decide to do the same measurements on that server using the same application. In this case, the measurements are more in line with what we’re seeing on other workstations on the LAN. It seems that this particular server and this person’s workstation are not happy with each other. The five minutes we spent with the System Monitor accomplished a couple of important things:

•  This person is not imagining things; we have objective data to prove it.

•  We’ve discovered that the workstation can connect to a different server without the slowdown problem; we now have a workaround while we further diagnose the problem server or workstation.

In this particular case, the server is definitely a problem. It’s not a Microsoft server; it’s a UNIX server running an older version of an SMB server. However, the server is talking to other PCs just fine. Something about the age of the server and the client software on the user’s PC isn’t jiving properly.

We (very carefully) reinstall the Microsoft file and print client to the workstation, consistent with other workstations in the department; then we reapply the Windows 95 Service Pack 1. In this case, because we’re dealing with a VIP, we make a backup of his hard drive—just in case we cause more problems through this process. After the application of the client and the service pack, we test again with the System Monitor. The problem is gone, and the VIP is happy.

---

We’ll talk more about network throughput in Hour 22, “The Network Is Slow!”

---