One thing most good network administrators have in common is that they constantly wonder how their servers are performing. Summing up a machine’s performance usually requires several different tools. For example, if you want to know when your server was last rebooted, you might check the event log. But what if the event logs have been purged recently?
A better way to get this kind of vital information is to use the Net Statistics command. In this Daily Drill Down, I’ll introduce you to the Net Statistics command and explain how to interpret the information it gives you.
The Net Statistics Command reports server statistics
If you’ve ever used Windows NT/2000/XP commands like Net Use or Net Print, then you’re probably somewhat familiar with the Net command. The Net command is a command line tool that allows you to perform many different network-related tasks. The Net Statistics command is the Net command’s method for reporting a server or workstation’s vital statistics.
As you read this Daily Drill Down, bear in mind that every networked Windows NT/2000/XP machine functions simultaneously as both a server and a workstation. As the Server service and the Workstation service run, they compile statistics over time. You can view these statistics through the Net Statistics command.
To use the Net Statistics command, simply open a Command Prompt window and enter either the Net Statistics Workstation command to access workstation statistics, or the Net Statistics Server command to access the server statistics.
Server statistics
You can obtain cumulative statistics on the server service’s performance by entering the Net Statistics Server command in a Command Prompt window. When you do, you’ll see information similar to what’s shown in Figure A.
| Figure A |
 |
| Statistics reported by the Net Statistics Server command |
As you look at the figure, you’ll notice that the various lines of information are divided into groups. The first bit of information that the Net Statistics command gives is a date and time representing when the server was most recently booted.
Session information
The second block of information has to do with server sessions. The session information can be a bit deceptive, partly because of the way that the Sessions Accepted statistic is presented and partly because of what’s missing.
If you look at Figure A, you’ll notice that the Sessions Accepted line has a much smaller number than the Sessions Timed-Out or Sessions Errored-Out lines. That’s because, like most of the other information that the Net Statistics command provides, the Sessions Timed-Out and Sessions Errored-Out lines are cumulative. However, the Sessions Accepted line represents the number of active sessions at the time that the command was run. Therefore, when I ran the command shown in Figure A there were three live sessions, but 120 sessions had been disconnected and 131 sessions had errored out since the last time the server was booted.
As you may have guessed, the Sessions Timed-Out line represents sessions that have been disconnected because of how long they remained idle, and the Sessions Errored-Out represents the number of sessions that were disconnected due to an error. What you may not know is that the number of sessions that have timed out is included in the number of sessions that have errored out. Therefore, although Figure A shows 131 errored sessions, 120 of those were time-outs. This means that there were only 11 actual errors.
The information presented in this portion of the report is useful for determining how many users are connected, whether the number of errors is disproportionately large, and whether the automatic time-out feature is working. Time out may not seem like a big deal, but it’s Windows’ way of freeing up resources.
I mentioned earlier that some information was missing from this part of the report. Windows 2000 also collects information on the number of sessions that have logged out normally and the number of sessions that were manually disconnected by an administrator. You can only access this information through Performance Monitor.
Kilobytes
If you’ve worked much with Performance Monitor, you’re probably familiar with the bytes sent/sec and bytes received/sec counters. The information in the Kilobytes section is based on those figures. The numbers next to the Kilobytes Sent and Kilobytes Received lines represent the number of total kilobytes sent and received by the server service, not the system as a whole, since the last boot. For example, in the figure, you can see that since July 25th, my server has sent about 13 GB and received about 3 GB.
Although this section doesn’t show you the bytes per second like the Performance Monitor would, it does show you the mean response time in milliseconds. The mean response time has nothing to do with how quickly the server sent the data, but rather how quickly the server responded to the request.
As you can see in the figure, my server had an ideal mean response time of zero. However, this number is a bit unrealistic in a production environment with more than a few users. I can’t tell you what your mean response time should be because it varies from location to location. What I can tell you is that the lower the number, the faster the response time.
One way to get a feel for how your server responds is to establish a baseline to find out what is normal for your server. For example, you can use the Net Statistics command to view the mean response time at a certain time of day over the course of a week. You can then tell how the server is performing by comparing the current mean response time with the baseline score. Bear in mind that, since this is a cumulative score, it could take a long time to reflect serious performance problems.
Errors
The errors section reports on three different types of errors. The System errors line reports the number of system errors that have occurred since the last reboot. System errors typically represent a problem with the server. Therefore, this number should be zero.
The next line indicates the number of permissions violations that have occurred since the last boot. As you can see in the figure, it’s normal to have a few permissions violations. Even if no one on your network is trying to get into anything unauthorized, it isn’t uncommon for a server that isn’t configured exactly right to generate access permissions at the system level. However if this number increases substantially each time you run the Net Statistics command, it could mean that someone is trying to hack your network.
The last line in this section is Password Violations. This number represents the number of times that users have entered passwords incorrectly. Again, big spikes in this number could signal a hack attempt.
Access
The next section tells you something about the way your users are accessing the server. The Files Accessed line shows the total number of times files were accessed since the last boot. It’s important to note that this is the total number of accesses, not the total number of individual files accessed. I don’t have 1.7 million data files on my server; however the files that are on my server (mostly temporary files) have been accessed that many times.
The next line, Communication Devices Accessed, shows you how many times devices like modems have been accessed. The Print Jobs Spooled line indicates how many print jobs have been spooled by the server since it was booted.
Buffers exceeded
The final section of the Servers report has to do with buffers that have been exceeded. In this particular case, the report refers to NetBEUI buffers. If you don’t have NetBEUI installed, both of these numbers should be zero.
Workstation statistics
The workstation statistics refer to the performance statistics gathered by the Workstation Service. You can view the workstation statistics by entering the Net Statistics Workstation command. When you do, you’ll see a report similar to the one in Figure B.
| Figure B |
 |
| Statistics reported by the Net Statistics Workstation command |
Bytes and SMBs
As you look at the Bytes and SMBs section, it’s important to bear in mind that the statistics pertain only to the Workstation Service, not to the computer as a whole. Most of the statistics found in this section are fairly self-explanatory.
The section begins by displaying the number of bytes and the number of server message blocks (SMBs) received. The report then displays the number of bytes and the number of SMBs transmitted. If you attempt to compare these stats against the sent and received stats shown by the server portion of the Net Statistics command, you should know that, while the server portion shows sent and received data in kilobytes, the workstation section shows the data in bytes. A kilobyte is equal to 1024 bytes. Therefore, the 11983814 bytes received shown in Figure B only represents about 11 MB.
Read and write operations
The Read Operations and Write Operations section displays the cumulative number of read and write operations followed by the number of raw reads and writes that have been denied. Under normal circumstances, the raw reads and raw writes denied should be zero. Larger numbers may represent permissions problems or a hardware issue involving your hard disk or controller.
Network errors and connections
The network errors and connections section is designed to tell you something about the stability of the workstation service’s network connection. The Network Errors line typically refers to physical network errors, such as bad packets. Under normal circumstances, this number should be zero. If you think that the system may be having network problems, try running the Net Statistics Workstation command repetitively. If a serious physical problem is causing the network connection to produce errors, you’ll see this line’s number increasing sharply.
The next few lines deal with network connections. As you can see in Figure B, the report shows the number of connections that have been made, followed by the number of reconnections made and the number of server disconnects. The numbers shown in this section are cumulative values and will vary widely, depending on what you use the machine for.
Notice that in the figure, my server’s number of connections is much higher than the number of reconnections or server disconnections. This is normal for a healthy system. The reason that the number of connections is so much higher than the other numbers is that, for every connect, there should be a corresponding workstation-side disconnect. Only when this disconnect doesn’t happen will you see a server-side disconnect or a reconnect.
Server disconnects can represent disconnections for a variety of reasons. Most of the time, server disconnects represent disconnections caused by time outs. However, these disconnects can also represent disconnections due to errors or connections that were manually terminated by an administrator.
You’ll also notice that the number of reconnects is higher than the number of server disconnects. Sometimes a workstation will lose a connection for no apparent reason, and it will automatically try to re-establish the connection. The reconnections represent situations in which the workstation was able to recover from a connection error after the connection had already been dropped.
As you can see, both the Server Disconnects and the Reconnections Made lines show totals in the single digits. Under ideal circumstances, this is how it should be. Server disconnects could be considerably higher if applications are often left idle. However, reconnections should never be very high.
An ever increasing number of reconnections could indicate a network hardware problem. Even on a healthy system, though, the number of reconnections won’t always be in the single digits. For example, my system shows five reconnections, but it has been running for only a month. Systems that have been up longer may show a proportionately larger number of reconnects.
Sessions
The statistics shown in the Sessions section are fairly self-explanatory. For example, the Sessions Started line shows the number of sessions that have been started. You can also see how many sessions have hung or failed, total sessions used, and how many of the sessions used have failed.
As you might have suspected, the Failed Sessions, Failed Operations, and Failed Use Count lines should show low numbers, preferably zero or in the single digits. Again, if you see a larger number associated with one of these counters, you should take a look at how long the machine has been online before jumping to conclusions. For example, my machine has been online for a month and has a failed use count of 4. Therefore, if the failed use count is 24 but the machine hasn’t been rebooted in six months, the statistic is no big deal.
Casting your net
The Net Statistics command can be a real time-saver. It lets you view several important pieces of information without using the Performance Monitor. The Net Statistics command shows you how well your server is performing and even gives some insight into how well your server’s security is holding up. The real trick is to know how to interpret the numbers that Net Statistics gives you.
