Неажиданно любвиабильное выдалось воскресенье - AD устроил восьмичасовой АД (надеюсь, кто-нибудь из знакомых оценит эту школьную аббревиатуру, ибо праведная рассшифровка довольно точно описывает саму ситуацию и атмосферу, создаваемую начальством при перспективе простоя производства).
Симптомы появившейся воскресным утром проблемы были самые классические - "ничего не работает" =). Но ведь и в самом деле ничего не работало - бэкапы не запускались, в систему залогинится не удавалось. Столь же преспективным был список последних изменений - "перезагрузка сервера". Без особых проблем беда была локализованна и идентифицированна, как неработающий Active Directory. Казалось бы, использовалась отказоустойчивая конфигурация с репликацией на несколько серверов, и проблема с одним из них не должна была повлиять на работоспособность AD.
Причиной же подобного поведения послужил DNS. Однако, исправления настроек DNS не привели к желаемому результату. AD хоть и показывал какие-то признаки жизни, но Global Catalog был недоступен, а в папку SYSVOL вообще смотреть стало неприятно. Итак, ситуация выглядит следующим образом:
-
Из SYSVOL'а сбежали все файлы, внутри SYSVOL'а находится только папка с пугающим именем "NtFrs_PreExisting__See_EventLog" (все содержимое SYSVOL'а магическим образом переместилось в эту папку)
-
В логах системы присутствует запись "Active Directory was unable to establish a connection with the global catalog" (спасибо, кэп).
-
Утилита dcdiag тесты заваливает, но понять весь смысл её красноречивых высказываний не особо удается.
Ясно и по делу пишет только netdiag:
Domain membership test . . . . . . : Failed
[WARNING] This system volume has not been completely replicated to the local machine. This machine is not working properly as a DC.
Всё дело в том, что контроллер домена с недореплицированным SYSVOL будет отказываться от выполнения своих прямых обязанностей до момента решения проблем с репликацией. На самом деле эта ситуация не раз уже обсуждалась в интернетах. Мы воспользовались инструкцией для принудительной синхронизации реплик из документа KB315457 (How to rebuild the SYSVOL tree and its content in a domain http://support.microsoft.com/kb/315457/en-us?fr=1 ).
Метод немножко хардкорный, так как предполагает выставление флагов Burflags в реестре, и в самом документе написано, что использовать данную процедуру следует только как последнее средство, когда ничего другое не помогает, хотя по сути все просто:
-
Останавливаем службу ntFRS на всех контроллерах домена
-
Выбираем один из контроллеров в качестве authoritative (все остальные будут копировать данные с него). Выставляем в реестре данной машины Burflags в D4 (authoritative), перемещаем содержимое SYSVOL в укромное место
-
На всех остальных системах вычищаем содержимое SYSVOL и выставляем в реестре Burflags в D2 (non-authoritative)
-
Перезапускаем службу ntfrs на всех DC, начиная с главного (того, что мы выбрали в качестве authoritative)
-
Восстанавливаем на authoritative DC содержимое папки SYSVOL (например, перемещая файлы из папки NtFrs_PreExisting__See_EventLog или из бэкапа). После этого все остальные DC должны синхронизировать свои реплики с authoritative DC.
Перед выполнением необходимо очень внимательно прочитать первоисточник, так как есть вероятность собрать некоторые очевидные и не очень грабли:
-
на шагах 2 и 5 рекомендуется именно перемещать файлы (move) и только в пределах одного раздела/файловой системы. В противном случае и в случае востановления из бэкапа ести шанс огрести проблемы с доступом к файлам из-за неправильных ACL.
-
перед запуском ntfrs, внутри SYSVOL на каждом контроллере должна существовать правильная иерархия дэфолтных каталогов, и некоторые из них должны иметь правильные линки в некоторые системные каталоги. Для проверки и создания линков используется утилита linkd.
-
имеется ограничение на максимальное количество DC. Если надо восстановить более 15 контроллеров, то необходимо делать это постепенно: сначала дождаться синхронизации первых 10 контроллеров, потом запускать ntfrs на следующем десятке и т.д.
Умные люди говорят, что проблему можно было решить и без ковыряния в реестре, но расскуривать все тонкости репликации AD времени не было.
