Article ID: 248047 - View products that this article applies to.
This article was previously published under Q248047
This article describes how phantoms are used in Microsoft Windows 2000 and in Microsoft Windows Server 2003.
Phantom objects are low-level database objects that Active Directory uses for internal management operations. Two common instances of phantom objects are as follows:
Object deletionWhen an object is deleted from the active directory, the object follows the following process.
Stage 1: Normal objectsThe object first exists as a typical Active Directory object. You can view the object by using the appropriate Active Directory and through the LDAP interface.
The object moves to Stage 2 when the object is deleted by an administrator or through another means.
Stage 2: Deleted objects before the tombstone lifetime expiresThe object now exists as a Tombstone object for the length of the tombstone lifetime interval. While the object maintains some of its original form:
The objects cannot be seen from normal Active Directory management tools. You may configure a low level LDAP interface like LDP to view these objects:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q258310The object moves to one of two possible states (Stage 3 or 4) when the tombstone lifetime has expired. The default tombstone lifetime is 60 days.
Stage 3: (Normal) object is removed from the active directory database CompletelyIf there no references to this object remain in the Active Directory, the row in the database is completely removed and there are no traces of the object left.
Stage 4: (External references still exist) phantom objectIf there are any references to this object remain in the Active Directory, the object itself is deleted and a phantom object is created in its place until those references are removed. This phantom object is deleted when all references to the object are removed.
You cannot view these phantom objects through any LDAP or ADSI interface. Note During the removal of the global catalog from a domain controller, the read-only objects that are removed from the global catalog do not go through the deletion process. They are immediately removed from the database and any references to them are unaffected.
Cross-domain references and the infrastructure master roleCertain types of groups in an active directory domain can contain accounts from trusted domains. To make sure that the names in the group's membership are accurate, the user object's GUID is referenced in the membership of the group. When Active Directory Tools displays these groups that have users from foreign domains, they must be able to display the accurate and current name of the foreign user without relying on immediate contact with a domain controller for the foreign domain or a global catalog.
Active Directory uses a phantom object for cross-domain group-to-user references. This phantom object is a special kind of object that cannot be viewed through any LDAP interface.
Phantom records contain a minimal amount of information to let a domain controller refer to the location in which the original object exists. The index of phantom objects contains the following information about the cross-referenced object:
If you change the foreign user's name or delete the foreign user, the phantoms must be updated or removed in the group's domain from every domain controller in the domain. The domain controller holding the infrastructure master (IM) role for the group's domain handles any updates to the phantom objects.
You cannot view these phantom objects through any LDAP or ADSI interface.
Phantom update and cleanup processesIf the object to which a phantom object refers has been deleted, the phantom object must be removed from the local domain (cleaned up). A phantom object must also be updated if the name of the original object changes so that the group membership list for the group has an accurate listing. The domain controller holding the IM role in a domain handles both operations for its domain.
The IM compares the information about the phantom objects against the latest versions on a global catalog server and makes changes to the phantoms as needed. The interval can be customized by adding the Days per database phantom scan registry entry to the following registry subkey:
To make this change, note the following:
Global catalog and infrastructure master role conflictIf the IM Flexible Single Master Operation (FSMO) role holder is also a global catalog server, the phantom indexes are never created or updated on that domain controller. (The FSMO is also known as the operations master.) This behavior occurs because a global catalog server contains a partial replica of every object in Active Directory. The IM does not store phantom versions of the foreign objects because it already has a partial replica of the object in the local global catalog.
For this process to work correctly in a multidomain environment, the infrastructure FSMO role holder cannot be a global catalog server. Be aware that the first domain in the forest holds all five FSMO roles and is also a global catalog. Therefore, you must transfer either role to another computer as soon as another domain controller is installed in the domain if you plan to have multiple domains.
If the infrastructure FSMO role and global catalog role reside on the same domain controller, you continually receive event ID 1419 in the directory services event log. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
251095For more information about FSMO role placement in the domain and how to transfer a FSMO role to another domain controller, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/251095/ )Event ID 1419 generated on a domain controller
(http://support.microsoft.com/kb/223346/ )FSMO placement and optimization on Active Directory domain controllers
(http://support.microsoft.com/kb/223787/ )Flexible Single Master Operation transfer and seizure process
Article ID: 248047 - Last Review: June 19, 2007 - Revision: 4.1