Dans une forêt multi-domaines, que se passe-t-il EXACTEMENT lorsque certains, mais pas tous, des maîtres d'infrastructure sont sur des catalogues globaux?

Il existe de nombreux articles TechNet, comme celui-ci, qui disent que l'objet fantôme n'est pas mis à jour si un maître d'infrastructure est également un catalogue global, mais à part cela, il n'y a pas beaucoup d'informations détaillées sur ce qui se passe réellement dans ce configuration.

Imaginez une configuration comme celle-ci:

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

Où childpossède deux contrôleurs de domaine qui sont tous deux des catalogues globaux, ce qui signifie que le rôle de maître d'infrastructure se trouve sur un GC. Et, examplea trois contrôleurs de domaine avec le rôle de maître d'infrastructure sur un contrôleur de domaine qui n'est pas un GC.

Je comprends qu'il est généralement préférable de faire de tout un GC et de ne pas avoir à se soucier de ce genre de chose, mais en supposant que ce n'est pas le cas - quel est le comportement d'erreur exact qui peut être attendu d'une configuration comme celle-ci, et quel domaine ( s) ce comportement se manifesterait-il? L'enfant ou le parent?

Un contrôleur de domaine qui n'est pas un catalogue global n'a pas de copie (jeu d'attributs partiel ou non) de chaque objet de la forêt. Par conséquent, un tel contrôleur de domaine doit créer des objets "fantômes" pour référencer des objets réels d'un autre domaine.

Le maître d'infrastructure du domaine est responsable de la mise à jour de ces références fantômes sur les autres contrôleurs de domaine du domaine. Pour ce faire, il fait d'abord référence à un serveur de catalogue global dans son domaine, car nous supposons que les catalogues globaux disposent des connaissances les plus complètes et les plus récentes sur tous les objets de la forêt.

Le problème est le suivant. Si le maître d'infrastructure est le même serveur que le catalogue global, lorsque le GI va faire son travail de mise à jour, (tous les 2 jours), il vérifie un GC, qui se trouve être lui-même. "Eh bien, je ne vois aucune différence ici!" Il dit, parce qu'il est déjà sur un GC et qu'il n'y a donc pas de différence entre ce qui est sur un GC et ce qui est sur la messagerie instantanée ... alors bien sûr, il semble qu'il soit complètement à jour. Le problème est maintenant qu'il se rendort, convaincu qu'il n'y a rien à faire. Cela signifie que les autres contrôleurs de domaine du domaine qui ne sont pas des GC ne sont pas mis à jour avec ces informations inter-domaines.

Éditer:

Si vous avez créé un objet dans example.com, il se répliquerait sur le GC dans child.example.com, mais puisque child.example.com a un IM sur un GC et a également d'autres contrôleurs de domaine qui ne sont pas des GC, ce nouvel objet ne jamais créer de fantôme sur ces autres contrôleurs de domaine dans child.example.com. Et vous ne seriez donc pas en mesure d'ajouter ce nouvel objet sur des ACL ou de le placer dans des groupes de sécurité, etc., à partir de ces autres contrôleurs de domaine, car ils ne vous permettront pas d'ajouter des principaux pour lesquels ils n'ont aucune référence. Et à juste titre parce que vous auriez alors toutes sortes de problèmes étranges d'intégrité référentielle.

Dans l'autre sens, si vous avez créé un nouvel objet dans child.example.com, il se répliquerait sur example.com et il serait OK d'utiliser ce nouvel objet dans example.com car vous n'avez pas de DC dans le parent domaine auquel la messagerie instantanée ne réplique pas correctement.

Et de la même manière, c'est pourquoi Microsoft recommande généralement de créer tous vos GC de DC, car cela n'a pas d'importance si le MI fonctionne correctement ou non, car tous les DC ont de toute façon toutes les informations mises à jour du fait qu'ils sont des GC.

Edit: Je voulais également revenir sur ce post et mentionner que lorsque la corbeille AD est activée, l'infrastructure FSMO ne fait absolument rien:

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