Восстановление active directory windows 10 что это

В этой статье мы покажем, как восстановить контроллер домена 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, произошедших с момента создания бэкапа (членство в группах AD, атрибуты Exchange и т.д.).

• 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 путь к ней.

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

Укажите, что вы восстанавливаете состояние 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_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

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

Этой статьей я завершаю тему восстановления данных в Active Directory. Напоследок я приберег самый тяжелый вариант — авторитативное восстановление Active Directory из резервной копии.  Авторитативное восстановление (англ. Authoritative restore) — процесс достаточно сложный и долгий, могущий привести к различным неприятным последствиям, поэтому применять его стоит очень аккуратно. Однако ситуации бывают разные, поэтому все, кто работает с Active Directory, должны знать об этом способе восстановления и уметь им пользоваться.

Вот что представляет из себя авторитативное восстановление:

1) Контроллер домена загружается в режиме Directory Services Restore Mode (DSRM).  В этом режиме служба AD не запускается, а база данных переводится в автономный режим;
2) База данных AD восстанавливается из резервной копии;
3) Восстанавливаемые объекты помечаются как авторитативные с помощью утилиты Ntdsutil;
4) Контроллер домена загружается в нормальном режиме.

Это если коротко. Более подробно рассмотрим процесс авторитативного восстановления на примере восстановления удаленной организационной единицы. Все действия будут проводится на Windows Server 2008 R2 с использованием встроенных средств, уровень леса Server 2008 R2.

Для авторитативного восстановления Active Directory нам потребуется резервная копия состояния системы (System State). System State включает в себя:

• Файл ntds.dit – база данных Active Directory;
• Системный реестр контроллера домена;
• База данных Certification Authority (служб сертификации);
• Системный том SYSVOL, хранящий сценарии входа в систему и групповые политики домена;
• Системные файлы, необходимые для загрузки операционной системы;
• База данных регистрации классов COM+, которая содержит информацию о приложениях COM+ ;
• Сведения Cluster Services (служб кластеров),  если данный сервер является компонентом кластера.

Для создания резервной копии я воспользуюсь встроенной в Windows Server 2008 программой для резервного копирования Wbadmin. Открываем командную консоль и создаем бэкап System State на диске E следующей командой:

wbadmin start systemstatebackup -backupTarget:E:

Создав резервную копию, открываем оснастку Active Directory Users and Computers (ADUC) и, совершенно случайно 🙂  удаляем подразделение Managers со всем содержимым.

Кстати, в отличие от других объектов (учетных записей пользователей, компьютеров и групп) у контейнеров предусмотрена защита от случайного удаления. Поэтому, прежде чем удалять объект, в оснастке ADUC в меню View включаем пункт Advanced Features. Затем открываем свойства объекта и на вкладке Object снимаем галку с чек-бокса «Protect object from accidental deletion».

Теперь мы должны перезагрузить контроллер домена в режиме восстановления Directory Services Restore Mode. Если в Windows Server 2003 для этого достаточно было нажать клавишу F8 при загрузке, то в Server 2008 необходимо внести изменения в загрузочное меню. Сделать это можно двумя способами.

Из командной строки, запущенной с правами администратора, введя команду:

bcdedit /set safeboot dsrepair

И перезагрузить сервер:

shutdown -r -t 0

Либо нажать Win+R и в строке выполнить (Run) ввести msconfig. Откроется оснастка System Configuration. В ней на вкладке Boot в поле «Boot options» надо отметить режим Safe boot, установить переключатель на Active Directory repair и нажать OK. И затем перезагрузиться.

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

Приступим к восстановлению. Опять задействуем Wbadmin и восстановим созданный ранее System State командой:

wbadmin start systemstaterecovery -version:11/20/2012-08:29

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

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

У каждого объекта Active Directory существует свойство USN (Update Sequence Numbers), или номер последовательного восстановления. При каждом изменении объекта в Active Directory к его значению USN прибавляется 1. Таким образом Active Directory определяет актуальность информации об объекте, т.е. чем больше USN, тем объект актуальнее.
Каждый контроллер домена имеет свой собственный USN, отличный от других. При репликации контроллеры обмениваются значениями USN и каждый запоминает значение USN партнера по репликации, чтобы после оповещения об изменениях партнер забрал произведенные изменения. Таким образом объект с более низким USN будет при репликации перезаписан объектом с более высоким USN.
Так вот, авторитативное восстановление объекта заключается в том, что значение его USN принудительно увеличивается на 100000. Это делает объект авторитативным, и при последующей репликации он будет сохранен.

На самом деле механизм репликации гораздо сложнее, но для понимания процесса этого хватит.

Чтобы пометить объект как авторитативный:

• В меню Start -> Run набираем ntdsutil и жмем ENTER;
• В строке ntdsutil набираем activate instance ntds и жмем ENTER;
• В строке ntdsutil набираем authoritative restore и жмем ENTER.

Теперь мы находимся в приглашении командной строки утилиты Ntdsutil для авторитативного восстановления. Синтаксис команд следующий:

restore object <DistinguishedName> — помечает одиночный объект (компьютер, пользователя или группу) как авторитативный для репликации;
restore subtree <DistinguishedName> — помечает поддерево (напр. подразделение (OU) со всем содержимым) как авторитативный объект;
restore database — помечает всю базу данных Active Directory как авторитативную. Это приведет к перезаписи содержимого базы данных Active Directory на всех контроллерах домена;
-verinc <increment> — параметр, который позволяет вручную задавать USN. По умолчанию при авторитативном восстановлении USN данных увеличивается на 100000. Параметр verinc оказывается полезен, если выполняется авторитетное восстановление данных поверх других авторитетно восстановленных данных, то есть значение USN должно быть увеличено больше, чем на 100000.

Пометим для восстановления подразделение Managers:

restore subtree ″OU=Managers,DC=contoso,DC=com″ 

Дело практически сделано. Теперь остается загрузить контроллер в нормальном режиме и дождаться репликации. Не забудьте отключить безопасную загрузку, сделать это можно командой bcdedit /deletevalue safeboot или из оснастки System Configuration.

На этом процесс авторитативного восстановления можно считать законченным. Для ускорения репликации можно выполнить команду repadmin /syncall.

Некоторые моменты, с которыми можно столкнуться при авторитативном восстановлении.

1) При авторитативном восстановлении может пропасть членство в группах. На этот случай Ntdsutil создает в процессе специальный ldf-файл примерно такого вида ar_20121120-134529_links_contoso.com.ldf. Для восстановления членства в группах надо запустить команду ldifde -i -k -f <FileName>;
2) И наоборот, возможно восстановление членства пользователей в группах, из которых они были удалены;
3) При наличии в организации Exchange 2003 при авторитативном восстановлении у пользователей могут создасться новые пустые почтовые ящики, подключенные к First Storage Group на First Mailbox Store. Подробнее здесь;
4) И еще, нельзя восстанавливать AD  из архива, который старше чем время жизни объектов-захоронений. Это чревато возникновением USN Rollback (откат USN), в результате чего может быть полностью заблокирована репликация в домене.

Обычно 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 в домене, выполните команду

netdom query 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 реплицирует изменение атрибута, указывающего, что объект удален.

Рисунок 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 в определении индивидуального атрибута в схеме. Количество атрибутов не ограничено, но нельзя добавлять связанные атрибуты, такие как членство в группе или база данных почтовых ящиков, содержащая почтовый ящик пользователя.

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

Рисунок 2. Срок существования объекта AD при включенной корзине 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. Запустите команду

authoritative restore

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

restore subtree
   OU=Executives, DC=contoso, DC=com

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

Рисунок 3. Сообщение об успешном принудительном восстановлении

7. Перезагрузите DC в нормальном режиме запуска операционной системы.

8. Зарегистрируйтесь на DC и откройте командную строку. Импортируйте LDIF-файл, экспортированный на шаге 6, выполнив команду

ldifde -i -f
   ar_20110221-151131_links_contoso
      . com.ldf

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

Если нужно восстановить лишь один объект (например, отмеченный как удаленный объект — компьютер), можно воспользоваться командой restore object вместо команды restore subtree на шаге 5. Если в лесу содержится несколько доменов, необходимо использовать текстовый файл, экспортированный на шаге 6 для восстановления членства в локальных группах других доменов.

Реанимация «захоронений»

Существует несколько инструментов для реанимации, но в сущности, все они выполняют одни и те же действия. В качестве примера рассмотрим шаги, необходимые для реанимации отмеченной как удаленная учетной записи пользователя John Doe с использованием утилиты AdRestore (technet.microsoft.com/en-us/sysinternals/bb963906).

1. Откройте командную строку и выполните поиск учетной записи пользователя с помощью команды

adrestore Doe

AdRestore ищет удаленные объекты, соответствующие шаблону *doe*, и выдает результаты, как показано на рисунке 4.

Рисунок 4. Пример вывода утилиты AdRestore

2. Проверьте наличие реанимируемого объекта, а затем вновь запустите AdRestore с ключом -r:

adrestore -r Doe

3. Подтвердите свое намерение реанимировать объект. AdRestore реанимирует объект в том месте, где он находился ранее.

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

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

Корзина Active Directory, несомненно, лучший вариант восстановления, поскольку восстанавливаются все атрибуты, в том числе связанные, такие как членство в группах. Однако, как отмечалось выше, для этого лесу необходим функциональный уровень Windows Server 2008 R2.

Активировать корзину Active Directory можно с использованием Windows PowerShell, выполнив команду

Enable-ADOptionalFeature -Identity
   'CN=Recycle Bin Feature,
   CN=Optional Features,
   CN=Directory Service,
   CN=Windows NT, CN=Services,
   CN=Configuration, DC=contoso, DC=com'
   -Scope ForestOrConfigurationSet
   -Target 'contoso.com'

Обратите внимание, что включение корзины Active Directory — необратимый шаг. Кроме того, после активации корзины Active Directory ранее захороненные объекты нельзя восстановить через реанимацию из захоронения.

Любые объекты, удаленные после активации корзины Active Directory, можно полностью восстановить в течение срока существования удаленных объектов леса. Есть несколько способов удалять объекты, но самый простой — использовать команды PowerShellТs Restore-ADObject. Например, для восстановления пользователя с именем John Doe нужно выполнить следующие шаги.

1. Запустите модуль Active Directory для Windows PowerShell из раздела Administrative Tools из меню Start.

2. Выполните поиск удаленного объекта, запустив команду

Get-ADObject -SearchBase
   "CN=Deleted
      Objects, DC=contoso, DC=com"
   -ldapFilter:" (msDs-lastKnownRDN=John
      Doe)"
   -IncludeDeletedObjects
   -Properties lastKnownParent

Убедитесь, что это единственный объект в наборе результатов.

3. Восстановите объект с помощью команды

Get-ADObject -SearchBase
   "CN=Deleted
      Objects, DC=contoso, DC=com"
   -ldapFilter:" (msDs-lastKnownRDN=John
      Doe)"
   -IncludeDeletedObjects
   -Properties lastKnownParent |
   Restore-ADObject

Если была удалена вся организационная единица, объекты нужно восстанавливать в правильном порядке (то есть нельзя восстанавливать объект прежде его родителя), чтобы разместить их в нужных местах. Полезный сценарий PowerShell для восстановления дерева объектов опубликован по адресу technet.microsoft.com/en-us/library/dd379504(WS.10).aspx на сайте Microsoft.

Сложная задача

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

Брайан Десмонд (brian@briandesmond.com) — старший консультант компании Moran Technology Consulting (Чикаго). Имеет сертификат Directory Services MVP. Автор книги «Active Directory», ведет блог www.briandesmond.com

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

---

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

---

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

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

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

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

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

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

DSA Invocation ID

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

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

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

RID Pool

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

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

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

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

SYSVOL restore

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

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

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

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

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

Подготовка

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

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

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

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

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

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

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

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

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

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

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

На этом восстановление завершено.

comments powered by HyperComments

Active Directory — одна из самых критичных служб в сети Windows. Чтобы свести к минимуму время простоя и снижение производительности, очень важно иметь эффективные планы аварийного восстановления при неполадках в Active Directory. Это может показаться очевидным, но просто поразительно, сколько администраторов не имеют плана восстановления при возникновении одной из наиболее вероятных проблем с Active Directory®: случайного удаления данных.

Случайное удаление объектов — одна из наиболее распространенных причин сбоя службы. Когда я провожу семинары или конференции, я часто спрашиваю, сталкивался ли кто-нибудь с неполадками в Active Directory из-за случайного удаления данных. И каждый раз почти все поднимают руку.

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

Хранение объектов

Active Directory — специальная база данных объектов, реализующая модель данных X.500/LDAP. Хранилище данных (называемое информационным деревом каталога — DIT) основано на механизме расширяемого хранилища (ESE), механизме базы данных на основе индексно-последовательного доступа (ISAM). Концептуально Active Directory хранит DIT в двух таблицах: таблице данных (которая содержит реальные объекты и атрибуты Active Directory) и таблице связей (которая хранит данные о связях между объектами).

Каждый объект Active Directory хранится в отдельной строке таблицы данных, один атрибут в столбце. Таблица данных содержит все элементы всех реплик, хранящихся на контроллере домена (DC). На обычном контроллере домена таблица данных содержит элементы из контекстов именования (NC) домена, конфигурации и схемы. В глобальном каталоге таблица данных содержит элементы для каждого объекта в лесу.

Для уникальной идентификации каждой строки таблицы данных Active Directory использует идентификатор различающегося имени (distinguished name tag, DNT) — 32-разрядное целое число. DNT, использующийся для внутреннего указания на объекты, меньше других идентификаторов, таких, как различающееся имя (DN) и идентификатор objectGUID (16-байтовая двоичная структура). Но, в отличие от идентификатора objectGUID, DNT является локальным идентификатором и отличается на разных контроллерах домена.

Как Active Directory связывает объекты

Active Directory управляет двумя видами отношений между объектами в информационном дереве каталога: отношения родитель-потомок (также называемые взаимоотношениями контейнера) и отношения ссылки (также называемые отношениями связи). Для реализации отношений родитель-потомок Active Directory содержит в таблице данных дополнительный столбец для идентификатора различающегося родительского имени (). Этот столбец всегда содержит DNT родителя объекта.

Каждый атрибут в Active Directory определяется объектом attributeSchema в контейнере схемы Active Directory. Некоторые атрибуты в Active Directory определяются как атрибуты ссылки и задаются четным ненулевым числом в атрибуте linkID объекта attributeSchema. Атрибуты ссылки устанавливают отношения между объектами в каталоге и могут иметь одно или несколько значений. Атрибут членства объекта группы — пример атрибута ссылки с несколькими значениями, устанавливающий связь между объектом-группой и объектом-участником.

Хотя кажется, что атрибут членства группы содержит различающиеся имена участников (как, например, показано в оснастке «Пользователи и компьютеры Active Directory»), на самом деле Active Directory хранит их другим способом. При добавлении различающегося имени объекта участника к атрибуту членства группы Active Directory сохраняет идентификатор различающегося имени объекта, а не само различающееся имя. Поскольку идентификатор различающегося имени не меняется даже при переименовании объекта, можно переименовать объект пользователя, и Active Di­rectory не нужно будет выполнять сортировку по всем группам системы, чтобы обновить различающееся имя в каждом атрибуте участника. Так Active Directory поддерживает ссылочную целостность в информационном дереве каталога. На рис. 1 показано сильно упрощенное представление взаимоотношений таблицы данных и таблицы связей. На этих таблицах показано, что три объекта пользователей — Molly Clark, Alexander Tumanov и Makoto Yamagishi — являются членами группы старших инженеров.

Эти ссылки называют ссылками на следующий элемент (ссылка вперед). Тем же образом Active Directory поддерживает атрибуты ссылки на предыдущий элемент (ссылка назад). Так обеспечивается связь между связанным объектом и объектом, который на него ссылается, то есть связан со следующим элементом. Атрибут memberOf для пользователей и групп — пример атрибута связи с предыдущим объектом. Объект attribute­Schema, который описывает атрибут ссылки на предыдущий объект, имеет значение linkID на единицу большее, чем целочисленное значение linkID соответствующего атрибута ссылки на следующий элемент. Например, атрибут членства схемы Windows Server® 2003 R2 имеет значение linkID, равное 2; атрибут memberOf, который служит ссылкой на предыдущий элемент, имеет значение linkID, равное 3. В качестве дополнительных сведений на Рис. 2 показан список стандартных атрибутов ссылки схемы Windows Server 2003 R2.

Атрибуты ссылки на предыдущий элемент всегда имеют несколько значений и обрабатываются Active Directory автоматически. На самом деле нельзя напрямую изменять атрибут ссылки на предыдущий элемент. Хотя кажется, что можно изменить атрибут memberOf пользователя или группы с помощью оснастки MMC «Active Directory – пользователи и компьютеры», на самом деле оснастка меняет атрибут членства соответствующей группы, и Active Directory «за кулисами» обновляет атрибут memberOf. Поэтому не требуются полномочия для объекта пользователя, чтобы добавить пользователя в группу; вы только меняете атрибут членства объекта группы. Поскольку каждый контроллер домена локально управляет атрибутами ссылки на предыдущий элемент, изменения ссылок назад никогда не реплицируются. Реплицируются только изменения атрибута ссылки на следующий элемент, такие, как атрибуты членства в группе.

На обычном контроллере домена таблица данных содержит элементы объектов домена, а также объекты контейнеров из конфигурации и схемы. Но некоторые типы групп могут содержать ссылки на объекты, расположенные в другом домене. Как Active Directory хранит идентификатор различающегося имени для объекта, отсутствующего в таблице данных? Ответ касается владельца роли хозяина инфраструктуры FSMO (Flexible Single Master Operations) и сущности, называемой фантомным объектом.

Фантомные объекты

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

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

Фантомы позволяют контроллерам домена управлять ссылками на объект, расположенный в другом домене леса, но атрибуты ссылки вперед также могут указывать на объект, расположенный вне леса, например, в доверенном домене. В этом случае Active Directory создает объект, называемый участником внешней безопасности (FSP) в контейнере CN=ForeignSecurityPrincipals в NC домена. FSP содержит идентификатор безопасности (SID) внешнего объекта и атрибуты, идентифицирующие объект во внешнем домене, но не существует процесса, поддерживающего актуальность данных FSP. При восстановлении данных мы рассматриваем FSP как любой другой объект Active Directory.

Удаление объектов

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

Когда Active Directory удаляет объект, он не удаляется из информационного дерева каталога физически. Вместо этого он помечает объект как удаленный путем установки значения «истина» для атрибута isDeleted, что делает объект невидимым для обычных операций в каталоге. Active Directory удаляет все атрибуты, не предназначенные для сохранения, как определяется схемой и меняет относительное различающееся имя (RDN) объекта на

aDEL:. Затем перемещает объект в контейнер CN=Deleted Objects для контекста именования. (Существуют некоторые классы объектов в контексте именования Конфигурация, которые Active Directory не может переместить в контейнер Deleted Objects.) Active Directory удаляет любые ссылки вперед на другие объекты, содержащие удаленные объекты, что снижает значение счетчика ссылок в таблице связей. Если существуют другие объекты, содержащие ссылки вперед на новые удаленные объекты, Active Directory также удаляет эти ссылки.

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

Active Directory обрабатывает объекты в информационном дереве каталога как определено атрибутом объекта tombstoneLifetime CN=Directory Service,CN=Windows NT,CN=Ser­vices,CN=Con­fig­ura­tion,DC=. Процессы «сборки мусора» на каждом DC удаляют объекты-захоронения, которые старше, чем настроенное для них время жизни. По умолчанию время жизни объектов-захоронений составляет 60 дней для Win­dows® 2000, Windows Server 2003, и Win­dows Server 2003 R2. Оно равно 180 дням для Win­dows Server 2003 SP1.

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

Репликация объектов

Когда контроллер домена выполняет любую операцию обновления, например, при добавлении объекта или изменения атрибута, контроллер присваивает операции уникальный 64-разрядный номер, называемый номером последовательного обновления (USN). Active Directory помечает с помощью USN обновляемые объекты и атрибуты, чтобы определить, следует ли их реплицировать.

Active Directory реплицирует объекты по принципу «атрибут за атрибутом». Поэтому при изменении атрибута объекта Active Directory будет реплицировать атрибут, а не объект целиком. Для этого Active Directory отслеживает изменения каждого атрибута при помощи метаданных репликации. Метаданные репликации атрибута включают:

• Локальный USN, который идентифицирует операцию изменения на локальном DC.
• InvocationID контроллера домена, на котором возникли изменения (особенно атрибут invocationID контроллера, соответствующего объекту nTDSSettings), который показывает отдельное появление информационного дерева каталога на контроллере домена.
• USN исходной операции, если она существует на исходном контроллере домена.
• Отметка времени, которая отражает системное время DC при выполнении изменения.
• 32-разрядный номер версии, последовательно возрастающий при каждом изменении.

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

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

Репликация связанных значений

В Windows 2000 Active Directory реплицирует атрибуты с множественными значениями так же, как и атрибуты с одним значением. Это вызывает проблемы для больших динамических групп объектов, имеющих атрибуты членства с несколькими значениями, которые могут часто меняться на разных контроллерах доменов. Если администратор добавил пользователя в группу на одном контроллере домена, а другой администратор добавил на другом контроллере другого пользователя в окне задержки репликации, Active Directory выберет последнее добавление, а предыдущее добавление будет полностью утрачено. Корпорация Майкрософт решила эту проблему в Windows Server 2003 с помощью процесса, называемого «репликация связанных значений» (LVR).

На функциональном уровне леса или внутреннего леса Windows Server 2003 Active Directory отдельно реплицирует индивидуальные значения атрибутов ссылок вперед с множественными значениями, при этом каждое значение имеет свои метаданные репликации. Это эффективно решает проблему, выявленную в Windows 2000, когда практически одновременные обновления членства в группах на различных контроллерах домена могут вызывать потерю данных.

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

Резервное копирование

В состав Windows включена служебная программа начального уровня NTBACKUP, которую можно использовать для создания резервной копии состояния системы контроллера домена. Состояние системы контроллера домена включает его реестр, папку SYSVOL, файлы информационного дерева каталога Active Directory и критические системные файлы. Большинство сторонних программ резервного копирования также способны создавать резервные копии и восстанавливать состояние контроллера домена.

Для резервного копирования состояния в файл на диске используйте следующую команду:

NTBACKUP backup systemstate /F ”<filename>”

Здесь — имя создаваемого файла резервной копии, который должен иметь расширение bkf .

Выполнение неполномочного восстановления

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

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

При удаленном управлении сервером меню загрузки Windows недоступно. Вместо этого можно изменить параметры загрузки системы, выбрав пункт «Настройка» в разделе «Мой компьютер», щелкнув вкладку «Дополнительно» и нажав кнопку «Параметры ниже надписи «Загрузка и восстановление». Нажмите кнопку «Правка» в разделе «Загрузка операционной системы» для внесения изменений в файл boot.ini, добавьте аргумент /SAFE­BOOT:DSREPAIR к концу строки, как показано на рис. 3. (Дополнительные сведения об аргументах файла boot.ini см.

microsoft.com/technet/ sysinternals/information/bootini.mspx.)

После перезагрузки сервера включится режим восстановления службы каталога. Помните, что нужно удалить аргумент /SAFEBOOT из файла boot.ini, если нужно перезагрузить контроллер домена в обычном режиме.

После входа в систему с паролем режима восстановления службы каталога восстановите состояние системы из резервной копии с помощью служебной программы NTBACKUP, но без каких-либо параметров. (Можно выполнить восстановление, набрав NTBACKUP в командной строке.) При появлении мастера выберите «Восстановление файлов и параметров» и нажмите кнопку «Далее». Выберите файл с резервной копией и проверьте состояние окна Состояние системы, как показано на рис. 4.

Рис. 4 Использование Мастера архивации и восстановления для восстановление состояния системы

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

Выполнение полномочного восстановления

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

После завершения неполномочного восстановления, но до перезагрузки используйте программу NTDSUTIL для выполнения полномочного восстановления объектов, которые хотите вернуть к первоначальному состоянию. Несмотря на название, полномочное восстановление объектов их не «восстанавливает», при этом Active Directory просто реплицирует объекты на другие контроллеры. Для этого NTDSUTIL присваивает следующий доступный USN локальному USN атрибутов объекта. Это приводит к тому, что объект будет отправлен для репликации партнерам при следующем сеансе синхронизации. Для восстановления единичного объекта убедитесь, что контроллер домена загружен в режиме восстановления службы каталога, и выполните следующие действия:

1. Откройте окно командной строки и наберите:

ntdsutil

2. При появлении приглашения ntdsutil наберите:

authoritative restore

3. При появлении запроса на полномочное восстановление наберите:

restore object ”<DN of object to be restored>”

Например, если нужно восстановить учетную запись Molly Clark в подразделении Eng домена DRNET, следует набрать:

restore object ”CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”

Если нужно полномочно восстановить все поддерево каталога, например подразделение, наберите вместо этого:

restore subtree ”OU=Eng,DC=DRNET,DC=com”

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

Planning for Active Directory Forest Recovery»,

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

5. Выйдите из программы ntdsutil (необходимо дважды набрать quit).

6. Перезагрузите контроллер домена в обычном режиме Active Directory.

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

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

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

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

Ситуация: Членство в группах домена не восстановлено

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

Корпорация Майкрософт постоянно вносит улучшения в процесс восстановления членства в группах, поэтому используемая методика зависит от версии Active Directory. Следующие разделы прежде всего применимы для Windows 2000 Active Directory.

Определить членство пользователя в старых группах достаточно просто: посмотрите атрибут ссылки назад на восстановленном контроллере домена — в данном случае это атрибут memberOf объекта пользователя. Атрибут memberOf будет содержать все сведения о членстве в локальных и глобальных группах домена пользователя. Для составления списка членства пользователя в группах можно использовать оснастку «Active Directory – пользователи и компьютеры» (ADUC), или программу LDIFDE, которая включена в состав Windows Server.

Следующая команда LDIFDE выведет список групп домена DRNET, членом которых состоит Molly Clark, сохранив результат в файле output.ldf:

C:> ldifde –r ”(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf

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

REPADMIN /options <dcname>+DISABLE_INBOUND_REPL

Здесь — имя восстанавливаемого контроллера домена. Не забудьте после окончания заново включить репликацию с помощью параметра —DISABLE_INBOUND_REPL.

Если восстанавливаются только некоторые пользователи, можно просто вручную добавить пользователя в группы с помощью ADUC. Для восстановления большого числа пользователей существуют средства, позволяющие автоматизировать некоторые процессы. Служебная программа Microsoft GROUPADD (доступна через службу поддержки Microsoft) может использовать созданный файл LDIF для просмотра членства пользователя в старых группах и, в свою очередь, для создания файла LDIF, который восстанавливает это членство. Например, можно использовать команду GROUPADD для обработки файла LDIF, ранее созданного для пользователя Molly Clark:

C:> groupadd /after_restore output.ldf

Эта команда создаст новый файл LDIF для каждого домена, в группы которого входит Molly Clark с именем groupadd_

.ldf (где — полное доменное имя (FQDN) домена, в котором будут обновлены группы). Импортировать ранее созданный файл LDIF можно при помощи следующей команды:

C:> ldifde –i –k –f groupadd_child.drnet.net.ldf

С выходом Windows Server 2003 корпорация Microsoft улучшила NTDSUTIL, добавив преимущества дополнительных метаданных, присутствующих в атрибуте членства для поддержки репликации связанных значений (LVR). Если восстанавливаемый объект пользователя являлся членом любых групп домена, а членство пользователя хранилось с метаданными LVR, служебная программа NTDSUTIL увеличивает номер версии соответствующего значения атрибута пользователя, что приводит к репликации восстановленного членства.

Служебная программа NTDSUTIL в составе Windows Server 2003 SP1 объединена с функциями GROUPADD и автоматически будет создавать файлы LDIF при полномочном восстановлении объекта пользователя. На рис. 5 показана новая версия NTDSUTIL, а на рис. 6 — содержимое автоматически созданного файла LDIF.

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

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

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

Ситуация: Членство в группах других доменов не восстановлено

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

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

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

C:> ldifde –r ”(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf

Если запустить программу GROUPADD или новую программу NTDSUTIL в глобальном каталоге, создается один файл LDIF для домена пользователя и один файл LDIF для каждого домена, в который восстанавливаемый пользователь был членом универсальной группы. При импорте этих файлов LDIF вы восстановите членство пользователя во всех группах. Или почти всех, как покажет рассмотрение следующей проблемы.

Ситуация: Восстановление членства в локальных группах других доменов

В среде Windows Active Directory существует три вида групп. Глобальные группы могут состоять только из членов своего домена, но которые могут использоваться как члены локальных групп того же домена или других доменов леса. Атрибут членства в глобальных группах не появляется в глобальном каталоге, но это не представляет проблемы, поскольку глобальные группы содержат только членов своего домена. Универсальные группы могут состоять из членов любого домена, которые могут выступать как члены других универсальных групп леса и локальных групп своего домена и других доменов леса. Атрибут членства в универсальных группах реплицируются в глобальные каталоги. Локальные группы домена могут состоять из членов любого домена леса, но которые не могут выступать как члены групп других доменов. Важнее то, что атрибут членства в локальных группах домена, как и в глобальных группах, не появляется в глобальном каталоге. В результате не существует простого способа восстановления членства пользователя в локальных группах других доменов.

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

В этом случае может помочь версия программы NTDSUTIL из Windows Server 2003 с пакетом обновления 1 (SP1). При запуске NTDSUTIL на контроллере домена создается текстовый файл, содержащий различающееся имя и идентификатор GUID восстановленных объектов пользователей. Затем для каждого внешнего домена можно неполномочно восстановить один контроллер домена, скопировать на него текстовый файл и запустить NTDSUTIL для создания нового файла LDIF для этого домена. Файл добавит восстановленного пользователя в локальные группы домена, членом которых он был ранее.

Для этого выполните следующие действия над контроллером домена в каждом внешнем домене:

• Загрузите контроллер внешнего домена в режиме восстановления службы каталога.
• С помощью программы NTBACKUP восстановите копию информационного дерева каталога, содержащую сведения о членстве в группах восстановленных пользователей.
• Скопируйте созданный NTDSUTIL TXT-файл на текущий контроллер домена.
• Откройте окно командной строки и наберите ntdsutil.
• Наберите authoritative restore (полномочное восстановление).
• Наберите create LDIF file(s) from

(где имя текстового файла).
• Дважды наберите quit для выхода из программы ntdsutil.
• Перезагрузите контроллер домена в обычном режиме Active Directory.
• Наберите ldifde –i –f (где имя созданного только что файла LDIF).

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

Шаг за шагом

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

При работе с Windows 2003 SP1 необходимы следующие действия:

• Загрузите глобальный каталог в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей.
• С помощью программы NTDSUTIL выполните полномочное восстановление удаленного пользователя. NTDSUTIL создаст текстовый файл, содержащий различающееся имя и идентификатор GUID восстановленного объекта, и один или несколько файлов LDIF для восстановления членства пользователя в группах.
• Используйте команду LDIFDE –i –f

(где имя файлов LDIF, созданных в шаге 2) для импорта членства в группах текущего и других доменов.
• Перезагрузите глобальный каталог в обычном режиме.
• В каждом внешнем домене загрузите какой-либо контроллер в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей.
• Запустите программу NTDSUTIL с командой create ldif files (создать файлы ldif).
• Перезагрузите контроллер домена в обычном режиме.
• Используйте команду LDIFDE –i –f (где имя LDIF файла, созданного в шаге 6) для восстановления членства в группах внешнего домена.
• На этой стадии можно запустить репликацию командой REPADMIN /syncall.

Если запущена версия Windows Server 2003 без установленного пакета обновления 1 (SP1) или Windows 2000, необходимо выполнить ряд дополнительных действий. Поскольку более старая версия NTDSUTIL не создает файлы LDIF, используйте для их создания программу GROUPADD. Процедура выполняется так:

• Загрузите глобальный каталог в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей.
• Отключите сетевую карту или отсоедините кабель для предотвращения входящей репликации.
• Перезагрузите глобальный каталог в обычном режиме.
• С помощью команды LDIFDE –r «(distinguishedName=

)» -t 3268 -l memberOf –p Base -f membership.ldf создайте дамп членства пользователя с различающимся именем .
• Для создания файлов LDIF используйте команду GROUPADD /after_restore membership.ldf.
• Для импорта членства в группах текущего и других доменов используйте команду LDIFDE –i –f (где имя файла LDIF, созданного программой GROUPADD в шаге 5).
• Заново разрешите входящую репликацию с помощью команды REPADMIN /options -DISABLE_INBOUND_REPL.
• В каждом внешнем домене загрузите какой-либо контроллер в режиме восстановления службы каталога и выполните восстановление состояния системы из архива, содержащего удаленных пользователей.
• Перезагрузите контроллер домена в обычном режиме.
• С помощью команды LDIFDE –i –f (где имя файла LDIF , созданного программой GROUPADD в шаге 5) восстановите членство в группах внешнего домена.
• На этой стадии можно запустить репликацию командой REPADMIN /syncall.

Единственное, что остается сделать в среде, предшествующей Windows Server 2003 с пакетом обновления 1 (SP1), — восстановить членство в локальных группах внешнего домена восстановленного пользователя. Можно вручную только восстановить членство в локальных группах домена или восстановить контроллер домена из резервной копии и полномочно восстановить локальные группы домена.

Заключение

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

Сможете ли вы правильно выполнить эти действия в вашем окружении с первой попытки? Для уверенности в том, что в следующий раз вы действительно сможете восстановить объект Генеральный директор, приготовьте письменный план восстановления удаленных объектов. И потренируйтесь в выполнении этого плана один-два раза перед тем, как испытывать его на реальных данных. Ваш босс (и ваш генеральный директор) оценят это по достоинству.

Дополнительные источники

How to Restore Deleted User Accounts and Their Group Memberships in Active Directory
Центр справки и поддержки Майкрософт
Step-by-Step Guide to Managing Active Directory

Джил Киркпатрик (Gil Kirkpatrick) — руководитель технологического отдела компании NetPro и разработчик программного обеспечения для Active Directory с 1996 г. Вместе с Гвидо Грилленмайером (Guido Grillenmeier) из компании HP он поставляет популярные средства аварийного восстановления Active Directory. Джил также является основателем конференции Directory Experts (www.dec2007.com).

Из April 2007 выпуска TechNet Magazine.

Оцените статью: Голосов

null

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

Если вы восстанавливаете Active Directory, потому что базу данных на одном из ваших контроллеров домена больше нельзя использовать, у вас есть два варианта. Первый вариант состоит в том, чтобы вообще не восстанавливать Active Directory на отказавшем сервере, а создать еще один контроллер домена, назначив другой сервер, на котором выполняется система Windows Server 2003, контроллером домена. Таким способом вы восстановите функциональные возможности контроллера домена, а не службу Active Directory на определенном контроллере домена. Второй вариант состоит в восстановлении отказавшего сервера и последующем восстановлении базы данных Active Directory на этом сервере. В этом случае вы выполните восстановление при отсутствии полномочий (nonauthoritative). При таком восстановлении база данных Active Directory восстанавливается на контроллере домена, а затем все изменения, сделанные к Active Directory после создания резервной копии, реплицируются на восстановленный контроллер домена.

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

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

Один из вариантов восстановления функциональности Active Directory состоит в создании нового контроллера домена, заменяющего отказавший контроллер домена. Если один контроллер домена выйдет из строя, вы можете создать другой сервер, на котором будет выполняться Windows Server 2003 и Active Directory 2003, или назначить контроллером домена один из уже имеющихся серверов. Затем можно использовать обычную репликацию Active Directory для заполнения базы данных Active Directory нового контроллера домена. Создание нового контроллера домена является наилучшим решением в следующих ситуациях.

• В дополнение к отказавшему серверу у вас имеется еще один доступный контроллер домена — это необходимое требование. Если нет другого контроллера домена, который доступен как партнер по репликации, то остается единственный вариант восстановления базы данных Active Directory на новом или на отремонтированном контроллере домена.
• На создание нового контроллера домена и репликацию информации с другого контроллера домена требуется значительно меньше времени, чем на ремонт отказавшего контроллера домена и на восстановление базы данных. Этот расчет зависит от размера базы данных Active Directory, скорости сетевой передачи данных между вашими контроллерами домена и скоростью, с которой вы можете создавать и восстанавливать контроллеры домена. Если база данных Active Directory относительно мала (менее 100 Мб), а второй контроллер домена находится в той же самой локальной сети, то создание другого контроллера домена и репликация базы данных пройдет быстрее, чем ремонт и восстановление отказавшего контроллера домена. Если ваша база данных велика или единственный доступный партнер по репликации отказавшего контроллера домена связан с ним через медленную глобальную сеть (WAN), то ремонт вышедшего из строя контроллера домена и восстановление базы данных будет более быстрым способом.
• Вы не можете отремонтировать отказавший контроллер домена. Возможно восстановление Windows Server 2003 и базы данных Active Directory на сервере, имеющем аппаратные средства, отличные от первоначального контроллера домена, однако этот процесс обычно труден и занимает много времени. Если вы не можете воссоздать отказавший сервер так, чтобы он имел похожие аппаратные средства, то создание другого контроллера домена займет меньше времени.

Планирование. Варианты восстановления, перечисленные выше, не потребуются, если вы сможете отремонтировать отказавший контроллер домена без необходимости создавать его заново и восстанавливать. Система Windows Server 2003 обеспечивает несколько усовершенствованных опций поиска неисправностей, таких как Last Known Good Configuration (Последняя известная хорошая конфигурация) и Safe Mode (Безопасный режим). Используйте эти инструментальные средства, чтобы попробовать вернуть контроллер домена в рабочее состояние, прежде чем начнете выполнять полное восстановление.
Чтобы создать дополнительный контроллер домена, который заменит отказавший сервер, используйте уже имеющийся сервер с системой Windows Server 2003 (или создайте новый сервер) и назначьте его контроллером домена. В процессе назначения сервера контроллером домена каталог будет реплицирован с одного из других контроллеров домена. Если отказавший контроллер домена служил сервером глобального каталога (GC) или выполнял роль одного из хозяев операций, вы должны подумать о том, как восстановить эти функциональные возможности. Восстановление GC-серверов и серверов хозяев операций описано подробно далее в этой главе.

Как говорилось в главе б, Windows Server 2003 обеспечивает опцию установки нового контроллера домена и загрузки базы данных Active Directory из восстановленной резервной копии вместо использования обычного процесса репликации. Эта опция очень полезна при создании контроллера домена в удаленном офисе, связанном с центральным офисом через медленную сетевую связь, потому что полный объем данных, связанных с начальной репликацией, не должен пересекать глобальную связь WAN. Если вы имеете хорошую резервную копию отказавшего контроллера домена в удаленном офисе, можно использовать такую же методику для создания нового контроллера домена.
Если вы решите восстанавливать функциональные возможности Active Directory через создание нового контроллера домена, вы все равно должны будете удалить старый контроллер домена из каталога и из DNS. Если вы планируете использовать имя отказавшего контроллера домена для восстановленного контроллера домена, вы должны очистить каталог перед началом восстановления. Если вы используете другое имя для нового контроллера домена, нужно очистить каталог после инсталляции.
Чтобы очистить каталог, выполните следующие действия на любой рабочей станции или сервере с системой Windows 2000, на рабочей станции Windows XP Professional или на сервере Windows Server 2003 /который является членом домена.
Откройте командную строку и напечатайте ntdsutil.

В командной строке утилиты Ntdsutil напечатайте metadatacleanup.
В окне Metadata Cleanup (Очистка мета-данных) напечатайте connections. Эта команда используется для соединения с текущим контроллером домена с целью удаления отказавшего контроллера домена.
В окне Server Connections (Подключение к серверу) напечатайте connecttoserverservername(соединиться с сервером servername), где servername— имя доступного контроллера домена. Если вы войдет в систему под учетной записью с административными правами в Active Directory, вы подключитесь к этому контроллеру домена. Если вы не имеете административных прав, используйте команду setcredsdomainusernamepassword, чтобы ввести «верительные грамоты» пользователя, имеющего разрешения уровня домена. Если вы напечатаете helpв окне Server Connections, то увидите, что одна из опций ваших команд — это connecttoserver %s(соединиться с сервером %s). Переменная %sдолжна всегда заменяться значением, имеющим тип символьной строки. В этом случае строка является или DNS-именем контроллера домена, или IP-адресом сервера.
В окне Server Connections напечатайте quit, чтобы возвратиться в окно Metadata Cleanup.
Напечатайте selectoperationtarget(выбрать адресата операции). Эта команда используется для выбора домена, сайта и контроллера домена, чтобы вы могли удалить контроллер домена.
В окне Select Operation Target напечатайте list domains (перечислить домены). Все домены вашего леса перечисляются с назначенными каждому их них номерами.

Напечатайте selectdomainnumber(выбрать номер домена), где numberуказывает домен, содержащий отказавший контроллер домена. Если вы напечатаете helpперед тем, как напечатать selectdomainnumber, то увидите, что одна из опций команды —selectdomain %d(выбрать домен %d). Переменная %dдолжна всегда заменяться числом.
Напечатайте listsites(перечислить сайты). Будут перечислены все сайты леса.
Напечатайте selectsitenumber(выбрать номер сайта), чтобы выбрать сайт, содержащий контроллер домена, который вы должны удалить.
Напечатайте listserversinsite(перечислить серверы в сайте). Все контроллеры домена, имеющиеся в выбранном сайте, будут перечислены. Используйте команду selectservernumber, чтобы выбрать контроллер домена, который вы должны удалить. Утилита Ntdsutil покажет*выбранный домен, сайт и контроллер домена (см. рис. 15-1.)

Рис. 15-1. Отображение домена, сайта и контроллера домена в утилите Ntdsutil

Напечатайте quit. Вы вфнетесь в окно Metadata Cleanup.
Напечатайте removeselectedserver(удалите выбранный сервер). Вас попросят подтвердить, что вы хотите удалить сервер из каталога. Щелкните на Yes (Да).
Чтобы выйти из утилиты Ntdsutil, печатайте quitв каждой командной строке, пока не выйдите из программы.

Инструмент Ntdsutil

В главе 14 были показаны примеры использования утилиты Ntdsutil для управления базой данных Active Directory. Ntdsutil — это инструмент командной строки, который применяется для управления некоторыми компонентами Active Directory и базой данных. Ntdsutil является мощным инструментом, им надо пользоваться с осторожностью.
Запустите инструмент Ntdsutil, напечатав в командной строке ntdsutil. Инструмент выдает приглашение к вводу команд Ntdsutil. Вы можете вводить разнообразные команды в зависимости от того, что вы хотите
сделать. Если вы напечатаете helpв любой командной строке, то получите список всех команд, которые можно использовать в этом положении. На рисунке 15-2 показан список команд, доступных из окна Ntdsutil.

Рис. 15-2. Список команд, доступных из командной строки в утилите Ntdsutil

Далее вы увидите еще несколько примеров использования утилиты Ntdsuti для управления службой Active Directory. Более детальную информацию по использованию утилиты Ntdsutil смотрите в Help And Support Center.
После очищения каталога от ненужных объектов с помощью Ntdsutil нужно очистить также DNS-записи отказавшего контроллера домена. Удалите все DNS-записи из DNS, включая все записи, касающиеся контроллера домена, записи GC-сервера и записи эмулятора основного контроллера домена (PDC). (Две последних записи существуют только в том случае, если контроллер домена был сконфигурирован на выполнение этих ролей.) Если вы не очистите записи DNS, клиентьТ продолжат получать информацию DNS и будут соединяться с этим контроллером домена.
Нужно также удалить вышедший из строя контроллер домена из сайта и домена. Для этого используйте инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory) и удалите объект, связанный с этим компьютером, из OU Domain Controllers (Контроллеры домена). В инструменте Active Directory Sites And Services (Сайты и службы Active Directory) удалите объект, связанный с этим компьютером, из контейнера Servers (Серверы) того сайта, в котором он был расположен.
Выполнение неофициального восстановления

Вторая опция по восстановлению базы данных Active Directory состоит в ремонте отказавшего контроллера домена с последующим восстановлением базы данных. Вместо восстановления отказавшего контроллера домена можно восстановить базу данных на новый сервер. Восстановление базы данных на новом или исправленном сервере является наилучшим выбором при следующих обстоятельствах.
•    Сервер является единственным контроллером домена в домене. Если дело обстоит так, у вас нет выбора, как восстанавливать службу Active Directory. Вы должны восстановить базу данных на новом или исправленном сервере.
•    Репликация информации с другого контроллера домена займет слишком много времени. В некоторых случаях вы восстановите отказавший контроллер домена и базу данных быстрее, чем инсталлируете новый контроллер домена и создадите базу данных путем репликации. Такая ситуация реализуется почти всегда, если отказавший контроллер домена связан медленными сетевыми связями с любым другим контроллером домена. Даже если он связан с другими контроллерами через более быструю сетевую связь, вам все-таки может быть выгоднее восстанавливать базу данных.

Планирование. Без тестирования различных вариантов в вашей конкретной среде трудно сказать, что является более быстрым: восстановление контроллера домена с резервной магнитной ленты или восстановление Active Directory путем создания дополнительного контроллера домена. Иногда совершенно ясно, что на создание нового контроллера домена уйдет меньше времени, если имеется сервер с системой Windows Server 2003, установленный на быстром сегменте сети, который вы можете сделать контроллером домена, и размер вашей базы данных Active Directory меньше, чем 100 Мб. В других случаях совершенно ясно, что меньше времени займет ремонт отказавшего контроллера домена и восстановление доменной информации с резервной копии, если ваша база данных имеет размер в несколько сотен мегабайт, и все другие контроллеры домена связаны медленными сетевыми связями. Однако большинство сетевых сценариев находится между этими двумя крайностями. Единственный способ узнать, какой вариант является более быстрым в вашей среде, состоит в тестировании обоих варианта задолго до того, как вам придется делать выбор.

Чтобы восстановить базу данных Active Directory, вы должны иметь хорошую резервную копию контроллера домена. Если потерпит аварию жесткий диск, содержащий только базу данных Active Directory, вы сможете загрузиться в режим восстановления Active Directory и восстановить данные состояния системы. Если потерпит аварию также и системный диск, вы должны починить аппаратные средства, а затем восстановить сервер.
В некоторых случаях вы будете восстанавливать контроллер домена на сервере, который использует другой набор аппаратных средств, чем тот, который был доступен на первоначальном сервере. Хотя вполне возможно восстановить Windows Server 2003 на аппаратных средствах, отличающихся от аппаратных средств сервера, с которого было сделана резервная копия, этот процесс чреват проблемами. Если вы попробуете восстановить Windows Server 2003 на сервере с отличающимися аппаратными средствами, выберите аппаратные средства, которые будут максимально совместимы. Гарантируйте, что уровень аппаратного абстрагирования (hardware abstraction layer — HAL), видеокарты и сетевые платы идентичны. Кроме того, конфигурация жесткого диска на новом сервере должна быть такой же, как на отказавшем. Даже если вы будете соблюдать эти предосторожности, восстановление системы Windows Server 2003 на сервер с другими аппаратными средствами труден, и успех не гарантирован. Возможная альтернатива состоит в создании контроллера домена из резервной копии. В этом случае вы сможете воспользоваться преимуществом чистой инсталляции системы Windows Server 2003, и в то же время сможете создать начальную копию базы данных из резервной копии, а не через репликацию.

Автоматизированное восстановление системы

Один из вариантов резервирования и восстановления в Windows Server 2003 — это автоматизированное восстановление системы (Automated System Recovery — ASR). Эта опция упрощает процесс восстановления данных состояния системы. Прежде чем вы будете использовать ASR, создайте ASR-копию, т.е. помощью инструмента Backup сделайте резервную копию данных состояния системы и создайте загрузочный диск ASR. Загрузочный диск содержит файлы, необходимые для загрузки сервера, а также информацию о конфигурации жесткого диска на сервере и резервную копию состояния системы. Если сервер выйдет из строя, эта ASR-копия может использоваться для частичной автоматизации восстановления сервера.
Если вы сделали какие-либо изменения к Active Directory после создания резервной копии, то они будут отсутствовать в копии. Однако другие контроллеры домена в домене будут иметь самую современную информацию. Если вы восстанавливаете контроллер домена в связи с поломкой сервера, то контроллер домена должен получить изменения от своих партнеров по репликации после того, как закончится восстановление. Для этого сделайте восстановление без полномочий.
Чтобы сделать восстановление без полномочий, выполните следующие действия.
Восстановите отказавший контроллер домена и повторно установите на сервере систему Windows Server 2003. После восстановления сервера перезапустите его и нажмите клавишу F8, чтобы загрузить Windows Advanced Options Menu (Меню дополнительных параметров Windows).

1. Выберите загрузку контроллера домена в режиме восстановления службы каталога Directory Services Restore Mode (Windows Domain Controllers Only) (Только контроллеры домена с системой Windows)). После этого контроллер домена загрузится в безопасном режиме, но не будут загружены компоненты Active Directory.
2. Выберите операционную систему, которую вы хотите запустить.
3. Войдите на сервер, используя учетную запись Administrator с паролем Directory Services Restore (Восстановление службы каталога), который был сконфигурирован на контроллере домена при инсталляции Active Directory.
4. Испсшьзуйте программку создания резервной копии и восстановления системы, чтобы восстановить данные System State (Состояние системы) на сервере.
5. После восстановления данных перезагрузите контроллер домена.
6. После перезагрузки контроллер домена свяжется со своими партнерами по репликации и начнет обновлять собственную базу данных, чтобы отразить все изменения доменной информации, сделанные с момента создания резервной копии.

Примечание. Восстанавливать информацию Active Directory могут только локальные администраторы. Эта учетная запись создается при инсталляции Active Directory на контроллере домена. Пароль для нее конфигурируется в это же время. Пароль может быть переустановлен только через утилиту Ntdsutil.
Выполнение восстановления с полномочиями
В некоторых случаях восстановление без полномочий не годится для решения проблемы, с которой вы имеете дело. Например, если кто-то только что удалил OU, содержащую несколько сотен пользователей, не нужно, чтобы контроллер домена просто перезагрузился после выполнения восстановления, а затем начал репликацию с других контроллеров домена. Если вы так сделаете, то контроллер домена получит информацию об удалении OU от своих партнеров по репликации, и к тому времени, как вы откроете инструмент Active Directory Users And Computers, OU будет удалена снова.
В этом сценарии нужно использовать восстановление с полномочиями для гарантии того, что восстановление OU будет реплицировано на другие контроллеры домена. Когда вы делаете это восстановление, восстанавливается резервная копия Active Directory, которая была сделана до того, как данные были удалены, а затем делаете принудительную
репликацию этих данных на другие контроллеры домена. Принудительная репликация делается путем манипулирования порядковым номером обновления (USN) для восстановленной информации. По умолчанию, когда вы делаете восстановление с полномочиями, номер USN на восстановленных объектах увеличивается на 100000, чтобы восстановленный объект стал полномочной копией для всего домена.

Проблемы восстановления с полномочиями

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

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

Третья проблема имеет отношение к домену и доверительным отношениям компьютеров. Когда к домену добавляется компьютер, на котором выполняется система Microsoft Windows NT, Windows 2000, Windows XP Professional или Windows Server 2003, то создается пароль, известный только контроллеру домена и добавленному компьютеру-члену домена. Этот пароль используется для поддержания доверительных отношений между компьютером и доменом. По умолчанию пароль изменяется каждые семь дней. Если вы выполняете восстановление с полномочиями, то будут восстановлены пароли, которые были в использовании при создании резервной копии. Если компьютер-член домена уже получил другой пароль, то доверительные отношения между доменом и компьютером-членом домена не будут функционировать. Доверительные отношения NTLM между доменами Active Directory и доменами Windows NT используют похожие правила, поэтому они также могут перестать работать, если будет восстановлен старый пароль. Доверительные отношения домена можно восстановить, удаляя старые доверительные отношения и создавая их заново. Доверительные отношения рабочей станции с доменом можно восстановить, используя инструмент командной строки NetDom или удаляя рабочую станцию из домена, а затем добавляя ее назад.

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

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

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

1. Выполните шаги с первого по пятый процедуры восстановления без полномочий; не перезагружайте сервер, когда восстановление закончено.
2. Откройте командную строку и напечатайте ntdsutil.
3. В окне Ntdsutil напечатайте authoritativerestore(восстановление с полномочиями).
4. В окне Authoritative Restore напечатайте restore subtree objectname (восстановление поддерева objectname). Например, чтобы восстановить OU Managers в домене NWTraders.com, нужно напечатать restore subtree ou=managers ou,dc~nwtraders,dc=com. Вы можете также восстановить индивидуальную группу, учетные записи пользователей (например,    restoresubtreeen—managerl,ou—managersou, dc—nwtraders,dc=com) или раздел приложений.
5. Чтобы восстановить с полномочиями весь каталог, напечатайте restoredatabase(восстановить базу данных) в окне команды Authoritative Restore.
6. Выйдите из утилиты Ntdsutil и перезагрузите сервер.

Предостережение. В некоторых случаях потребуется восстановление всей базы данных Active Directory, используя восстановление с полномочиями. Такое восстановление всего каталога — это очень важная операция, она должна выполняться только в тех случаях, когда была разрушена база данных или произошла какая-то другая очень серьезная ошибка. Восстановление с полномочиями всего каталога увеличивает номер USN на каждом объекте в домене и в разделах конфигурации каталога на 100000. Раздел схемы не может быть восстановлен такими образом.
Восстановление информации Sysvol
До настоящего момента эта глава была посвящена восстановлению базы данных Active Directory, содержащей учетные записи и параметры настройки для домена или леса. Однако папка Sysvol на каждом контроллере домена тоже содержит критическую информацию, касающуюся домена, такую как шаблоны групповых политик и сценарии, используемые компьютерами или пользователями в сети. Поэтому восстановление информации Sysvol может быть столь же важным, как и восстановление базы данных Active Directory.

Резервная копия папки Sysvol создается как часть информации о состоянии системы, касающейся контроллера домена, т.е. если контроллер домена выйдет из строя, то информация Sysvol может быть восстановлена как часть обычного процесса восстановления контроллера
домена. Кроме того, если вы не хотите восстанавливать контроллер домена, а только восстановить его функциональные возможности, создавая другой контроллер домена в домене, то информация Sysvol будет реплицироваться с любых существующих контроллеров домена. Это происходит при помощи службы репликации файлов (File Replication Service — FRS), а не в процессе репликации Active Directory.

Потенциально может возникнуть одно осложнение, если вам надо выполнить восстановление с полномочиями для контейнера Sysvol. Например, если кто-то удалил все сценарии входа в систему, находившиеся в папке Sysvol, вы захотите восстановить сценарии, вместо того чтобы заново создавать их. Проблема состоит в том, что, если удаление было реплицировано на все другие контроллеры домена, то оно будет иметь более довременное репликационное значение, чем на восстановленном контроллере домена. Поэтому если вы выполните просто обычное восстановление контроллера домена, то он реплицирует удаление с другого контроллера домена. Решение проблемы состоит в том, чтобы выполнить основное (primary) восстановление информации Sysvol. Если вы используете системную резервную копию сервера Windows Server 2003 и программу восстановления, то будет выполняться обычное восстановление без полномочий, но при выполнении программы восстановления не следует принимать заданные по умолчанию параметры настройки восстановления. Вместо этого в окне Advanced Restore Options (Дополнительные опции восстановления) мастера восстановления выберите опцию When Restoring Replicated Data Sets, Mark The Restored Data As The Primary Data For All Replicas (При восстановлении наборов реплициру-емых данных отмечать восстановленные данные как основные для всех реплик) (см. рис. 15-3). В результате папка Sysvol на этом контроллере домена будет отмечена, как основной контейнер для репликации Sysvol.

Рис. 15-3. Выполнение основного восстановления для Sysvol информации

Восстановление хозяев операций и серверов глобального каталога

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

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

Планирование.Из-за важности ролей, которые играют серверы-хозяева операций в сети, вы должны тщательно планировать размещение и управление этими ролями. Хозяин операций должен всегда включаться в регулярный режим резервного копирования. Он должен быть расположен в том же самом сайте, где находится, по крайней мере, один контроллер домена, содержащий информацию, имеющуюся у хозяина операций.
Например, если пользователь только что изменил свой пароль, используя клиента низкого уровня, то это изменение было сделано на эмуляторе PDC. Эмулятор PDC будет реплицировать это
изменение партнеру по репликации, расположенному в том же самом сайте, в пределах 15 секунд. Если в этом сайте нет партнера по репликации, то репликация пароля не произойдет до следующей запланированной репликации между сайтами. Если контроллер домена выйдет из строя перед этим запланированным временем, то изменение пароля не будет реплицироваться на другие сайты. Если контроллер домена находится там же, где сервер хозяина операций, то вероятность неполной репликации гораздо меньше. Контроллер домена, находящийся в том же сайте, где расположен хозяин операций, является также наилучшим кандидатом на захват роли хозяина операций, потому что он имеет самую свежую информацию от хозяина операций. Если у вас имеется больше одного дополнительного контроллера долена в том же самом сайте, где расположен отказавший хозяин операций, то вы можете использовать команду repadmin/ showvectornamingcontext, чтобы определить, какой из контроллеров домена имеет самые свежие обновления с вышедшего из строя контроллера домена.
Чтобы захватить роли хозяина операций, вы можете использовать утилиту Ntdsutil или инструмент Active Directory Users And Computers (чтобы захватить роли эмулятора PDC и хозяина инфраструктуры). Роли хозяина RID, хозяина схемы и хозяина именования доменов можно захватить только с помощью утилиты Ntdsutil.

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

1. Откройте командную строку и напечатайте ntdsutil.
2. В окне команд Ntdsui^l напечатайте roles(роли).
3. В окне койанд Fsmo Maintenance (Обслуживание Fsmo) напечатайте connections(подключения).
4. В окне команд Server Connections (Подключения сервера) напечатайте connecttoserverservername.domainname(соединиться с сервером servername.domainname), где servername— контроллер домена, на котором вы хотите захватить роль хозяина операций. Напечатайте quit(выход).
5. В окне команд Fsmo Maintenance напечатайте seizeoperations_master_role(захватить роль хозяина операций). Где operations_master_role— это роли, которые вы хотите захватить: schemamaster(хозяин схемы), domainnamingmaster(хозяин именования доменов), infrastructuremaster(хозяин инфраструктуры), RID—master(хозяин RID) или PDC.
6. Примите предупреждение. Сервер сначала будет пробовать выполнить нормальную передачу роли хозяина операций. Если это не получится, потому что с вышедшим из строя контроллером домена нельзя войти в контакт, то роль будет захвачена. На рисунке 15-4 смотрите пример захвата роли хозяина RID.

Рис. 15-4. Вывод утилиты Ntdsutil при захвате роли хозяина RID

1. Напечатайте quit(выход) в каждой командной строке, пока не выйдете из утилиты Ntdsutil.

Эмулятор PDC и роль хозяина инфраструктуры могут быть захвачены также через инструмент администрирования Active Directory Users And Computers. Откройте инструмент Active Directory Users And Computers и используйте опцию Connect To Domain Controller (Подключиться к контроллеру домена), чтобы удостовериться, что он связан с контроллером домена, на котором вы хотите захватить роль. Затем щелкните правой кнопкой мыши на имени домена и выберите Operations Masters (Хозяева операций). Если вы попробуете захватить роль, получите предупреждающее сообщение (см. рис. 15-5). Если вы выберите вынужденную передачу, то роль хозяина операций будет захвачена. Только эмулятор PDC и роль хозяина инфраструктуры могут быть захвачены таким образом, т.е. попытки передать любую другую роль хозяина операций с помощью другого инструмента, кроме утилиты Ntdsutil, потерпят неудачу.

Рис. 15-5. Предупреждающее сообщение, полученное при захвате роли хозяина операций через инструмент Active Directory Users And Computers

Эмулятор PDC

В большинстве сетей отказ эмулятора PDC обычно вызывает немедленный отклик, чем отказ любого другого хозяина операций. В домене, который работает на функциональных уровнях Windows 2000 mixed (смешанный) или Windows Server 2003 interim (временный), эмулятор PDC является основным (primary) партнером по репликации для всех резервных копий контроллеров домена Windows NT (BDC). Пока не восстановлен эмулятор PDC BDC-контроллеры не будет получать модифицированную информацию. Кроме того, низкоуровневые клиенты типа Windows NT, Windows 95 и Windows 98 (не имеющие клиентов службы каталога) должны соединяться с эмулятором PDC, чтобы пользователь имел возможность изменять свой пароль. Даже в домене, работающем на функциональном уровне Windows 2000 native (естественный) или на более высоком, эмулятор PDC играет роль основного партнера по репликации для замен пароля. Эмулятор PDC является также предпочтительным сервером для создания каких-либо изменений к групповым политикам. Если эмулятор PDC недоступен, когда вы пытаетесь просмотреть групповые политики, вы получите предупреждающее сообщение. Поскольку эмулятор PDC поддерживает все эти службы, то восстановление роли эмулятора PDC в сети должно иметь высокий приоритет.

Хотя эмулятор PDC играет важнейшую роль в домене, захват этой роли другим контроллером домена, в то время как оригинальный эмулятор PDC недоступен, имеет свои ограничения. Фактически, захват этой роли подобен захвату роли PDC в домене Windows NT. Если PDC когда-либо выходил из строя в домене Windows NT, вы могли выбирать другой контроллер домена и конфигурировать его так, чтобы он был PDC-koh-троллером. Те же самые функциональные возможности существуют в Windows Server 2003. Если эмулятор PDC выходит из строя, вы должны передать эту роль на другой контроллер домена. Даже если контроллер домена будет недоступен только в течение пары часов, все равно нужно передать эту роль. Когда оригинальный эмулятор PDC будет восстановлен и снова связан с сетью, он обнаружит присутствие нового эмулятора PDC и уступит ему эту роль.

Хозяин схемы

Хозяин схемы играет важнейшую роль в домене сервера Windows Server 2003, но эта роль используется очень редко. Хозяин схемы является единственным контроллером домена, в котором может быть изменена схема. Если этот сервер выйдет из строя, вы не сможете делать изменения к схеме, пока сервер не будет восстановлен или пока эта роль не будет захвачена другим контроллером  домена.
Функциональные возможности хозяина схемы используются редко, потому что в большинстве сетей схема изменяется редко. Требуется проводить испытание для гарантии того, что изменение схемы совместимо с текущей схемой. Это означает, что изменение схемы было запланировано
на определенное время, и в большинстве случаев задержка в развертывании изменений схемы до того времени, пока не будет восстановлен хозяин схемы, не должна вызывать проблем. Однако если вы не планируете восстанавливать хозяина схемы, можно захватить эту роль другим контроллером домена, используя утилиту Ntdsutil. Если вы захватываете роль хозяина схемы другим контроллер домена, то первоначальный хозяин схемы более не должен восстанавливаться в сети.

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

Хозяин именования доменов

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

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

Хозяин инфраструктуры

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

Хозяин RID

Хозяин RID — это хозяин операций уровня домена, который назначает RID-пулы другим контроллерам домена по мере создания новых участников безопасности. Если хозяин RID недоступен в течение длительного периода времени, то у контроллеров домена могут закончиться относительные идентификаторы RID, необходимые для назначения их новым участникам безопасности. Каждый раз, когда у контроллера домена заканчиваются свободные идентификаторы RID, он запрашивает дополнительные пулы идентификаторов RID у хозяина RID. Затем хозяин RID выдает дополнительный пул, состоящий из 512 идентификаторов RID. Если хозяин RID недоступен, то контроллер домена не разрешит создание новых участников безопасности, пока не получит дополнительные идентификаторы RID у хозяина RID. Хозяин RID важен и при перемещении участников безопасности между доменами. В этом случае, если хозяин RID недоступен, то перемещение учетных записей немедленно потерпит неудачу.
Если ваш контроллер домена, являющийся хозяином RID выходит из строя, вы должны решить, нужно ли вам захватывать эту роль, передавая ее другому серверу. Если вам требуется создать большое количество участников безопасности или перемещать пользователей между доменами, прежде чем восстановится хозяин RID, то вы должны захватить эту роль. Кроме того, если не планируется восстанавливать ориги-
нального хозяина RID, вы также должны захватить эту роль. Если вы решите захватить роль хозяина RID, то оригинальный хозяин RID не должен возвращаться в интерактивный режим из-за потенциальной возможности выдачи дублирующих идентификаторов защиты (SID).

GC-серверы

Серверы глобального каталога (GC) также требуют некоторого дополнительного планирования для восстановления их в случае сбоя, несмотря на то, что нет никаких специальных требований для создания их резервных копий. Единственная проблема, о которой вы должны позаботиться, состоит в том, что для нескольких доменов леса база данных каталога на GC-сервере будет значительно больше, чем база данных на других контроллерах домена. Если вы решите восстанавливать GC-сервер, восстанавливая базу данных на контроллере домена, то сервер будет автоматически сконфигурирован как GC-сервер. Если вы решите восстанавливать функциональные возможности Active Directory, назначая другой сервер контроллером домена, вы должны сконфигурировать этот сервер как GC-сервер.
Наличие GC-сервера в сети является критическим для обслуживания входа в систему клиентов в домене, работающем на функциональном уровне Windows 2000 native (или на более высоком) или при использовании основных имен пользователя (UPN). Наличие GC-сервера критично, если вы развернули Microsoft Exchange Server 2000. В этом случае вам придется сконфигурировать дополнительные GC-серверы в этом месте, пока не воссоздадите отказавший контроллер домена. Например, если выйдет из строя единственный GC-сервер, расположенный в сайте, где у вас работает Exchange Server 2000, то вам придется сконфигурировать один из других контроллеров домена, расположенных в том же сайте, как GC-сервер, и восстановить как можно быстрее отсутствующие функциональные возможности.

Когда я был маленьким, я хорошо знал, кем хочу стать, когда вырасту. Нет, не космонавтом. И не врачом, и не юристом. Я мечтал стать менеджером по продукту инструмента резервирования и восстановления Active Directory.

Шутка. Я был уверен, что стану трансформером.

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

Так в самом деле, почему?

Если кто не знает, Microsoft Active Directory является основной службой аутентификации, используемой большинством организаций по всему миру. То есть это критически важная инфраструктура.

Резервирование и восстановление в Active Directory. К счастью, мне никогда не приходилось непосредственно присутствовать при катастрофическом падении критически важной части инфраструктуры, такой как Active Directory. Тем не менее, имея доступ в Интернет, можно почитать мнения довольно умных людей, которые оценивают убытки бизнеса, являющиеся прямым следствием такого рода сбоев, в среднем от 25 000 до 300 000 долларов в час.

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

Да-да, существуют разные типы сценариев восстановления Active Directory! Мне нравится делить их на пять категорий: восстановление объектов, восстановление атрибутов, восстановление сервера, восстановление домена и восстановление леса.

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

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

Восстановление сервера или восстановление контроллера домена Active Directory должно быть относительно простой задачей для организации, имеющей более-менее приличный опыт в сфере IT. Даже если не принимать во внимание тот факт, что в организации чаще всего имеется отлаженное решение по резервному копированию серверов, процесс восстановления после физической или логической потери контроллера домена (при наличии в домене нескольких контроллеров) достаточно прост: отремонтировать сервер и восстановить его из существующей резервной копии, либо полностью заменить сервер и выполнить процесс замены контроллера.

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

Если Вы уже столкнулись с проблемой и наткнулись на эту заметку, ища в Интернете простой способ восстановления после нежелательных изменений в Active Directory в результате случайного или злонамеренного действия, Вам также стоит обратить внимание на StealthRECOVER.

Резервирование и восстановление в Active Directory. Восстановление объектов Active Directory

Примечание: Для данной статьи будем считать, что в домене не была включена корзина Active Directory (Active Directory Recycle Bin). Корзина AD и её влияние на восстановление объектов будут рассмотрены в далее.

Когда какой-либо объект удаляется из Active Directory, он на самом деле не удаляется, по крайней мере, не сразу.

И это не какое-то там особое свойство, а следствие того, как реализована репликация с несколькими главными серверами, применяемая в Active Directory. Такой вариант репликации позволяет любому контроллеру домена создавать или обновлять объект, а затем реплицировать эти изменения на другие контроллеры домена.

Для того, чтобы рассмотреть, что же на самом деле происходит при удалении объекта, давайте воспользуемся утилитой LDP. И поможет нам в этом мистер Delete Q. Me, демонстрационная учётная запись пользователя, любезно созданная моим любимым PowerShell-скриптом.

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

Извини, приятель.

Ну а теперь, когда его не стало, у нас могут возникнуть трудности с поиском нашей мёртвой, но всё ещё не исчезнувшей учётной записи. LDP нужно немного подшаманить, чтобы он стал показывать удалённые объекты. Откроем меню «Options» и выберем пункт «Controls». В диалоговом окне «Controls» откроем выпадающий список «Load Predefined», выберем «Return deleted objects» и нажмём кнопку «OK».

Теперь в корне нашего раздела каталога стал виден контейнер «Deleted Objects». Мы можем развернуть его и поискать наш недавно умерший пользовательский объект.

А вот и он! А теперь давайте коротко разберём, что же произошло в каталоге в результате удаления объекта пользователя:

1. Объект был перемещён.
   Конечно, Вы обратили внимание, что для того, чтобы найти объект удалённого пользователя, нам пришлось перейти в другое место. У каждого раздела каталога есть свой собственный контейнер «Deleted Objects». Ну, на самом деле не совсем так. У раздела «Schema» нет своего контейнера «Deleted Objects», поскольку удалять объекты из схемы данных каталога нельзя. Как Вы, наверное, уже догадались, предназначение контейнера «Deleted Objects» — хранить удалённые объекты. Active Directory скрывает эти контейнеры, пока Вы их специально не запросите, это Вы тоже уже заметили.
2. Объект был переименован.
   Имя объекта обновляется с использованием хитроумного шаблона: Common-NameADEL:Object-Guid. Такая схема именования гарантирует уникальность имён объектов даже когда будут удалены несколько объектов с совпадающим относительным уникальным именем.
3. У объекта появилось несколько новых атрибутов.
   Теперь у нашей старой знакомой учётки три новых атрибута. Первый из них — isDeleted. Если значение этого атрибута «TRUE», значит объект был отмечен для удаления. Следующий новый атрибут — isRecycled. Этот атрибут был добавлен и ему назначено значение только потому, что функциональный уровень данного домена выше, чем Windows 2008. Иначе добавление этого атрибута не имело бы смысла, поскольку в более ранних версиях функционал доменной корзины просто отсутствовал. Наконец, ещё один новый атрибут — lastKnownParent, содержащий уникальное имя последней известной родительской записи для нашего объекта пользователя (оно нам пригодится буквально через пару минут).
4. Множество атрибутов было удалено.
   При удалении объекта сохраняются только важные атрибуты. Атрибуты, не имеющие флага поиска 0x8 ( PRESERVE_ON_DELETE ), удаляются, так как предполагается, что они больше не нужны. В связи с тем, что я не модифицировал схему данных своего домена так, чтобы по умолчанию иметь возможность сохранить большее количество атрибутов (поскольку это не очень хорошая идея), мой пользовательский объект утратил большинство своих атрибутов вместе со связанными с ними значениями.

Получившийся в итоге объект называют «надгробным камнем» («tombstone»). И последнее, что мы попробуем в рамках этой демонстрации — »реанимировать» его. Это не шутки, а вполне официальные технические термины.

Так или иначе, мы можем полностью реанимировать наш «надгробный камень» утилитой LDP, используя ее функцию Modify:

1. Щёлкните правой кнопкой мыши по «камню» и выберите пункт меню «Modify».
2. В секции «Edit Entry» в поле «Attribute» введите значение «isDeleted», установите переключатель в секции «Operation» в значение «Delete», и нажмите кнопку «Enter» для добавления сведений об операции в список «Entry List».
3. В секции «Edit Entry» в поле «Attribute» введите значение «distinguishedName», в поле «Values» введите уникальное имя объекта, которое было у него до удаления, установите переключатель в секции «Operation» в значение «Replace», и нажмите кнопку «Enter» для добавления сведений об операции в список «Entry List».
   Помните, я говорил, что атрибут lastKnownParent может оказаться полезным? Так вот, если Вы не знаете, какое же DN было у объекта до удаления, можно попробовать такой трюк: возьмите текущее DN объекта и замените нуль-символ («A») и всё, что справа от него, на значение атрибута lastKnownParent.
4. Выберите пункт «Extended» в левом нижнем углу панели.
5. Нажмите кнопку «Run».

После нажатия кнопки «Run» мы можем найти вновь реанимированный объект и посмотреть, как он выглядит.

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

Обойти проблему потери большинства полезных атрибутов можно, делая регулярные VSS-снапшоты Active Directory. При использовании данного метода, если Вам необходимо восстановить удалённый объект, Вы можете просто найти резервную копию, сделанную до удаления этого объекта, смонтировать снапшот с помощью NTDSUTIL, подключиться к смонтированному снапшоту с помощью LDAP-утилиты, найти объект, экспортировать его в… Ладно, не забивайте себе голову.

Но подождите, тут есть ещё один гадкий момент.

Объекты в контейнере «Deleted Objects» не вечны. Метко названное свойство tombstoneLifetime («время жизни надгробного камня») объекта CN=Directory Service,CN=Windows NT,CN-Services,CN=Configuration,ForestDistinguishedName определяет количество дней до того момента, как удалённый объект будет навсегда удалён из Active Directory.

Значение свойства tombstoneLifetime основывается на версии Windows Server, с помощью которого был создан лес используемого нами домена. В лесах, созданных с использованием Windows Server выше версии 2003, по умолчанию установлено значение 180 дней (текущий рекомендуемый параметр Microsoft). В более старых версиях значение по умолчанию — 60 дней. Обработка значения свойства tombstoneLifetime — то, на что действительно стоит обратить внимание. Если свойство существует, время жизни надгробного камня будет соответствовать заданному в нём значению. Но только в том случае, если это значение не меньше, чем 2. А если меньше, то по умолчанию время жизни будет 60 дней (для Windows Server от 2000 до 2008) или 2 дня (Windows Server 2008 R2 или выше). Если значение свойства не задано, то время жизни будет 60 дней.

Если Вам интересно, каково значение tombstoneLifetime в Вашем окружении, данный PowerShell-скрипт выдаст его Вам (для его работы требуются инструменты AD DS и AD LDS):

(Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties *).tombstoneLifetime

Как только объект провёл в контейнере «Deleted Objects» количество дней, равное значению tombstoneLifetime, он логически удаляется сборщиком мусора Active Directory. В этот момент он уходит от нас навсегда и восстановлению больше не подлежит.

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

Восстановление объектов Active Directory с использованием корзины

Выше мы обсуждали прелести восстановления объектов Active Directory в окружении без корзины AD (AD Recycle Bin). Если Вы пропустили этот пост, я настоятельно рекомендую Вам вернуться и прочитать его, поскольку это, пожалуй, самый замечательный пост в блоге, который я когда-либо писал о восстановлении объектов Active Directory в среде без корзины AD. Если коротко, при удалении объекта Active Directory в домене без корзины он становится «надгробным камнем». Этот объект, лишённый большинства своих атрибутов, затем находится в контейнере «Deleted Objects» раздела Active Directory на время, установленное в параметре tombstoneLifetime домена. В течение этого периода объект технически поддаётся восстановлению, но его утраченные атрибуты в общем случае можно считать невосстановимыми. При превышении «надгробным камнем» времени tombstoneLifetime сборщик мусора отправит объект в небытие. Совсем коротко этот процесс выглядит так:

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

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

Объекты в этом новом восстанавливаемом состоянии называются «удалёнными объектами» («deleted object»), а период времени, в течение которого они сохраняют свои атрибуты, определяется в новом атрибуте msDS-DeletedObjectLifetime. При включении корзины AD значение атрибута msDS-DeletedObjectLifetime по умолчанию соответствует значению атрибута tombstoneLifetime. Если значение атрибута msDS-deletedObjectLifetime является нулевым, либо этот атрибут вообще отсутствует, его значение интерпретируется как эквивалентное значению атрибута tombstoneLifetime. Если также отсутствует и значение tombstoneLifetime, то оба они по умолчанию считаются равными 60 дням.

Если время пребывания объекта в статусе «удалённый объект» превышает период, указанный в msDS-DeletedObjectLifetime, то объект отправляется на переработку. Переработанный объект («recycled object») подозрительно похож на «надгробный камень» у которого появился атрибут isRecycled, установленный в TRUE. Как и у «надгробного камня» большинство из его атрибутов удаляются, и он присутствует в Active Directory в течение времени tombstoneLifetime, после чего зачищается сборщиком мусора Active Directory.

Упрощённо жизненный цикл удалённого объекта при включённой корзине AD выглядит так:

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

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

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

Итак, в результате удаления объекта произошли следующие изменения:

1. Объект был перемещён.
   Как и в нашем предыдущем эксперименте без использования корзины, объект был перемещён в контейнер «Deleted Objects» раздела каталога.
2. Объект был переименован.
   Как и в прошлый раз, имя объекта было обновлено по тому же шаблону Common-NameADEL:Object-Guid.
3. У объекта появилось несколько новых атрибутов.
   И снова у нас появился атрибут isDeleted со значением TRUE, а также соответствующим образом заполненный атрибут lastKnownParent с (хотя в данном случае он уже был заполнен в результате удаления и восстановления объекта, которое мы проводили в прошлом эксперименте). Новый атрибут msDS-LastKnownRDN заполняется последним относительным уникальным именем (RDN) объекта. Этот атрибут позволяет корзине AD правильно переназначить RDN объекта при его восстановлении даже в том случае, если переименование объекта привело к усечению его исходного RDN.
4. Два атрибута были удалены.
   Благодаря корзине AD, было утрачено только два атрибута: objectCategory и sAMAccountType. Фактически, при удалении объекта эти два атрибута всегда удаляются из него, независимо от работы корзины или наличия флага поиска 0x8 ( PRESERVE_ON_DELETE ). При восстановлении объекта значение атрибута objectCategory автоматически устанавливается в наиболее подходящее для объектного класса (атрибут objectClass) данного объекта, а значение sAMAccountType вычисляется на основании либо значения атрибута userAccountControl (для объектов пользователей), либо значения атрибута groupType (для объектов групп).
   Внимательные читатели могут также отметить, что на приведённом скриншоте нет ещё и атрибутов manager и memberOf. На самом деле они просто прячутся. Оба этих типа атрибута имеют так называемые ссылочные значения (то есть они содержат ссылки на другие объекты), и LDAP не возвращает деактивированные ссылки, если не был задан элемент управления с говорящим названием «Return Deactivated Links». Если бы я включил этот элемент управления, атрибуты и их значения были бы видны на моём скриншоте, но тогда я бы упустил случай упомянуть об этом поучительном моменте.

Перейдём к процессу восстановления объекта корзины AD. Хотя выгод от корзины AD довольно много, изначально работа с ней была затруднена тем, что её было относительно сложно использовать. До Windows Server 2012 для просмотра содержимого корзины требовалось использовать инструмент LDAP или PowerShell. Например, вот такой PowerShell-запрос возвращает всё удалённые объекты в домене:

Get-ADObject -filter 'isDeleted -eq $true -and name -ne "Deleted Objects"' -includeDeletedObjects

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

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

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

Restore-ADObject -Identity '562f229c-e03a-4005-a098-10046e9b8942'

Для указания объекта, который я пытаюсь восстановить, задаю его идентификатор ObjectGUID в параметре Identity. Можно было бы поступить и по-другому: напрямую передать результаты запроса Get-ADObject через конвейер командлету Restore-ADObject.

В этом была своя прелесть: если бы корзину AD не было так сложно использовать, было бы труднее проникнуться всей полнотой её полезности. К счастью, после получения Microsoft множества недовольных отзывов от сообщества пользователей, они упростили работу, добавив в Windows Server 2012 функционал корзины в Центр администрирования Active Directory (Active Directory Administrative Center, ADAC).

Давайте заглянем в контейнер «Deleted Objects» с помощью ADAC:

Как видите, те же четыре объекта, которые вернул мой PowerShell-запрос, представлены в гораздо более дружественном для пользователя интерфейсе. Также имеется возможность простой генерации фильтров для ограничения количества отображаемых пользователю объектов, а в списке задач (Tasks) правой части окна предусмотрен пункт Restore. Сейчас я по нему кликну, а затем снова зайду в LDP, чтобы посмотреть на наш свежевосстановленный объект.

Здорово, правда?

Однако перед тем, как все побегут включать корзину Active Directory, необходимо предупредить о непосредственных и потенциально вредных последствиях этого шага:

1. Включение корзины Active Directory влечёт за собой изменение схемы данных каталога.
   В результате такого изменения схемы становится невозможно отключить корзину, не прибегая к полному восстановлению леса. Другими словами, если Вы включите корзину, отключить её Вы уже не сможете.
2. Active Directory станет немного больше.
   После включения корзины AD удалённые объекты сохранят все свои атрибуты до истечения срока своего пребывания в статусе «удалённый объект». И вообще, время нахождения объекта в каталоге увеличится вдвое (на период пребывания в статусе «надгробного камня»). За счёт обоих этих факторов Active Directory будет использовать немного больше дискового пространства, чем раньше.
3. Корзина не может работать ретроспективно.
   Из этого есть очень серьёзное следствие: в момент включения корзины AD все «надгробные камни» в лесу перестают существовать. Если Вы злорадны, можете поискать в Интернете «удалённые объекты, исчезнувшие после включения корзины». Для весьма немалого количества людей знания об этом конкретном следствии стало запоздалым и неприятным откровением.

Хотя мы и должны были об этом предупредить, ни одна из этих проблем не является настолько серьёзной, чтобы перевесить преимущества от включения корзины AD. Но мы также должны отметить, что StealthRECOVER работает как с включённой, так и не с включённой корзиной Active Directory, и предоставляет дополнительный уровень защиты за счёт способности восстанавливать из резервных копий объекты, которые превысили период mdDS-DeletedObjectLifetime своего леса, и более не могут быть восстановлены с помощью корзины AD.

Выполнение отката значений и восстановления атрибутов объекта Active Directory

В начале истории перед нами возникает ещё не набивший достаточного количества шишек IT-специалист, недавно взявшийся за изучение PowerShell. Заметив, что в большинстве учётных записей пользователей домена нет никакой информации о почтовом адресе, наш главный герой быстро приходит к пониманию, что у него есть прекрасная возможность использовать свои зарождающиеся сверхспособности в области написания сценариев.

Затем наш герой решает, что наилучшим решением в данной ситуации будет сначала идентифицировать все учётки, у которых отсутствуют атрибуты адреса, а затем обновить эти объекты, указав в незаполненных атрибутах почтовый адрес главного офиса их организации. Это всё-таки лучше, чем ничего, верно? Усилия нашего героя вылились в следующий скрипт:

Get-ADUser -Filter {streetAddress -ne '*'} | Set-ADUser -streetAddress '123 Main Street' -l 'Madison' -st 'Wisconsin' -postalCode '53701'

К несчастью для нашего вундеркинда PowerShell, используемый в фильтре оператор -ne является оператором равенства. Эта невинная оплошность вкупе с необъяснимой беспечностью, в результате которой скрипт не был протестирован (впрочем, необходимой, чтобы наш поучительный пример имел хоть какой-то шанс) привели к созданию сценария PowerShell, применимого лишь для обновления всех адресных атрибутов в каждом объекте пользователя в домене, у которого значение атрибута streetAddress явно не соответствует символу «звёздочка».

Да, неловко получилось…

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

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

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

Поскольку Active Directory не ведёт хронологическую запись значений атрибутов объекта, первым шагом на пути к решению этой проблемы будет найти что-то, что делает это. К счастью, в инструментах создания резервных копий Active Directory недостатка нет.

Один из вариантов — использовать инструмент Microsoft’s Windows Server Backup («WBADMIN»). При инсталляции функционала резервного копирования Windows Server (Windows Server Backup) будет установлен инструмент командной строки wbadmin.exe. Кроме того, станут доступны командлеты Windows PowerShell для Windows Server Backup, а также MMC-оснастка Windows Server Backup.

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

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

Ничего не мешает сделать batch-скрипт, который будет создавать внутри заданного UNC-пути папку с именем, сформированным на основе текущей даты в формате YYYYMMDD, а затем выполнять в эту папку резервирование файла Active Directory ntds.dit с помощью команды START BACKUP инструмента WBADMIN:

@echo off
set backupRoot=\FILESHARENtdsBackups
set backupFolder=%date:~-4,4%%date:~-10,2%%date:~7,2%
set backupPath=%backupRoot%%backupFolder%
mkdir %backupPath%
wbadmin start backup -backuptarget:%backupPath% -include:C:WindowsNTDSntds.dit -quiet

В результате такой операции вы получите VSS-снапшот (Volume Shadow Copy Service) файла ntds.dit. Из недостатков данного подхода можно отметить то, что в результате создаётся файл, по размерам значительно превышающий исходные файлы: в моей лаборатории ntds.dit занимает 20 Мбайт, а полученный снапшот гораздо больше 20 Мбайт. В лабораторных условиях это не имеет принципиального значения, но в производственной среде может приводить к значительному расходу дискового пространства.

Другой вариант решения от Microsoft — NTDSUTIL.exe, утилита командной строки для доступа и управления базой данных Windows Active Directory. NTDSUTIL — экстремально мощный инструмент, и Ваше рабочее окружение — неподходящее место для изучения его возможностей. Набор полезных команд его невероятно широк, но в рамках данной заметки нас интересует команда SNAPSHOT, которая фиксирует состояние Active Directory на момент создания снапшота:

Большим недостатком данного подхода является то, что NDTSUTIL записывает резервные копии на тот же том, где размещается Active Directory, что не идеально.

Эти два варианта далеко не единственные, но с их помощью мы уже получили множество резервных копий на выбор для выполнения восстановления. Пришла пора открыть их и заглянуть внутрь. Для того чтобы сделать это мы воспользуемся инструментом Active Directory Domain Services Database Mounting Tool («DSAMAIN»). DSAMAIN позволяет монтировать файлы ntds.dit, прячущиеся в наших резервных копиях, после чего мы можем исследовать их с помощью LDAP.

Начнём с одного из VHD-образов, созданных WBADMIN. В первую очередь нужно найти один из наших VHD, смонтировать его и назначить буквенный идентификатор диска его первичному разделу.

Затем нам нужно определить путь к файлу ntds.dit в смонтированной резервной копии, открыть командную строку с правами администратора и выполнить следующую команду для монтирования этого файла ntds.dit:

dsamain -dbpath "E:WindowsNTDSntds.dit" -ldapport 10389

При закрытии окна командной строки DSAMAIN остановится, так что не закрывайте её пока не закончите процедуру восстановления.

А теперь, когда мы подключили каталог из резервной копии WBADMIN, смонтируем снимок, сделанный NTDSUTIL. Для этого откроем ещё один экземпляр командной строки с правами администратора и с помощью команды snapshot утилиты ntdsutil сначала просмотрим список наших резервных копий, смонтируем одну из них и скопируем путь к диску, назначенный утилитой NTDSUTIL.

Затем нам нужно найти путь к файлу ntds.dit внутри пути, назначенного NTDSUTIL, открыть ещё один экземпляр командной строки с правами администратора и с помощью следующей команды смонтировать нужный нам файл ntds.dit:

dsamain -dbpath "C:$SNAP_201903261110_VOLUMEC$WindowsNTDSntds.dit" -ldapport 20389

Смонтировав две разных резервных копии, можно приступать к экспериментам. Я поменял значение атрибута Description моего старого товарища — тестовой учётной записи Delete Q. Me.

Открыв PowerShell, мы можем с помощью командлета Get-ADUser взглянуть на нашего тестового пользователя. По умолчанию Active Directory ожидает подключения на порту 389. Вы наверняка обратили внимание, что смонтированные нами резервные копии ожидают соединения на портах 10389 и 20389. С помощью дополнительного параметра Server мы можем посмотреть как наш тестовый пользователь выглядит в живом каталоге и в обеих наших смонтированных резервных копиях.

Как видите, текущее значение атрибута Description — »Oops», а в обеих резервных копиях содержится предыдущее значение — »Demo User Account».

Мы можем использовать тот же PowerShell-командлет Get-ADUser так, чтобы с его помощью получить данные для восстановления нужного нам атрибута до значения, найденного в наших резервных копиях. Если мы получим копию объекта из одной из смонтированных резервных копий, мы можем использовать значение атрибута из неё для восстановления значения атрибута живого объекта:

$UserBackup = Get-ADUser -Identity dqme -Properties Description -Server dc01:10389
Set-ADUser -Identity dqme -Description $UserBackup.Description -Server dc01:389

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

Как видите, всё не так плохо. Однако, необходимо отметить, что это было всё-таки лабораторное упражнение, затронувшее только один конкретный изменённый атрибут в одном конкретном объекте. Также нам было известно, в какой резервной копии находится информация, требуемая для операции восстановления. В реальном сценарии восстановления этот процесс может оказаться крайне непростым, особенно когда нужно всё делать в сжатые сроки. Данный сценарий восстановления — тот самый случай, когда инструмент типа StealthRECOVER может принести очень много пользы. Он позволяет делать снапшоты Active Directory по заданному расписанию, искать изменения среди множества снапшотов, и откатывать изменения на уровне объекта в целом или на уровне атрибута.

Резервирование и восстановление объектов групповых политик (GPO)

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

Резервное копирование и восстановление объектов групповых политик

Перед тем, как погрузиться в резервирование и восстановление объектов групповых политик (Group Policy Object, GPO), давайте, по сложившейся в этой серии заметок традиции, немного отвлечёмся, разбавив повествование некоторой справочной информацией об этих самых объектах групповой политики.

Создание объекта групповой политики в домене — сфера ответственности контроллера домена Active Directory с FSMO-ролью (Flexible Single Master Operator) эмулятора основного контроллера домена (PDC Emulator). В домене Windows NT было разрешено существование только одного доменного контроллера с возможностью записи данных, он назывался основным контроллером домена (Primary Domain Controller или PDC). Это было следствием архитектуры репликации Windows NT с единственным главным сервером. В противовес этому, Active Directory использует архитектуру с несколькими главными серверами, в которой все доменные контроллеры могут иметь возможность записи данных. Роль эмулятора PDC в Active Directory была разработана как часть стратегии упрощения миграции доменов Windows NT в Active Directory.

Эмулятор PDC имитирует поведение основного контроллера домена Windows NT как единственного главного сервера, делая его идеально подходящим для выполнения определённых функций, таких как минимизация возможности добавления конфликтующих GPO. Он также выполняет ряд столь же важных функций в домене: служит авторитетным источником для синхронизации времени и отвечает за фиксацию и репликацию особенно важной информации, например, при смене пароля.

При создании нового объекта групповой политики эмулятор PDC назначает идентификатор GUID, который используется для именования каждого из двух компонентов, составляющих объект групповой политики. Это гарантирует, что каждый объект групповой политики может быть уникально идентифицирован. Кроме того, это помогает защитить две групповые политики по умолчанию: Политику домена по умолчанию (Default Domain Policy) и Политику контроллеров домена по умолчанию (Default Domain Controllers Policy). Обе они именуются с использованием общеизвестных идентификаторов GUID: Политика домена по умолчанию всегда {31B2F340-016D-11D2-945F-00C04FB984F9}, а Политика контроллеров домена по умолчанию всегда {6AC1786C-016F-11D2-945F-00C04fB984F9}.

Первый компонент объекта групповой политики — шаблон групповой политики (Group Policy Template, GPT), состоящий из набора директорий внутри общей папки SYSVOL («C:WindowsSYSVOLdomainPolicies{GUID}»). Эти директории используются для хранения большей части содержимого объекта групповой политики (например, шаблонов, настроек, сценариев, сведений о пакетах MSI и т. д.). GPT реплицируются на каждый контроллер домена с помощью Службы репликации файлов (File Replication Service, FRS) или Репликации распределенной файловой системы (Distributed File System Replication, DFSR) в зависимости от версии Windows. Фактически, объекты групповой политики имеют эффект лишь в пределах домена, поскольку SYSVOL реплицируется только внутри домена.

Второй компонент объекта групповой политики — контейнер групповой политики (Group Policy Container, GPC), представляющий собой объект Active Directory groupPolicyContainer, располагающийся в ветке CN=System,CN=Policies в контексте именования домена. Атрибуты этого объекта используются для хранения справочной информации, относящейся к объекту групповой политики. В частности, в атрибуте gPCFileSysPath содержится путь к шаблону GPT объекта групповой политики в SYSVOL. В отличие от GPT, GPC реплицируется Доменными службами Active Directory (Active Directory Domain Services) в соответствии с настроенными стоимостью, расписанием и интервалом репликации.

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

Такие связи являются внешними по отношению к самому GPO и содержатся в атрибуте gPLink, доступном в трёх классах объектов Active Directory: Organizational Unit («OU»), Domain и Site. Значение атрибута gPLink представляет собой список путей к GPC каждого объекта групповой политики, с которым связан данный объект. При создании или удалении связи GPO с каким-либо объектом фактически модифицируется только значение атрибута gPLink соответствующего объекта.

(Примечание: Хотя репликация SYSVOL ограничивает эффект применения объекта групповой политики лишь конкретным доменом, тот факт, что объекты групповой политики могут быть связаны с объектом узла (Site), означает, что информация, связанная с объектом групповой политики, не обязательно ограничена доменом. Объекты узла хранятся в разделе Configuration Active Directory, который реплицируется на все контроллеры домена в лесу. В результате этого путь к GPC объекта групповой политики, содержащийся в атрибуте gPLink, так или иначе выводится за рамки конкретного домена во время репликации Active Directory.)

Порядок обработки групповой политики

Объекты Organizational Unit, Domain и Site также играют важную роль при определении приоритета применения политик в ситуациях, когда имеются конфликтующие друг с другом политики.

Active Directory применяет GPO в следующем порядке: локальные политики, политики узла, политики домена, политики контейнера OU, причём «побеждает» последняя применяемая групповая политика (если не была использована опция «Enforce», предотвращающая переопределение групповой политики со стороны следующих применяемых групповых политик). Групповые политики, привязанные к контейнерам Organizational Unit, обрабатываются, начиная с корня дерева каталога, поэтому объект групповой политики, связанный с вложенным контейнером OU, будет иметь приоритет над объектом групповой политики, связанным с его родительским контейнером OU.

И последнее, на что следует обратить внимание: объекты групповой политики содержат две подгруппы: Конфигурация компьютера (Computer Configuration) и Конфигурация пользователя (User Configuration). В обеих подгруппах находятся практически идентичные наборы параметров политики. Принципиальное различие между каждой из подгрупп заключается в том, когда эти параметры политики применяются.

Параметры конфигурации компьютера применяются к компьютерам во время загрузки, а параметры конфигурации пользователя применяются при входе в систему. Это означает, что параметры в подгруппе Конфигурация компьютера групповой политики всегда применяются к связанным с этой политикой компьютерам, а параметры в подгруппе Конфигурация пользователя применяются только тогда, когда пользователь c учётной записью, связанной с этой политикой, входит в систему на компьютере.

Если пользователь вошёл в систему на каком-то компьютере и возник конфликт между параметрами Конфигурации компьютера и Конфигурации пользователя, то параметры Конфигурации компьютера всегда будут превалировать над параметрами Конфигурации пользователя.

Ну а теперь давайте вернёмся к нашей основной теме и обсудим резервное копирование и восстановление объектов групповой политики.

Начнём с командлетов PowerShell Group Policy, доступных как часть пакета Windows Remote Server Administration Tools от Microsoft, включающего в себя командлеты Backup-GPO и Restore-GPO. С помощью командлета Backup-GPO очень просто создать снапшот как всех объектов групповой политики в домене, так и одного конкретного объекта групповой политики. Командлет Restore-GPO может восстановить объект групповой политики до его состояния, зафиксированного в резервной копии, созданной командлетом Backup-GPO.

В следующем PowerShell-скрипте используется командлет Backup-GPO с параметром -All для создания резервных копий всех GPO в домене с явно заданным именем с использованием контроллера домена, который также указан явно. Поддерживается многократное резервное копирование в одно и то же место, но в данном случае при каждом выполнении скрипта создаётся уникальная папка для выгрузки данных:

$BackupPath = '\HOSTNAMEGPOBackup'
$Domain = 'domain.com'
$DomainController = 'DC.domain.com'

$BackupFolder = New-Item -Path $BackupPath -Name (Get-Date -format yyyyMMddTHHmmss) -ItemType Directory
Backup-GPO -All -Domain $Domain -Server $DomainController -Path $BackupFolder

Выгружаемые данные командлета Backup-GPO состоят из отдельных подпапок для резервной информации каждого GPO, а также файла manifest.xml, содержащего информацию, необходимую для связывания каждой из этих подпапок с соответствующими объектами групповой политики.

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

Заглянув внутрь одной из таких подпапок, мы обнаружим, что каждая резервная копия состоит из одной папки и трёх XML-файлов.

В папке содержится копия GPT объекта групповой политики, а XML-файлы содержат данные из GPC объекта групповой политики, информацию, относящуюся к выполнению резервного копирования, а также отчёт, который описывает содержимое объекта групповой политики.

Как уже упоминалось выше, разделение выгружаемых данных при каждом выполнения скрипта на уникальные папки не является строго необходимым. Однако такая стратегия создает преимущество при выполнении командлета Restore-GPO. Командлет Restore-GPO позволяет восстановить все GPO сразу, но он будет использовать самую последнюю резервную копию каждого из объектов групповой политики согласно информации из файла manifest.xml. При разделении наборов резервных копий по отдельным папкам, каждый такой набор получает свой собственный файл manifest.xml. Это позволяет выполнить восстановление всех GPO из любого такого набора за одну операцию.

Недостатком использования параметра -All командлета Backup-GPO в приведённом выше сценарии является то, что он производит резервное копирование всех объектов групповой политики в домене, независимо от того, были они изменены или нет, при каждом его исполнении.

Поскольку мы работаем с PowerShell, мы можем попытаться обойти эту проблему, например, так, как представлено ниже:

$BackupPath = '\HOSTNAMEGPOBackup'
$Domain = 'domain.com'
$DomainController = 'DC.domain.com'

if((Test-Path "$BackupPathlastBackup")) {
    $LastBackup = Get-Content -Path "$BackupPathlastBackup"
    Set-Content -Path "$BackupPathlastBackup" -Value (Get-Date)
    $GPOs = Get-GPO -All -Domain $Domain -Server $DomainController
    $GPOs | Where-Object { $_.ModificationTime -gt $LastBackup } | ForEach-Object {
        Backup-GPO -Guid $_.Id -Domain $Domain -Server $DomainController -Path $BackupPath
    }
}
else {
    Set-Content -Path "$BackupPathlastBackup" -Value (Get-Date)
    Backup-GPO -All -Domain $Domain -Server $DomainController -Path $BackupPath
} 

В этом скрипте PowerShell командлет Backup-GPO выполняется дифференцировано в зависимости от содержимого файла, который создается в папке обновлений и хранит отметку времени последнего выполнения сценария. Если данный файл существует, скрипт создаёт резервные копии только тех GPO домена, которые были изменены позднее той отметки времени, которая хранится в файле. Если же данного файла не существует, скрипт создаёт его, помещает в него отметку времени, и создаёт резервные копии всех GPO домена.

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

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

$BackupPath = '\HOSTNAMEGPOBackup'
$Domain = 'domain.com'
$DomainController = 'DC.domain.com'

$BackupFolder = New-Item -Path $BackupPath -Name (Get-Date -format yyyyMMddTHHmmss) -ItemType Directory

if((Test-Path "$BackupPathlastBackup")) {
    $LastBackup = Get-Content -Path "$BackupPathlastBackup"
    Set-Content -Path "$BackupPathlastBackup" -Value (Get-Date)
    $GPOs = Get-GPO -All -Domain $Domain -Server $DomainController
    $GPOs | Where-Object { $_.ModificationTime -gt $LastBackup } | ForEach-Object {
        Backup-GPO -Guid $_.Id -Domain $Domain -Server $DomainController -Path $BackupFolder
    }
}
else {
    Set-Content -Path "$BackupPathlastBackup" -Value (Get-Date)
    Backup-GPO -All -Domain $Domain -Server $DomainController -Path $BackupFolder
} 

Но оказывается, что изоляция каждого из результатов дифференцированного резервного копирования в их собственных папках на самом деле делает всё намного хуже. Ведь при данном подходе также изолируются в отдельных папках и файлы manifest.xml, что с одной стороны лишает нас возможности одновременного восстановления всех объектов групповой политики, а с другой стороны значительно усложняет процесс поиска резервной копии, связанной с каким-либо конкретным объектом групповой политики.

На практике некоторые ограничения, с которыми сталкиваются рассмотренные нами подходы, — это ограничения, накладываемые относительно скромными возможностями командлета Restore-GPO.

# Восстановление одного GPO из его самой последней резервной копии
Restore-GPO -Name 'GpoName' -Path '\HOSTNAMEGPOBackup' -Domain 'domain.com' -Server 'DC.domain.com'

# Восстановление одного GPO из конкретной резервной копии
Restore-GPO -BackupId 12345678-09ab-cdef-1234-567890abcdef -Path '\HOSTNAMEGPOBackup' -Domain 'domain.com' -Server 'DC.domain.com' 

# Восстановление всех GPO домена из их самой последней резервной копии
Restore-GPO -All -Path '\HOSTNAMEGPOBackup' -Domain 'domain.com' -Server 'DC.domain.com'

Restore-GPO может восстанавливать конкретный объект групповой политики либо из самой последней резервной копии, указанной в файле manifest.xml, либо из заданной резервной копии. Но восстановление всех GPO домена сразу ограничено использованием самых последних резервных копий из указанного файла manifest.xml.

Когда объект групповой политики восстанавливается из резервной копии, версия этого объекта увеличивается (то есть увеличение версии — часть процесса восстановления).

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

Придётся нам ещё немного отвлечься.

Вывод командлета Restore-GPO включает два набора номеров версий: один для Конфигурации компьютера, второй — для Конфигурации пользователя.

GPT и GPC раздельно ответственны за поддержание своего собственного номера версии, причём отдельные значения UserVersion и ComputerVersion рассчитываются на основе соответствующих номеров версий Конфигурации пользователя и Конфигурации компьютера. Это становится возможным из-за применяемого метода увеличения номера версии. Он увеличивается на 1 при изменении Конфигурации компьютера объекта групповой политики, и на 65536 каждый раз при изменении Конфигурации пользователя.

Всё это важно, поскольку, как обсуждалось ранее, GPT и GPC объектов групповых политик реплицируются отдельно друг от друга разными сервисами, в результате чего номера версий GPT и GPC какой-либо групповой политики на каком-то контроллере домена могут оказаться рассинхронизированными (не совпадать). Пока объект групповой политики находится в этом состоянии, при его обработке будет возникать сбой. После того, как номера версий придут в состояние синхронизации, GPO вновь будут успешно обрабатываться.

А мы вновь возвращаемся к нашему повествованию.

Задокументированное ограничение командлета Restore-GPO — то, что он не может быть использован для восстановления объекта групповой политики, который был удалён. Попытка сделать это приведёт к примерно такой ошибке:

Причина, по которой работа командлета Restore-GPO завершается неудачей в данной ситуации — то, что он не может найти компонент GPC объекта групповой политики в каталоге Active Directory.

Если Вы сможете сначала восстановить GPC, то тогда Restore-GPO фактически может быть использован для восстановления объекта групповой политики. Посмотрите:

Когда GPC снова на месте (в последнем примере для полного восстановления компонента объекта групповой политики, хранящегося в Active Directory, из корзины Active Directory был использован командлет Restore-ADObject), командлет Restore-GPO способен восстановить GPO.

Хотя с помощью данного процесса можно восстановить удалённый GPO, но при этом не получится восстановить значения gPLink, существовавшие до того, как этот GPO был удалён. Всё потому, что, как мы уже упоминали, данные значения не были частью объекта групповой политики, а находились в самих связанных с этим GPO объектах каталога. Единственный безопасный способ обойти это ограничение — использовать отдельно созданные резервные копии Active Directory, содержащие данные значения gPLink.

Кроме командлетов PowerShell для работы с объектами групповой политики, Microsoft также предлагает Консоль управления групповыми политиками (Group Policy Management Console, GPMC), оснастку MMC, которая может использоваться для резервного копирования и восстановления объектов групповых политик. Как и командлет Backup-GPO, она может создавать резервные копии как отдельного заданного объекта групповой политики, так и всех GPO домена. В отличие от командлета Restore-GPO, её возможности ограничены восстановлением единственного GPO за раз.

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

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

Инструмент Microsoft Расширенное управление групповой политикой (Advanced Group Policy Management, AGPM), доступный как часть пакета Microsoft Desktop Optimization Pack, дополняет функциональные возможности GPMC за счёт внедрения в неё функции контроля версий. Это помогает расширить возможности просмотра и понимания содержимого созданных резервных копий.

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

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

Возможно вам будет интересно — Подборка программ — инструментов для системного администратора

источник