!!! Overview
[{$pagename}] occasionally show up in [eDirectory] as part of the [Eventual consistency] of the [Distributed Data Store]. 

These [{$pagename}] should be resolved relatively quickly and not be an issue.

If the [{$pagename}] persist it is important that they be resolved. We show how these persistent [{$pagename}] 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 [{$pagename}].

Replace the [replica] that has the [{$pagename}] 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 [{$pagename}]. 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 [{$pagename}].

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 [{$pagename}] 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
%%category [eDirectory]%%

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]