DS Analyzer has two components: the server-side data monitor and the client-side analysis tool. On each server you wish to monitor, three agent NLMs are loaded (using the client program) to gather NDS traffic information and communicate with the client program. A Java-based program on the client workstation lets administrators extract and graph the data gathered by the NLMs.

DS Analyzer was quick and easy to set up and run. After installing the client portion on my NT workstation, I used it to install the server agents on 10 of my NetWare 4.11 and 5 servers. These servers are part of the production NDS tree for the College of Engineering at the University of Wisconsin-Madison. I had no problems installing the software on the servers, nor did I find any problems once the software began to collect the information. I did not notice any appreciable change in the server utilization with the software running.

After letting the NLMs gather data for a day or so, I looked at what had been captured. When no explicit time range has been set, DS Analyzer will show the past four hours of captured data. DS Analyzer's lack of flexibility in configuring this time range for the graphs bothered me. You can choose either the default range of the past four hours, or set a "preferred" time range, as I did. But I had to specify an explicit start (and optional end) time. I set my default time range to start at the time I installed the software, but I would have preferred to tell it to show the past 24 hours or even the past two days of traffic analysis. NetPro says it will be working to add more flexibility in this area for a future release.

I decided to look at the traffic by server. I was asked to select either a specific set of servers to graph, or to select the most active servers option, which determines which servers have the highest traffic levels. It displays data for up to 15 servers on a graph.

After the initial graph of server traffic level is displayed, you can drill down into the data. For example, I selected the CAESTAFF server, and was given the choice of displaying its traffic levels as traffic by client, traffic by hop count, traffic by partition, traffic by category or error counts by category. When looking at the traffic by category, DS Analyzer will display the server's traffic levels in the following areas: access, bindery emulation, resolve name, synchronization, database maintenance, security, authentication login, backlink process, NDS other, DS management, time synchronization, schema access and schema synchronization.

I liked the depth of the help system very much. For example, I noticed that on one server a large number of access requests were being made. I didn't know just what this meant; the online help system explained each category, what expected traffic-level conditions should look like and some possible causes of common errors. It turns out the access category includes most DS read/write APIs.

While DS Analyzer was running, I decided to see how much traffic ZENworks generates. On my NT workstation, I forced the NAL (NetWare Application Launcher) to refresh its application list five or six times. After waiting a few minutes for DS Analyzer to update, I easily found a spike in NDS access traffic to a server to which my workstation was connected. Drilling down and having DS Analyzer display the traffic by client, it was easy to spot my NT workstation on the list. Those five or six NAL refreshes generated 22,697 requests. Our ZENworks installation has more than 300 application objects available to users. From this test, it was readily apparent that NAL could place a large traffic load on the server if a classroom of students all logged in and started up NAL at one time.

Of course, there is a slight cost to all this data gathering. The software generated a 1.6 MB file per day per server. The good news is that when the agent is installed on the server, you can choose the volume on which the gathered data will reside. The number of days to store the collected data is also configurable. The system will remove older data automatically, another feature I applaud. It would have been nice, however, to configure the software to clean up old files after a specified amount of space had been used, instead of solely by the data's age.

DS Analyzer 1.01 offers a good starting point. If NetPro adds more smarts, providing more analysis of the data gathered as well as generating possible suggestions on improving the network configuration, it will have a great package. Even with the lack of analysis, DS Analyzer is a valuable tool for gaining insight into the workings of NDS.

James E. Drews is a network administrator for the CAE Center of the University of Wisconsin-Madison. Send your comments on this article to him at jdrews@nwc.com.