This application will collect information about the servers and/or partitions of the selected tree and allow you to export the information to a specified file.

In addition to this, you may select the identified servers or partitions to perform a variety of eDirectory operations.

* select the target tree

* choose to scan for servers and/or partitions

* optionally export the data to the selected format

* double-click on a partition or server name to open the action dialog

Interpretation of selected fields:

For NCP servers, the following fields will be displayed:

'Server' Server Short Name
'Context' Relative Context
'Version' OS Version
'DS Revision' eDirectory Version
'Network Address' IP/IPX Addresses - Numbers indicate the address type
(0: IPX, 1: IP, 7: SOCK, 8: UDP, 9: TCP, 10: UDP6, 11: TCP6)

For partitions, the following fields will be displayed:

'Partition' Partition Short Name
'Context' Relative Context
'Replica' List of replicas with DN of host server,
[ type (master, secondary, read-only, subordinate reference) ]
[ nr (Unique replica number, assigned when the replicas are created) ]
'Partition Status' Time and success/failure of the last synchronization cycle
see also: http://developer.novell.com/research/appnotes/1998/may/03/a980503_.pdf
'Local Received Up To' Last time the replica has received any updates
'Purge Vector' Oldest state in time that has been seen by each eDirectory agent in the replica ring
'Transitive Vector' State in time that the specified eDirectory agent has received changes up to

Notes of Partition and Replica Operations

"Reload DS"

Requests a specified server to unload and then load DS.

"Sync Replica To Server"

Requests a replica to synchronize with a specific server.

"Sync Replica To Server" requests that a replica initiate synchronization with the destination server

"Sync Schema"

Signals the skulker to schedule an update of the schema a specified number of seconds in the future.
"Sync Schema" wakes up the sleeping synchronization process and alerts it to begin synchronization at the time specified.

"Remove Replica"

Removes a replica from the replica set of an eDirectory partition.
"Remove Replica" removes any replica except the master replica of a partition.
Remove the master replica by calling "Remove Partition" after all other replicas have been removed by calling "Remove Replica".

"Sync Partition"

Signals the skulker to schedule an update of a specified partition a specified number of seconds into the future.

"Join Partitions"

Joins a subordinate partition to its parent partition.
For partitions to be joined, a single replica (Master) of both the parent and subordinate partitions must exist. In addition, the master replicas must exist on the same server.

"Partition Receive All Updates"

Changes the state of the partition so all servers holding a replica will send entire partition information to the specified partition.

"Partition Receive All Updates" changes the state of the specified partition to that of a new partition. This results in all servers holding a replica of this partition sending their entire partition information, not just changes, to the partition on the target server.
This function replaces a replica on the specified server when that replica's time stamps are incorrect. For example, an operation to repair a local database may not finish correctly and leave the replica in an unknown state. Use this function to remedy such a problem.

"Partition Send All Updates"

Tells the specified partition to send full updates to any server holding a replica of the partition.
Error conditions may prevent data from being propagated to all replicas of a partition.
To remedy this situation, call "Partition Send All Updates".

"Remove Partition"

Removes an existing partition from eDirectory by deleting its master replica.

The partition must be completely empty (except for the root object) or the deletion will fail. In addition, no other replicas can exist.

Remove other replicas of the partition beforehand by calling "Remove Replica".

Since "Remove Partition" must be performed on the partition's master replica, it is assumed the operation will be performed on the server storing this replica.

"Repair Time Stamps"

Sets the time stamps for all of a partition's objects and their attributes to the current time on the server where the master replica is located.

"Repair Time Stamps" sets the time stamps on all of the objects and their attributes, even if valid time stamps exist. It will replace information such as the creation dates of the attributes.

After "Repair Time Stamps" is called, eDirectory will synchronize all replicas to match the information in the master replica.

IMPORTANT: Because of the wide scope of changes made by "Repair Time Stamps", it should be used only to recover from a catastrophic failure.

One concern with using "Repair Time Stamps" is that it can result in the loss of information. For example, any changes that have been made on replicas other than the master replica will be lost if they have not been synchronized with the master replica before "Repair Time Stamps" is called.

Another concern is with applications that use eDirectory Event Notification Services. After "Repair Time Stamps" is called, eDirectory will produce event notifications for every object and attribute on the master replica. It will also provide the same notification each time one of the other replicas is synchronized with the master replica.


* If you are not sure what you're doing, do not do it!

* Partition, Replica and Server operations may be used to check for or recover from errors.

* Potentially, such operations may also result in data loss. The documentation in this file
may not be sufficient for you to evaluate the potential consequences.

* Check www.novell.com or your reseller for additional information.

* More details on many of the retrieved server/partition attributes can be found in these URLs

# http://developer.novell.com/ndk/doc/ndslib/

# http://support.novell.com/search/kb_index.jsp

# eDirectory Synchronization and Background Processes

# Transitive Synchronization Revisited


Comment List