| Being able to combine information from multiple diagnostic tools can give you a better idea of what is really happening. As discussed previously in this book, having as much information as possible available increases your chances for correctly identifying the source of a problem, and correctly identifying the source of a problem is as important as resolving the problem. Chapter 7 examines a number of different Novell tools for diagnosing problems: -
DSRepair -
DSTrace -
DSView, DSBrowse, and DSDiag -
NDS iMonitor and iManager -
NetWare Administrator and ConsoleOne -
Schema Manager Chapter 7 also examines four tools for looking up and providing general DS information and information on the tree: Individually, these tools provide a number of useful functions, but when combined, their usefulness increases significantly. One combination that you are probably already familiar with is using a diagnostic tool to determine an error condition followed by using an information tool to define an error message. For example, you have probably used DSRepair to determine that there was an error -625 in the NDS synchronization process and then used the help files, knowledge bases, LogicSource for eDirectory, or this book to look up what an error -625 was and possible causes and resolutions . This is a very simple example, but it is intuitive and something you probably do on a day-to-day basis. Combining different tools needs to become as second nature to you as using an information resource to look up an error code. When you are attempting to determine whether a problem exists, it is important to look at the problem from multiple angles ”and that frequently involves using multiple tools. The diagnostic tools listed previously are good at specific things; in cases where functions and features of two tools overlap ”for example, both NDS iMonitor and DSRepair can report replica synchronization status ”using both tools to validate a problem is recommended. Doing this enables you to see two different views of the same problem ”even to the extent of giving you different views of the same error conditions. NOTE Using different tools to examine a problem is highly recommended, especially if the problem is something you have not encountered before or if the symptoms are confusing or inconsistent. This is similar to your being ill with a not-so-common sickness; it may be a good idea to ask for additional opinions from a second doctor so you are presented with a different viewpoint.
Suppose that during a routine health check using NDS iMonitor, you find a partition reporting synchronization errors. You can use the features in NDS iMonitor to isolate the server that is having the problem and isolate the error code itself. The data presented with the Agent Synchronization link (refer to Figure 9.1) is server-centric. To gain a "ringwide" view of the situation, you could switch to either the Replica Synchronization view or the Continuity view (see Figure 9.11) by clicking the appropriate link to the right of the entry. This shows you which server(s) in the replica ring is reporting what error; sometimes two servers in the same replica ring may not report the same error condition because one server is the sender and the other server is the receiver. Figure 9.11. Replica ring Continuity view. 
Depending on the view you use (Replica Synchronization versus Continuity, in this example), you can get different error codes for the same error condition. In this particular example, two servers are in the replica ring, and one of the servers is taken offline. The Continuity view (refer to Figure 9.11) reports a -626 error when you try to query the downed server for the status flag. A -626 error means "all referrals failed" ”that is, the local agent knows about the server but cannot connect to it over the network. The online help for the error code lists a number of causes. You can either try each of those suggested actions or try to narrow down the possibilities. If you checked the Replica Synchronization view, it would immediately become clear that there is a communication problem because the view shows a -625 error. Simply by looking at different views of the same issue, you can quickly narrow down the possibilities and save yourself from needlessly looking down the wrong alley. NOTE Generally, the synchronization status is based on reading the status flag from the partition root object of only one server in each replica ring. Therefore, a utility such as NDS iMonitor may show that everything is running okay, but it does not necessarily mean that synchronization is running correctly across all servers. You should treat this option as a quick-check diagnostic and not a definitive one.
Now, suppose the error is something more complex than a -625 error ”for example, a -694 error ( ERR_ENTRY_LOST ). At this point, in order to isolate the object that the -694 error is being reported on, you need to switch to a different tool. For instance, you can use DSTrace to watch the synchronization take place and observe the error. This combination of using diagnostic tools and viewing the error from different perspectives is frequently necessary to completely diagnose a problem. Remember that the better you diagnose a problem, the better your chances are for resolving the issue and returning to normal operation. | 