Troubleshooting guide

Obituaries 55
If the obituary is a Back Link obituary and this server is the master, then this server is
responsible for processing this obituary.
IMPORTANT: Perform the required operation for this state if it has not been done. Most
often, this is done by notifying an external reference.
If the obituary is a Used By obituary and this server is the server where the delete occurred
(determined by comparing the replica number in the obituary's MTS to our replica
number), this server is responsible for processing this obituary.
 If this server is responsible for processing a particular Secondary obituary type (Back Link
or Used By), all Secondary obituaries of that type on an entry are in the same state, the
required operation for that state has been completed on all obituaries (for example, servers
have been notified), and the obituary's MTSs for that obituary type are older than the
Obituary Vector, then all Secondary obituaries of that type can be advanced to the next
state.
9.1.2 Moving an Object
Move acts much like Delete, but with the following changes:
 Before the Primary obituary is placed on the move source, a partial entry is created in the
destination container and a Tracking obituary (OBT_INHIBIT_MOVE) is placed on that partial
entry. This Tracking obituary is placed to prevent the entry from being moved or taking part in a
partition operation before the full entry is transferred from the source.
 On the source entry, the Primary obituary is OBT_MOVED.
 After the Primary obituary (OBT_MOVED) is moved to the Notified state (meaning that all
replicas of the source know the entry is being moved) and all external references have been
notified, the Tracking obituary (OBT_INHIBIT_MOVE) is removed from the destination entry.
9.2 Impact of Stuck and Orphaned Obituaries
Objects with obituaries are considered every time an agent outbound synchronizes, and by the
obituary process, which is scheduled to run at the end of an inbound synchronization cycle.
9.3 Prevention
On a regular basis, run the iMonitor Server Information report. This report walks the entire tree,
communicates with every NCP server it can find, and reports any errors it finds. You can use this
report to diagnose time synchronization and limber problems, or to find out if the current server is
able to communicate with all other servers from this server’s perspective. If selected in the
configuration page, the server can also generate NDS Agent Health information for every server in
the tree. See “Configuring and Viewing Reports” in the Novell eDirectory 8.8 SP7 Administration Guide
for more information on running the Server Information report.
If you are using iMonitor 2.0 or later, make sure that the Errors and Health Sub-report report options
are enabled. The following items will be verified. You should browse the report and make sure that
there are no errors.
 Based on the information in the
ndsimonhealth configuration file stored with iMonitor (see
“Configuration Files” in the Novell eDirectory 8.8 SP7 Administration Guide), this report will check
the eDirectory agent version to ensure you are running the correct directory patches tree-wide.
 All servers are within Timesync tolerances.