En un bosque multidominio, ¿qué sucede EXACTAMENTE cuando algunos, pero no todos, los Maestros de Infraestructura están en los Catálogos Globales?

Hay muchos artículos de TechNet, como este que dicen que el objeto fantasma no se actualiza si un maestro de infraestructura también es un catálogo global, pero aparte de eso no hay mucha información detallada sobre lo que realmente sucede en este configuración.

Imagine una configuración como esta:

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

Where childtiene dos DC que son catálogos globales, lo que significa que el rol de maestro de infraestructura está en un GC. Y exampletiene tres DC con el rol de maestro de infraestructura en un DC que no es un GC.

Entiendo que generalmente es mejor hacer de todo un GC y no tener que preocuparse por este tipo de cosas, pero suponiendo que ese no sea el caso: ¿cuál es el comportamiento de error exacto que se puede esperar de una configuración como esta y qué dominio ( s) ¿se manifestaría este comportamiento? ¿El niño o el padre?

Un controlador de dominio que no es un catálogo global no tiene una copia (conjunto de atributos parciales o no) de cada objeto en el bosque. Por lo tanto, dicho DC tiene que crear objetos "fantasmas" para hacer referencia a objetos reales de otro dominio.

El maestro de infraestructura en el dominio es responsable de actualizar esas referencias fantasmas en los otros DC en el dominio. Para hacer esto, primero hace referencia a un servidor de catálogo global en su dominio, porque suponemos que los catálogos globales tienen el conocimiento más completo y actualizado sobre todos los objetos en el bosque.

El problema es este. Si el maestro de infraestructura es el mismo servidor que el catálogo global, cuando el IM va a hacer su trabajo de actualización (cada 2 días), verifica un GC, que también es él mismo. "Bueno, ¡no veo diferencia aquí!" Él dice, porque ya está en un GC y, por lo tanto, no hay diferencia entre lo que está en un GC y lo que está en el IM ... así que, por supuesto, parece que está completamente actualizado. El problema ahora es que vuelve a dormir, satisfecho de que no hay nada que hacer. Esto significa que los otros controladores de dominio en el dominio que no son GC no se actualizan con esa información entre dominios.

Editar:

Si creó un objeto en example.com, se replicaría al GC en child.example.com, pero dado que child.example.com tiene un IM en un GC y también tiene otros DC que no son GC, ese nuevo objeto nunca se ha creado un fantasma para él en esos otros DC en child.example.com. Por lo tanto, no podrá agregar ese nuevo objeto a las ACL ni colocarlo en los Grupos de seguridad, etc., de esos otros DC porque no le permitirán agregar entidades principales para las que no tienen referencia. Y con razón, porque entonces tendrías todo tipo de problemas raros de integridad referencial.

En el otro sentido, si creó un nuevo objeto en child.example.com, se replicaría a example.com y estaría bien usar ese nuevo objeto en example.com porque no tiene ningún DC en el padre dominio que el IM no está replicando correctamente.

Y de manera similar, esa es la razón por la cual Microsoft generalmente recomienda simplemente hacer todos sus DCs GC, porque entonces no importa si el IM funciona correctamente o no, porque todos los DC tienen toda la información actualizada de todos modos en virtud de ser GC.

Editar: También solo quería volver a esta publicación y mencionar que cuando la Papelera de reciclaje de AD está habilitada, la Infraestructura FSMO no hace absolutamente nada:

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