Managing eDirectory

When you have an understanding of the basics of eDirectory architecture and design, it is important to understand the activities and tools necessary to maintain eDirectory on a day-to-day basis.

As with the rest of OES Linux, eDirectory management is performed through web-based utilities. Specifically, comprehensive eDirectory management is available through iManager and iMonitor. For information on installing and configuring both iMonitor and iManager, see Chapter 5, "OES Management Tools."

iManager provides comprehensive role-based management capabilities for the entire OES Linux environment. iMonitor consolidates the monitoring and data-gathering aspects of several terminal-based tools, including ndstrace and ndsrepair. It also includes the object viewing and reporting functionality of the NetWare-only utilities, DSBrowse and DSDiag. The iMonitor interface is shown in Figure 7.8.

Figure 7.8. The iMonitor user interface.

iManager provides a complete set of eDirectory management tools and functions for object, partition, and replica operations. Much of this functionality is also available from the Partition and Replica view in ConsoleOne. As mentioned in Chapter 5, although ConsoleOne is not provided with OES Linux, this utility can still be used in existing infrastructures or specifically downloaded from download.novell.com. You can also use SSH for remote access to a server terminal, from which you can run several eDirectory-specific terminal-based utilities.

This section gives you an overview of common eDirectory tasks and the tools used to perform them. eDirectory management tasks can be organized into six main categories:

• Partition operations

• Replica operations

• Tree operations

• eDirectory repair

• Monitoring eDirectory

• Managing synchronization

NOTE

Managing specific eDirectory objects is covered in the appropriate chapter on that topic. For example, User and Group object management is covered in Chapter 8, "Users and Network Security," whereas Printer object management is covered in Chapter 13, "OES Printing Services."

Partition Operations

You will be required to make three primary partition operations:

• Create a partition

• Merge a partition

• Move a partition

WARNING

eDirectory does a great deal of work when performing partition operations. In larger eDirectory environments, each of the operations described in the following sections can take a significant amount of time to process completely. Furthermore, each operation has to complete before the next can begin. Make sure you take this into account when planning these tasks.

CREATE A PARTITION

The first operation we want to look at is creating a partition. As mentioned earlier, partitioning the tree serves to break up the eDirectory database into chunks that can be distributed across multiple servers for fault tolerance and increased performance.

If you want to create a new partition, complete the following steps in iManager:

1.	In the Navigation frame, open the Partition and Replicas group and select Create Partition.
2.	In the Content frame, browse to and select the container that will be the root of the child partition, and then click OK.
3.	Select Close at the message that eDirectory is processing your request.

By default, the Master replica of the new partition is created on the server that maintains the Master replica of the parent partition. Read/Write replicas are stored on servers that maintain Read/Write replicas of the parent partition. You can move or change replica placement after the partition has been created, if desired.

MERGE A PARTITION

Sometimes you want to consolidate partitions, such as when moving from an older NDS environment to a much more scalable eDirectory tree. To merge a partition with its parent, complete the following steps in iManager:

1.	In the Navigation frame, open the Partition and Replicas group and select Merge Partition.
2.	Browse to and select the container that is the root of the child partition, and then click OK.
3.	Select Close at the message that eDirectory is processing your request.

When merged, all replicas of the child partition are removed and the child partition data will be replicated to the existing parent partition replicas.

MOVE A PARTITION

The partition move operation is commonly known as a prune and graft. It involves moving a partition and all its associated containers and objects from one location in the tree to another (pruning a branch from one part of the tree and grafting it in somewhere else). This is the most complex of the partition operations, so note the following qualifications before attempting a partition move:

• You cannot move a container unless it is a partition root. If you want to move a container that is not a partition, you first need to define it as a partition. Then you can move the container to its new location and merge it with its new parent partition.

• This operation is available only to partitions that do not have any sub-ordinate (child) partitions. If you want to move a partition with subordinates, you will have to merge the subordinates into the parent partition first.

• When you move a partition, you must follow eDirectory containment rules that define what type of objects can be placed in each type of eDirectory container object. For example, you cannot move an organizational unit directly under the root of the tree because the containment rules for [Root] allow only Locality, Country, Organization, and Security objects, and not Organizational Unit objects.

If you want to prune and graft a partition, complete the following steps in iManager:

1.	In the Navigation frame, open the Partition and Replicas group and select Move Partition.
2.	Provide the required information and click OK. In the Object Name dialog box, browse to and select the container you want to move. In the Move To dialog box, browse to and select the new location for the partition. This will be the container within which the new partition will be placed. Check Create an Alias in Place of Move Object if you want users to be able to continue accessing those objects from their original directory context. This is usually a good idea at least until all users have been notified of the location change.
3.	At the Move summary, click Move to perform the prune and graft.

The summary screen lists all servers involved in the Move operation so that you can make sure everything is in good shape before attempting the move.

Replica Operations

Now that you have eDirectory partitions created and situated within the tree, you might notice that the default placement for the replicas is less than perfect. After all, you probably don't want all Master replicas on one server, and you want to avoid replicating across expensive WAN links, as discussed previously. Replica operations, similar to partition operations, are accomplished from iManager in Partition and Replica Management. There are four primary replica operations:

• Add a replica

• Change the replica type

• Delete a replica

• Create a Filtered replica

Selecting Replica View in iManager shows you all servers that hold replicas of the selected partition. These servers form the replica ring.

NOTE

You will likely see Subordinate reference replicas listed in the iManager Replica View. However, Subordinate references are not manageable in iManager, so their placement is purely informational.

ADD A REPLICA

If you want to place a partition replica on a server that does not currently have a copy of that partition, complete the following steps in iManager:

1.	In the Navigation frame, open the Partition and Replicas group and select Replica View.
2.	Browse to and select the partition for which you want a new replica and click Add Replica.
3.	Specify the server on which you want to create the replica, select the type of replica you are going to create, and then click OK.
4.	Click Done to exit the Replica View.

When created, the new partition will participate in all replication processes for that partition. Too many replicas can slow down partition operations significantly, so try to limit the number of replicas to three.

CHANGE THE REPLICA TYPE

Sometimes it is useful to be able to change the type of an existing replica. For example, if a Master replica is stored on a server and it is going down for a hardware upgrade, you can change an existing Read/Write replica to be the Master so that eDirectory partition operations can continue normally.

NOTE

You cannot change the type of a Master replica because a Master replica must exist for every partition. If you want to change a Master replica, change an existing Read/Write replica to be the new Master, and the existing Master will automatically be converted to a Read/Write.

If you want to change the type of a replica, complete the following steps in iManager:

1.	In the Navigation frame, open the Partition and Replicas group and select Replica View.
2.	Browse to and select the partition for which you want to change a replica type, and then click OK.
3.	In the Type column, select the replica that you want to change.
4.	Specify the type of replica to which you want to change the replica and click OK.
5.	Click Done to exit the Replica View.

The replica will immediately start behaving as the new replica type you have selected.

NOTE

You cannot create a Master replica from a Filtered replica.

DELETE A REPLICA

Sometimes, when partitions have been merged or moved, a given replica is no longer necessary. To delete an existing replica from a server, complete the following steps in iManager:

1.	In the Navigation frame, open the Partition and Replicas group and select Replica View.
2.	Browse to and select the partition for which you want to delete a replica, and click OK.
3.	Click the red X next to the replica name that you want to delete, and click OK in the Delete Replica window.
4.	Click Done to exit the Replica View.

The replica is removed from the server on which it was stored, and all future partition operations will include only the remaining replicas.

CREATE A FILTERED REPLICA

If you are using Filtered replicas in your network, you can configure them with the Replica Wizard option in iManager. To create a Filtered replica, complete the following steps in iManager:

1.	In the Navigation frame, open the Partition and Replicas group and select Filtered Replica Wizard.
2.	Browse to and select the server on which the Filtered replica will reside, and then click Next.
3.	Click Define the Filter Set to specify the object classes and attributes to include in this Filtered replica. Only one filter can be configured per server, meaning that you can only have Filtered replicas of one type on any given server.
4.	Click The Filter Is Empty, select the eDirectory objects and classes that you want included in the Filtered replica, and then click OK. Alternatively, you can select Copy Filter From to specify an existing server with the type of Filtered replica you need, and it will be copied to the new server.
5.	(Optional) Click Next to continue. You can click Define Partition Scope to add partitions for which you want to create Filtered replicas on this server. This opens the Replica View so that you can add replicas to the server.
6.	Click Finish to create the Filtered replicas as defined.

Filtered replicas are often used when eDirectory is sharing data with an external system, such as another directory or database, but only a subset of eDirectory information is shared.

Tree Operations

There are a few operations that you can perform on an entire eDirectory tree, and these are available from iManager as well. Each of these operations is available under eDirectory Maintenance:

• Rename a tree

• Merge two trees

• Graft one tree into another

NOTE

Tree operations are complex operations that are not recommended for those who are not experienced eDirectory administrators. You can easily damage trees with these operations, so be very careful and perform these types of tree operations only when it is absolutely necessary.

RENAME A TREE

Once in a while it might become necessary to rename an eDirectory tree. Perhaps an organizational name change has occurred, or you are moving to match your directory-naming scheme to that being used on the Web. Whatever the reason, you can rename your tree by completing the following steps in iManager:

1.	In the Navigation frame, open the eDirectory Maintenance group and select Rename Tree.
2.	Specify the name of the server that will perform the rename operation and click Next. You can specify the server by eDirectory server name, DNS name, or IP address.
3.	Specify suitable authentication information for the tree and click Next. Make sure you authenticate as a user with Supervisor rights to the tree.
4.	Provide the necessary information and click Start. Specify the new tree name, the Admin username (with context), and the Admin password. Remember that the tree name can be up to 32 alphanumeric characters (dashes and underscores are also allowed).
5.	Click Yes to rename the tree.

The utility will first perform a check on the tree to be sure that it can be renamed successfully. When the rename is complete, you will be prompted to log out and log back in to the "new" tree.

The terminal-based ndsmerge utility can also be used to rename a tree. To perform this operation with this utility, open up a terminal and execute the following command:

 ndsmerge r <target-tree> <source-admin> 

MERGE TWO TREES

iManager and the terminal-based ndsmerge utility both have the capability to perform a tree merge. During a tree merge, a source tree is inserted into a target tree such that the tree branches at the Organization level, with each branch corresponding to the contents of one of the formerly distinct trees. To perform a tree merge from iManager, complete the following steps:

1.	Under eDirectory Maintenance in the navigation frame of iManager, select Merge Tree.
2.	Specify the name of the server that will perform the merge operation for the trees and click Next. You can specify the server by eDirectory server name, DNS name, or IP address.
3.	Provide suitable authentication information for both the source and the target eDirectory trees and click Next. Make sure you authenticate as a user with Supervisor rights to the tree.
4.	Provide the necessary information and click Start. Source Tree The source tree is the tree to which you are currently authenticated. It will be merged into the target tree. Specify the name and password of the Admin user for this tree. Target Tree The target tree is the tree that will remain after the merge. The source tree information will become part of this tree. Specify the name and password of the Admin user for this tree.
5.	Click Yes to rename the tree.

The utility will first perform a check on both trees to be sure that they can be successfully merged. If you encounter an error during this check process, follow the instructions to resolve the conflict and try the merge again.

To perform a tree merge using the ndsmerge terminal utility, the source and destination trees, along with administrative credentials must be specified on the command line as in the following example:

 ndsmerge m <target-tree> <target-admin> <source-admin> 

GRAFT ONE TREE INTO ANOTHER

A graft is a subset of a merge, in which you can choose the insertion point for the source tree objects. During a tree graft, a source tree is inserted into the specified location of a target tree. The source tree is then converted into a Domain object and it and all of its contents become part of the target tree. To graft one tree into another, complete the following steps:

1.	Under eDirectory Maintenance in the navigation frame of iManager, select Graft Tree.
2.	Specify the name of the server that will perform the graft operation and click Next. You can specify the server by eDirectory server name, DNS name, or IP address.
3.	Specify suitable authentication information for the tree and click Next. Make sure you authenticate as a user with Supervisor rights to the tree.
4.	Provide the necessary information and click Start. Source Tree The source tree is the tree to which you are currently authenticated. It will be grafted into the target tree. Specify the name and password of the Admin user for this tree. Target Tree The target tree will receive the source tree information as a Domain object after the graft. The source tree information will become part of this tree. Specify the name and password of the Admin user for the target tree. Specify the point at which you want the source tree inserted in the Container field.
5.	Click Yes to perform the graft operation.

The utility will first perform a check on both trees to be sure that they can be successfully merged. If you encounter an error during this check process, follow the instructions to resolve the conflict and try the merge again.

To perform a tree graft using the ndsmerge terminal utility, the source and destination trees, target container, and administrative credentials, must all be specified on the command line as in the following example:

 ndsmerge m <target-tree> <target-admin> <source-admin> <target-container> 

NOTE

For more information on ndsmerge, please see ndsmerge help.

Monitoring and Maintaining eDirectory

This section identifies some common administrative tasks that will help you effectively monitor the operation of eDirectory in your network and make little repairs as they are found. After all, the one thing more impressive than resolving a serious network problem is preventing it from occurring in the first place. Although this is not always possible, a program of active monitoring and proactive maintenance will go a long way toward getting you home on time at night. For more information on Novell management tools, see Chapter 5.

The following tasks are a starting point for maintaining your eDirectory environment. By monitoring eDirectory process execution, you can see every type of communication activity and determine whether any errors are being reported. The best way to keep track of the activities of eDirectory processes is through iMonitor (see Figure 7.9). iMonitor provides comprehensive trace capabilities for eDirectory. More detailed information on DSTrace capabilities in iMonitor is available in Appendix C, "eDirectory Reference Materials."

Figure 7.9. The eDirectory process monitoring configuration in iMonitor.

To access the iMonitor Trace page, use a browser to connect to iMonitor and click the Trace Configuration icon in iMonitor's Header frame. iMonitor can be accessed from the Novell eDirectory 8.7 Welcome page found on the OES home page, or can be accessed directly using the iMonitor URL. The iMonitor URL is

http://www.quills.com:8028/nds/summary

iMonitor Trace gives you web-based access to monitor all eDirectory processes. Tracing eDirectory activity involves the following tasks:

• From the Trace Configuration page, check the eDirectory processes that you want to monitor and click Trace On. Note that Trace preselects some of the more common processes. For more information on the individual options listed here, see Appendix C.

• To see a live view of the trace, select Trace History in the left side of the navigation frame, and click the View icon next to the current trace session.

• To stop a trace, click Trace Off in the Trace Configuration screen. Because of the added overhead and the size to which log files can grow, you usually want to run DSTrace for only enough time to gather the information for which you are looking.

eDirectory traces provide a powerful tool to track eDirectory processes and monitor operations when troubleshooting directory issues.

NOTE

There is also a terminal-based trace utility called ndstrace. The ndstrace utility can be used directly on an OES Linux terminal to view eDirectory activity. For information on using ndstrace, enter help ndstrace after starting the ndstrace utility.

VERIFY THE VERSION OF EDIRECTORY

Even if you don't apply updates immediately, it's a good idea to be aware of what updates exist and, more importantly, what issues they are intended to resolve. Keep track of the versions that you have installed on your servers so that as you review Novell support documents, you can keep an eye out for any problems that might relate to your environment.

NOTE

With the release of eDirectory in NetWare 6, Novell implemented a new versioning scheme in an attempt to eliminate inconsistencies in the previous model. Although still known as eDirectory v8.6 or 8.7 to provide eDirectory customers with a version context they are familiar with, the build version takes a considerably different format. For example, the build version of eDirectory 8.7 that ships with OES Linux is 10551.46.

You can check the version of eDirectory that you are currently running on any server in the following ways:

• iMonitor Select Known Servers. The DS revision for all known eDirectory servers is listed.

• ndsrepair Use the -E startup option to report eDirectory synchronization status. eDirectory and ndsrepair versions are displayed in the header.

• ndsmerge Use the c startup option to report all servers in the current tree, as well as their running status and eDirectory versions.

• ndsstat This utility reports the tree and server name as well as the eDirectory binary and product versions.

NOTE

Review Novell's support website, http://support.novell.com, on at least a quarterly basis for updates to eDirectory files and utilities.

VERIFY THAT TIME IS SYNCHRONIZED

Check the time sync status for each partition in the tree every couple of weeks. Keep an eye out for synthetic time messages that might keep background processes from completing properly.

You can check the status of time synchronization between eDirectory servers in the following ways:

• ndsrepair Use a -T startup option to show you the time synchronization status of all servers known by the server from which you run ndsrepair.

• ndsmerge Use a -T startup option to show you the time synchronization status of all servers.

NOTE

The ntpq utility can be used to check time synchronization status of the local NTP client daemon. Although being synchronized to an NTP time source is important, it is technically more important that servers with eDirectory are in time sync with each other. The ndsrepair and ndsmerge utilities are used to check time synchronization between servers in the same eDirectory tree. If time sync problems are located, they are often resolved by properly configuring the local NTP client. More information on configuring NTP is available in Chapter 2, "Installing OES Linux."

If time is not synchronizing properly, you can run into problems with the timestamps that are maintained on eDirectory objects. Timestamps indicate when the object was last synchronized.

Probably the best-known eDirectory timestamp issue is synthetic time. Synthetic time occurs when an eDirectory object has a modification timestamp ahead of current network time. If the period between current time and synthetic time is small, this problem will correct itself. However, if the period is large, it is possible to resolve the problem manually by reviewing the eDirectory communications processes to be sure that all replicas are communicating properly. From iMonitor, review the status of the Master replica from Agent Summary. You can drill down on the Master to review current state and a detailed set of statistics. Make sure the Master does not contain any errors, and that it is receiving current updates properly.

Timestamps can be repaired in two ways:

• Use ndsrepair to repair timestamps and declare a new epoch. To use this option, load ndsrepair with the P -Ad parameters. Enter the desired partition number, and select the Repair Timestamps and Declare a New Epoch option.

• Identify the replica(s) with the synthetic timestamps and rebuild those replicas using the Receive All Objects operation:

  • iManager In the Navigation frame, open the eDirectory Maintenance group and select Replica Ring Repair. Specify the server that you want to receive correct replica information from the Master replica. Select the Receive All Objects option.

  • ConsoleOne Open the Partition and Replica view in ConsoleOne. Browse to and select the container on which you are going to work and select the Partition Continuity button from the toolbar. In the Partition Continuity table, highlight the replica you need to repair and select Receive Updates.

  • ndsrepair Use the -P startup options to invoke Replica and Partition Operations. Enter the desired partition number to work with and select the View Replica Ring operation. Select the replica number to be repaired and choose Receive All Objects from the Master to This Replica.

WARNING

This operation generates a large amount of eDirectory-related traffic as timestamps for all replicas are reset.

VERIFY REPLICA SYNCHRONIZATION

You can view synchronization status from several perspectives. However, making sure that all replicas of a given partition are synchronizing properly is probably one of the best ways to keep track of things. Check this every couple of weeks.

You can check the sync status of a replica ring in the following ways:

• iMonitor From the Agent Summary, select the Continuity link next to the Partition for which you want to check synchronization status (see Figure 7.10). This will show you the status of the replica ring in general as well as the status of each replica in the ring.

  Figure 7.10. The Agent Synchronization summary page in iMonitor.

  
  
  

• ndsrepair Use the -E startup option to view synchronization status for all partitions. To select a specific partition, use the -P startup option and then select the desired partition and choose Report Synchronization Status of all Servers.

If you begin to notice inconsistencies in replica rings, you can use the following general steps to diagnose and resolve the problems:

1.	Identify all servers that host replicas of this partition and the type of replica on each server. iMonitor Select Agent Synchronization, and then select the Replica Synchronization link beside the partition with which you need to work. ndsrepair Use the -P startup option to begin Replica and Partition Operations. Select the partition to work with and select View Replica Ring.
2.	Examine the server hosting the Master replica because it functions as the authoritative source for partition information. If the Master replica is the source of the problem, designate one of the Read/Write replicas as a new Master: iManager Follow instructions outlined in the earlier section on replica operations. ndsrepair From the server that you want to host the new Master replica, start ndsrepair with the P -Ad parameters. Select the partition with which to work, and choose Designate This Server as the New Master Replica.
3.	When a healthy Master replica exists, you can receive updates on the server that is having synchronization problems to eliminate any inconsistent objects: iManager In the Navigation frame, open the eDirectory Maintenance group and select Replica Ring Repair. Specify the server holding the Master replica for the partition and select the Send All Objects option. ConsoleOne Open the Partition and Replica view in ConsoleOne. Browse to and select the container on which you are going to work and select the Partition Continuity button from the toolbar. In the Partition Continuity table, highlight the replica you need to repair and select Receive Updates. ndsrepair Use the -P startup options to invoke Replica and Partition Operations. Enter the desired partition number to work with and select the View Replica Ring operation. Select the replica number to be repaired and choose Receive All Objects from the Master to This Replica.
4.	Monitor the replica ring after making repairs to make sure that it is successfully sending updates between all replica-hosting servers. You can perform a send-updates operation from the Master replica by doing the following: iManager In the Navigation frame, open the eDirectory Maintenance group and select Replica Ring Repair. Specify the server holding the Master replica for the partition and select the Send All Objects option. ConsoleOne Open the Partition and Replica view in ConsoleOne. Browse to and select the container on which you are working and select the Partition Continuity button from the toolbar. In the Partition Continuity table, highlight the server with the Master replica and select Send Updates. ndsrepair Use the -P startup option to invoke Replica and Partition Operations. Select the partition to work with, and then select View Replica Ring. Select the Master replica, and then Send All Objects to Every Replica in the Ring.

You should regularly use the preceding techniques to monitor synchronization activities and make sure that eDirectory is performing properly.

CHECK EXTERNAL REFERENCES

External references are pointers to eDirectory objects not stored in replicas on the current server. The check examines each external reference and makes sure that it links to a valid eDirectory object. Performing this check on a weekly basis makes sure that queries can traverse the tree properly.

You can do one of the following to check external references:

• iMonitor In the Navigation frame, select Agent Process Status. Review the data under the External Reference Status heading.

• ndsrepair Use the -C startup parameter to automatically perform the Check External References procedure.

One nice thing about the external reference check is that it will list any obituaries in your tree. Obituaries are references to deleted objects that are maintained until word of the deletion has been propagated to all servers hosting replicas of the affected partition. It is possible for obituaries and other types of external references to become corrupt or get stuck in the tree.

One thing that can cause this is problems with network addresses. To resolve network referral problems, do the following:

1.	Identify the actual assigned IP address for each server involved. iMonitor In the Navigation frame, select Known Servers. Select the link for the server you want to look at, and then browse down and select Network Address in the left side of the navigation frame. ifconfig Run this terminal utility on each Linux server you want to check. CONFIG.NLM For mixed platform environments, run this console-based utility on each NetWare server you want to check.
2.	Check network addresses to make sure that the addresses stored by eDirectory match those being reported by the servers in their SLP or SAP broadcasts. In iMonitor, click the Repair icon and select Advanced. Select Repair Network Addresses and click Start Repair. Use the Known Servers option in iMonitor to repeat this process for each server hosting eDirectory replicas in the network. This same procedure can be performed using ndsrepair tHRough the -N startup option. Server addresses can be repaired individually, or the addresses for all known servers can be repaired.
3.	More severe problems might require a rebuild of replicas that have received invalid network address information, as described in the previous section on verifying replica synchronization.

Checking external references in this way will help ensure the health and smooth operation of your eDirectory environment.

CHECK THE EDIRECTORY SCHEMA

Whenever you make changes to the eDirectory schema, confirm that all servers hosting eDirectory replicas are properly receiving schema updates. You can check the schema synchronization status in iMonitor by selecting Agent Process Status, and then reviewing the data under the Schema Sync Status heading.

It is possible that an eDirectory server, due to communication problems or corruption of synchronization timestamps, will fail to receive schema updates as they are applied to the eDirectory environment. The resulting schema inconsistencies can be resolved by doing the following:

• Identify the server that is reporting schema errors. This will be the server that has not received the schema updates properly. In iMonitor, force schema synchronization by clicking the Agent Configuration icon in the Header frame and then selecting Agent Triggers in the Navigation frame. Check the Schema Synchronization box and select Submit. Before doing this, make sure that DSTrace is configured to report Schema Sync messages and that it is currently logging in to iMonitor.

  TIP

  You can also view the schema sync in iMonitor as it occurs with Trace. Using Trace is described earlier in this chapter. For information on specific Trace options, see Appendix C.

  
  

• When the server has been identified, one potential solution is to declare a new epoch on the server. Start ndsrepair with the P -Ad parameters. Select the partition with which you want to work, and then choose Repair Timestamps and Declare a New Epoch.

Unless you are making frequent changes to the schema, these types of activities shouldn't be necessary, but you should be aware of how such schema issues can be resolved.

REVIEW TREE FOR UNKNOWN OBJECTS

On a monthly basis, search eDirectory for unknown objects. You can do this from iManager by completing the following steps (you can also search for unknown objects from ConsoleOne):

1.	In the Header frame, click the View Objects icon.
2.	In the left pane, select the Search tab.
3.	Select Unknown in the Type field. Make sure that you are searching from [Root] and that the Search Sub-containers option is checked.

Unknown objects can indicate resources that have not been properly installed or removed from the tree. However, they can also indicate that iManager or ConsoleOne does not have a snap-in capable of recognizing that object type, so don't immediately assume that unknown objects need to be deleted.

It is also possible to get eDirectory object and attribute inconsistencies when replicas of the same partition, for whatever reason, have different information stored about the same eDirectory object or object attribute. In order to isolate the server(s) that have the faulty information, it is necessary to unload eDirectory on other servers. This type of troubleshooting can only be done during off hours.

In order to troubleshoot this type of problem, do the following:

1.	Identify all servers that host replicas of the partition, and note the type of replica on each server. iMonitor In the Navigation frame, select Agent Synchronization. Select the Replica Synchronization link beside the partition with which you need to work. ndsrepair Use the -P startup option to begin Replica and Partition Operations. Select the partition to work with and select View Replica Ring.
2.	Select one of the servers and unload eDirectory by entering /etc/init.d/ndsd stop at the server console.
3.	Use ConsoleOne to query the tree for the faulty objects and/or attributes. If they are still faulty, you know this server's replica is not the source of the error. Be sure to restart the ndsd (/etc/init.d/ndsd start) process after determining the validity of objects stored on that server.
4.	Repeat steps 2 and 3 until the faulty server(s) is (are) found.
5.	To attempt to repair the problem, first attempt to receive updates at the faulty server: iManager In the Navigation frame, open the eDirectory Maintenance group and select Replica Ring Repair. Specify the server that you want to receive correct replica information from the Master replica. Select the Receive All Objects option. ConsoleOne Open the Partition and Replica view in ConsoleOne. Browse to and select the container on which you are going to work and select the Partition Continuity button from the toolbar. In the Partition Continuity table, highlight the replica you need to repair and select Receive Updates. ndsrepair Use the -P startup parameter to begin Replica and Partition Operations. Select the partition to work with and select View Replica Ring. Select the replica to be repaired and enter Receive All Objects from the Master to This Replica.
6.	If that fails, attempt to send all objects from one of the known good servers. If possible, use the Master replica for this operation. iManager In the Navigation frame, open the eDirectory Maintenance group and select Replica Ring Repair. Specify the server holding the Master replica for the partition and select the Send All Objects option. ConsoleOne Open the Partition and Replica view in ConsoleOne. Browse to and select the container on which you are working and select the Partition Continuity button from the toolbar. In the Partition Continuity table, highlight the server with the Master replica and select Send Updates. ndsrepair Use the -P parameter to begin Replica and Partition Operations. Select the partition to work with and select View Replica Ring. Select the Master replica, and then Send All Objects to Every Replica in the Ring.
7.	If that fails, the replica has to be destroyed. At this point you might want to involve Novell Technical Support, unless you are comfortable with the use of advanced ndsrepair options. Start ndsrepair with the P -Ad parameters. Select the partition with which you want to work, and then select the Destroy the Selected Replica on This Server option.

These tasks will help you ensure the object health within your eDirectory tree and stay on top of the health of your eDirectory environment.