Overview#

NDS Unknow Entries occasionally show up in eDirectory as part of the Eventual consistency of the Distributed Data Store.

These NDS Unknow Entries should be resolved relatively quickly and not be an issue.

If the NDS Unknow Entries persist it is important that they be resolved. We show how these persistent NDS Unknow Entries entries might be created and some possible resolution processes.

There are 5 common unknown object types:

• Missing Mandatory Attribute
• Unknown Forward Reference
• Unknown NDS External References
• Non-Auxiliary Class Compatible Replica
• Deleted Object

MISSING MANDATORY (-609)#

MISSING MANDATORY (-609) entries usually happen when a process fails to provide the MUST attribute values for mandatory attributes as dictated by the ObjectClasses which were added to the entry.

Each type of eDirectory object is called an objectClass. Each class of object requires certain properties or attributes. If an attribute is mandatory, a value must be assigned to the attribute before an instance of the object can be created.

The resolution is to add the values for the missing mandatory attributes. When found, you can perform a one of the following:

• Re-send the object from a replica that has all the object’s attributes. This option works well if there are only a few objects that are NDS Unknow Entries.

Replace the replica that has the NDS Unknow Entries with an uncorrupted replica from another server. This is usually the best solution. You can achieve this in several ways:

• Request Schema: The specified server is sent the schema from the Master Replica. Only the schema entries which have newer timestamps are updated.
• Use DSREPAIR to send all objects from a replica that is not corrupted to every replica in the ring. Use DSREPAIR, in Advanced Options Menu/Replica and Partition Operations/View Replica Rings, select a server holding a replica that is not corrupt and choose Send All Objects to Every Replica in the Ring.
• Request Schema: The specified server is sent the schema from the Master Replica. Only the schema entries which have newer timestamps are updated.
• Reset Schema operation which will remove the schema synchronized up to attribute value which will resend the schema to the specified server.
• Schema Epoch: Use with Extreme Caution – Makes the specified server the Authority and causes the schema to be removed on all other servers in the tree and the schema to be rebuilt from the specified server. Could cause data-loss.
• Delete the NDS Unknow Entries. This option works best for object types that are easily re-created.
• Delete the corrupted replica and then place a replica back on the server.

Unknown Forward Reference#

A Forward Reference object is a placeholder created for non-existent containers until the real object is created (during an import). When a later operation creates the container, the forward reference is changed into a normal entry.

To fix:

• These occur as part of the normal replica synchronization process and will become known when the actual object successfully synchronizes. If it does not, you should verify that the LDIF file has a command to create the parent container.
• Check for and resolve any schema and object synchronization problems, and then wait for the synchronization to finish.
• In rare cases you may need to use the Single Object Send operation to send the entry from a consistent replica to all other replicas.

Unknown NDS External Reference#

An NDS External Reference object that has not yet been received a backLink, or the real object is unknown.

To fix:

• Check and resolve any errors reported in the Agent Process Status in the External Reference section.
• Start the Reference Check for EDirectory Background Processes process and wait for it to complete.

Non-Auxiliary Class Compatible Replica#

AUXILIARY classes are supported in eDirectory but not in NDS. A replica on a non-auxiliary class compatible NDS server will show objects with AUXILIARY classes as NDS Unknow Entries.

This would ONLY happen in a TREE with both a FLAIM and RECMAN (very OLD) eDirectory versions.

To determine if the replica resides on a server that supports AUXILIARY classes:

• Check the version of the server
• Check the version of the Directory service

In iMonitor, examine the AuxClass Object Class Backup, auxClassCompatibility, and Object Class attributes.

Deleted Object#

An object may appear as NDS Unknow Entries if it is still in the process of being deleted. You can identify if an object is still being deleted by the following:

• Entry Information Flags attribute value DS_ENTRY_NOT_PRESENT
• There may be NDS Obituaries on the object

These objects are visible in utilities such as imonitor

Collision rename#

A Collision Rename happens when an entry is renamed and there is an existing entry with the same name.

A Collision Rename could cause any of the following:

• Missing Mandatory Attribute
• Unknown Forward Reference
• Unknown External Reference

The typical resolution is to delete, rename or move either the collision entry or the "real" entry. If the entry is an object that is easily re-created, like a user entry, deleting the collision entry and adding the remaining entry is usually the simplest option.

If the entry is a critical entry like an NcpServer, or container entry, you should spend due diligence and verify each attributes to determine which entry should be kept.

If the entry you need to keep was not renamed, you can simply delete the collision renamed entry.

If you determine the collision renamed entry should be kept, you need to delete the other entry and then rename the collision renamed entry to the original name.

Category#

eDirectory

More Information#

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