Infrastructure Master & GC on same DC?

  • Thread starter Thread starter Ali
  • Start date Start date
A

Ali

Hi everyone,
I'm a little confused about the explanation given by MS (and other sources)
about the co-existance of an Infrastucture Master and GC on the same DC.

"Global Catalog should not be placed on the same server as infrastructure
master. The role of infrastructure master is to update references from
objects in its own domain to objects in other domains. This is done by
comparing its data with that of a global catalog. If the infrastructure
master finds out that its data is outdated, it requests the update from the
global catalog and then sends the updates to other domain controllers in the
domain. If they happen to be the same server, the infrastructure master
would never be able to find that the data is out of date and update other
domain controllers in the domain. However, it is recommended to place the
infrastructure master in the same site as a Global Catalog server."

why wouldn't the Infrastructure Master be able to find the data is out of
date, if the GC was on the same server?

thanks a bunch,
Ali,
MCSA, CCNA
 
Hello Ali.
Ali wrote
[...]
why wouldn't the Infrastructure Master be able to find the data is out of
date, if the GC was on the same server?

thanks a bunch,
Ali,
MCSA, CCNA
Click to expand...

....because his own information will never differ from the information on the
GC (his own info IS the GC).

Regards,
Wolfgang
MCSE, MCDBA, MCSD, MCT
 
A GC won't get out of date, because the GC will have a copy/replica of
every Domain, so it will replicate in DN modifications to objects
(such as users) in other domains. So a cross-domain DN references
(what the infrastructure FSMO maintains) will never (at least not for
long) be out of date on a GC, b/c the correct DN just replicates in.

The infrastructure FSMO relies on the DNs being out of date, when the
"DN fixup task" (official name can't remember right now, its' 2:30 AM)
runs, it enumerates all DNs that point out of (reference objects
outside of) it's local domain, and then talks to a GC to get the
correct DNs (but remember it isn't a GC, ironic eh? that it isn't a
GC, but needs to talk to a GC. ;).

Anyway, if the DNs match, the object obviously hasn't moved, and there
is no work to do.

When the object's DN has changed, from the one this DC/Infrastructure
Master has locally, the infrastructure master creates a special object
in this domain called an "Infrastructure Update", that's sole purpose
is to replicate around that domain, and fix up this out of domain DN
reference that is wrong on other non-GC DCs for this domain.
Obviously, the GCs would've just fixed themselves up as part of
regular replication, so they can ignore the Infrastructure Update if
they have the current DN.

The problem occurs, if this task runs on a GC, its very likely that a
changed DN replicates in relatively quickly. Then when the "DN fixup
task" runs it takes the current DN (which is correct, b/c the change
replicated in), and so when this DN is checked against a GC, it
appears to be correct, even though the DN has changed. Other non-GC
DCs for this domain will be left with a stale old DN reference, b/c no
Infrstructure Update object was created to fix them up.

One exception is if every DC for a domain is a GC then you can't have
the Infrastructure Master on a non-GC, but this is OK, b/c all the DCs
are GCs so they'll all just replicate in the DN changes.

Cheers,
Brett Shirley [MSFT]
SDE, AD Replication

Posting is "AS IS", confers no rights.
 
Back
Top