Восстановление контроллера домена на другом железе

WinITPro.ru  /  Active Directory  /  Windows Server 2012 R2  /  Windows Server 2016  /  Восстановление 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 как более новые и будут реплицированы по домену. Полномочный способ восстановления нужно использовать очень аккуратно!!!
• Non-authoritative Restore (неполномочное или не-авторитиативное восстановление) – после восстановления базы AD этот контроллер сообщает другим DC, что он восстановлен из резервной копии и ему нужны последние изменения в AD (для DC создается новый DSA Invocation ID). Этот способ восстановления можно использовать на удаленных площадках, когда сложно сразу реплицировать большую базу AD по медленному WAN каналу; или когда на сервере имелись какие-то важные данные или приложения.

Восстановление контроллера домена 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.

Перезагрузите сервер. Он должен загрузиться в режиме DSRM. Запустите Windows Server Backup (wbadmin) и в правом меню выберите Recover.В мастере восстановления выберите, что резервная копия хранится в другом месте (A backup stored on another location).

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

Note: This recovery option will cause replicated content on the local server to re-synchronize after recovery. This may cause potential latency or outage issues.
Загрузите сервер в обычном режиме (отключите загрузку в DSRM режиме)

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

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

Active Directory Domain Services
Naming information cannot be located for the following reason:
The server is not operational.

При этом на сервере нет сетевых папок 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″
• Или один объект:
• restore object “cn=Test,OU=Users,DC=winitpro,DC=ru”
• Данная команда запретит репликацию указанных объектов (путей) с других контроллеров домена и увеличит USN объекта на 100000.
• Выйдите из ntdsutil: quit
• Загрузите сервер в обычном режиме и убедитесь, что удаленный объект был восстановлен.
• Предыдущая статья Следующая статья

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

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

В предыдущей статье из этой серии рассказывалось о процедуре бэкапе физических и виртуальных контроллеров домена (DC). Сегодня поговорим об их восстановлении.

Сразу скажу, что этот пост не является руководством по восстановлению Active Directory. Его задача — рассказать о том, что необходимо учитывать при восстановлении AD или конкретного контроллера домена из резервной копии, а также показать, как можно выполнить эти действия с помощью решений Veeam. Доскональное знание своей инфраструктуры очень помогает при планировании восстановления AD. Вот лишь часть вопросов, ответы на которые вам необходимо знать, чтобы успешно восстанавливать данные:

• Сколько контроллеров домена в вашей среде — один или несколько?
• Это контроллеры домена, доступные для чтения и записи (RWDC) или только для чтения (RODC)?
• Вышел из строя только один контроллер, или повреждена вся инфраструктура AD?
• Если у вас несколько контроллеров, используете ли вы для синхронизации изменений между разными контроллерами домена службу репликации файлов (FRS) или перешли на распределенную DFSR для синхронизации изменений между разными контроллерами домена?

Примечание: Начиная с Windows Server 2008, репликация DFSR стала вариантом настройки по умолчанию для репликации каталога SYSVOL.

Восстановление виртуализованного контроллера домена

Собираясь восстанавливать контроллер домена, необходимо сначала определить, будет ли достаточен режим non-authoritative или потребуется воспользоваться режимом authoritative.

Разница между этими двумя режимами заключается в том, что при режиме восстановлении non-authoritative контроллер домена понимает, что он был в течение некоторого времени отключен.

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

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

В большинстве сценариев восстановления вам потребуется режим non-authoritative, поскольку в среде имеется несколько контроллеров домена. (Кроме того, authoritative восстановление может привести к новым проблемам.)

Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется non-authoritative восстановление, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров.

Чтобы выполнить authoritative восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые будут описаны позже.

Полезно: Еще один распространенный вариант действий при отказе контроллера домена — распределить его роли между другими контроллерами и очистить метаданные, если восстановление маловероятно. В этом случае вы поручаете другим DC выполнять функции отказавшего, и вам не нужно его восстанавливать.

Восстановление в режиме «non-authoritative»

Итак, вернемся к файлам резервных копий, создание которых было описано в предыдущей статье. Для того, чтобы восстановить контроллер домена из резервной копии Veeam Backup & Replication, нужно:

1. Запустить мастер восстановления в консоли Veeam Backup.
2. Найти нужный контроллер домена.
3. Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM).
4. Указать точку восстановления.
5. Выбрать исходное или новое место восстановления.
6. Завершить процедуру.

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

1. Восстановление файлов и дисков ВМ.
2. Загрузка ОС в специальном режиме восстановления доменных сервисов (DSRM mode).
3. Применение настроек.
4. Перезапуск в обычном режиме.

Контроллер домена будет знать о восстановлении из резервной копии и предпримет соответствующие действия: существующая база данных будет объявлена недействительной, и партнеры репликации смогут обновить ее, внеся наиболее свежую информацию.

Восстановление в режиме «authoritative»

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

Этот режим можно использовать, например, когда вы пытаетесь восстановить верную копию контроллера домена в среде с несколькими контроллерами домена, при том, что вся структура AD по какой-то причине повреждена (напр., вредоносное ПО, вирус и т. п.).

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

Примечание: Выполняемые действия сходны с тем, что происходит при использовании Veeam SureBackup для восстановления контроллера домена в изолированной среде.

Чтобы выполнить восстановление удаленного объекта или контейнера в режиме authoritative и принудить контроллер домена скопировать восстановленные данные с этого DC на другие контроллеры:

1. Выберите в Veeam операцию восстановления ВМ полностью: программа автоматически выполнит стандартное восстановление DC в режиме «non-authoritative» (см. выше).
2. При втором перезапуске DC откройте мастер загрузки (нажмите F8), выберите пункт DSRM и войдите в систему с данными учетной записи DSRM (та учетная запись, которую вы указали, когда назначали данный компьютер контроллером домена).
3. Откройте командную строку и запустите утилиту ntdsutil
4. Используйте следующие команды:
   • activate instance ntds;
   • затем authoritative restore;
   • затем restore object “distinguishedName” или restore subtree “distinguishedName” Пример: restore subtree “OU=Branch,DC=dc,DC=lab, DC=local
5. Подтвердите authoritative восстановление и перезапустите сервер после завершения операции.

Процедура authoritative восстановления SYSVOL (при использовании службы DFSR) осуществляется следующим образом:

1. Выполните non-authoritative восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
2. При второй загрузке перейдите в ветку реестра HKLMSystemCurrentControlSetServicesDFSR, создайте ключ Restore, а затем создайте строку SYSVOL со значением authoritative. Это значение будет считано службой DFSR. Если значение не установлено, по умолчанию производится восстановление SYSVOL в режиме non-authoritative.
3. Перейдите к HKLMSystemCurrentControlSetControlBackupRestore, создайте ключ SystemStateRestore, затем создайте строку LastRestoreId с любым значением GUID, например, 10000000-0000-0000-0000-000000000000.
4. Перезапустите службу DFSR.

Процедура authoritative восстановления SYSVOL (при использовании службы FRS):

1. Выполните non-authoritative восстановление контроллера домена (например, восстановление ВМ целиком в Veeam Backup & Replication).
2. При второй загрузке перейдите в ветку реестра HKLMSystemCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup и измените значение ключа Burflag на 000000D4 (hex) или 212 (dec).

   Это обеспечит принудительное копирование данных на контроллеры домена, использующие старую технологию FRS, в «authoritative» режиме. Подробнее о восстановлении FRS можно почитать здесь.

3. Перезапустите службу NTFRS.

Восстановление физического контроллера домена с Veeam Endpoint Backup

Теперь немного о восстановлении физической машины из резервной копии с помощью Veeam Endpoint Backup. Вам потребуется:

1. Заранее подготовленный аварийный загрузочный диск Veeam.
2. Доступ к самой резервной копии (на USB-носителе или сетевом диске).

Важно! Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет.

После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления.

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

Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup более подробно.

Итак, мы рассмотрели восстановление отдельного контроллера домена. Однако чаще всего при работе с AD требуется восстановить случайно удаленный объект, и в этом случае восстанавливать контроллер целиком — не самый эффективный вариант. Поэтому в следующей статье я расскажу о восстановлении отдельных объектов каталога AD с помощью собственных инструментов Microsoft и утилиты Veeam Explorer для Active Directory.

Полезные ссылки:

sysrtfm

Привет, сегодня, с разрешения своего коллеги, Андрея Федюнина, поделюсь его опытом: «Как восстановить AD из System State на другом железе«. Данный эксперимент проводился лично им и включает опыт многих. Было потрачено много времени на чтение технической информации, так что спасибо тебе!

Ниже приведен полный текст автора без изменений, и рассчитан он на опытного системного администратора, картинок не будет, так как и так все достаточно подробно описано. Поехали!

Восстановление Active Directory из System State

Рассматривается случай полного выхода из строя сервера и разворачивание System State на новом железе.

• Устанавливается Windows той же версии которая стояла на исходной машине;
• Устанавливаем все необходимые драйвера;
• Установить тот же SP и версию IE (критична разница между IE6 и IE7);
• Настраивается IP адрес, меняется название компьютера как на вышедшей из строя;
• Поднимаются роли, которые были на исходном сервере (для работы AD необходимо поднять AD и DNS, настройки не важны, за исключением названия домена);
• Перезагружаемся и заходим в режим восстановления AD;
• Заходим в редактирование реестра (regedit) и экспортируем как кусты (!важно) следующие ветки реестра:
  HKLMSystemCurrentControlSetControlClass; HKLMSystemCurrentControlSetControlCriticalDeviceDatabase
• Запускаем ntbackup и восстанавливаем System State без замены файлов;
• Загружаемся с LiveCD (лучше использовать WinPE чем ERD Commander в связи с ограниченностью редактора реестра последнего);
• Подгружаем ветку реестра System и импортируем сохраненные ранее кусты на прежнее место (!важно: при импорте куста необходимо выделить ветку в которую необходимо произвести импорт, при импорте все предыдущее содержимое удаляется);
• Перезагружаемся и загружаемся в безопасном режиме с поддержкой сети.Устанавливаем необходимые драйвера, удаляем те службы, которые больше никогда использоваться не будут на новом сервере. Запускаем regedit, идем в
  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices
  и делаем резервную копию этой ветки реестра на всякий случай.Далее, сопоставляя службы, которые должны запускаться автоматически, но не запускаются, со списком из реестра и удаляем их;
• Снова настраиваем IP адрес;
• Скорее всего потребуется активировать windows, поэтому либо активируем повторно или используем killWPA;
• Загружаемся в обычном режиме.

Далее необходимо действовать в зависимости от ситуации

1 — Единственный контроллер домена:

• Проверить журнал событий на наличие ошибок в DNS и Directory Service;

• Проверить сетевые шары Sysvol и Netlogon, если таковых не имеется то зайти в управление компьютером, остановить службу репликации файлов, зайти в папку
  SysvolDomainNtfrs_PreExisting__See_Event_Log
  вырезать содержимое на уровень выше, запустить редактор реестра, найти ключ BurFlagsраздела
  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup
  и установить значение D4, запустить службу заново (Более подробное описание находится на сайте Microsoft http://support.microsoft.com/kb/316790). Сетевые папки должны создаться, проверить можно командой
  net share

• Если dcdiag выдает ошибки, выполнить команду
  dcdiag /fix

После чего желательно перезагрузиться и проверить журнал событий заново.

2 — В домене несколько контроллеров домена:

• Проверить журнал событий на наличие ошибок в DNS и Directory Service;

• Проверить сетевые шары Sysvol и Netlogon, если таковых не имеется то зайти в управление компьютером, остановить службу репликации файлов, зайти в папку
  SysvolDomainNtfrs_PreExisting__See_Event_Log
  вырезать содержимое на уровень выше, запустить редактор реестра, найти ключ BurFlagsраздела
  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup
  и установить значение D4, запустить службу заново (Более подробное описание находится на сайте Microsoft http://support.microsoft.com/kb/316790). Сетевые папки должны создаться, проверить можно командой
  net share

• Если dcdiag выдает ошибки, выполнить команду
  dcdiag /fix

• Открыть оснастку AD Sites & Services, открыть NTDS Settings каждого из контроллеров и запустить репликацию вручную. Если восстановленный бекап делался незадолго до сбоя, то велика вероятность что репликация пройдет без ошибок, в противном случае возникнет ошибка «Главное конечное имя неверно«. В этом случае необходимо сделать следующее (http://support.microsoft.com/kb/288167):
  • Определить контроллер домена, являющийся хозяином операций для эмулятора основного контроллера домена (PDC).Установите программу Netdom.exe из набора Windows Support Toolsи выполните следующую команду:
    netdom query fsmo
  • На контроллерах домена, подверженных данной проблеме, отключите службу «Центр распространения ключей Kerberos» (KDC), выбрав в «Тип запуска» значение Отключено и перезагрузите компьютер;
  • Воспользуйтесь программой Netdom для сброса безопасных каналов между данным контроллером домена и хозяином операций для эмулятора PDC. Для этого выполните следующую команду на контроллере домена, не являющемся хозяином операций для эмулятора PDC:
    netdom resetpwd /server:имя_сервера /userd:имя_доменаadministrator /passwordd:пароль_администратора
    Где имя_сервера — имя сервера, являющегося хозяином операций для эмулятора PDC;
  • После сброса безопасного канала перезагрузите компьютер. Даже если попытка сброса удаления безопасного канала с помощью программы Netdom окончилась неудачно, компьютер необходимо перезагрузить, перед этим вернув тип запуска службы «Центр распространения ключей Kerberos» на Авто;

• Провести повторную репликацию, в случае использования старого System State могут появиться устаревшие объекты, что приведет к ошибке «Недостаточно атрибутов для создания объекта» для ее устранения необходимо (http://support.microsoft.com/kb/2028495/en-us):
  • Зайти на КД на котором встречается ошибка 1988 в событиях Directory Service и отфильтровать по ней все записи;
  • Поочередно просматривать данные события и записывать в табличку все уникальные Объекты (Исходный домен, Объект, Guid объекта);
  • Выполните команду repadmin. Синтаксис команды:
    repadmin /removelingeringobjects /advisory_mode
    В качестве параметров команды введите следующие значения. Имя_целевого_КД — имя узла контроллера домена, который предполагается использовать для удаления устаревших объектов. В журнале событий он указан как исходный DC и указано его полное доменное имя GUID_исходного_КД— выполните команду
    repadmin /showrepl имя_заслуживающего_доверие_КД
    где имя_заслуживающего_доверие_КД — имя узла контроллера домена, который выбирается в качестве заслуживающего доверие, т.е. на котором находятся актуальные данные. Введите первый отображаемый GUID объекта DSA в качестве параметра . Раздел_LDAP — имя целевого раздела протокола LDAP. Взять из событий с кодом 1988. Пример команды:
    repadmin /removelingeringobjects ncfs.domain.local d0c1b7e6-fdbd-4d35-9319-ce169990aa94 dc=domain,dc=local /advisory_mode

После удаления всех устаревших объектов репликация должна пройти успешно.

Полезные KB: http://support.microsoft.com/kb/216498, http://support.microsoft.com/kb/312862, http://support.microsoft.com/kb/305476, http://support.microsoft.com/kb/315457

Все готово! Сисадмины делятся на тех, кто не делает бэкапы и тех кто уже делает! © народная мудрость…

Восстановление леса AD — выполнение начального восстановления

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 и 2012 R2, Windows Server 2008 и 2008 R2

Начиная с записываемого контроллера домена в корневом домене леса выполните действия, описанные в этом разделе, чтобы восстановить первый контроллер домена. Корневой домен леса важен, так как он хранит группы администраторов схемы и администраторов предприятия. Она также помогает поддерживать иерархию доверия в лесу.

Кроме того, корневой домен леса обычно содержит корневой DNS-сервер для пространства имен DNS леса.

Следовательно, зона DNS, интегрированная с Active Directory для этого домена, содержит записи ресурсов псевдонима (CNAME) для всех остальных контроллеров домена в лесу (которые необходимы для репликации) и записи ресурсов DNS глобального каталога.

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

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

Затем выполните следующие действия. Процедуры для выполнения определенных действий находятся в процедуре восстановления леса AD.

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

2. Так как это первый записываемый контроллер домена в домене, необходимо выполнить неавторитическое восстановление AD DS и заслуживающее доверия восстановление SYSVOL.

   Операция восстановления должна быть завершена с помощью приложения резервного копирования и восстановления с поддержкой Active Directory, например windows Server Backup (т. е.

   восстановление контроллера домена с помощью неподдерживаемых методов, таких как восстановление моментального снимка виртуальной машины).

   • Требуется заслуживающее доверия восстановление SYSVOL, так как репликация реплицированной папки SYSVOL должна быть запущена после восстановления после аварии. Все последующие контроллеры домена, добавленные в домен, должны повторно синхронизировать свою папку SYSVOL с копией выбранной папки, чтобы быть заслуживающей доверия до объявления папки.

   Внимание!

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

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

   • Если восстановленный контроллер домена размещает роль хозяина операций, может потребоваться добавить следующую запись реестра, чтобы избежать недоступности доменных служб Active Directory до завершения репликации секции каталога с возможностью записи:
     HKLMSystemCurrentControlSetServicesNTDSParametersRepl выполняет начальную синхронизацию
     Создайте запись с типом данных REG_DWORD и значением 0. После полного восстановления леса можно сбросить значение этой записи до 1. Для этого требуется контроллер домена, который перезапускает и удерживает роли главного сервера операций для успешной входящей и исходящей репликации AD DS с известными партнерами-репликами, прежде чем объявлять себя как контроллер домена и начинает предоставлять службы клиентам. Дополнительные сведения о требованиях к начальной синхронизации см. в статье о том, как выполняется синхронизация в доменных службах Azure AD.
     Перейдите к следующим шагам только после восстановления и проверки данных и перед присоединением этого компьютера к рабочей сети.

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

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

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

   В рамках процесса после восстановления вы можете повторно распространить роли хозяина операций по мере необходимости. Дополнительные сведения об виртуализации ролей хозяина операций см. в разделе «Захват роли главного сервера операций». Рекомендации по расположению ролей главного сервера операций см.

   в разделе «Что такое мастеры операций?».

6. Очистите метаданные всех остальных записываемых контроллеров домена в корневом домене леса, которые не восстанавливаются из резервной копии (все записываемые контроллеры домена в домене, кроме первого контроллера домена).

   При использовании версии пользователей и компьютеров Active Directory или сайтов и служб Active Directory, входящих в состав Windows Server 2008 или более поздней версии или RSAT для Windows Vista или более поздней версии, очистка метаданных выполняется автоматически при удалении объекта контроллера домена.

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

   Очистка метаданных предотвращает возможное дублирование объектов параметров NTDS, если AD DS установлен на контроллере домена на другом сайте.

   Возможно, это также может сохранить средство проверки согласованности знаний (KCC) процесс создания ссылок репликации, когда сами контроллеры домена могут не присутствовать.

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

   До тех пор, пока метаданные всех остальных контроллеров домена в домене не будут удалены, этот контроллер домена, если он был главным контроллером RID перед восстановлением, не будет принимать роль главного контроллера RID и, следовательно, не сможет выдавать новые идентификаторы RID. В системном журнале в средстве просмотра событий может появиться идентификатор события 16650, указывающий на этот сбой, но после очистки метаданных должен появиться идентификатор события 16648, указывающий на успешное выполнение.

7. Если у вас есть зоны DNS, хранящиеся в AD DS, убедитесь, что служба локального DNS-сервера установлена и запущена на восстановленном контроллере домена. Если этот контроллер домена не был DNS-сервером до сбоя леса, необходимо установить и настроить DNS-сервер.

   Примечание

   Если восстановленный контроллер домена работает под управлением Windows Server 2008, необходимо установить исправление в статье базы знаний 975654 или временно подключить сервер к изолированной сети, чтобы установить DNS-сервер. Исправление не требуется для других версий Windows Server.

   В корневом домене леса настройте восстановленный контроллер домена с собственным IP-адресом (или адресом замыкания на себя, например 127.0.0.1) в качестве предпочтительного DNS-сервера. Этот параметр можно настроить в свойствах TCP/IP адаптера локальной сети (LAN). Это первый DNS-сервер в лесу. Дополнительные сведения см. в разделе «Настройка TCP/IP для использования DNS».

   В каждом дочернем домене настройте восстановленный контроллер домена с IP-адресом первого DNS-сервера в корневом домене леса в качестве предпочтительного DNS-сервера. Этот параметр можно настроить в свойствах TCP/IP адаптера локальной сети. Дополнительные сведения см. в разделе «Настройка TCP/IP для использования DNS».

   В зонах DNS _msdcs и домена удалите записи NS контроллеров домена, которые больше не существуют после очистки метаданных. Проверьте, удалены ли записи SRV удаленных контроллеров домена. Чтобы ускорить удаление записей DNS SRV, выполните следующую команду:

   nltest.exe /dsderegdns:server.domain.tld

8. Повышение значения доступного пула RID на 100 000. Дополнительные сведения см. в разделе «Повышение значения доступных пулов RID».

   Если у вас есть основания полагать, что повышение пула RID на 100 000 недостаточно для конкретной ситуации, следует определить наименьшее увеличение, которое по-прежнему безопасно использовать.

   Идентификаторы идентификаторов — это конечный ресурс, который не следует использовать без необходимости.

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

   Эти субъекты безопасности больше не существуют после восстановления, так как восстановление вернулось к резервной копии; однако их права доступа могут по-прежнему существовать.

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

   Чтобы проиллюстрировать, рассмотрим пример нового сотрудника с именем Эми, который был упомянут в вводной статье. Объект пользователя для Amy больше не существует после операции восстановления, так как он был создан после резервной копии, которая использовалась для восстановления домена.

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

9. Отмените текущий пул RID. Текущий пул RID становится недействительным после восстановления состояния системы.

   Но если восстановление состояния системы не было выполнено, текущий пул RID должен быть недействительным, чтобы предотвратить повторное выдачу идентификаторов riD восстановленного контроллера домена из пула RID, который был назначен во время создания резервной копии. Дополнительные сведения см. в разделе «Недействительный текущий пул RID».

   Примечание

   При первой попытке создать объект с идентификатором безопасности после отмены пула RID вы получите сообщение об ошибке. Попытка создать объект активирует запрос для нового пула RID. Повторная попытка операции завершается успешно, так как будет выделен новый пул RID.

10. Сбросьте пароль учетной записи компьютера этого контроллера домена дважды. Дополнительные сведения см. в разделе Сброс пароля учетной записи компьютера контроллера домена.

11. Сбросьте пароль krbtgt дважды. Дополнительные сведения см. в разделе «Сброс пароля krbtgt».

    Так как журнал паролей krbtgt является двумя паролями, сбросьте пароли дважды, чтобы удалить исходный (предварительно подготовленный) пароль из журнала паролей.

12. Если лес содержит несколько доменов, а восстановленный контроллер домена был сервером глобального каталога до сбоя, снимите флажок глобального каталога в свойствах параметров NTDS, чтобы удалить глобальный каталог из контроллера домена. Исключением из этого правила является распространенный случай леса с одним доменом. В этом случае удаление глобального каталога не требуется. Дополнительные сведения см. в разделе «Удаление глобального каталога».

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

    В домене A dc1 восстанавливается из резервной копии, которая была сделана во время T1. В домене B dc2 восстанавливается из резервной копии глобального каталога, которая была создана во время T2.

    Предположим, T2 является более поздним, чем T1, и некоторые объекты были созданы между T1 и T2. После восстановления этих контроллеров домена DC2, который является глобальным каталогом, содержит новые данные для частичной реплики домена A, чем домен A, удерживает себя.

    В этом случае DC2 содержит задерживающиеся объекты, так как эти объекты отсутствуют в DC1.

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

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

    Оба объекта имеют один и тот же адрес электронной почты; поэтому сообщения электронной почты не могут быть доставлены.

    Вторая проблема заключается в том, что учетная запись пользователя, которая больше не существует, может по-прежнему отображаться в глобальном списке адресов. Третья проблема заключается в том, что универсальная группа, которая больше не существует, может по-прежнему отображаться в маркере доступа пользователя.

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

13. Настройка службы времени Windows. В корневом домене леса настройте эмулятор PDC для синхронизации времени из внешнего источника времени. Дополнительные сведения см. в разделе «Настройка службы времени Windows» в эмуляторе PDC в корневом домене леса.

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

После проверки присоединитесь к рабочей сети контроллеров домена и выполните действия по проверке работоспособности репликации леса.

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

Примечание

Контроллер домена не будет объявлен как сервер глобального каталога, пока он не завершит полную синхронизацию всех секций каталогов в лесу. Таким образом, контроллер домена должен быть вынужден реплицироваться с каждым из восстановленных контроллеров домена в лесу.

Отслеживайте журнал событий службы каталогов в средстве просмотра событий для события с идентификатором 1119, который указывает, что этот контроллер домена является сервером глобального каталога, или убедитесь, что следующий раздел реестра имеет значение 1:

HKLMSystemCurrentControlSetServicesNTDSParametersGlobal Catalog Promotion Complete

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