Managing eDirectory

Once 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 NetWare 6.5, eDirectory management is now available through ever-more-powerful Web-based utilities. NetWare 6.5 includes much more comprehensive eDirectory management options in iManager and iMonitor. For information on installing and configuring both iMonitor and iManager, see Chapter 3, "Novell Management Tools."

iManager provides comprehensive role-based management capabilities for the entire NetWare 6.5 environment. iMonitor consolidates the monitoring and data gathering aspects of several console-based tools, including DSTrace, DSRepair, and DSBrowse. It also includes the reporting functionality of DSDiag. The iMonitor interface is shown in Figure 5.8.

Figure 5.8. The iMonitor user interface.

iManager now provides a complete set of eDirectory management tools and functions for object, partition, and replica operations (see Figure 5.9). Much of this functionality is also available from the Partition and Replica view in ConsoleOne. You can also use RConsoleJ for remote access to the server console from ConsoleOne, from which you can run any of the legacy command- line-based utilities.

Figure 5.9. eDirectory management options in iManager.

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 6, " Users and Network Security ," whereas Printer object management is covered in Chapter 7, " NetWare Printing Services ."

Partition Operations

There are three primary partition operations that you will be required to make:

• 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:

1. Under Partition and Replicas in the navigation frame of iManager, select Create Partition.

2. 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:

1. Under Partition and Replicas in the navigation frame of iManager, 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.

Once 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 subordinate (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:

1. Under Partition and Replicas in the navigation frame of iManager, 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. Similar to partition operations, replica 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:

1. Under Partition and Replicas in the navigation frame of iManager, 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.

Once 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 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:

1. Under Partition and Replicas in the navigation frame of iManager, 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:

1. Under Partition and Replicas in the navigation frame of iManager, 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:

1. Under Partition and Replicas in the navigation frame of iManager, 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:

1. Under eDirectory Maintenance in the navigation frame of iManager, 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 NetWare 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. Once the rename is complete, you will be prompted to log out and log back in to the "new" tree.

Merge Two Trees

iManager moves the capability to perform a tree merge away from the command-line utility DSMERGE.NLM for the first time. 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 NetWare server name, DNS name, or IP address.

3. Provide suitable authentication information for the both the source and 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.

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 NetWare 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.

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 3.

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 5.10). iMonitor provides comprehensive trace capabilities for eDirectory. More detailed information on DS Trace capabilities in iMonitor is available in Appendix D, "Novell eDirectory Reference."

Figure 5.10. The eDirectory process monitoring configuration in iMonitor.

To access the iMonitor Trace page, select DS Trace from the NoRM navigation frame, or click the Trace Configuration icon in the iMonitor header frame.

Trace in iMonitor gives you access to all the process monitoring capabilities formerly available solely through DSTRACE.NLM. Tracing eDirectory activity involves the following tasks:

• From the Trace Configuration page, check the eDirectory process(es) that you want to monitor and click Trace On. Note that Trace pre-selects some of the more common processes. For more information on the individual options listed here, see Appendix D.

• 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.

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, those issues they are intended to resolve. Keep track of the versions that you have installed on your servers, so 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 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 that ships with NetWare 6.5 is 10510.64.

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.

• DSREPAIR.NLM: Look in the header for the DS version.

• Server console: Type MODULES ds* and look for the entry for DS.NLM.

NOTE

Review Novell's support Web site, 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 in the following ways:

• NoRM: Select Health Monitor. Browse to and select TimeSync Status. This will show you the time sync status for the server to which you are currently connected. To check another server, switch to it by selecting Managed Server List, under the Access Other Servers heading, and select the server to which you want to connect.

• DSREPAIR.NLM: Select Time Synchronization from the main menu. This method will show you the synchronization status of all servers known by the server from which you run DSRepair.

• Server console: Type TIME SYNC and review the server's time sync information. This method lets you know only if this single server is synchronized.

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 is 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 DSREPAIR.NLM to repair timestamps and declare a new epoch . To use this option, load DSREPAIR with the -a parameter. Select Advanced Options >> Replica and Partition Operations. Select the partition with which you want to work, and choose Repair Timestamps and Declare a New Epoch.

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

  • iManager: From the eDirectory Maintenance Utilities group in the left pane of iManager, 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.

  • DSREPAIR.NLM: Select Advanced Options >> Replica and Partition Operations. Select the partition to work with and select View Replica Ring. Select the replica to be repaired and choose Receive All Objects for 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 a replica in the ring you want to check for synchronization. Under Partition Synchronization Status, select the Continuity link on the right, as shown in Figure 5.11. This will show you the status of the replica ring in general as well as the status of each replica in the ring.

  Figure 5.11. The Agent Synchronization summary page in iMonitor.

  

• DSREPAIR.NLM: Select Advanced Options >> Replica and Partition Operations. Select the partition you want to check, 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.

   • DSREPAIR.NLM: Select Advanced Options >> 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 previous section on replica operations.

   • DSREPAIR.NLM: From the server that you want to host the new Master replica, load DSRepair with the -a parameter. Select Advanced Options >> Replica and Partition Operations. Select the partition with which to work, and choose Designate This Server as the New Master Replica.

3. Once a healthy Master replica exists, you can receive updates on the server that is having synchronization problems to eliminate any inconsistent objects:

   • iManager: From the eDirectory Maintenance Utilities group in the left pane of iManager, 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.

   • DSREPAIR.NLM: Select Advanced Options >> Replica and Partition Operations. Select the partition to work with and select View Replica Ring. Select the replica to be repaired, and then Receive All Objects for 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: From the eDirectory Maintenance Utilities group in the left pane of iManager, 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.

   • DSREPAIR.NLM: Select Advanced Options >> 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: Select Agent Process Status and review the data under the External Reference Status heading.

• DSREPAIR.NLM: Select Advanced Options >> Check External References.

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 or IPX addresses for each server involved.

   • iMonitor: 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.

   • CONFIG.NLM: Run this console-based utility on each 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.

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 schema synchronization.

Checking External References in this way will help ensure the health and smooth operation of you eDirectory environment.

Check the eDirectory Schema

Anytime 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 communications 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 selecting Agent Configuration and Agent Triggers. 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 previously in this chapter. For information on specific Trace options, see Appendix D .

  
  

• Once the server has been identified, one potential solution is to declare a new epoch on the server. Load DSREPAIR with the -a parameter. Select Advanced Options >> Replica and Partition Operations. 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. From iManager, 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: Select Agent Synchronization, and select the Replica Synchronization link beside the partition with which you need to work.

   • DSREPAIR.NLM: Select Advanced Options >> 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 UNLOAD DS.NLM at the server console. This can be done remotely through iManager or RConsoleJ.

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.

4. Repeat step 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: From the eDirectory Maintenance Utilities group in the left pane of iManager, 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.

   • DSREPAIR.NLM: Select Advanced Options >> Replica and Partition Operations. Select the partition to work with and select View Replica Ring. Select the replica to be repaired and Receive All Objects for 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: From the eDirectory Maintenance Utilities group in the left pane of iManager, 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.

   • DSREPAIR.NLM: Select Advanced Options >> 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 DSRepair switches. Load DSREPAIR with the -a parameter. Select Advanced Options >> Replica and Partition Operations. 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.

Managing eDirectory Traffic

Replication is an event-driven process, meaning that it is initiated by the occurrence of some external trigger. A few of these trigger events include adding, deleting, and moving directory objects, as well as modifying object attributes. Each trigger event is flagged as being high convergence or not. High convergence means that eDirectory considers this event to be more significant than others, and it should be replicated as quickly as possible.

High convergence events are scheduled for fast synchronization (Fast Sync). Fast Sync occurs every 10 seconds by default. Other events are replicated using slow synchronization (Slow Sync). Slow Sync occurs every 30 minutes by default. Both of these sync processes serve to send the changed information out to each server that maintains a replica of the affected partition. Because only the actual database changes are replicated, as opposed to sending the entire partition, replication operations are generally small.

Because each directory operation is timestamped, the synchronization process relies heavily on the time synchronization processes described earlier in this chapter. During the eDirectory synchronization process, each operation will be ordered based upon its timestamp and will be applied to the eDirectory database in that order.

Using WAN Traffic Manager

If your network spans geographical areas, you might want to use the WAN Traffic Manager to control how often eDirectory information is synchronized across the network. WAN Traffic Manager enables you to control when routine eDirectory synchronization takes place, so that the traffic is minimized and/or confined to less active times of day.

WAN Traffic Manager is an optional feature of NetWare 6.5. You can select it for installation during the NetWare 6.5 installation process or you can install it after the fact using iManager.

You need to install WAN Traffic Manager on each server whose traffic you want to control. If servers that share replicas of the same partition are on opposite sides of a WAN link, all those servers should have WAN Traffic Manager installed if you want to control their traffic.

Creating a WAN Traffic Policy

To control the eDirectory traffic, you need to create a WAN traffic policy, which defines the rules that control how the traffic goes out on the network. This policy is stored as a property of each server object. If you have several servers that all require the same policy, you can create a LAN Area object, which contains a list of all the affected servers. Then you can assign the policy to that single LAN Area object, instead of to multiple individual servers.

NetWare 6.5 includes several predefined policies that may suit your situation. For example, one commonly used policy specifies that all routine updates should be performed between 1:00 and 3:00 a.m. You can also edit those policies to create customized policies for your network. For more detailed information about these predefined policies, see the Novell online documentation.

WARNING

Creating and using WAN traffic policies can have adverse effects on your eDirectory communications if done incorrectly. Make sure you understand the consequences of the policy before you enact it. For more information on using WAN Traffic Manager, see the NetWare 6.5 online documentation.

The following predefined policies are available in NetWare 6.5:

• 1-3AM Group: These policies limit eDirectory traffic to be sent between the hours of 1:00 a.m. and 3:00 a.m.

• 7AM-6PM Group: These policies limit eDirectory traffic to be sent between the hours of 7:00 a.m. and 6:00 p.m.

• COSTLT20 Group: These policies allow traffic to be sent only if the cost factor is less than 20. You can assign cost factors to destinations in units, such as dollars per hour or cents per minute.

• IPX Group: These policies allow only IPX traffic.

• NDSTTYPS Group: These policies are sample policies for limiting traffic to specific types of eDirectory traffic and events.

• ONOSPOOF Group: These policies allow eDirectory traffic to be generated only across existing WAN links that are already open.

• OPNSPOOF Group: These policies allow eDirectory traffic to be generated only across existing WAN connections that are already opened, unless the connection hasn't been used for at least 15 minutes. (It assumes the connection is being used for another purpose and is not available.)

• SAMEAREA Group: These policies allow traffic only between servers in the same network section (servers sharing a common network address).

• TCPIP Group: These policies allow only TCP/IP traffic.

• TIMECOST Group: These are additional policies that cover different types of time and cost restrictions.

The following sections explain how to set up a LAN Area object and how to assign a WAN policy to a server or LAN Area object.

Creating a LAN Area object

If you want to assign a single WAN policy to multiple servers, you can save time by creating a LAN Area object that contains a list of all the servers, and then assigning the policy to the LAN Area object. Complete the following steps to create a LAN Area object.

1. Launch iManager and select WAN Traffic in the left side of the navigation frame. Click Create LAN Area.

2. Specify the name of the LAN Area object and the context in which you want it stored.

3. Click Create.

4. Select WAN Traffic Manager Overview in the left side of the navigation frame, and click the LAN Area object you have just created.

5. Configure the LAN Area object as needed and click OK.

   • Policies Tab: From this page, you can define the policy that will govern your eDirectory background process communication. Click Add Policy to select a pre-defined policy, or browse to your own custom policy. Once you have chosen a policy, you can modify the policy specifics in the Policy window.

   • Costs Link: From this page you can associate costs with specific network destinations that WAN Manager can use in its policy calculations. The cost value is simply a number that might represent cents or dollars per minute, or packets per second. Click the Add (+) icon to set a cost value and assign it to a TCP/IP or IPX address or address range. You can also define a default cost that will be applied to all addresses that are not specifically assigned a cost in the cost table.

   • Server List Link: From this page you can add or remove servers as members of this LAN Area object.

When you are finished, the new LAN Area object, along with its associated eDirectory traffic policies, will be active.