Don't Panic 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. |
