Tw-city.info

IT Новости
3 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Восстановление контроллера домена из резервной копии

Восстановление после сбоев Active Directory

Однако многие приемы, используемые для восстановления после простых сбоев, применимы и к катастрофическим отказам. В данной статье рассматривается, как устранить последствия двух наиболее типичных аварий: отказа DC и случайного удаления объектов

Обычно Active Directory (AD) — ключевая сетевая служба в любой компании, без нее невозможна работа всех прочих механизмов. Поэтому важно заранее подготовиться к авариям различных типов, которые могут произойти в лесу.

Масштабы аварий AD могут быть очень разными. Это может быть просто сбой единственного контроллера домена (DC) или случайное удаление одного объекта. Сложнее, если случайно удалена целая иерархия организационных единиц (OU). В худшем случае требуется восстанавливать целый домен или лес.

Стратегия резервного копирования

В первую очередь необходимо иметь материал для восстановления. По меньшей мере, требуются последние резервные копии состояния системы не менее чем двух контроллеров домена в каждом домене леса. Последние резервные копии состояния системы можно получить с помощью Windows Server Backup (Windows Server 2008 и более новые версии), NTBackup (Windows Server 2003 и Windows 2000 Server) и большинства других инструментов резервного копирования. Однако лучше всего проверить резервные копии, чтобы убедиться в их исправности. Важно использовать инструмент резервного копирования, совместимый со службой Volume Shadow Copy Service (VSS). Программы резервного копирования, в которых применяются образы дисков или моментальные снимки виртуальных машин, как правило, несовместимы с AD. Восстановление резервной копии с помощью одного из этих инструментов может привести к серьезным проблемам репликации, известным как возврат номера последовательного обновления (USN).

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

Чтобы смягчить эти проблемы, я часто применяю двухуровневый подход к резервному копированию DC. С помощью сценария Windows Server Backup запускается на DC каждый вечер, а резервные копии за одну или две недели хранятся локально на DC. Папка, содержащая резервные копии, объявляется общей, и доступ к ней ограничивается инструментом резервного копирования, так как многие инструменты могут работать с общей папкой без агента. Кроме того, иногда я сохраняю файлы архива на соседних DC внутри сайта. Поэтому, например, если в сайте имеются контроллеры домена DC1 и DC2, резервные копии DC1 хранятся в общей папке на DC2, и наоборот.

Перечислим преимущества двухуровневого подхода.

  • Снижается риск, связанный с зависимостью резервного копирования от другой группы специалистов.
  • Выполнить восстановление можно немедленно из собственных файлов резервных копий, имеющихся под рукой, не ожидая, пока восстановлением займутся специалисты другой группы.
  • Не нужно тратить время на ожидание, пока резервная копия будет передана через канал WAN из другого сайта, в случае удаленного резервного копирования.

Используемый сценарий для запуска Windows Server Backup вместе с соответствующими инструкциями опубликованы в блоге по адресу briandesmond.com/blog/managing-local-backups-withwindows-server-backup/.

Восстановление DC

Важное достоинство AD — в основном неизменное состояние DC. Помимо возможности исполнения одной или нескольких ролей мастера операций (FSMO), каждый DC должен быть копией других контроллеров в домене, если исключить потенциальные задержки репликации, зависящие от топологии. Если DC выходит из строя из-за неисправности, неизменность состояния очень удобна, поскольку устраняется необходимость в сложном восстановлении из резервной копии. Вместо этого можно просто заново установить Windows и преобразовать сервер в DC с помощью утилиты Dcpromo, а затем реплицировать данные (предполагается, что в домене больше одного DC). Если в домене лишь один DC, отказоустойчивость можно значительно повысить, развернув второй контроллер.

Но перед переустановкой и повторным преобразованием DC необходимо очистить AD. Последняя операция выполняется в два этапа. На первом этапе захватываются любые роли FSMO, которыми может обладать DC, на другом DC в домене. Если неясно, на каких DC размещены роли FSMO в домене, выполните команду

в окне командной строки. Затем можно захватить роли FSMO с использованием утилиты Ntdsutil. Следуйте инструкциям в разделе Seize FSMO roles в статье Microsoft «Using Ntdsutil.exe to Transfer or Seize FSMO Roles to a Domain Controller» (support.microsoft.com/kb/255504). При захвате роли FSMO не рекомендуется подключать к сети первоначального обладателя роли.

Поскольку нельзя вернуть первоначального владельца роли FSMO, второй шаг — удалить метаданные конфигурации отказавшего контроллера домена в AD. Это можно сделать с помощью утилиты Ntdsutil. Выполните действия, описанные в статье Microsoft «How to Remove Data in Active Directory After an Unsuccessful Domain Controller Demotion» (support.microsoft.com/kb/216498). Однако, если используется версия оснастки Active Directory Users and Computers для Server 2008 (или более новой), это можно сделать, удалив учетную запись DC в организационной единице Domain Controllers.

Повторное назначение компьютера контроллером домена через сеть может оказаться неприемлемым, если из-за большого объема реплицируемых данных сеть подвергается перегрузке. В этом случае существует еще два варианта. Первый — восстановить состояние системы DC из резервной копии и продолжать работу. Второй — использовать функцию восстановления с носителя (Install from Media, IFM), появившуюся в Windows 2003. Благодаря IFM можно задействовать резервную копию состояния системы (подготовленную с помощью NTBackup в Windows 2003) или носитель IFM (созданный с использованием Ntdsutil в Server 2008 или новой версии) и указать Dcpromo базу данных на IFM-носителе. IFM-носитель, подготовленный в Windows 2003, необходимо сначала восстановить в другом месте файловой системы (в этом случае его может использовать Dcpromo). DC внесет необходимые изменения в базу данных на носителе и реплицирует только изменения, так как носитель был создан через сеть.

Жизненный цикл объекта AD

Между удалением объекта и изъятием записи из базы данных AD нет непосредственной связи. Чтобы не нарушить согласованность модели репликации AD, объекты сначала переводятся в состояние, именуемое «захоронением», как показано на рисунке 1. Вместо того чтобы применять распределенный механизм для репликации физического удаления из базы данных, AD реплицирует изменение атрибута, указывающего, что объект удален.

При удалении объекта из AD атрибуту isDeleted присваивается значение True, и почти все атрибуты объекта удаляются. Объект перемещается в контейнер Deleted Objects, а атрибут lastKnownParent отмечается различающимся именем (DN) родительского объекта, прежде чем объект удаляется. Объект, отмеченный как удаленный, невидим для любых инструментов, опрашивающих AD, если не добавить специальный элемент управления LDAP, указывающий на необходимость показывать помеченные к удалению объекты в поисковых результатах AD. Этот элемент управления есть в различных бесплатных инструментах формирования запросов LDAP (таких, как AdFind из www.joeware.net).

Объект останется удаленным в течение определенного времени. По умолчанию время существования «захоронения» в лесу определяется операционной системой первого DC леса. В таблице показано время существования «захоронений» по умолчанию. При обновлении AD время существования «захоронений» для леса не меняется.

Периодически на каждом DC запускается фоновый процесс, именуемый «сбором мусора». «Сборщик мусора» просматривает базу данных в поисках «захоронений» старше установленного для леса срока их существования и удаляет их из базы данных AD.

До того как «захоронение» удалено «сборщиком мусора», можно восстановить объект, реанимировав его. После реанимации восстанавливаются лишь немногие атрибуты, сохранившиеся в процессе «захоронения». Например, атрибуты, сохраненные для объекта пользователя, включают SID пользователя, журнал SID и имя пользователя (sAMAccountName). Обратите внимание, что в этом списке отсутствуют такие атрибуты, как пароль пользователя, членство в группах или демографическая информация (например, имя и подразделение). Списком атрибутов, сохраняемых при «захоронении» объекта, можно управлять, изменяя атрибут searchFlags в определении индивидуального атрибута в схеме. Количество атрибутов не ограничено, но нельзя добавлять связанные атрибуты, такие как членство в группе или база данных почтовых ящиков, содержащая почтовый ящик пользователя.

Читать еще:  Альбомная страница в word 2003

В лесу AD на функциональном уровне леса (FFL) Server 2008 R2 можно активировать новую функцию — корзину Active Directory Recycle Bin. Как показано на рисунке 2, благодаря корзине Active Directory появляется промежуточное состояние между удалением и «захоронением» объекта. Объект, находящийся в новом удаленном состоянии, не отображается в результатах поиска, но все его атрибуты (в том числе связанные атрибуты, такие как членство в группах) сохраняются.

Объект на стадии удаления можно восстановить точно в том состоянии, в котором он был в момент удаления с использованием того же процесса, который применялся для реанимации. По умолчанию объект остается на стадии удаления в течение времени, равного сроку существования «захоронения» в лесу, в соответствии с таблицей. Этот период можно изменить, изменив атрибут msDSdeletedObjectLifetime леса.

После окончания срока существования объекта, отмеченного как удаленный, «сборщик мусора» перемещает объект на этап утилизации. Утилизация — функциональный эквивалент «захоронения», с одним отличием: нельзя реанимировать утилизированный объект или восстановить его из резервной копии.

Механизмы восстановления объектов

С каждым новым выпуском AD становится все более зрелой, и механизмы восстановления удаленных объектов совершенствуются. В Windows 2000 единственным способом восстановить объект, отмеченный как удаленный, было выполнить принудительное восстановление из резервной копии. Вместе с Windows 2003 появилась концепция реанимации из «захоронений», чтобы получить частичную копию удаленного объекта, не восстанавливая его из резервной копии. В Server 2008 R2 добавилась корзина Active Directory, что позволяет полностью вернуть удаленный объект без восстановления.

Важно отметить, что срок хранения резервной копии AD (а также носителя IFM) — такой же, как у «захоронения». Если включена корзина Active Directory, срок хранения равен меньшему из сроков существования объекта, отмеченного как удаленный, и утилизированного объекта. Например, если срок существования объекта, отмеченного как удаленный, — 180 дней, а утилизированного объекта — 60 дней, то срок хранения будет 60 дней. Таким образом, невозможно восстановить отмеченный как удаленный объект из резервной копии, которая старше этих значений.

Принудительное восстановление

Если требуется получить объект или группу объектов из резервной копии, часто приходится использовать принудительное восстановление. Пункт Directory Services Restore Mode (DSRM) в загрузочном меню (вызываемом нажатием клавиши F8) DC предназначен для принудительного восстановления. Если выполнить загрузку в режиме DSRM, AD не запускается, а база данных переводится в автономный режим. Можно восстановить базу данных AD из резервной копии в режиме DSRM, а затем выбрать восстанавливаемые объекты с помощью Ntdsutil. Обратите внимание, что невозможно выполнить восстановление, если на контроллерах домена Server 2008 и более новых версий остановлена служба NTDS AD.

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

Часто принудительно восстанавливаются организационные единицы (OU), содержащие множество объектов (учетные записи пользователей, групп, компьютеров, других OU). Предположим, случайно удалена организационная единица Executives из домена contoso.com. Чтобы вернуть OU и все ее содержимое, необходимо выполнить следующие шаги.

1. Загрузитесь в режиме DSRM и выполните регистрацию с паролем DSRM, заданным во время работы Dcpromo.

2. Восстановите системное состояние из резервной копии, созданной до аварии. Не перезагружайте компьютер. Это типичная ошибка, особенно в спешке.

3. Откройте командную строку и запустите Ntdsutil.

4. Запустите команду

5. Воспользуйтесь командой

6. Просмотрите и подтвердите предупреждения безопасности. Затем будет выдано сообщение, подобное показанному на рисунке 3. Обратите внимание на сформированные текстовые и LDIF-файлы.

Неполномочное восстановление AD DS

Неполномочное восстановление AD DS выполняется средствами Windows Server Backup и может потребоваться в самых разных случаях . Сценарий восстановления также зависит от используемой версии операционной системы и версии гипервизора (если контроллеры домена работают в виртуальной среде). Большинство из возможных вариантов я рассмотрю в этой статье.

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.

Неполномочное восстановление AD DS

Выполнять неполномочное восстановление будем через бэкап System State нашего КД.

Того же эффекта можно добиться, используя бэкап критически важных томов, а также при восстановлении из полного бэкапа сервера 1 .

Немного теории

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

  1. Система возвратится в состояние на момент снятие бэкапа (это очевидно);
  2. Будет сгенерирован новый DSA Invocation ID;
  3. Текущий пул RID будет сброшен и получен новый;
  4. Произойдет неполномочное восстановление SYSVOL.

Теперь о каждом пункте подробнее, начиная со 2.

DSA Invocation ID

Invocation ID — это уникальный guid-идентификатор базы данных ntds.dit. Сбрасывая этот параметр, контроллер домена сообщает своим «соседям» о том, что он был восстановлен из бэкапа. То есть, по сути, восстановленный КД становится другим источником репликации и ему требуются все изменения в AD, начиная с момента создания бэкапа.

Этот механизм необходим, чтобы избежать отката номеров последовательных обновлений (USN Rollback 2 ), который заключается в следующем.

AD работает таким образом, что между контроллерами домена передаются лишь последние изменения, а не вся база целиком. Каждый КД поддерживает значение USN своих соседей (up-to-dateness vector). Если другой КД вдруг сообщает свой USN и он оказывается выше «запомненного», значит на другом КД произошли изменения и их надо получить посредством репликации данных. Откат к состоянию бэкапа возвращает максимальный последовательный номер изменений восстановленного сервера к меньшему значению. В итоге все другие КД, получая с восстановленного контроллера его USN, будут уверены, что все изменения с него уже реплицированы, ведь их «запомненные» значения USN восстановленного КД будет больше. Все изменения, внесенные в AD на восстановленном КД в промежутке восстановленного USN и «запомненных» USN на других КД, никогда не будут реплицированы на другие контроллеры. Подобная ситуация приведет к рассогласованию баз данных.

RID Pool

Любой принципал безопасности (пользователь, компьютер, группа) в AD имеет уникальный идентификатор, называемый SID. SID, в свою очередь, состоит из нескольких значений, последним из которых является относительный идентификатор — RID.

Если на момент создания резервной копии у КД имеется выданный пул идентификаторов (а на деле в 99% случаев так оно и будет, за исключением ситуации, когда на момент бэкапа пул был израсходован полностью, а связи с хозяином RID для получения нового пула не было), то после восстановления из бэкапа контроллер домена начнет использовать этот пул заново и в лесу появятся принципалы безопасности с одинаковыми SID.

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

Если же вы восстанавливаете весь лес AD, не забудьте повысить границу выдаваемого пула 3 и сбросить текущие пулы на контроллерах домена 4 .

Переходим к последнему пункту.

SYSVOL restore

Этот момент самый очевидный из всех рассматриваемых. По умолчанию осуществляется именно неполномочное восстановление SYSVOL, чтобы стянуть последние актуальные данные с других КД. Если же необходимо полномочное восстановление 5 , то достаточно поставить соответствующую галочку в мастере WSB или выставить флаг -sysvol, если используете командную консоль.

Когда нужно неполномочное восстановление

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

  1. Рабочий КД вышел из строя в связи с аппаратными/программными проблемами и нет желания разворачивать полностью свежий КД (например потому что на старом были какие-то важные приложения и данные);
  2. При откате к снимку виртуальной машины. Если:
    • КД имеет ОС старше Windows Server 2012;
    • Гипервизор не поддерживает VM-Generation ID (все до Windows Server 2012), вне зависимости от гостевой ОС.
Читать еще:  Второй контроллер домена

Во всех остальных случаях используются другие сценарии восстановления.

Подготовка

К моменту восстановления у вас должны быть:

  1. Резервная копия (я подключил к виртуализованному КД отдельный диск, на который ранее был скопирован бэкап состояния системы);
  2. Пароль DSRM. Придется загружаться в режиме восстановления AD, сервисы будут остановлены, а потому зайти под доменной учеткой не получится, только под локальным админом.

«Операции восстановления, которые выполняются с помощью следующей процедуры, не поддерживаются Майкрософт и должны использоваться только в крайнем случае при отсутствии других вариантов».

Переходим к кульминации.

Восстановление

Хочу отметить, что мой сервер перед операцией восстановления полностью доступен. Если же у вас более сложный случай, то возможно вам понадобится установочный диск операционной системы. В любом случае сценарий восстановления будет отличаться.

Есть несколько способов загрузить сервер в режиме восстановления служб каталогов и я воспользуюсь самым простым из них — нажатие F8 во время загрузки.

bcdedit /set safeboot dsrepair
shutdown -t 0 -r
После выполнения восстановления выполните команду bcdedit /deletevalue safeboot для загрузки в нормальном режиме.
Третий способ — использовать всем знакомую утилиту Msconfig (Загрузка -> Параметры загрузки -> Безопасный режим -> Восстановление Active Directory).
После восстановления также не забудьте вернуть сервер в нормальный режим загрузки.

Итак, нажав F8 дожидаемся загрузки сервера и входим под учетной записью локального администратора:

Вводим пароль DSRM, дожидаемся пока система загрузится.

Не забудьте выбрать Восстановление системы:

После этого увидите предупреждение:

Подтверждаем, далее нажимаем Восстановить и снова соглашаемся с всплывшим предупреждением. Дожидаемся окончания процесса восстановления и перезагружаемся.

Восстановление Active Directory из резервной копии

В этой статье мы покажем, как восстановить контроллер домена Active Directory из резервной копии System State, созданной ранее (см. статью Резервное копирование Active Directory) и рассмотрим типы и принципы восстановления DC в AD.

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

Восстановление контроллера домена AD через репликацию

Восстановление DC через репликацию – это не совсем процесс восстановления DC из бэкапа. Этот сценарий может использоваться, если у вас в сети есть несколько дополнительных контроллеров домена, и все они работоспособны. Этот сценарий предполагает установку нового сервера, повышение его до нового DC в этом же сайте. Старый контроллер нужно просто удалить из AD.

Это самый простой способ, который гарантирует что вы не внесете непоправимых изменений в AD. В этом сценарии база ntds.dit, объекты GPO и содержимое папки SYSVOL будут автоматически реплицированы на новый DC с DC-ов, оставшихся онлайн.

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

Типы восстановления Active Directory: полномочное и неполномочное

Есть два типа восстановления Active Directory DS из резервной копии, в которых нужно четко разобраться перед началом восстановления:

    Authoritative Restore (полномочное или авторитативное восстановление) – после восстановления объектов AD выполняется репликация с восстановленного DC на все остальные контроллеры в домене. Этот тип восстановления используется в сценариях, когда упал единственный DC или все DC одновременно (например, в результате атаки шифровальщика или вируса), или когда по домену реплицировалась поврежденная база NTDS.DIT. В этом режиме у всех восстановленных объектов AD значение USN (Update Sequence Number) увеличивается на 100000. Таким образом восстановленные объекты будут восприняты всеми DC как более новые и будут реплицированы по домену. Полномочный способ восстановления нужно использовать очень аккуратно.

Восстановление контроллера домена AD из system state бэкапа

Итак, предположим, что у вас в домене только один DC. По какой-то причине вышел из строя физический сервер, на котором он запущен.

У вас есть относительно свежий бэкап System State старого контроллера домена, и вы хотите восстановить Active Directory на новом сервере в режиме полномочного восстановления.

Чтобы приступить к восстановлению, вам нужно установить на новом сервер туже версию Windows Server, которая была установлена на неисправном DC. В чистой ОС на новом сервере нужно установить роль ADDS (не настраивая ее) и компонент Windows Server Backup.

Для восстановления Actve Directory вам нужно загрузить сервер в режиме восстановления служб каталогов DSRM (Directory Services Restore Mode). Для этого запустите msconfig и на вкладе Boot выберите Safe Boot -> Active Directory repair.

Active Directory repair mode» srcset=»https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode.png 575w, https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode-300×196.png 300w» sizes=»(max-width: 575px) 100vw, 575px» />

Перезагрузите сервер. Он должен загрузиться в режиме DSRM. Запустите Windows Server Backup (wbadmin) и в правом меню выберите Recover.

В мастере восстановления выберите, что резервная копия хранится в другом месте (A backup stored on another location).

Заметем выберите диск, на котором находится резервная копия старого контроллера AD, или укажите UNC путь к ней.

wbadmin get versions -backupTarget:D:

Выберите дату, на которую нужно восстановить резервную копию.

Укажите, что вы восстанавливаете состояние System State.

Выберите для восстановления «Исходное размещение» (Original location) и обязательно установите галочку «Выполнить заслуживающее доверия восстановление файлов Active Directory» (Perform an authoritative restore of Active Directory files).

Система покажет предупреждение, что эта резервная копия другого сервера, и что при восстановлении на другом сервере может не завестись. Продолжаем.

Согласитесь с еще одним предупреждением:


После этого запустится процесс восстановления контроллера домена AD на новом сервере. По завершении сервер потребует перезагрузку (имя нового сервера будет изменено на имя DC из бэкапа).

Загрузите сервер в обычном режиме (отключите загрузку в DSRM режиме)

Авторизуйтесь на сервере под учетной записью с правами администратора домена.

При первом запуске консоли ADUC я получил ошибку:

При этом на сервере нет сетевых папок SYSVOL and NETLOGON. Чтобы исправить ошибку:

  1. Запустите regedit.exe;
  2. Перейдите в ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters
  3. Измените значение параметра SysvolReady с 0 на 1;
  4. Потом перезапустите службу NetLogon: net stop netlogon & net start netlogon

Попробуйте открыть консоль ADUC еще раз. Вы должны увидеть структуру вашего домена.

Итак, вы успешно восстановили свой контроллер домен AD в режиме Authoritative Restore. Теперь все объекты в Active Directory будут автоматически реплицированы на другие контроллеры домена.

Если у вас остался единственный DC, проверьте что он является хозяином всех 5 FSMO ролей и выполните их захват, если нужно.

Восстановление отдельных объектов в AD

Если вам нужно восстановить отдельные объекты в AD, воспользуйтесь корзиной Active Directory. Если время захоронения уже просрочено, или ActiveDirectory RecycleBin не включена, вы можете восстановить отдельные объекты AD в режиме авторитаивного восстановления.

Вкратце процедура выглядит следующим образом:

  1. Загрузите DC в DSRM режиме;
  2. Выведите список доступных резервных копий: wbadmin get versions
  3. Запустите восстановление выбранной резервной копии: wbadmin start systemstaterecovery –version:[your_version]
  4. Подтвердите восстановление DC (в не полномочном режиме);
  5. После перезагрузки запустите: ntdsutil
  6. activate instance ntds
  7. authoritative restore

Укажите полный путь к объекту, который нужно восстановить. Можно восстановить OU целиком:

restore subtree ″OU=Users,DC=winitpro,DC=ru″

Или один объект:

Читать еще:  Контроллер домена 2020 поддержка ос

restore object “cn=Test,OU=Users,DC=winitpro,DC=ru”

Данная команда запретит репликацию указанных объектов (путей) с других контроллеров домена и увеличит USN объекта на 100000.

Выйдите из ntdsutil: quit

Загрузите сервер в обычном режиме и убедитесь, что удаленный объект был восстановлен.

Опыт восстановления контроллера домена Active Directory


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

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

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

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

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

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

В командной строке запустил утилиту 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:windowsNTDS и c:windowsSYSVOL файлы с имеющейся копии. Удалил все файлы *.log в каталоге NTDS:

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

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

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

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

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

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

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

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

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

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

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

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

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

Active Directory: копирование и восстановление

Одним из важных аспектов использования Active Directory является восстановление в случае отказа. Для защиты от отказа стоит всегда иметь надежную резервную копию Состояния системы (System State). Резервное копирование состояния системы позволяет обеспечить сохранение файлов, критических для функционирования системы.

В число этих файлов входят Active Directory, системный реестр и содержимое папки SYSVOL, которая содержит регистрационные сценарии и шаблоны групповых политик. При отказе контроллера домена лучшим способом восстановления является вообще отказ от восстановления.

Всегда, если позволяет пропускная способность сетевого подключения и в домене присутствует второй контроллер домена, старайтесь переустановить операционную систему Windows (или восстановите ее из резервной копии ASR) и повторно запустите утилиту DCPromo для повышения сервера до контроллера домена. При этом будет получена чистая система.

Так как резервная копия Active Directory может создаваться только в составе Состояния системы, при восстановлении Active Directory необходимо восстановить и состояние системы. Если сервер полностью отказал, то восстановление системы на другом аппаратном обеспечении может привести к проблемам.

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

Таким образом, если все остальные попытки исправления проблемы завершились неудачно и в наличии есть действительная резервная копия состояния системы, и необходимо восстанавливать базу данных Active Directory, можно воспользоваться одним из трех типов восстановления.

  • Основной (Primary) — выберите этот вариант, если восстанавливается первый контроллер домена и в домене больше не включено ни одного контроллера домена. При выборе этого варианта восстановление остальных контроллеров домена должно быть неавторитетным (Nonauthoritative).
  • Авторитетный (Authritative) — используется только тогда, когда базу данных Active Directory необходимо привести в состояние, в котором она находилась в момент создания резервной копии. Такое восстановление должно выполняться только при возникновении серьезных ошибок, например, удаление подразделения, или при необходимости выполнить откат всех предыдущих действий. Этот вариант восстановления требует запуска команды ntdsutil после восстановления для выбора объектов, авторитетных для репликации.
  • Неавторитетный (Nonauthoritative) — этот вариант восстановления используется в 99% случаев восстановления базы данных Active Directory. Этот вариант приводит к восстановлению данных, после чего контроллер домена получает обновления от других контроллеров домена в пределах леса (что позволяет восстановить синхронизацию).

При запуске восстановления Active Directory вариант восстановления выбирается в диалоговом окне Дополнительные параметры восстановления (Advanced Restore Options) в приложени Backup. Еще раз подчеркиваю, восстановление должно рассматриваться только как последняя возможность.

Если контроллер домена является единственным сервером DNS и в службе DNS используются зоны, интегрированные в Active Directory, данные зоны DNS окажутся недоступными при загрузке контроллера домена в режиме восстановления службы каталогов.

Если состояние системы восстанавливается по сети с помощью утилиты резервного копирования от третьей фирмы, может потребоваться внесение соответствующих записей в файл Hosts (это позволит предоставить преобразование имен для всех компьютеров, принимающих участие в процессе восстановления).

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector
×
×