Helpdesk

Данные Exchange, хранящиеся в службе Active Directory

База данных Active Directory хранит информацию в логических разделах трех типов, описанных далее:

• Раздел схемы

• Раздел конфигурации

• Раздел домена

Раздел схемы

Раздел схемы используется для хранения двух типов сведений:

• Классы схемы определяют все типы объектов, которые могут создаваться и храниться в Active Directory.

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

Когда вы установите первый сервер Exchange Server в лесу (или запустите процесс подготовки Active Directory), процесс подготовки Active Directory добавит множество классов и атрибутов в схему Active Directory. Добавляемые в схему классы используются для создания объектов Exchange (таких как агенты и соединители). Такие атрибуты используются для настройки объектов Exchange, а также поддерживающих почту пользователей и групп. Эти атрибуты включают такие свойства, как параметры Outlook в Интернете (прежнее название — Outlook Web App).

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

Дополнительные сведения об изменении схемы в Exchange см. в статье Изменения схемы Active Directory в Exchange Server.

Раздел конфигурации

Раздел конфигурации используется для хранения сведений о конфигурации в масштабах леса. Эти сведения о конфигурации включают конфигурацию сайтов Active Directory, глобальные параметры Exchange, параметры транспорта, политики почтовых ящиков и абонентские группы единой системы обмена сообщениями. Каждый тип сведений о конфигурации хранится в контейнере раздела конфигурации. Сведения о конфигурации Exchange хранятся в подпапке внутри контейнера «Службы» раздела конфигурации. В этом контейнере хранятся перечисленные ниже типы сведений.

• Списки адресов

• Политики почтовых ящиков адресной книги

• Административные группы

• Параметры клиентского доступа

• Подключения

• Параметры мобильного почтового ящика

• Глобальные параметры

• Параметры мониторинга

• Системные политики

• Контейнер политик хранения

• Параметры транспорта

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

Раздел домена

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

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

Восстановление объектов AD с помощью утилиты LDP

LDP (LDP.exe) — старая и надежная программа, созданная разработчиками Active Directory. Выглядит она довольно просто, но у нее много возможностей, которые позволяют полностью управлять объектами Active Directory. Недостаток ее в том, что на освоение функционала программы нужно потратить довольно много времени, а интерфейс не слишком современен и понятен.

Чтобы восстановить «tombstone» объект с помощью LDP, необходимо сделать следующее:

• Запустите программу (Пуск – Выполнить – ldp)
• Подключите ее к контроллеру домена (Connection – Connect..)
• Используйте для подключения данные соответствующей учетной записи (администратора предприятия или домена). (Connection – Bind..)
• Найдите нужный объект (Browse – Search) в контейнере удаленных объектов. Вам потребуется научиться использовать различные настройки поиска и фильтра (см. рис. ). В диалоговом окне «Controls» (элементы управления) выберите вариант «return deleted objects» (Выводить удаленные объекты) и нажмите кнопку «check in» (добавить), чтобы добавить идентификатор объекта для этого варианта в список Active Control (активные элементы управления). Затем сохраните настройки и выполните запрос, чтобы найти удаленный объект
• Восстановите «tombstone» объект, используя мастер (Browse – Modify), чтобы найти объект по параметру distinguishedName (DN) и удалить значение isDeleted с одновременным переименованием объекта. В результате объект будет восстановлен, и его можно будет увидеть через инструмент просмотра пользователей и компьютеров Active Directory.

На рисунке ниже показан типовой пример поиска, который я выполнил, чтобы найти tombstone-объекты в моем тестовом домене:

Рис. 2. Поиск «tombstone» объектов с помощью программы LDP.

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

В дополнение к сказанному выше, следует помнить некоторые особенности такого восстановления tombstone-объектов. Так, некоторые атрибуты (например, членство в группах), удаленные при первоначальном удалении, не будут восстановлены, что потенциально может создать вам проблемы.

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

Итак, почему же так важно понимать, как функционируют старые системы? Потому что современная логика и привычная функциональность в этих случаях неприменимы. До появления Windows Server 2008 R2 жизненный цикл объектов Active Directory выглядел следующим образом:

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

Удаление объекта Active Directory не приводит к его физическому удалению. Как вы, возможно, знаете, Active Directory скрывает удаленный объект, меняя значение атрибута isDeleted на TRUE. Затем большинство атрибутов объекта сбрасывается, а сам объект переименовывается и перемещается в специальный контейнер (CN=Deleted Objects). С этого момента объект получает статус «tombstone», и стандартные средства Active Directory не знают о его существовании. В этом специальном состоянии объект находится в течение установленного периода (60 дней в Windows Server 2000/2003 и 180 дней в Windows 2003 SP1/2008). Это делается, чтобы гарантировать успешное выполнение репликации данных в системе. По окончании отведенного времени существования в состоянии «tombstone» осуществляется вызов специального процесса (так называемый сборщик мусора), который физически удаляет объект из базы данных.

И вот здесь возникает вопрос: если «tombstone» объект не удаляется физически в течение некоторого времени, нельзя ли его восстановить? Коротко говоря — можно. Хотя такой механизм удаления объектов не был предназначен для использования в качестве временной корзины, а удаленные объекты не предполагалось восстанавливать, технически это возможно. Далее я расскажу, как это можно сделать.

Использование Veeam Explorer для Microsoft Active Directory

В качестве альтернативного способа можно использовать решения Veeam, в частности, Veeam Explorer для Active Directory. Эта программа позволит вам выполнять восстановление гораздо проще и быстрее. При этом она решает многие проблемы восстановления tombstone-объектов — например, потерю пароля учетной записи и многих важных атрибутов, таких как имя и фамилия пользователя. Однако такой вариант восстановления годится не для всех сценариев — сначала надо провести предварительную подготовку. А именно: для использования Veeam Explorer для Active Directory у вас должна быть резервная копия контроллера домена, где был удален объект. На сегодня мы рассматриваем виртуализованный контроллер, чья резервная копия была создана с помощью Veeam Backup & Replication.

Итак, если вам посчастливилось быть администратором виртуального контроллера домена с функциональным режимом работы леса доменов Windows Server 2003 или Windows Server 2008, можно использовать следующую процедуру:

Убедитесь, что у вас есть резервная копия контроллера домена и что при ее создании была включена обработка данных с учетом состояния приложений (о том, почему это важно, говорилось в первой статье серии) – то есть у задания бэкапа была выбрана опция Guest Processing > Enable application-aware processing.

1. Если вам нужно восстановить удаленный объект, перейдите к резервной копии контроллера домена, кликните правой кнопкой и выберите Restore application items > Microsoft Active Directory objects… (объекты Microsoft Active Directory), чтобы начать восстановление и запустить Veeam Explorer для Active Directory.

1. Найдите нужный контейнер и включите опции Compare all objects (сравнить все объекты) и Show changed objects only (показывать только измененные объекты). Таким образом вы настроите предварительную фильтрацию: Veeam Explorer сравнит данные в резервной копии с текущим состоянием DC и отобразит только измененные объекты. Просмотрите состояние объектов и найдите те, у которых оно обозначено как Tombstone.

1. Нужный объект (объекты) можно восстановить в рабочую среду или экспортировать как файл .lde.

1. При восстановлении учетной записи пользователя на одном из шагов мастера вам будет предложено указать параметры восстановления пароля (Specify password restore options). Вы можете выбрать один из следующих вариантов:

• восстановить учетную запись со старым паролем (Restore password)
• задать новый пароль вручную (Set password to)
• выполнить восстановление без пароля (Do not restore password)

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

С учетом сказанного выше, понятно, что Veeam Explorer для Microsoft Active Directory предлагает относительно простой способ восстановления tombstone-объектов Active Directory

Если вы работаете в подходящей системе, рекомендую обратить внимание на этот продукт

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

Восстановление удаленных объектов в Active Directory Печать

Изменено: Чт, 14 Апр, 2016 at 12:06 AM

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

В качестве примера возьмем учетную запись пользователя Ivanov Vasiliy и удалим ее. Прощай Vasiliy

Для восстановления воспользуемся утилитой LDP. LDP — это служебная программа для работы с Active Directory, немного схожая с проводником Windows. В Windows Server 2008 она включена в состав операционной системы, в Server 2003 входит в средства поддержки (Support tools) и устанавливается отдельно, с установочного диска.
Для запуска LDP нажимаем Win+R и в строке выполнить вводим ldp. Затем идем в меню Connection, выбираем пункт Connect и в открывшемся окне вводим имя контроллера домена, к которому надо подключиться. Если вы запускаете LDP на контроллере домена, то можно просто ввести localhost.

Теперь необходимо пройти проверку подлинности. Открываем меню Connection, выбираем Bind (Привязка), вводим учетные данные и жмем OK. Для работы нам понадобятся учетные данные пользователя с правами администратора домена или предприятия (только они имеют право просматривать и восстанавливать объекты в контейнере Deleted Objects).

Контейнер Deleted objects надежно скрыт от посторонних глаз, и для того, чтобы его увидеть, необходимо включить элемент управления LDAP «Возврат удаленных объектов». Для этого открываем меню Options и выбираем пункт Controls, чтобы вывести диалог элементов управления. Открываем список Load Predefined, в нем выбираем пункт Return Deleted Objects (Вернуть удаленные объекты) и нажимаем кнопку Check in. Это добавит идентификатор объекта (OID) для элемента управления «Вернуть удаленные объекты» (1.2.840.113556.1.4.417) в список активных элементов управления. Нажимаем OK, чтобы сохранить настройки элемента управления.

Затем открываем меню View, выбираем режим просмотра Tree, в поле BaseDN выбираем DC=contoso,DC=com.

Заходим в корень, раскрываем контейнер Deleted Objects и видим перечень удалённых объектов. В этом перечне находим нужный нам объект-пользователя CN=Ivanov Vasily. Кликаем правой клавишей мыши на найденом объекте и в выпадающем меню выбираем пункт Modify. Кстати, будьте готовы к тому, что в Deleted Objects очень много объектов, что может затруднить поиск.

Для восстановления объекта надо провести две операции:
1) Удалить отметку об удалении — набираем в строке Attribute: isDeleted, в поле Operation выбираем Delete и нажимаем Enter;
2) Переместить из Deleted objects в исходный контейнер — набираем в поле Attribute: distinguishedName, в поле Values пишем: CN=Ivanov Vasily, OU=Managers, DC=contoso, DC=com (это исходный DN пользователя). Исходный контейнер пользователя можно посмотреть в правом окне, он записан в атрибуте lastKnownParent. В качестве операции выбираем Replace и опять нажимаем Enter.
Далее отмечаем оба пункта Synchronous и Extended и жмём кнопку Run.

Всё! Теперь объект пользователя полностью восстановлен, в чем можно убедиться, открыв консоль Active Directory Users and Computers.

Была ли эта статья полезной?
Да
Нет

Отправить отзыв К сожалению, мы не смогли помочь вам в разрешении проблемы. Ваш отзыв позволит нам улучшить эту статью.

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

1. запустите программа установки Windows, укажите формат языка, времени и валюты, а также параметры клавиатуры и нажмите кнопку далее.
2. Нажмите Восстановить компьютер.
3. щелкните устранение неполадок, выберите восстановление образа системы и щелкните Windows Server 2016.
4. При восстановлении последней локальной резервной копии щелкните выбрать образ системы и нажмите кнопку Далее.
5. Теперь можно выбрать расположение резервной копии, которую необходимо восстановить. Если образ является локальным, его можно выбрать из списка.
6. Если образ находится в общей сетевой папке, выберите Дополнительно. Если необходимо установить драйвер, можно также выбрать Дополнительно .
7. При восстановлении из сети после нажатия кнопки Дополнительно выберите Поиск образа системы в сети. Возможно, вам будет предложено восстановить сетевое подключение. Нажмите кнопку ОК.
8. Введите UNC-путь к расположению общей папки резервных копий (например, \ \server1\backups) и нажмите кнопку ОК. Также можно ввести IP-адрес целевого сервера, например \ \192.168.1.3\backups..
9. Введите учетные данные, необходимые для доступа к общей папке, и нажмите кнопку ОК.
10. Теперь выберите дату и время образа системы для восстановления и нажмите кнопку Далее.
11. Теперь у вас будет возможность:
    • Форматирование и повторное разбиение дисков
    • Установка драйверов
    • Отмените выбор дополнительных функций автоматического перезапуска и проверки на наличие ошибок диска. Эти типы включены по умолчанию.
12. Щелкните Далее.
13. Нажмите кнопку Готово. Вам будет предложено подтвердить, что вы действительно хотите продолжить. Нажмите кнопку Да.
14. После этого выполните полномочное восстановление SYSVOL, как описано в статье восстановление леса Active Directory. выполнение полномочной синхронизации SYSVOL, реплицированнойс помощью DFSR.

Next Steps

• Восстановление леса AD — необходимые условия
• Восстановление леса AD — Девисинг план восстановления пользовательского леса
• Восстановление леса AD. обнаружение проблемы
• Восстановление леса AD. Определение способа восстановления
• Восстановление леса AD — выполнение начального восстановления
• Восстановление леса AD — процедуры
• Восстановление леса AD — часто задаваемые вопросы
• Восстановление леса Active Directory. Восстановление одного домена в лесу с несколькими доменами
• восстановление леса active directory — восстановление леса с контроллерами домена Windows Server 2003

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

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

Примечание

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

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

• Чтобы устранить разрешение имен, создайте записи делегирования DNS и настройте пересылку DNS и корневые ссылки по мере необходимости. Выполните команду repadmin/реплсум , чтобы проверить репликацию между контроллерами домена.
• Если восстановленные контроллеры домена не являются прямыми партнерами по репликации, восстановление репликации будет выполняться гораздо быстрее, создавая временные объекты соединения между ними.
• Чтобы проверить очистку метаданных, выполните команду repadmin \ /виевлист _ для списка всех контроллеров домена в лесу. Выполните команду _ nltest/дклист: * <> domain , чтобы получить список всех контроллеров домена в домене.
• Чтобы проверить работоспособность контроллера домена и DNS, запустите DCDiag/v, чтобы сообщить об ошибках на всех контроллерах домена в лесу.

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

Чтобы WSB увидел бэкап на диске, нужно поместить каталог WindowsImageBackup с резервной копией в корень диска. Можете проверить наличие резервных копий на диске с помощью команды:

Выберите дату, на которую нужно восстановить резервную копию.
Укажите, что вы восстанавливаете состояние System State.
Выберите для восстановления «Исходное размещение» (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.

После этого запустится процесс восстановления контроллера домена AD на новом сервере. По завершении сервер потребует перезагрузку (имя нового сервера будет изменено на имя DC из бэкапа).
Загрузите сервер в обычном режиме (отключите загрузку в 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_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Измените значение параметра SysvolReady с 0 на 1;
4. Потом перезапустите службу NetLogon: 

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

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

Восстановление объектов Active Directory с помощью утилиты LDP

LDP (LDP.exe) —проверенная временем программа, созданная разработчиками Active Directory. Выглядит она довольно просто, но у нее много возможностей, которые позволяют полностью управлять объектами Active Directory. Недостаток ее в том, что на освоение функционала программы нужно потратить довольно много времени, а интерфейс не слишком современен и понятен.Примечание: Эта статья не является полноценным руководством по программе LDP. Чтобы научиться работе с программой, рекомендую воспользоваться руководством по LDP.

Итак, чтобы восстановить «tombstone» объект с помощью LDP, необходимо сделать следующее:

1. Запустите программу (Start — Run — ldp)
2. Подключите ее к контроллеру домена (Connection – Connect..). Используйте для подключения данные соответствующей учетной записи (администратора предприятия или домена). (Connection – Bind..)
3. Найдите нужный объект в контейнере удаленных объектов. Вам потребуется научиться использовать различные настройки поиска и фильтра (Browse – Search).
4. В диалоговом окне «Controls» (элементы управления) выберите вариант «return deleted objects» (выводить удаленные объекты) и нажмите кнопку «check in» (добавить), чтобы добавить идентификатор объекта для этого варианта в список Active Control (активные элементы управления).
5. Затем сохраните настройки и выполните запрос, чтобы найти удаленный объект.
6. Восстановите «tombstone» объект, используя мастер (Browse – Modify), чтобы найти объект по параметру distinguishedName (DN) и удалить значение isDeleted с одновременным переименованием объекта.
7. В результате объект будет восстановлен, и его можно будет увидеть через инструмент просмотра пользователей и компьютеров Active Directory.

На рисунке ниже показан типовой пример поиска, который я выполнил, чтобы найти tombstone-объекты в моем тестовом домене:

В дополнение к сказанному выше следует помнить некоторые особенности такого восстановления tombstone-объектов. Так, некоторые атрибуты (например, членство в группах), удаленные при первоначальном удалении, не будут восстановлены, что потенциально может создать вам проблемы.

Очистка корня DFS

Если вы используете корень DFS а тем более если вы используете репликацию в DFS, то у вас после восстановления службы FRS может сохраниться событие 13508 в журнале, а DCDIAG в результатах может выдавать такую ошибку «Conflict Mangled Value». Это происходит из-за разных причин, но в основном из-за вручную удаленных объектов репликации.

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

Итак, что я удаляю в такой ситуации:

Сначала я запускаю оснастку «Distributed File System». У меня всего две корневых ссылки, в одной из них включена репликация.

Затем я удаляю целевые папки

Если вы удаляете последнюю целевую папку для корневой ссылки, то при этом удаляется и сама ссылка.

Удаляю оставшуюся корневую ссылку

Теперь удаляю корневые целевые папки, папку с текущего контроллера удаляю последней

Удаление последней целевой папки удаляю весь корень DFS.

Все, корень DFS удален, но в дереве все объекты остались, удаляем и их. Делаю это с помощью ADSIedit.

Первый объект, который я удаляю, это объектCN=DFS Volumes,CN=File Replication Service,CN=System,DC=test,DC=com. Удаляю его полностью со всем содержимым.

Второе место в котором я чищу ссылки это объект «CN=NTFRS Subscriptions» для каждого контроллера домена, который участвовал в репликации. В моем случае:

«CN=DFS Volumes\0ACNF:98627048-5ae0-492c-b929-911c72c54100,CN=NTFRS Subscriptions,CN=DC1,OU=Domain Controllers,DC=test,DC=com» — для контроллера DC1

«CN=DFS Volumes\0ACNF:2d3688fd-094c-4bdd-b017-8e2b29a51c5f,CN=NTFRS Subscriptions,CN=DC2,OU=Domain Controllers,DC=test,DC=com» — для контроллера DC2

Так как контроллер DC3 не учувствовал в репликации ссылок DFS, то у него и не создавались подобные объекты.

После очистки дерева необходимо почистить реестр каждого контроллера домена. Запускаю regedit и открываю ветку реестра «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets». В этой ветке должно быть несколько реплик, которые относятся к службе FRS. Нахожу реплики, которые относятся к DFS. У этих реплик значение параметра «Replica Set Type» будет равно «DFS»

Репликиудаляю в двух ветках реестра:

• «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets»
• «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets»

Все реплики удалены

Аналогично удаляю на всех контроллерах домена.

После создания корня DFS заново все выглядит вот так:

А в системных событиях появились записи о событиях 13553 и 13554 говорящие о успешном запуске репликации ссылок DFS.

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

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

В большинстве сценариев восстановления вам потребуется режим «non-authoritative», поскольку в среде имеется несколько контроллеров домена. Кроме того, «authoritative» восстановление контроллера домена может привести к новым проблемам. Именно на этом основана логика Veeam Backup & Replication: по умолчанию выполняется «non-authoritative» восстановление DC, поскольку считается, что инфраструктура выстроена с избыточностью и включает в себя несколько контроллеров домена. Чтобы выполнить «authoritative» восстановление с помощью Veeam, необходимо осуществить некоторые дополнительные действия, которые описаны ниже.

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

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

• Выбрать мастер восстановления в пользовательском интерфейсе
• Найти нужный контроллер домена
• Выбрать в меню восстановления вариант восстановления ВМ целиком (Restore Entire VM)
• Затем указать точку восстановления
• Выбрать исходное или новое место восстановления
• Завершить процедуру

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

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

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

Рис. 1. Veeam Backup & Replication: Восстановление ВМ целиком

Здесь можно прочитать о восстановлении «на голое железо» резервной копии с помощью Veeam Endpoint Backup. Вам потребуется заранее подготовленный аварийный загрузочный диск Veeam и доступ к самой резервной копии (на USB-носителе или сетевом диске). Помните, что в данном случае особая логика Veeam Backup & Replication использоваться не будет. После восстановления с помощью Veeam Endpoint Backup ваш контроллер домена загрузится в режиме восстановления. Вам нужно будет решить, хотите ли вы менять ключи реестра или сразу перезапустите ВМ в обычном режиме. Возможно, эта статья базы знаний будет полезна.

Рис. 2. Veeam Endpoint Backup: восстановление «на голое железо»

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

Итак, почему же так важно понимать, как функционируют системы более ранних версий? Потому что современная логика и привычная функциональность в этих случаях неприменимы. До появления Windows Server 2008 R2 жизненный цикл объектов Active Directory выглядел следующим образом:

Удаление объекта Active Directory не приводит к его физическому удалению – а происходит вот что:

1. Active Directory скрывает удаленный объект, меняя значение атрибута isDeleted на TRUE.
2. Затем большинство атрибутов объекта сбрасывается, а сам объект переименовывается и перемещается в специальный контейнер (CN=Deleted Objects). С этого момента объект получает статус «tombstone», и стандартные средства Active Directory не знают о его существовании.
3. В этом специальном состоянии объект находится в течение установленного периода (60 дней в Windows Server 2000/2003 и 180 дней в Windows 2003 SP1/2008). Это делается, чтобы гарантировать успешное выполнение репликации данных в системе.
4. По окончании отведенного времени существования в состоянии «tombstone» осуществляется вызов специального процесса (так называемый сборщик мусора), который физически удаляет объект из базы данных.

И вот здесь возникает вопрос: если «tombstone» объект не удаляется физически в течение некоторого времени, нельзя ли его восстановить? Коротко говоря — можно. Хотя такой механизм удаления объектов не был предназначен для использования в качестве временной корзины, а удаленные объекты не предполагалось восстанавливать, технически это возможно. Далее я расскажу, как это можно сделать.