Что именно происходит в многодоменном лесу, когда некоторые, но не все, хозяева инфраструктуры находятся в глобальных каталогах?

Есть много статей TechNet, таких как эта , в которых говорится, что фантомный объект не обновляется, если мастер инфраструктуры также является глобальным каталогом, но в остальном не так много подробной информации о том, что на самом деле происходит в этом конфигурации.

Представьте себе такую ​​конфигурацию:

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

Где childесть два DC, которые являются глобальными каталогами, что означает, что роль хозяина инфраструктуры принадлежит GC. И exampleимеет три контроллера домена с ролью «Руководитель инфраструктуры» на контроллере домена, который не является GC.

Я понимаю, что обычно лучше всего сделать все GC и не беспокоиться о подобных вещах, но при условии, что это не так - каково точное поведение ошибки, которое можно ожидать от такой установки, и какой домен ( s) проявится ли это поведение? Ребенок или родитель?

Контроллер домена, который не является глобальным каталогом, не имеет копии (установлен или нет частичный атрибут) каждого объекта в лесу. Следовательно, такой DC должен создавать «фантомные» объекты для ссылки на реальные объекты из другого домена.

Мастер инфраструктуры в домене отвечает за обновление этих фантомных ссылок на других контроллерах домена. Чтобы сделать это, он сначала ссылается на сервер глобального каталога в своем домене, поскольку мы предполагаем, что глобальные каталоги обладают наиболее полными, актуальными знаниями обо всех объектах в лесу.

Проблема в этом. Если хозяин инфраструктуры находится на том же сервере, что и глобальный каталог, когда IM собирается выполнять свою работу по обновлению, (каждые 2 дня) он проверяет GC, который также оказывается самим собой. «Ну, я не вижу здесь никакой разницы!» Он говорит, потому что он уже в GC, и поэтому нет никакой разницы между тем, что находится в GC, и тем, что находится в IM ... так что, конечно, похоже, что он полностью в курсе. Проблема в том, что теперь он снова ложится спать, довольный, что ничего не поделаешь. Это означает, что другие контроллеры домена в домене, которые не являются GC, не обновляются с этой информацией между доменами.

Редактировать:

Если вы создали объект в example.com, он будет реплицирован в GC в child.example.com, но поскольку child.example.com имеет IM для GC, а также имеет другие контроллеры домена, которые не являются GC, этот новый объект будет никогда не создавайте фантом для этого на других DC в child.example.com. И поэтому вы не сможете добавить этот новый объект в списки ACL или поместить его в группы безопасности и т. Д. Из этих других контроллеров домена, потому что они не позволят вам добавить участников, на которые они не ссылаются. И это правильно, потому что тогда у вас возникнут всевозможные странные проблемы ссылочной целостности.

В противном случае, если вы создали новый объект в child.example.com, он реплицировался бы на example.com, и было бы нормально использовать этот новый объект в example.com, потому что у вас нет контроллеров домена в родительском объекте. домен, который не реплицируется в IM должным образом.

И аналогичным образом именно поэтому Microsoft обычно рекомендует просто сделать все ваши контроллеры домена GC, потому что тогда не имеет значения, работает ли IM должным образом или нет, потому что все контроллеры домена в любом случае имеют всю обновленную информацию в силу того, что они являются GC.

Изменить: я также просто хотел вернуться к этому посту и упомянуть, что, когда AD Recycle Bin включена, инфраструктура FSMO абсолютно ничего не делает:

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