Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

There are plenty of TechNet articles, like this one that say that phantom object don't get updated if an Infrastructure Master is also a Global Catalog, but other than that there isn't a lot of in depth information on what actually happens in this configuration.

Imagine a configuration like this:

|--------------|
| example.com  |
|              |
| dedicated IM |
|--------------|
    |
    |
    |
|-------------------|
| child.example.com |
|                   |
|  IM on a GC       |
|-------------------|

Where child has two DCs that are both global catalogs, meaning that the Infrastructure Master role is on a GC. And, example has three DCs with the Infrastructure Master role on a DC that is not a GC.

I understand that it's usually best to just make everything a GC and not have to worry about this sort of thing, but assuming that's not the case - what is the exact error behavior that can be expected from a setup like this, and which domain(s) would this behavior manifest in? The child or the parent?

share|improve this question
add comment

1 Answer

up vote 10 down vote accepted

A Domain Controller who is not a Global Catalog does not have a copy (partial attribute set or not) of every object in the forest. Therefore, such a DC has to create "phantom" objects to reference real objects from another domain.

The Infrastructure Master in the domain is responsible for updating those phantom references on the other DCs in the domain. To do this, it first references a global catalog server in its domain, because we assume that global catalogs have the most complete, up-to-date knowledge about all the objects in the forest.

The problem is this. If the infrastructure master is the same server as the global catalog, when the IM goes to do his job of updating, (every 2 days,) he checks a GC, which also happens to be himself. "Well, I see no difference here!" He says, because he's already on a GC and so there's no difference between what's on a GC and what's on the IM... so of course it looks like he's completely up to date. The problem is now he goes back to sleep, satisfied that there's nothing to do. This means the other domain controllers in the domain that are not GCs don't get updated with that inter-domain info.

Edit:

If you created an object in example.com, it would replicate to the GC in child.example.com, but since child.example.com has an IM on a GC and also has other DCs that are not GCs, that new object would never have a phantom created for it on those other DCs in child.example.com. And so you would not be able to add that new object onto ACLs or put it into Security Groups, etc., from those other DCs because they won't let you add principals for which they have no reference of. And rightfully so because then you'd have all sorts of weird referential integrity problems.

Going the other way, if you created a new object in child.example.com, it would replicate to example.com and it would be OK to use that new object in example.com because you don't have any DCs in the parent domain that are not being replicated to properly by the IM.

And similarly, that's why Microsoft usually recommends just making all your DCs GCs, because then it doesn't matter if the IM is working properly or not, because all DCs have all the updated information anyway by virtue of being GCs.

Edit: I also just wanted to come back to this post and mention that when the AD Recycle Bin is enabled, the Infrastructure FSMO does absolutely nothing:

http://myotherpcisacloud.com/post/2013/04/13/AD-Recycle-Bin-and-a-Eulogy-for-the-Infrastructure-Master.aspx

share|improve this answer
    
So, in what practical scenario would you not make a DC a GC? –  ewwhite Dec 12 '12 at 15:04
6  
If you had a very large directory/amount of data to replicate, and very slow links, and a complicated inter-site topology, and thus a need to control replication patterns and bandwidth with extreme precision... so in reality, almost never. –  Ryan Ries Dec 12 '12 at 15:08
    
Added a short new edit. –  Ryan Ries Apr 14 '13 at 0:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.