Що в багатодоменному лісі, що ТОЧНО відбувається, коли деякі, але не всі, майстри інфраструктури знаходяться на глобальних каталогах?

Існує велика кількість статей TechNet, як ця, що говорить про те, що фантомний об’єкт не оновлюється, якщо майстер інфраструктури є також Глобальним каталогом, окрім того, що немає багато глибокої інформації про те, що насправді відбувається в цьому конфігурація.

Уявіть таку конфігурацію:

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

Там, де childє два постійних постійного струму, які є обома глобальними каталогами, це означає, що роль магістра інфраструктури належить до GC. І exampleмає три постійних джерела постійного струму з роллю майстра інфраструктури для постійного струму, який не є GC.

Я розумію, що зазвичай краще всього зробити GC і не потрібно турбуватися про подібні речі, але припускаючи, що це не так - яка точна поведінка помилок, яку можна очікувати від такої установки та який домен ( s) чи проявилася б така поведінка в? Дитина чи батько?

Контролер домену, який не є глобальним каталогом, не має копії (часткового набору атрибутів чи ні) кожного об'єкта в лісі. Тому такий DC повинен створювати "фантомні" об'єкти для посилання на реальні об'єкти з іншого домену.

Майстер інфраструктури в домені несе відповідальність за оновлення цих фантомних посилань на інших DC в домені. Для цього він спочатку посилається на глобальний сервер каталогів у своїй області, оскільки ми припускаємо, що глобальні каталоги мають найповніші, найсвіжіші знання про всі об’єкти в лісі.

Проблема в цьому. Якщо майстер інфраструктури - той самий сервер, що і глобальний каталог, коли ІМ іде виконувати свою роботу з оновлення, (кожні 2 дні) він перевіряє GC, що також буває самим собою. "Ну, я не бачу тут різниці!" Він каже, тому що він уже в GC, і тому немає різниці між тим, що є в GC, і тим, що в IM ... так, звичайно, це виглядає так, що він повністю в курсі. Проблема в тому, що він повертається спати, переконавшись, що робити нічого. Це означає, що інші контролери домену в домені, які не є GC, не оновлюються цією доменною інформацією.

Редагувати:

Якщо ви створили об'єкт в example.com, він буде реплікуватися на GC у child.example.com, але оскільки в child.example.com є чат на GC, а також у інших постійних токах, які не є GC, цей новий об'єкт буде ніколи не створюйте для цього фантома для інших ЦК в child.example.com. І тому ви не зможете додати цей новий об’єкт до ACL або розмістити його в групах безпеки тощо з цих інших ДК, оскільки вони не дозволять вам додавати принципи, на які вони не мають посилання. І це справедливо, тому що тоді у вас виникли б усілякі дивні проблеми з цілісністю референтності.

Якщо піти іншим способом, якщо ви створили новий об’єкт у child.example.com, він буде реплікуватися на example.com, і було б нормально використовувати цей новий об’єкт в example.com, оскільки у вас немає жодного постійного струму в батьківському середовищі домен, який не відтворюється належним чином IM.

І подібним чином, тому Microsoft зазвичай рекомендує просто створити всі ваші постійні комп'ютери, тому що тоді не має значення, чи чат працює належним чином, чи ні, оскільки всі постійні комп'ютери все-таки мають всю оновлену інформацію через те, що вони є GC.

Редагувати: Я також просто хотів повернутися до цієї публікації та зазначити, що коли ввімкнено кошик AD, інфраструктура FSMO абсолютно нічого не робить:

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