In a multi-domain forest, what EXACTLY happens when some, but not all, of the Infrastructure Masters are on Global Catalogs?

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?

Solution 1:

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