Unknown Objects

There are valid reasons for objects to have a base class of type "Unknown." Objects with the base class Unknown can be contained by anything, can contain anything, and can have any attributes. These special properties of Unknown are used during the normal course of eDirectory operations to facilitate interoperability and ensure object consistency during certain operations. However, there are some cases of Unknown objects where administrator action is advised. Understanding why an object has an Unknown base class will prevent you from taking needless or potentially disastrous action which would disrupt the normal course of eDirectory operations.

This document describes many of the cases of Unknown objects, how to identify the case using the iMonitor utility, and if action is required, how to resolve the issue.

Finding Unknown Objects

To find Unknown objects in your tree, run the object statistics report with Unknown objects selected.

Unknown Object Causes

Any of the following can cause an Unknown object:

An Object Referenced By a Mandatory Attribute Has Been Deleted

Objects must remain consistent with their schema definition, meaning they must have all of the naming and mandatory attributes in the inherited class definition. If any of the mandatory attributes must be removed, rather than allowing the object to be inconsistent with its schema, eDirectory saves the original base class in the Unknown base class attribute and the original Auxiliary classes in the Unknown Auxiliary class attribute, and then makes the base class of the object Unknown.

Detecting the Cause

Browse to the object in iMonitor and and click on Validate Entry to gather information regarding the Unkown object. The help page for Validate will describe the diagnosis Validate is performing. Determine what attributes are required by the original base class as stored in the Unknown base class attribute.

Resolving the Issue

The Object Is an External Reference and the Object Has Not Yet Been Backlinked, Or the Real Object Is Unknown

External Reference objects are not normally seen in eDirectory except by using advanced diagnostic tools such as iMonitor. An External Reference is a name that needs to be tracked by the local Directory Information Base (DIB). It might contain a partial cache of attributes from the real object or results of local operations. External References are typically created when any of the following occurs:

External References are maintained by a Reference Check process. On real replicas, this process maintains User, Used By, and Back Link attributes.

What is actually maintained depends on the object and the version of eDirectory. The base class, name, and certain attributes are all maintained. Some examples of maintained attributes include Public Key and GUID for User objects, Replica for Partition Root objects, and Status and NDS® Version for NCP™ objects.

Reasons for concern about External References:

You can usually tell if there is a problem with External References by using iMonitor and looking at the Agent Process Status.

Detecting the Cause
Resolving the Issue

The Object Is Only a Forward Reference

A Forward Reference is a temporary placeholder the server creates for an entry that would normally need to exist before an update operation could succeed. Also, unlike the creation of other entries, when the server receives a command to create an entry that already exists as a Forward Reference, it transforms it into a real entry rather than returning an error that the entry already exists.

Most occurances of Forward Referrence objects occur during synchronization. In rare cases, LDIF might create Forward Reference objects that are incomplete.

Detecting the Case
Resolving the Issue

The Object Has Auxiliary Classes and You Are Viewing the Object on a Non-Aux Class Compatible Replica

Detecting the Cause
Resolving the Issue

The Object Is Being Deleted

These objects are not normally seen in eDirectory except by using advanced diagnostic tools such as iMonitor.

Detecting the Cause
Resolving the Issue

The Object Is Actually Damaged (Rare)

Contact NetIQ Technical Services.

Schema Inconsistencies (Rare)

Contact NetIQ Technical Services.

Ghost Objects (Extremely Rare)

Check the following and then contact NetIQ Techncal Services.

Detecting the Cause
Resolving the Issue

 

For information about NetIQ trademarks, see http://www.netiq.com/company/legal/.