Перестала работать репликация DFS на одном контроллере домена. Ошибка DFSR 6002

Недавно столкнулись ситуацией – производилась миграция контроллера домена, и после её завершения на соседнем контроллере перестала работать репликация sysvol. В журнале событий были записи с кодом 6002 относящиеся к DFSR, с текстом:

Служба репликации DFS обнаружила недопустимые данные объекта msDFSR-Subscriber при запросе сведений о конфигурации.

 Дополнительные сведения:

DN объекта: CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC03,OU=Domain Controllers,DC=test,DC=loc

Имя атрибута: msDFSR-MemberReference

Контроллер домена: dc03.test.loc

Цикл запроса: 60 мин

Также при просмотре репликации в оснастке DFS – проблемный контроллер домена перестал отображаться.

В тексте ошибки ясно указано с каким объектом и атрибутом возникла проблема, можно посмотреть на этот объект в adsiedit, в контексте именования по умолчанию:

Смотрим – значение атрибута msDFSR-MemberRefference – не задано.

Поглядим, что на «живом» контроллере в таком же объекте:

Есть какое-то значение:

CN=DC01,CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=test,DC=loc

Попробуем вбить аналогичное значение, указав соответственно нужное имя для неработающего контроллера домена:

Не прокатило, получаем ошибку – ссылка на имя не верна.

ОК, раз пишет про ссылку, можно попробовать глянуть, на ссылку из работающего контроллера, путь там указан, по нему и идём – System, GlobalSettings, DFSR-GlobalSettings, Domain System Volume, Topology

Тут у нас всего один контроллер, хотя в моём случае должно быть 2. Можно попробовать вручную создать второй, подсматривая нужные параметры из работающего объекта.

Common-Name – это CN, т.е. имя контроллера домена – у меня DC03

msDFSR-ComputerReference – ссылка на объект компьютера, типа полного пути

Пробуем нажать на готово

Ура! Объект создался, можно попробовать теперь указать ссылку для поля msDFSR-MemberRefference, в объекте CN=Domain System Volume проблемного контроллера домена.

Значение успешно задалось.

Ну что ж можно попробовать перезапустить службу DFSR и посмотреть – пойдет ли теперь репликация:

Увы, опять что-то пошло не так. При чём теперь ошибки стало 2. Но можно заметить, что ошибка 6002 теперь ругается на другой атрибут - службе не нравится атрибут ServerRefference, да и объект другой – тот самый, который мы только что создали:

Служба репликации DFS обнаружила недопустимые данные объекта msDFSR-Member при запросе  сведений о конфигурации.

Дополнительные сведения:

DN объекта: CN=DC03,CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=test,DC=loc

Имя атрибута: ServerReference

Контроллер домена: dc03.test.loc

Цикл запроса: 60 мин

В новой ошибке с кодом 6006 пишется следующее:

Служба репликации DFS обнаружила несогласованный объект msDFSR-Subscriber при запросе сведений о конфигурации. Объект на CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC03,OU=Domain Controllers,DC=test,DC=loc ссылается на другой объект на  CN=DC03,CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=test,DC=loc, которого не существует.

Дополнительные сведения:

Контроллер домена: dc03.test.loc

Цикл опроса: 60 мин

Возвращаемся в adsiedit и идем в свойства только что созданного объекта

Атрибут serverReference – не задан.

Зададим его, подсмотрев, что написано на рабочем контроллере домена и изменив конечно имя контроллера домена:

Всё должно пройти успешно. Пробуем опять перезапустить службу DFSR

В журнале событий больше нет ошибок:

Проверяем репликацию – работает

В консоли DFS теперь отображается оба контроллера домена

Как такое могло произойти? Тут как мне кажется возможно 2 варианта:

1. Маловероятный – диверсия, целенаправленное или случайное удаление объекта из AD.
2. Более вероятный – один из контроллеров домена уже ранее переименовывался, но не был выполнен второй ОБЯЗАТЕЛЬНЫЙ шаг переименования (если отталкиваться ]]>от шагов из документации MS]]>) объекта CN=ИмяКонтроллераДомена в CN=Topology, который мы собственно пересоздали. Его обязательно нужно переименовывать вручную, после изменения имени контроллера домена.

При чём, если его не переименовать, то ничего не выдаст потенциальной неприятности, которая может случиться через много-много лет после выполнения процедуры. Репликация будет работать как ни в чём небывало, ни каких ошибок и предупреждений не будет появляться, dcdiag не будет находить проблем. До часа икс, конечно.

Я предполагаю, что было примерно так – когда-то сто лет назад, уже было переименование контроллера домена, но имя объекта осталось старым. И вот сейчас, когда потребовалось снова прозрачно смигрячить сервер, ему было дано имя, которое уже было забито в топологии. Этот объект успешно перезаписался, и по невнимательности ввиду большого количества контроллеров домена это не бросилось в глаза тому, кто осуществлял миграцию. Вот вам одна из причин, почему рекомендуется всё же давать нужное имя до повышения роли.