В один не очень замечательный день перестал отвечать на запросы сервер контроллера домена Active Directory. Второй контроллер домена тоже оказался неработоспособным. Оба они находились в синем экране смерти с кодом 0xc0002e2. Пришлось проводить восстановление Active Directory.

@duzlov (Дмитрий Узлов) и @sergey_algin (Сергей Альгин) запаслись крепким кофе и начали работу.

Использование ntdsutil для тестирования базы данных Active Directory

Перезагрузка серверов в разных режимах не помогла. Причем один из серверов при загрузке выдавал огромное количество предупреждений и ошибок про контроллер дисков. Вскрытие сервера показало, что вышла из строя батарея raid-контроллера. Похоже, что это и послужило причиной сбоя сервера.

Я перегрузил сервер в режиме восстановления служб Active Directory (Directory Service Restore Mode (DSRM)).

Сделал копии всех файлов, находящихся в каталогах c:\windows\NTDS; c:\windows\SYSVOL.

В командной строке запустил утилиту ntdsutil, служащую для работы с базой данных ntds.dit:

В командной строке ntdsutil необходимо активировать базу данных Active Directory:

А после проверить базу данных на наличие ошибок:

База данных рассыпалась, виноват сбой в контроллере дисков:

Повреждения базы данных Active Directory (фото из Интернет)

На втором сервере ситуация была схожей. Было решено восстановить сервер из резервной копии.

После восстановления сервера из резервной копии казалось, что все проблемы разрешатся, но этого не случилось.

Сервер уходил в бесконечную перезагрузку. Зато база данных ntds.dit, журналы, SYSVOL были в надлежащем состоянии.

К сожалению, все попытки восстановить работоспособность сервера не привели к успеху.

После чтения документации и статей в Интернет я решил попробовать неописанный в них способ восстановления – попытку подмены файлов базы данных Active Directory, SYSVOL во вновь установленном сервере.

Предпосылкой к этому решению был тот факт, что для поднятия контроллера домена можно использовать IFM.

IFM (Install from Media) – метод установки дополнительного контроллера в существующий домен с использованием набора файлов. Это помогает уменьшить трафик репликации и применимо в сценариях с удаленными территориальными офисами, связанными медленными WAN-каналами.

Подробнее про IFM можно прочесть в статье technet.

В структуре IFM есть копии файлов ntds, SYSVOL и кусты реестра. Но для использования этих файлов при типовой установке требуется наличие работоспособных контроллеров домена. В нашей ситуации этот способ использовать нельзя.

Установка новой серверной операционной системы

Для подтверждения гипотезы с подменой необходимых файлов было решено установить новую операционную систему и перезаписать файлы Active Directory.

После установки системы я установил роли AD DS, DNS, DHCP. Это необходимо для того, чтобы в файловой системе уже присутствовали все необходимые бинарные компоненты для запуска служб.

Затем перегрузил сервер с внешнего носителя в Windows PE, сделал копии Windows, ProgramData, Users и начал эксперимент.

Первым делом я перезаписал в каталоги c:\windows; c:\windows\NTDS и c:\windows\SYSVOL файлы с имеющейся копии. Удалил все файлы *.log в каталоге NTDS:

Перезагрузка сервера и снова

Вывод, что для восстановления работоспособного контроллера домена наличия NTDS и SYSVOL недостаточно. Это и так было понятно, но проверить всё-таки стоило.

Снова перезагрузка сервера в Windows PE, восстановление папок Windows, ProgramData и Users. Проверка – сервер загружается.

Вторая попытка – копирование помимо NTDS и SYSVOL ещё и ProgramData, Users и кустов реестра.

Кусты реестра находятся в папке %SystemRoot%\System32\Config. Скопировал все кусты реестра. Перезагрузка и снова синий экран.

В третьей попытке восстановления я решил не копировать ProgramData, Users и ограничился копированием NTDS, SYSVOL и кустов реестра SAM и SYSTEM.

Перезагрузка – УДАЧА! Сервер загрузился, в него можно было войти под доменной учётной записью, он определился как контроллер домена.

DNS был интегрирован в Active Directory, все записи DNS тоже были на месте. База DHCP не восстановилась. Но, если на клиентском компьютере установить static IP, пользователь и компьютер могут получить доступ к ресурсам.

Но внутри самого сервера были проблемы, связанные с отсутствием прав доступа к меню Пуск, контекстному меню в Проводнике. Можно было запустить командную строку и работать из неё.

Проверка целостности ntds с помощью ntdsutil показала, что всё в порядке.

Было решено заново установить серверную операционную систему и создать новый контроллер домена.

Проверка репликации базы данных показала, что не синхронизируются netlogon и sysvol. Для решения этой задачи необходимо провести процедуру полномочной синхронизации.

Полномочная синхронизация для DFSR репликации SYSVOL

На контроллере домена, который обладает актуальной копией Active Directory (в нашем случае – это восстановленный в предыдущем шаге контроллер), запускаем adsiedit.msc.

Выбираем Контекст по умолчанию и переходим в раздел

Необходимо модифицировать два атрибута и установить следующие значения:

На всех остальных контроллерах домена модифицируем только один атрибут:

На всех контроллерах домена выполняем репликацию:

Команда выполняется без ошибок, далее необходимо перезапустить службу DFSR на всех контроллерах домена:

Ждем, пока в журнале событий не появится Event ID 4114 и меняем значение атрибута на полномочном (восстановленном) сервере обратно:

Снова на всех контроллерах домена выполняем репликацию:

На полномочном сервере запускаем команду:

В журнале событий должно появиться событие Event ID 4602

На полномочном сервере перезапускаем службу DFSR:

На втором контроллере домена меняем значение атрибута

и выполняем команду

Состояние репликации можно проверить в оснастке Управление DFS:

Передача ролей FSMO новому контроллеру домена

Из-за того, что старый контроллер домена находится в неустойчивом состоянии, его необходимо вывести из эксплуатации и передать или захватить роли FSMO на новый контроллер домена.

Есть разные варианты сделать это, но я решил делать передачу ролей через ntdsutil.

На новом контроллере домена в командной строке, запущенной с привилегиями Enterprise Admin, вводим команду:

Далее в командной строке ntdsutil вводим по одной команды

Переустановка серверной операционной системы на первом сервере

На текущий момент есть два контроллера домена – восстановленный из резервной копии и новый.

Восстановленный сервер необходимо переустановить, чтобы устранить все ошибки, связанные с его работоспособностью.

Для этого производится чистая установка операционной системы, серверу необходимо дать новое имя. Сервер вводится в домен и устанавливаются необходимые роли AD DS и DNS. Сервер поднимается до уровня контроллера домена. Необходимо удостовериться в успешной репликации Active Directory между контролерами домена.

Следующим шагом необходимо очистить  устаревшие метаданные в базе данных Active Directory. Подробнее написано в статье.

Выводы

Active Directory – очень чувствительная для работы компании инфраструктура и необходимо проверять её работоспособность на регулярной основе.

Необходимы средства резервного копирования для сохранения информации с инфраструктурных серверов, а не только пользовательской информации.

Без наличия кустов реестра, обладая только файлами NTDS, восстановить работоспособность сервера невозможно.

Необходимо отслеживать и устранять неполадки в оборудовании.

И не сдавайтесь!

Опыт восстановления контроллера домена Active Directory
Поделись с друзьями:
Дмитрий Узлов on EmailДмитрий Узлов on FacebookДмитрий Узлов on Linkedin
Руководитель направления проектов компании "Технополис".
MCSE - Cloud Platform and Infrastructure [Charter Member]
MCSE - Productivity

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

Отправить ответ

Please Login to comment

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

  Subscribe  
Уведомлять
Перейти к верхней панели