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

Есть две причины, по которым вам придется восстанавливать 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. Вы можете также восстановить индивидуальную группу, учетные записи пользователей (например,    restoresubtreeenmanagerl,oumanagersou, dcnwtraders,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-сервер, и восстановить как можно быстрее отсутствующие функциональные возможности.