Overview[1]#

MISSING MANDATORY (-609) or FFFFFD9F is an NDS Result Code.

Source: eDirectory or NDS

Explanation: #

One or more of the mandatory attributes for the object being created or modified are missing.

WARNING: #

Applying all solutions mentioned in this topic could make the problem worse if the actual cause of the problem is not known. Before following a course of action, make sure that you understand the cause of the error and the consequences for the actions suggested.

Possible Cause: When modify an object#

An attempt was made to modify an object without specifying values for all of the mandatory attributes listed within the expanded eDirectory or NDS schema class definition of the object's base class.

Action: #

To determine which attributes are mandatory for an operational eDirectory or NDS schema class definition, use NDS Schema Manager.

Possible Cause: NDS replica synchronization #

If the error occurs during the background processes for eDirectory or NDS replica synchronization, two causes for this error might be:
  • NDS schema - The eDirectory or NDS schema class definition used by the source server differs from the definition used by the target server. Additionally, the error indicates that the eDirectory or
  • NDS schema on the source server contains additional information. The database on the source server is damaged.

Action: #

If the error occurs during the background processes for eDirectory or NDS replica synchronization, and the eDirectory or NDS schema class definition used by the source server differs from the definition used by the target server, see Resolving Novell eDirectory or NDS Schema Synchronization Issues.

If you suspect that the database on the source server is the problem, try repairing it using DSREPAIR with Rebuild Operational Schema selected.

From Edirectory Field Book#

Viewing the Entry in iMonitor by browsing for the object or selecting from the Object Statistics report summary.

In the bottom-left pane, Replicas section, slect each server link one at a time.

Observe the entry information section of the Entry on each replica. If you find a replica with a valid BaseClass field, note the server and continue through the other replicas.

If you DID NOT find a valid baseclass on one of the replicas you there is nothing you can do but delete the object from the tree.

If you found a valid baseClass on one of the replicas, go the the server which held the valid baseClass.

  • Click the Advanced Options link.
  • From here you can select Timestamp Entry. This will send this entry to all replicas including the replica(s) with the unknown objectClass.

It the above does not work, you can try running Ndsrepair:

 ndsrepair -p
The -P option on the server(s) that contains the unknown objectClass. This marks the unknown objectClass as a reference object which tells the directory agents that the object is synchronized through an inbound synchronization process and they should ignore the local defintion and all inbound synchronization to overwrite the object.

If this fails, you need to delete the unknown objectClass.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-5) was last changed on 14-Oct-2014 15:07 by jim