Explain an incomplete global catalog result

Keep the server and the view separate

A global catalog server is still a DC for its own domain. It also holds partial replicas of the other domains. The GC interface provides a forest search view; it does not turn every local replica into one complete writable directory.

The protocol GC model includes domain, Configuration and Schema naming contexts. It does not include application partitions. A GC that also hosts DomainDnsZones does not make that partition searchable through the GC view. Application partitions have their own replica placement and lookup requirements.

A missing filter attribute can hide the whole object

There are two distinct failures:

1. The object is found, but a requested attribute is absent.
2. The object is excluded because the filter depends on an attribute unavailable in that partial replica.

Adding the attribute to the requested property list fixes neither the replica nor the filter. Nor does the server automatically visit the owning domain to evaluate the missing attribute. Microsoft’s GC search explanation describes this limitation.

Watch out for tests that change both the object’s domain and the LDAP endpoint. A GC has a full replica of its own domain, but that doesn’t promise access to non-PAS attributes through the GC interface. Compare objects in each relevant domain and keep the ports, filters and credentials with the results. Read attributes outside the GC view from the owning domain’s LDAP interface.

For example, an application’s custom employee attribute might be present on a user in a domain LDAP search but absent in the GC’s other-domain partial replica. A GC filter on that attribute can miss the user completely. Investigate where the value is stored and replicated before interpreting the empty result as “no such employee.”

Use the GC to locate, then read the full object

This read-only example deliberately makes the two targets explicit:

$gc = 'gc1.contoso.com:3268'
$hits = @(Get-ADObject -Server $gc -SearchBase '' `
    -LDAPFilter '(userPrincipalName=alice@child.contoso.com)' `
    -Properties userPrincipalName,mail -ErrorAction Stop)
$hits | Select-Object ObjectGUID,DistinguishedName,userPrincipalName,mail
if ($hits.Count -ne 1) {
    throw 'Resolve the identity before reading an owning-domain replica.'
}

# Select a writable DC in the domain owning the returned DN.
$ownerDC = 'dc1.child.contoso.com'
Get-ADObject -Server $ownerDC -Identity $hits[0].ObjectGUID `
    -Properties description,whenChanged -ErrorAction Stop |
    Select-Object ObjectGUID,DistinguishedName,description,whenChanged

Use the directory context to choose the owning domain. A user’s UPN suffix can be an alternate suffix with no connection to the domain DN. A forest can also contain separate domain trees, so searching below one assumed forest-root DN may miss whole domains. The AD module’s empty-base GC behavior helps with that search.

Microsoft documents this locate-then-read pattern for non-GC attributes. Check replication and permissions on the second read too. A full replica can still have stale data or properties your account can’t read.

Check the schema and the population

Use the PAS query to inspect both isMemberOfPartialAttributeSet and the mandatory system-flags bit. Check whether the attribute can exist on the object’s class, whether a value is actually set, and whether it is constructed or confidential. An absent property has several explanations besides PAS membership.

Backlinks need particular care: Microsoft’s attribute-query guidance requires both the backlink and its forward link to be GC-enabled for GC querying. A replicated group object is not proof that every membership value is available in every replica.

Before adding an attribute to the PAS for a report, compare the cost with a second read from the owning domain. Large or frequently changing attributes add storage and replication work across the GCs.

Membership is not one forest-wide list

memberOf is a direct-membership backlink. It omits the primary group and does not expand every nested group. Its answer depends on which group data the selected DC can see. GC availability is useful for universal membership, but a GC response is not a complete resource access token for every domain and server.

Microsoft’s user security attribute definitions describe the domain/GC distinction. For an authorization incident, identify the resource domain, group scopes, logon session, token creation time and the access check at the resource. Groups and tokens separates directory queries from issued tokens.

Separate an incomplete view from an inconsistent directory

Once endpoint, filter, properties and permissions are matched, compare the exact object’s GUID and replication metadata. A newly promoted GC may still be building its partial replicas. Selecting the GC checkbox does not establish readiness; use GC promotion evidence and the affected naming context’s replication status.

An object visible on a GC or RODC but absent from every intended writable replica is a different investigation. Microsoft’s abandoned-object case explains why some such objects are not removed by ordinary lingering-object cleanup. Preserve the identity, exact replica and errors; repeated broad cleanup attempts can obscure the distinction.

An internal phantom is a local reference, not an ordinary LDAP-visible object to delete. See directory storage and references. These terms sound similar, but the repair depends on which case you’ve actually found.