О некоторых нюансах настройки межсайтовой репликации AD, или «почему Technet не заменит головы»
Invite pending
Причиной появления поста явился текст О некоторых нюансах настройки межсайтовой репликации AD или «Не все статьи от Microsoft одинаково полезны», ответить на который прямо в топике не позволяет read-only.
Вкратце, описана следующая ситуация — настройка, включающая механизм Change Notification при межсайтовой репликации через созданный вручную коннектор, не дает желаемого эффекта, хотя, согласно этой статье, должна.
— Ок, магия не сработала, — спросит пытливый читатель. — Что же случилось?
Вариант «и правда не работает, они на своем технете не знают, о чем пишут» мы пока рассматривать не будем, как крайне маловероятный. А будем исходить из более часто встречающегося варианта — мы что-то упустили в настройке.
1. Воспроизводим тестовую среду — делаем тестовый домен на WS 2012 с двумя контроллерами TESTDC0 и TESTDC1 в разных сайтах, настраиваем Change Notification на сайте. Убеждаемся, что при автоматически созданных межсайтовых связях всё работает. Не буду лишний раз перечислять подробности настройки.
2. Создаем вручную два межсайтовых подключения. Удаляем автоматически созданные. Выставляем на каждом ручном подключении атрибут Options = 8 (USE_NOTIFY). Видим, что проблема действительно имеет место быть — репликация идет только по расписанию.
Ну что же, попробуем разобраться. Первое, что приходит в голову — если по автоматически созданным подключениям всё работает, а по ручным — нет, какая первая мысль? Просто посмотреть, чем же эти подключения друг от друга отличаются. И начать с банального сравнения атрибутов соответствующих объектов в AD. Тут мы видим, что отличий практически нет, только вот созданное KCC подключение имеет значение атрибута Options не 0x8 (как мы выставили на ручном подключении), а 0xD. Причем редактор атрибутов заботливо подсказывает нам расшифровку — (IS_GENERATED|OVERRIDE_NOTIFY_DEFAULT|USE_NOTIFY). Без расшифровки пришлось бы наконец заглянуть в мануал и посмотреть, что же значат биты, но MS тщательно делает за админа его работу по чтению документации. Бит IS_GENERATED, означающий, что подключение было автоматически создано KCC, нас пока не интересует, а вот название OVERRIDE_NOTIFY_DEFAULT, похоже, весьма намекает на возможную причину проблемы.
Проверяем. Options=0xC на обоих линках, реплицируемся, и вуаля — процесс пошел.
С одной стороны, можно только похвалить MS за то, что Windows Server доведен до такой простоты в эксплуатации, что в подавляющем большинстве случаев для настройки даже очень комплексных фич надо просто запустить мастер, ткнуть Next-Next-Next, и всё само заработает. С другой — в среде администраторов это порождает массу проблем вида «кнопка не работает, гугль не гуглит, никогда такого не бывало, что же теперь делать?» даже в ситуациях, когда для решения нужно всего лишь немного любопытства. И хорошо ещё, если это не переходит в «да глюкалово сплошное эта ваша винда» или «а вот в линуксе можно прямо в сорцы посмотреть, а винде вообще непонятно, что делать».
Коллеги — администраторы Windows, пожалуйста, не позволяйте внешней простоте продуктов MS и обилию готовых решений в статьях Технета отучить себя думать.
Вкратце, описана следующая ситуация — настройка, включающая механизм Change Notification при межсайтовой репликации через созданный вручную коннектор, не дает желаемого эффекта, хотя, согласно этой статье, должна.
— Ок, магия не сработала, — спросит пытливый читатель. — Что же случилось?
Вариант «и правда не работает, они на своем технете не знают, о чем пишут» мы пока рассматривать не будем, как крайне маловероятный. А будем исходить из более часто встречающегося варианта — мы что-то упустили в настройке.
1. Воспроизводим тестовую среду — делаем тестовый домен на WS 2012 с двумя контроллерами TESTDC0 и TESTDC1 в разных сайтах, настраиваем Change Notification на сайте. Убеждаемся, что при автоматически созданных межсайтовых связях всё работает. Не буду лишний раз перечислять подробности настройки.
2. Создаем вручную два межсайтовых подключения. Удаляем автоматически созданные. Выставляем на каждом ручном подключении атрибут Options = 8 (USE_NOTIFY). Видим, что проблема действительно имеет место быть — репликация идет только по расписанию.
Ну что же, попробуем разобраться. Первое, что приходит в голову — если по автоматически созданным подключениям всё работает, а по ручным — нет, какая первая мысль? Просто посмотреть, чем же эти подключения друг от друга отличаются. И начать с банального сравнения атрибутов соответствующих объектов в AD. Тут мы видим, что отличий практически нет, только вот созданное KCC подключение имеет значение атрибута Options не 0x8 (как мы выставили на ручном подключении), а 0xD. Причем редактор атрибутов заботливо подсказывает нам расшифровку — (IS_GENERATED|OVERRIDE_NOTIFY_DEFAULT|USE_NOTIFY). Без расшифровки пришлось бы наконец заглянуть в мануал и посмотреть, что же значат биты, но MS тщательно делает за админа его работу по чтению документации. Бит IS_GENERATED, означающий, что подключение было автоматически создано KCC, нас пока не интересует, а вот название OVERRIDE_NOTIFY_DEFAULT, похоже, весьма намекает на возможную причину проблемы.
Проверяем. Options=0xC на обоих линках, реплицируемся, и вуаля — процесс пошел.
С одной стороны, можно только похвалить MS за то, что Windows Server доведен до такой простоты в эксплуатации, что в подавляющем большинстве случаев для настройки даже очень комплексных фич надо просто запустить мастер, ткнуть Next-Next-Next, и всё само заработает. С другой — в среде администраторов это порождает массу проблем вида «кнопка не работает, гугль не гуглит, никогда такого не бывало, что же теперь делать?» даже в ситуациях, когда для решения нужно всего лишь немного любопытства. И хорошо ещё, если это не переходит в «да глюкалово сплошное эта ваша винда» или «а вот в линуксе можно прямо в сорцы посмотреть, а винде вообще непонятно, что делать».
Коллеги — администраторы Windows, пожалуйста, не позволяйте внешней простоте продуктов MS и обилию готовых решений в статьях Технета отучить себя думать.