Em uma floresta de vários domínios, o que EXATAMENTE acontece quando alguns, mas não todos, os mestres de infraestrutura estão nos catálogos globais?

Existem muitos artigos do TechNet, como este, que dizem que o objeto fantasma não é atualizado se um mestre de infraestrutura também for um catálogo global, mas, além disso, não há muitas informações detalhadas sobre o que realmente acontece neste configuração.

Imagine uma configuração como esta:

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

Onde childtem dois controladores de domínio que são catálogos globais, significando que a função de mestre de infraestrutura está em um GC. E, examplepossui três controladores de domínio com a função de mestre de infraestrutura em um controlador de domínio que não é um GC.

Entendo que geralmente é melhor transformar tudo em um GC e não ter que se preocupar com esse tipo de coisa, mas supondo que esse não seja o caso - qual é o comportamento exato do erro que pode ser esperado de uma instalação como essa e qual domínio ( s) esse comportamento se manifestaria? A criança ou os pais?

Um controlador de domínio que não é um catálogo global não possui uma cópia (conjunto parcial de atributos ou não) de todos os objetos da floresta. Portanto, esse controlador de domínio precisa criar objetos "fantasmas" para fazer referência a objetos reais de outro domínio.

O mestre de infraestrutura no domínio é responsável por atualizar essas referências fantasmas nos outros controladores de domínio no domínio. Para fazer isso, ele primeiro faz referência a um servidor de catálogo global em seu domínio, porque supomos que os catálogos globais tenham o conhecimento mais completo e atualizado sobre todos os objetos na floresta.

O problema é esse. Se o mestre da infraestrutura é o mesmo servidor que o catálogo global, quando o IM faz seu trabalho de atualização (a cada 2 dias), ele verifica um GC, que também é ele próprio. "Bem, não vejo diferença aqui!" Ele diz, porque ele já está em um GC e, portanto, não há diferença entre o que está em um GC e o que está no IM ... então é claro que parece que ele está completamente atualizado. O problema agora é que ele volta a dormir, satisfeito por não ter o que fazer. Isso significa que os outros controladores de domínio no domínio que não são GCs não são atualizados com essas informações entre domínios.

Editar:

Se você criou um objeto em example.com, ele seria replicado para o GC em child.example.com, mas como child.example.com tem uma mensagem instantânea em um GC e também possui outros DCs que não são GCs, esse novo objeto nunca tenha um fantasma criado para ele nos outros CDs em child.example.com. E, portanto, você não seria capaz de adicionar esse novo objeto às ACLs ou colocá-lo em Grupos de Segurança etc. desses outros DCs, porque eles não permitirão que você adicione entidades principais às quais eles não têm referência. E com razão, porque então você teria todos os tipos de problemas de integridade referencial estranhos.

Por outro lado, se você criasse um novo objeto em child.example.com, ele seria replicado para example.com e seria bom usar esse novo objeto em example.com porque você não possui nenhum controlador de domínio no pai. domínio que não está sendo replicado corretamente pelo IM.

Da mesma forma, é por isso que a Microsoft geralmente recomenda apenas criar todos os seus DCs GCs, porque não importa se o IM está funcionando corretamente ou não, porque todos os DCs têm todas as informações atualizadas de qualquer maneira, em virtude de serem GCs.

Edit: Eu também só queria voltar a este post e mencionar que, quando a Lixeira do AD está ativada, o FSMO da infraestrutura não faz absolutamente nada:

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