Fixing Cross-Domain Object References with FSMO Placement
Your network contains an Active Directory Domain Services (AD DS) forest.
The forest contains a root domain named contoso.com and a child domain named branch.contoso.com.
The forest contains the domain controllers shown in the following table.
You discover that cross-domain object references in contoso.com fail to update for objects in branch.contoso.com.
You need to modify the FSMO role placement. The solution must minimize administrative changes.
What should you do?
Community Insight
The question tests the FSMO/Global Catalog interaction: the Infrastructure Master must sit on a non-GC DC in a multi-domain forest, and the failing references live in contoso.com — so the contoso.com role (DC1) is the one to move, which is the trap most learners miss.
In a multi-domain forest, each domain's Infrastructure Master (FSMO) refreshes phantom records so cross-domain references resolve to current object data. When contoso.com references to branch.contoso.com objects stop updating, the fix is to move contoso.com's Infrastructure Master off a Global Catalog domain controller onto a non-GC DC in the same domain — here, transfer the role from DC1 to DC2.
Learners often pick D (moving branch.contoso.com's Infrastructure Master from DC4 to DC3) because the referenced objects sit in branch.contoso.com; but each Infrastructure Master updates the phantoms in its OWN domain, and the failures are explicitly reported in contoso.com, so the contoso.com role must be relocated.
Community Discussion (2 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The Infrastructure Master in a domain is responsible for keeping that domain's phantom objects (cross-domain references) synchronized with the real objects held in other domains. Because the symptom is stated as cross-domain object references in contoso.com failing to update for objects in branch.contoso.com, the misbehaving role is contoso.com's Infrastructure Master, currently held by DC1. In a multi-domain forest where not every domain controller is a Global Catalog server, a GC-hosted Infrastructure Master ignores the phantoms of other domains, producing exactly this stale-reference behavior. Transferring (not seizing) the role from DC1 to DC2 — a non-GC DC in the same domain — restores phantom updates while changing only one role on one DC, satisfying the "minimize administrative changes" constraint.Why the Other Options Are Wrong
Option D, moving branch.contoso.com's Infrastructure Master from DC4 to DC3, treats the wrong domain: branch's Infrastructure Master maintains phantoms inside branch.contoso.com that point to objects in other domains, which is not the failure described. Options B and E move the PDC Emulator and domain naming master respectively, neither of which touches cross-domain object reference updates; the PDC Emulator handles time synchronization, password lockout and group policy fallback, while the domain naming master controls adding or removing domains and application partitions. Option C, moving the schema master, affects only forest-wide schema changes and requires Schema Admins privileges, making it both irrelevant and far more disruptive than needed.Community Comment Notes
Both commenters converged on the same underlying rule; as seldur put it, "In a multi-domain forest, the Infrastructure Master FSMO role cannot run on a Global Catalog server" unless every DC is a GC, and Gina Lexx stated that "In a multi-domain forest, the Infrastructure Master FSMO cannot run on a Global Catalog server." Their rule is correct, but it points to the contoso.com role: the reported failures occur in contoso.com, so the correct transfer is DC1 to DC2 (A), not a change to branch.contoso.com's role holders.Official Reference
Exam Strategy
Read which DOMAIN reports the failure before choosing a FSMO transfer; Infrastructure Master always repairs phantoms in its own domain. Then apply the golden rule: in a multi-domain forest keep the Infrastructure Master on a non-Global Catalog DC, and prefer a role transfer within the domain to minimize changes.
Frequently Asked Questions
Why can't the Infrastructure Master run on a Global Catalog server in a multi-domain forest?
A Global Catalog holds a partial replica of every domain's objects, so its Infrastructure Master sees phantom objects as 'real' and stops refreshing them. Keep the role on a non-GC DC unless every DC in the forest is a GC.
Why not transfer the Infrastructure Master for branch.contoso.com from DC4 to DC3?
The failures are reported in contoso.com, and each Infrastructure Master updates only the phantom references stored in its own domain. Branch's role cannot repair contoso.com's stale references, so contoso.com's role must move instead.
Related Analysis
Practice All AZ-802 Questions
Access 125 questions with complete answers and detailed explanations.
View Full AZ-802 Practice Test →