После аварийного отключения физического сервера с ролью контроллера домена Active Directory при загрузке сервера столкнулись с BSOD ошибкой stop code 0x00002e2. Данная ошибка указывает на то, что база Active Directory (файл NTDS.DIT) повреждена. В этой статье мы разберемся, как исправить файл ntds.dit и запустить контроллер домена (в нашем примере это сервер с Windows Server 2016).
В предыдущих версиях Windows Server эта же ошибка выглядит так:
STOP c000002e2 Directory Services could not start because of the following error: A device attached to the system is not functioning. Error Status: 0xc0000001 Please shutdown this system and reboot into Directory Services Restore Mode, check the event log for more detailed information.
Итак, Windows Server на контроллере домена не загружается с ошибкой 0xc00002e2. После трех перезагрузок сервера он автоматически перейдет в режим восстановления WinRE (или нажмите F8 при загрузке). Вам нужно запустить Windows в режиме восстановления службы каталогов (DSRM).
Выберите Startup Settings -> Restart.
Затем после загрузки выберите Directory Services Restore Mode в меню расширенных опций загрузки.
При загрузке сервера в режиме DSRM вы сможете войти на него под локальным администратором. На контроллере домена единственная локальная учетная запись — администратор DSRM. Вы задаете его пароль при установке роли контроллера домена ADDS на сервере (SafeModeAdministratorPassword).
После входа на рабочий стол DC запустите командную строку. На этом этапе нужно убедиться, на месте ли все каталоги и файлы службы каталога.
Выполните команды:
NTDSUTIL
activate instance ntds
Files
Info
Убедитесь, что каталог с файлом NTDS (по умолчанию C:\Windows\NTDS) и сам файл ntds.dit находятся по указанным путям и не удалены.
Попробуем проверить целостность базы данных AD:
integrity
В моем случае команда вернула, что база повреждена:
Could not initialize the Jet engine: database is inconsistent. Failed to open DIT for AD DS/LDS instance NTDS. Error -2147418113
Нам придется исправить файл с базой AD с помощью утилиты esentutl. Утилита должна быть хорошо знакома администраторам Exchange. Также мы показывали, как использовать esentutl, чтобы уменьшить размер индексного файла службы поиска Windows.edb. Но сначала сделайте резервную копию содержимого каталога NTDS:
mkdir c:\ntds_bak
xcopy c:\Windows\NTDS\*.* c:\ntds_bak
Проверим целостность файла ntds.dit:
esentutl /g c:\windows\ntds\ntds.dit
Утилита определила, что база AD повреждена:
The database is not up-to-date. This operation may find that this database is corrupted because data from the log files has not yet to be placed in the database. To ensure the database is up-to-date please use the Recovery operation. Integrity check completed. Database is CORRUPTED.
Попробуйте исправить ошибки в базе данных с помощью команды:
esentutl /p c:\windows\ntds\ntds.dit
Если ошибки исправлены, должно появится сообщение:
Operation completed successfully in xx seconds.
Еще раз проверьте целостность с помощью
esentutl /g
.
Integrity test successful. It is recommended you to run semantic database analysis to ensure semantic database consistence as well.
Выполните анализ семантики базы с помощью ntdsutil:
ntdsutil
activate instance ntds
semantic database analysis
go
Если семантические ошибки найдены, чтобы исправить их выполните:
go fixup
Теперь можно сжать файл ntds.dit:
activate instance ntds
files
compact to C:\Windows\NTDS\TEMP
Замените оригинальный файл ntds.dit:
copy C:\Windows\NTDS\TEMP\ntds.dit C:\Windows\NTDS\ntds.dit
Удалите все лог файлы из каталога NTDS:
Del C:\Windows\NTDS\*.log
Перезагрузите сервер в обычном режиме. Убедитесь, что службы ADDS стартовали и контроллер домена доступен по сети. Проверьте здоровье контроллера домена и состояние репликации Active Directory.
Если резервной копии нет, придется удалить роль ADDS в режиме DSRM и принудительно удалить из AD все упоминания об этом DC. Потом выполните sysprep, и установите новый контроллер домена.
ИМХО
такой способ восстановления оправдан только если это единственный контроллер в домене.
Если есть хотя бы один другой контроллер, я бы лучше принудительно удалил сбойный контроллер из домена, и поднял бы новый.
Неизвестно, что там эти утилиты проверки-исправления базы могут наворотить. Пометят, например, OU контроллеров домена как отсутствующую и после включения это всё среплицируется на весь лес.
А не многовато ли мороки, если контроллер не один? Удалять, да еще и принудительно, вычищать из AD, потом ловить глюки…
Не самое ли верное решение подняться из резервной копии wbadmin?
Вадим, Вашего способа тоже касается. А вдруг не просто файл не был закрыт, но и транзакция какая-то криво прошла или кэш был включен(например аппаратный) и не записался на диск(пока батарейка не иссякла)…
В данной статье рассматривался кейс из тестовой среды с одним DC и полным отсуствием бэкапов. Наверно это нужно было указать в начале статьи. Утилиты базу точно не сломают, но каких-то послежних измненеий вы можете не увидеть.
В большом домене — согласен — проще вариант с восстановлением или поднятием нового сервера. Тут кому что быстрее.
Спасибо )
Насчет бэкапов DC etc.
У меня вся инфра-ра расположена на Proxmox VE.
Бэкапы вирт. машин (DC, BDC etc) выполняются по расписанию (встроенная фича proxmox), хранятся нес-ко копий.
Также можно прикрутить proxmox backup server и бэкапить инкрементно.
Оба продукта — open source )
Кому интресно про Proxmox, ZFS, pfsense etc — forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-%D0%B8-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D1%87%D0%B0%D1%81%D1%82%D1%8C-2
Здравствуйте, не подскажите полный код для того, что бы он менял значение extensionAttribute1 на то, которое мне нудно (массово) через csv