In una foresta multi-dominio, cosa succede ESATTAMENTE quando alcuni, ma non tutti, i master infrastrutturali si trovano su cataloghi globali?

Ci sono molti articoli TechNet, come questo che afferma che l'oggetto fantasma non viene aggiornato se un Infrastruttura Master è anche un catalogo globale, ma a parte questo non ci sono molte informazioni approfondite su ciò che realmente accade in questo configurazione.

Immagina una configurazione come questa:

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

Dove childha due controller di dominio che sono entrambi cataloghi globali, il che significa che il ruolo di master infrastruttura è su un GC. Inoltre, exampleha tre controller di dominio con il ruolo di master infrastruttura su un controller di dominio che non è un GC.

Capisco che di solito è meglio trasformare tutto in un GC e non doversi preoccupare di questo genere di cose, ma supponendo che non sia il caso: qual è l' esatto comportamento dell'errore che ci si può aspettare da un'installazione come questa e quale dominio ( s) si manifesterebbe questo comportamento? Il figlio o il genitore?

Un controller di dominio che non è un catalogo globale non ha una copia (set di attributi parziale o meno) di ogni oggetto nella foresta. Pertanto, tale controller di dominio deve creare oggetti "fantasma" per fare riferimento a oggetti reali da un altro dominio.

Il master dell'infrastruttura nel dominio è responsabile dell'aggiornamento di quei riferimenti fantasma sugli altri controller di dominio nel dominio. Per fare ciò, fa prima riferimento a un server di catalogo globale nel suo dominio, poiché ipotizziamo che i cataloghi globali dispongano delle conoscenze più complete e aggiornate su tutti gli oggetti nella foresta.

Il problema è questo Se il master dell'infrastruttura è lo stesso server del catalogo globale, quando l'IM esegue il suo lavoro di aggiornamento (ogni 2 giorni) controlla un GC, che è anche lui stesso. "Bene, non vedo alcuna differenza qui!" Dice, perché è già su un GC e quindi non c'è alcuna differenza tra ciò che è in un GC e ciò che è nell'IM ... quindi ovviamente sembra che sia completamente aggiornato. Il problema è che ora torna a dormire, soddisfatto che non ci sia nulla da fare. Ciò significa che gli altri controller di dominio nel dominio che non sono GC non vengono aggiornati con le informazioni tra domini.

Modificare:

Se si creava un oggetto in example.com, si replicava nel GC in child.example.com, ma poiché child.example.com ha un messaggio istantaneo in un GC e ha anche altri controller di dominio che non sono GC, quel nuovo oggetto verrebbe mai un fantasma creato per esso su quegli altri controller di dominio in child.example.com. Quindi non saresti in grado di aggiungere quel nuovo oggetto su ACL o di inserirlo in gruppi di sicurezza, ecc., Da quegli altri controller di dominio perché non ti permetteranno di aggiungere entità per le quali non hanno riferimenti. E giustamente perché allora avresti tutti i tipi di strani problemi di integrità referenziale.

In caso contrario, se si creasse un nuovo oggetto in child.example.com, si replicerebbe in example.com e sarebbe corretto usare quel nuovo oggetto in example.com perché non si hanno controller di dominio nel genitore dominio che non viene replicato correttamente dall'IM.

E allo stesso modo, è per questo che di solito Microsoft consiglia di creare tutti i GC dei controller di dominio, perché non importa se l'IM funziona correttamente o meno, perché tutti i controller di dominio dispongono comunque di tutte le informazioni aggiornate in quanto sono GC.

Modifica: volevo solo tornare a questo post e menzionare che quando il Cestino di AD è abilitato, l'infrastruttura FSMO non fa assolutamente nulla:

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