Есть много статей в TechNet, например вот этот которые говорят, что фантомный объект не обновляется, если мастер инфраструктуры также является глобальным каталогом, но кроме этого не так много подробной информации о том, что фактически происходит в этой конфигурации.
Представьте себе такую конфигурацию:
|--------------|
| example.com |
| |
| dedicated IM |
|--------------|
|
|
|
|-------------------|
| child.example.com |
| |
| IM on a GC |
|-------------------|
куда child имеет два контроллера домена, которые являются глобальными каталогами, что означает, что роль хозяина инфраструктуры находится на глобальном каталоге. И, example имеет три DC с ролью Infrastructure Master на DC, который не сборщик мусора.
Я понимаю, что обычно лучше всего просто сделать все GC и не беспокоиться о подобных вещах, но если это не так - что точный поведение ошибки, которое можно ожидать от такой настройки, и в каких доменах это поведение проявится? Ребенок или родитель?
Контроллер домена, не являющийся глобальным каталогом, не имеет копии (с частичным набором атрибутов или нет) каждого объекта в лесу. Следовательно, такой DC должен создавать «фантомные» объекты для ссылки на реальные объекты из другого домена.
Мастер инфраструктуры в домене отвечает за обновление этих фантомных ссылок на других контроллерах домена в домене. Для этого он сначала ссылается на сервер глобального каталога в своем домене, поскольку мы предполагаем, что глобальные каталоги имеют наиболее полные и актуальные сведения обо всех объектах в лесу.
Проблема вот в чем. Если хозяином инфраструктуры является тот же сервер, что и глобальный каталог, когда IM отправляется выполнять свою работу по обновлению (каждые 2 дня), он проверяет сборщик мусора, которым также является он сам. "Ну, я тут разницы не вижу!" Он говорит, потому что он уже на GC, и поэтому нет никакой разницы между тем, что находится на GC, и тем, что находится в IM ... так что, конечно, похоже, что он полностью обновлен. Проблема в том, что теперь он снова засыпает, довольный, что делать нечего. Это означает, что другие контроллеры домена в домене, не являющиеся сборщиками мусора, не обновляются с помощью этой междоменной информации.
Редактировать:
Если вы создали объект в example.com, он будет реплицироваться в GC в child.example.com, но поскольку child.example.com имеет IM на GC, а также имеет другие DC, которые не являются GC, этот новый объект будет никогда не создавайте фантомы для этого на других контроллерах домена в child.example.com. И поэтому вы не сможете добавить этот новый объект в списки управления доступом или поместить его в группы безопасности и т. Д. С этих других контроллеров домена, потому что они не позволят вам добавлять участников, для которых у них нет ссылок. И это правильно, потому что тогда у вас будут всевозможные странные проблемы ссылочной целостности.
Иначе говоря, если вы создали новый объект в child.example.com, он будет реплицирован на example.com, и будет нормально использовать этот новый объект в example.com, потому что у вас нет контроллеров домена в родительском домен, который не реплицируется должным образом IM.
Точно так же Microsoft обычно рекомендует просто сделать все ваши контроллеры домена GC, потому что тогда не имеет значения, работает ли IM должным образом или нет, потому что все контроллеры домена в любом случае имеют всю обновленную информацию в силу того, что они являются GC.
Редактировать: Я также просто хотел вернуться к этому сообщению и упомянуть, что когда AD Recycle Bin включена, Infrastructure FSMO абсолютно ничего не делает: