Chapter 1 The Four Basics of eDirectory Troubleshooting
The purpose of network troubleshooting is the timely restoration of essential services. Troubleshooting is part science, part art, and part pure luck. Many attempts have been made to reduce troubleshooting to a set of procedures and flowcharts; however, given the diversity of problems, no one has yet come up with a procedure or flowchart that covers every possible situation.
The key to any successful troubleshooting is to develop the ability to break down a problem (“it doesn’t work”) into its elemental parts (“it works when I do this but doesn’t when I do that”). This ability is the cumulation of personal experience and knowledge gained by exchanging war stories with others who have “been there, done that, and gotten the T-shirt.” A combination of knowledge and experience (and some dumb luck doesn’t hurt either) helps you to develop an efficient on-the-spot strategy to tackle each problem. You can apply this divide-and-conquer technique to troubleshooting eDirectory problems.
The material presented in this book focuses on the first three steps of the troubleshooting process: Gather information, develop a plan of attack, and execute the plan.
In order to be able to break down an eDirectory error into its elemental parts, it is necessary to have an understanding of how eDirectory functions. Regardless of the nature and cause of an eDirectory issue, there are four rules you can follow to make your eDirectory troubleshooting efforts much easier. This chapter briefly outlines and explains each of the four rules. The rest of this book covers in detail the various information and tools that you need to troubleshoot and resolve eDirectory errors. Chapter 11, “Examples from the Real World,” in particular, illustrates how you can use the knowledge presented in this book to solve a number of real-world eDirectory issues.
TIP
The four basics outlined here are not specific to troubleshooting eDirectory issues. You can easily modify them to resolve other problems, such as NetWare operating system ABENDs or a network communication problem.
A solid understanding and reasonable application of the following four eDirectory troubleshooting doctrines will assist you in quickly and efficiently identifying the cause of and restore any disruptions in your eDirectory tree:
Don’t panic.
Understand the error codes and eDirectory processes.
Troubleshoot and resolve the problem.
Proactively manage eDirectory to prevent problems.
NOTE
eDirectory is the current name of the directory services (DS) product from Novell, Inc. In the past, the product was generally referred to as NDS (which stood for NetWare Directory Services, and later on, Novell Directory Services, when it was made available for operating system platforms other than NetWare). The concepts and much of the information presented in this book are applicable to both eDirectory and previous versions of NDS. However, some of the information (such as filtered replica) and tools (such as iManager) discussed in this book apply only with eDirectory. Where that is the case, every attempt is made to note this.
When an essential network service is down, you are generally under pressure to restore it—quickly. When the service is eDirectory, the pressure is much higher because it can potentially affect all your users; however, the first rule of dealing with eDirectory issues is to be patient and don’t panic.
Often, the eDirectory errors you encounter are transitional, and eDirectory self-heals; furthermore, sometimes the eDirectory error condition is a secondary result of other network-related problems. For example, a -625 (unable to communicate) error is not a true eDirectory error but a by-product of a network communication problem. So, without first trying to understand the cause of the eDirectory error, if you start performing eDirectory-related “corrections,” such as running DSRepair needlessly, you could cause eDirectory errors where there weren’t really any to start with.
Many current administrators have worked with NetWare since the days of the NetWare 3 bindery. Certain actions could be easily performed with the bindery, but you can’t and shouldn’t treat eDirectory the same way. You need to keep in mind that eDirectory is implemented as a globally distributed, replicated, loosely consistent, hierarchical database. The primary challenge in maintaining a globally distributed database is keeping all the information up-to-date when changes are made. For example, when you create a new user in a container, the change must be propagated to all servers that hold a replica of that container; however, the loose-consistency nature of eDirectory means that the eDirectory database is not necessarily in strict synchronization all the time.
Because of the loosely consistent nature of eDirectory, when major changes are made, such as moving a Server object or splitting a partition, it can take some time for the changes to propagate to all replicas. Therefore, there can be periods of time during which the information in one replica is different from that in another replica. But the information held by the replicas does eventually converge to an identical state, making eDirectory consistent once again. Because eDirectory is replicated, you shouldn’t perform any partition-related operations when any of the servers holding a replica of the affected partition(s) are not available. If you do, you’ll get eDirectory into a stuck state, where it is unable to complete the operation because it can’t communicate the change to some servers.
As the old sayings go, “haste makes waste” and “patience is a virtue.” You should always allow eDirectory sufficient time to perform what it is designed to do: replicate data without flooding the network with eDirectory traffic.
Frequently, in order to keep an application’s file size (and thus, memory and disk space requirements) down, the programmer opts to substitute comprehensive error and debugging messages with cryptic error codes. For example, instead of telling you, “The eDirectory object you’re searching for doesn’t exist in the current context,” an error code of -601 is displayed. If you don’t have ready access to these error codes, your effort in determining the cause of the eDirectory error can be greatly hampered.
In addition to knowing the meanings of the various error codes, you also need to understand the eDirectory processes that are involved when an error code is generated. Some could be due to legal error conditions (“false-positives”), suggesting that there is not an actual error, while others indicate real error conditions. For instance, if you have enabled DSTrace at the server console with the +ERR flag, you may see a -601 error when an application is searching for an object in multiple containers. In such a case, they are legal errors that are to be expected. On the other hand, if you receive a -618 (eDirectory database inconsistent) error, it could mean real trouble; therefore, it is essential to know what the various error codes mean and to understand the processes that generate them.
NOTE
You can find some of the most commonly encountered eDirectory error codes and eDirectory processes discussed, respectively, in Chapters 5, “eDirectory/NDS Error Codes Explained,” and 6, “Understanding Common eDirectory Processes.” A list of all published eDirectory error codes and their explanations is presented in Appendix A, “eDirectory Error Codes.”
An important side benefit of developing this understanding is your ability to determine whether a problem is indeed eDirectory related or whether it’s caused by other sources, such as network communication faults. This ability can save you from going on a wild goose chase.
After you’ve determined the cause of eDirectory trouble and formulated an attack plan, it’s time to select your weapons. eDirectory ships with a wide range of utilities, such as DSRepair, iManager, and DSTrace, which you can use to troubleshoot and fix your eDirectory tree. Also, there are a number of third-party tools that help fill the gap in areas that Novell-supplied utilities don’t cover. You need to know the capabilities of these tools, however, and know when to use the one best suited for the task. This is discussed in more detail in Chapters 7, “Diagnostic and Repair Tools,” and 8, “eDirectory Data Recovery Tools.”
As you probably know, troubleshooting is a reactive network management process: You’re on the defensive and are trying to stop the bleeding. Seasoned network managers tell you that the best network management tactic is a proactive one: You should take actions to actively and properly manage your eDirectory so that problems don’t occur in the first place. Treat the health of your eDirectory tree as you would your family’s health: Prevention is better than cure.
Refer to 12, “eDirectory Management Tools,” 13, “eDirectory Health Checks,” and 14, “eDirectory Management Techniques,” for details on proactive eDirectory management tips and information. Of particular interest to security-conscious network administrators is Chapter 15, “Effectively Setting Up eDirectory Security;” that chapter covers various techniques used to detect intruders and minimize eDirectory security risks.
This chapter introduces four eDirectory troubleshooting doctrines that can assist you in quickly and efficiently identifying the cause of and restore any disruptions in your eDirectory tree:
Don’t panic.
Understand the error codes and eDirectory processes.
Troubleshoot and resolve the problem.
Proactively manage eDirectory to prevent problems.
You’ll find in-depth discussion of these topics in the remainder of this book. Before we go into them, however, Chapter 2, “eDirectory Basics,” provides a quick review of eDirectory terminology and basics that you should know and be familiar with before proceeding with the rest of this book.