This article discusses and explains how to avoid the Infrastructure Master (IM) role holder and Global Catalog (GC) server role conflict, and gives a brief summary of both these roles.
Phantom objects
Active Directory allows for groups to contain members and other groups from other domains, etc. Because of this, domain-local and global groups can contain objects that do not actually reside in the local domain naming context. In order for a group in one domain to contain members from another domain, a pointer or cross-domain reference is required. The Directory Service uses what's called a Phantom object as this cross-domain reference or placeholder object.Note. A phantom is not the same as a cross reference (crossRef) object. In the preceding section, the term cross reference is used in a generic manner, and can be assumed to be synonymous with the terms pointer and link.
The Directory System Attendant (DSA) maintains external group members through the use of phantom objects. A phantom object is a system object, and cannot be viewed or manipulated. A phantom object consists of the object's GUID, Distinguished Name (DN) and, in the case of a security principal, the object's Security Identified (SID). A phantom object needs to be kept updated, as changes to the location of the source object (the object that the phantom references) will change the DN and possibly the SID (in the case of a domain move). It is the job of the Infrastructure Master Role holder to maintain and update phantom objects stored in the domain that the IM resides in (and is therefore responsible for).
The IM does this by periodically checking the phantoms in its own domain partition against a Global Catalog server. A Global Catalog server holds a partial replica of all other domain partitions in the forest (and obviously has access to the full domain partition for its own domain), and as such is always (loosely, based on the fact that this is a multi-master replication topology) up-to-date with an object's DN.
The IM and GC conflict
Because of the way the IM maintains its phantom objects, it cannot reside on a Global Catalog server. If the IM were to reside on a DC that also holds the role of a GC then it would always hold up-to-date objects and as such would not hold an out-of-date phantom. The IM needs to discover out-of-date phantoms so that it can update them and thence replicate them to the other DCs in the domain. Therefore, in a multi-domain environment, the IM should not reside on a GC.However, if all of the domain controllers in a given domain hold the role of Global Catalog server then there will never be an out-of-date phantom object, and as such the role of the IM is redundant. Therefore, the earlier statement of "an IM should not reside on a GC" is only valid under the following circumstances:
- The forest contains multiple domains; and
- There are Domain Controllers in the domain that do not hold the role of GC
The following section details when and when not this is an issue:
A single-domain forest
| The domain has multiple Domain Controllers some of which hold the role of GC and some of which do not. |
The IM is not used in this environment*; therefore the IM can reside on a GC with no ill effects. |
| The domain has multiple Domain Controllers all of which hold the role of GC. |
The IM is not used in this environment*; therefore the IM can reside on a GC with no ill effects. |
* In this environment, there is no need for the IM as phantoms are not used -because there are no other domains.
A multi-domain forest
| A given domain has multiple Domain Controllers some of which hold the role of GC and some of which do not. |
The IM is used in this environment, and cannot reside on a GC |
| A given domain has multiple Domain Controllers, all of which hold the role of GC. |
The IM is not used in this environment, and as such can reside on a GC with no ill effects. |
Summary
Phantom objects are hidden, system-only objects that act as pointers to the actual objects in another domain. They consist of the source object's GUID, DN and SID (if the object is a security principal). It is the IM Role holder's job to keep these phantoms up-to-date. It does this by periodically checking a GC. Because of this the DC that holds the role of IM cannot reside on a DC that holds the role of GC under certain circumstances. The conflict can happen if the IM resides on a DC that is also a GC in a multi-domain forest when there are DCs in this domain that are not GCs. If all DCs in the domain are GCs, or there is only one domain, then the IM is not needed and as such the conflict doesn't exist.Additional information
Document information
Author: Paul WilliamsDate: 08-06-2004
Version: 2.0
Last updated: 01-08-2007
Last updated by: Paul Williams
