11.1 Merging eDirectory Trees

To merge eDirectory trees, use the Merge Tree Wizard in NetIQ iManager. This wizard lets you merge the root of two separate eDirectory trees. Only the Tree objects are merged. Container objects and their leaf objects maintain separate identities within the newly merged tree.

The two trees you merge are called the source tree and the target tree. The target tree is the tree that the source tree will be merged into.

DSMerge does not change object names within the containers. Object and property rights for the merged tree are retained.

11.1.1 Prerequisites

  • NetIQ eDirectory 8.8 must be installed on the server containing the master replica of the source tree's [Root] partition.

  • Other servers in the source tree should be upgraded to eDirectory 8.6 or later to ensure proper functionality.

NOTE:To delete Authorized Login Methods, use the ldapdelete tool or ConsoleOne.

11.1.2 Target Tree Requirements

  • NetIQ eDirectory 8.8 must be installed on the server containing the master replica of the target tree's [Root] partition. If this server is running any other version of NDS® or eDirectory, the merge operation will not complete successfully.

  • Other servers in the target tree should be upgraded to eDirectory 8.6 or later to ensure proper functionality.

  • You cannot maintain containers with the same name subordinate to Tree in both the source and target trees. Before merging two trees, one of the containers must be renamed.

  • If both the source and target trees have a Security object, one of them must be removed before merging the trees.

11.1.3 Schema Requirements

Before attempting to perform a merge operation, the schema of both trees must match exactly. You should run DSRepair on the server containing the master replica of the [Root] partition for each tree. Use the Import Remote Schema option to ensure that each tree is aware of all schema in the other tree.

  1. In NetIQ iManager, click the Roles and Tasks button Roles and Tasks button.

  2. Click eDirectory Maintenance > Schema Maintenance.

  3. Specify which server will perform the schema maintenance operation, then click Next.

  4. Authenticate to the specified server, then click Next.

  5. Click Import Remote Schema > Next.

  6. Specify the name of the tree the schema is to be imported from.

  7. Click Start.

    You might have to perform this option on both the source and target tree until no schema differences are reported. Otherwise, the merge operation will not succeed.

  8. When a “Completed” message appears with information returned from the schema maintenance operation, click Close to exit.

11.1.4 Merging the Source into the Target Tree

When you merge the trees, the servers in the source tree become part of the target tree.

The target Tree object becomes the new Tree object for objects in the source tree, and the tree name of all servers in the source tree is changed to the target tree's name.

After the merge, the tree name for the target tree servers is retained.

The objects that were subordinate to the source Tree object become subordinate to the target Tree object.

11.1.5 Partition Changes

During the merge, DSMerge splits the objects below the source Tree object into separate partitions.

All replicas of the Tree partition are then removed from servers in the source tree, except for the master replica. The server that contained the master replica of the source tree receives a replica of the target tree's Tree partition.

Figure 11-1 and Figure 11-2 illustrate the effect on partitions when you merge two trees.

Figure 11-1 eDirectory Trees before a Merge

Figure 11-2 Merged eDirectory Tree

11.1.6 Preparing the Source and Target Trees

Before performing a merge operation, ensure that the state of synchronization for all servers affected by the operation is stable. The following table provides prerequisites for preparing source and target trees for merging.

Prerequisite

Required Action

WANMAN should be turned off on all servers that hold a replica of the source tree's Tree partition or the target tree's Tree partition.

Review your WANMAN policy so that WAN communication restrictions do not interfere with the merge operation. If required, turn WANMAN off before initiating the merge operation.

No aliases or leaf objects can exist at the source tree's Tree object.

Delete any aliases or leaf objects at the source tree's Tree object.

No identical names can exist between the source and target trees.

Rename objects on the source and target trees if identical names exist. Move objects from one of the containers to a different container in its tree if you don't want to rename the container objects, then delete the empty container before running DSMerge. For more information, see Section 3.0, Managing Objects.

You can have identical container objects in both trees if they are not immediately subordinate to the Tree object.

No login connections should exist on the source tree.

Close all connections on the source tree.

The eDirectory version must be the same on both the source and target trees.

Upgrade all non-eDirectory 8.8 servers that have a replica of the root partition.

The target tree must have only one copy of the root replica.

Remove all replicas on the target tree except the master replica.

The schema on both the source and target trees must be the same.

Run DSMerge. If reports indicate schema problems, use DSRepair to match the schemas. See Importing Remote Schema for more information. Run DSMerge again.

Only one tree can have a security container subordinate to the tree root.

If both the source and target trees have a security container, remove one container as explained in Section A.0, NMAS Considerations.

Because the merge operation is one single transaction, it is not subject to catastrophic failure caused by power outages or hardware failure. However, you should perform a regular backup of the eDirectory database before using DSMerge. For more information, see Section 17.0, Backing Up and Restoring NetIQ eDirectory.

11.1.7 Synchronizing Time before the Merge

IMPORTANT:Proper configuration of time synchronization is a very involved process. Make sure you allow enough time to synchronize both trees before you merge the trees.

NetIQ eDirectory will not work properly if different time sources are used that have different times or if all servers in a tree are not time synchronized.

Before you do the merge, make sure that all servers in both trees are time synchronized and that they use only one time server as a time source. However, the target tree time can be ahead of the source tree time by as much as five minutes.

Generally, there should be only one Reference or one Single time server in a tree. Likewise, after the merge, the tree should contain only one Reference or one Single time server.

If each of the trees you are merging has either a Reference or a Single time server, reassign one of them to refer to the Reference or Single time server in the other tree so that the final merged tree contains only one Reference or Single time server.

For more information on time server types, see “Time Services” in the OES Planning and Implementation Guide.

11.1.8 Merging Two Trees

For complete functionality of all menu options, run DSMerge on a server that contains the master replica of the Tree partition.

If you don't know where the master replica is stored, you will be prompted with the correct server name when you attempt an operation that requires the master replica.

To perform a merge operation, use either of the following methods:

When merging large trees, it is significantly faster to designate the tree with the fewest objects immediately subordinate to the Tree object as the source tree. By doing this, you create fewer partition splits during the merge, because all objects subordinate to the Tree object result in new partitions.

Because the source tree name no longer exists after the merge, you might need to change your client workstation configurations. For the Novell Client for DOS/Windows, check the Preferred Tree and Preferred Server statements in the net.cfg files. For the Novell Client for Windows, check the Preferred Tree and Preferred Server statements on the client Property Page.

If Preferred Server is used, the client is unaffected by a tree merge or rename operation because the client still logs in to the server by name. If Preferred Tree is used and the tree is renamed or merged, then that tree name no longer exists. Only the target tree name is retained after the merge. Change the preferred tree name to the new tree name.

HINT:To minimize the number of client workstations you need to update, designate the tree with the most client workstations as the target tree, because the final tree retains the name of the target tree. Or rename the tree after the merge operation so that the final tree name corresponds to the tree with the greater number of client workstations attaching to it. For more information, see Section 11.3, Renaming a Tree.

Use the following list of prerequisites to determine readiness for the merge operation:

  • You have access to the source tree server through iManager

  • You have the name and password of the Administrator objects that have Supervisor object rights to the Tree object of both trees you want to merge

  • The eDirectory database for the two trees has been backed up

  • All servers in both trees are synchronized and using the same time source

  • (Optional) All servers in the tree are operational (Servers that are down will update automatically when they are operational.)

  • Review the merge prerequisites listed in Preparing the Source and Target Trees

The merge process itself only takes a few minutes, but there are other variables that increase the length of time for the merge operation to complete:

  • Many objects subordinate to the Tree object that must be split into partitions

  • Many servers in the source tree that require a tree name change

To merge two trees:

  1. In NetIQ iManager, click the Roles and Tasks button Roles and Tasks button.

  2. Click eDirectory Maintenance > Merge Tree.

  3. Specify which server will run Merge (this will be the source tree), then click Next.

  4. Authenticate to the server, then click Next.

  5. Specify an Administrator user name and password for the source tree.

  6. Specify the target tree name and the Administrator user name and password, then click Start.

    A Merge Tree Wizard Status window appears and shows the progress of the merge.

  7. When a “Completed” message appears with information returned from the merge process, click Close to exit.

11.1.9 Post-Merge Tasks

Following the merging of two trees, it might be necessary to complete the following steps:

  1. Verify that all tree names were changed correctly.

  2. Check the new partitions that the merge operation created.

    If you have many small partitions in the new tree, or if you have partitions that contain related information, you might want to merge them. For more information, see Section 6.2, Merging a Partition.

  3. Re-create any leaf objects or aliases in the tree that were deleted before you ran DSMerge.

  4. Evaluate partitioning of the eDirectory tree.

    Merging trees might change replica placement requirements on the new tree. You should carefully evaluate and change the partitioning as needed.

  5. Update your client workstation configuration.

    For the Novell Client for Windows, check the Preferred Tree and Preferred Server statements on the client Property Page, or rename the target tree.

    If Preferred Server is used, the client is unaffected by a tree merge or rename operation because the client still logs in to the server by name. If Preferred Tree is used and the tree is renamed or merged, then that tree name no longer exists. Only the target tree name is retained after the merge. Change the preferred tree name to the new tree name.

The Access Control List (ACL) for the Tree object of the source tree is preserved. Therefore, the rights of the source tree's user Admin to the Tree object are still valid.

After the merge is complete, both admin users still exist and are uniquely identified by different container objects.

For security reasons, you might want to delete one of the two Admin User objects or restrict the rights of the two objects.