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
- Don’t panic.
- Use Replica Ring listed in the Replica frame of iMonitor to check replicas.
- Is the missing attribute missing on all replicas or just some of the
replicas?
- If the attribute is missing on all replicas, add the missing attribute
using LDAP, ConsoleOne®, or NetIQ iManager (the object will remain Unknown).
- After restoring the missing attributes, use the Mutate link from the
Validate page or the Advanced Operations page in iMonitor to convert from
the Unknown back to the original base class.
- If the object is consistent on some replicas but not others, use iMonitor
to resend that one object from the consistent replica to the other replicas.
- As a last resort, remove and re-create the object. Note that the removal
of the object might cause other objects which refer to the removed object to
become Unknown. Readding the object will not restore any broken references.
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:
- Authentication
- It is referenced by another eDirectory object
- File rights or another operating system (OS) dependency
- eDirectory itself has a dependency
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:
- If you have a lot of External References from one partition, consider placing
a replica of that partition on another server.
- External References must be maintained properly for those subsystems that
are dependent on them.
- External References affect the amount and types of communication that are
required between eDirectory agents.
- Referential integrity.
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
- Entry Information Flags show "Reference."
- There are no "real" server names in the replica ring frame .
- The partition type is subordinate .
- The attribute list is abbreviated although the authenticated user has
rights to the object being viewed .
Resolving the Issue
- Don’t panic. This is not generally a problem.
- If the Entry Information Flags show "Temporary Reference," by
design this server might never receive the base class of the real object.
- Check and resolve any errors shown in "Agent Process Status" in the External
Reference section.
- Start the Reference Check and wait for it to complete.
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
- Entry Information flags show “Reference.”
- The Replica Type shown in the Entry Information is something other than
Subordinate.
- The object might not have all attributes.
- Walking the replica ring shows the object is not Unknown on all replicas.
Resolving the Issue
- Don’t panic. Forward references happen all the time in the course of synchronization
and will become known when the object successfully synchronizes.
- Check for and resolve any schema and object synchronization problems, then
wait for the synchronization operation to finish.
- In rare cases, use Single Object Send to send the entry from a consistent
replica to all other replicas.
- Change Forward Reference entries into normal objects
.
You can change a Forward Reference entry into an normal object by simply
creating it (using, for example, an LDIF file or an LDAP client request).
When you ask eDirectory to create an entry that already exists as a Forward
Reference, eDirectory transforms it into
the object you asked it to create.
The Object Has Auxiliary Classes and You Are Viewing the Object on a Non-Aux Class
Compatible Replica
Detecting the Cause
- Check the version of the servers in the replica ring. If the directory version
is not at least 8.x and the object has auxilary classes,
it will be displayed as an Unknown object.
- Examine the AuxClass Object Class Backup, auxClassCompatibility, and Object
Class attributes.
Resolving the Issue
- Don’t panic. This is not a real problem, and it is safe to ignore these unknowns.
- Upgrade older servers to eDirectory 8.x or later and apply appropriate
service patches.
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
- Entry Information flags don’t show “Present.”
- There might be obituary attributes on the object.
- These objects are visible only in utilities such as iMonitor.
Resolving the Issue
- This object will generally finish deleting without manual intervention.
- Wait for the synchronization to finish.
- Run the Purger background process.
- Run the Obituary Report to obtain information about deleted entries.
- Look at the Obituaries help topic.
The Object Is Actually Damaged (Rare)
Contact NetIQ Technical Services.
Contact NetIQ Technical Services.
Check the following and then contact NetIQ Techncal Services.
Detecting the Cause
- Entry Information flags show “Reference.”
- Walking the replica ring shows the object is an Unknown object on all replicas.
Resolving the Issue
- Delete the object if it is not needed.
For information about NetIQ trademarks, see
http://www.netiq.com/company/legal/.