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

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

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

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

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

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

Если у вас есть возможность отремонтировать отказавший контроллер домена без его полного воссоздания, то перечисленные ранее методы восстановления не потребуются. Windows Server 2003 предлагает улучшенные инструменты для диагностики и устранения проблем, такие как "Last Known Good Configuration" и "Safe Mode". Прежде чем приступать к полному восстановлению, рекомендуется попробовать восстановить работоспособность контроллера с помощью этих инструментов.

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

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

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

Для очистки каталога выполните действия на рабочей станции или сервере с Windows 2000, Windows XP Professional или Windows Server 2003, которые являются членами домена. Откройте командную строку и введите ntdsutil.

Для начала работы в командной строке утилиты Ntdsutil введите команду metadata cleanup. Это переведет вас в режим "Очистка мета-данных".

Далее, чтобы установить соединение с текущим контроллером домена с целью удаления отказавшего контроллера, введите connections. После этого вам будет предоставлено окно "Подключение к серверу".

В этом окне введите команду connect to server servername, где servername - имя рабочего контроллера домена. Если у вас есть административные права в Active Directory, вы автоматически подключитесь к этому контроллеру. В противном случае используйте команду set creds domain username password для ввода учетных данных пользователя с правами на уровне домена.

Если вы введете команду help, то увидите опцию connect to server %s. Здесь %s - это либо DNS-имя контроллера домена, либо IP-адрес сервера.

Чтобы вернуться к окну "Очистка мета-данных", введите команду quit.

Для выбора домена, сайта и контроллера домена используйте команду select operation target. Это позволит вам выбрать нужный контроллер домена для удаления.

В окне "Выбор адресата операции" введите list domains для просмотра всех доменов вашего леса с присвоенными им номерами.

Напечатайте select domain number(выбрать номер домена), где number указывает домен, содержащий отказавший контроллер домена. Если вы напечатаете help перед тем, как напечатать select domain number, то увидите, что одна из опций команды -select domain %d(выбрать домен %d). Переменная %d должна всегда заменяться числом. Напечатайте list sites(перечислить сайты). Будут перечислены все сайты леса. Напечатайте select site number(выбрать номер сайта), чтобы выбрать сайт, содержащий контроллер домена, который вы должны удалить. Напечатайте list servers in site(перечислить серверы в сайте). Все контроллеры домена, имеющиеся в выбранном сайте, будут перечислены. Используйте команду select server number, чтобы выбрать контроллер домена, который вы должны удалить. Утилита Ntdsutil покажет выбранный домен, сайт и контроллер домена (см. рис. 15-1.)

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

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

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

Инструмент Ntdsutil

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

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

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

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

Выполнение неофициального восстановления

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

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

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

Иногда восстановление контроллера домена происходит на сервере с другим набором аппаратных средств. Несмотря на то, что можно восстановить Windows Server 2003 на другом оборудовании, этот процесс может вызвать проблемы. Если решите восстановить Windows Server 2003 на другом сервере, выберите максимально совместимое оборудование. Убедитесь, что уровень аппаратного абстрагирования (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, содержит учетные записи групп и пользователей. Если информация о группе реплицируется раньше, чем информация о пользователе, это может привести к ошибкам в членстве группы. К сожалению, невозможно контролировать порядок репликации объектов.

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

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

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

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

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

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

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

Чтобы выполнить восстановление с полномочиями, сделайте следующее.

  1. Выполните шаги с первого по пятый процедуры восстановления без полномочий; не перезагружайте сервер, когда восстановление закончено.
  2. Откройте командную строку и напечатайте ntdsutil.
  3. В окне Ntdsutil напечатайте authoritative restore (восстановление с полномочиями).
  4. В окне Authoritative Restore напечатайте restore subtree objectname (восстановление поддерева objectname). Например, чтобы восстановить OU Managers в домене NWTraders.com, нужно напечатать restore subtree ou=managers,dc=nwtraders,dc=com. Вы можете также восстановить индивидуальную группу, учетные записи пользователей (например, restore subtree en-manager1,ou=managers,dc=nwtraders,dc=com) или раздел приложений.
  5. Чтобы восстановить с полномочиями весь каталог, напечатайте restore database (восстановить базу данных) в окне команды 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.

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

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

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

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

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

Планирование

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

Например, если пользователь только что изменил свой пароль, используя клиента низкого уровня, то это изменение было сделано на эмуляторе PDC. Эмулятор PDC будет реплицировать это изменение партнеру по репликации, расположенному в том же самом сайте, в пределах 15 секунд. Если в этом сайте нет партнера по репликации, то репликация пароля не произойдет до следующей запланированной репликации между сайтами. Если контроллер домена выйдет из строя перед этим запланированным временем, то изменение пароля не будет реплицироваться на другие сайты. Если контроллер домена находится там же, где сервер хозяина операций, то вероятность неполной репликации гораздо меньше. Контроллер домена, находящийся в том же сайте, где расположен хозяин операций, является также наилучшим кандидатом на захват роли хозяина операций, потому что он имеет самую свежую информацию от хозяина операций. Если у вас имеется больше одного дополнительного контроллера домена в том же самом сайте, где расположен отказавший хозяин операций, то вы можете использовать команду repadmin / showvector namingcontext, чтобы определить, какой из контроллеров домена имеет самые свежие обновления с вышедшего из строя контроллера домена.

Чтобы захватить роли хозяина операций, вы можете использовать утилиту Ntdsutil или инструмент Active Directory Users And Computers (чтобы захватить роли эмулятора PDC и хозяина инфраструктуры). Роли хозяина RID, хозяина схемы и хозяина именования доменов можно захватить только с помощью утилиты Ntdsutil.

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

  1. Откройте командную строку и напечатайте ntdsutil.
  2. В окне команд Ntdsutil напечатайте roles(роли).
  3. В окне команд Fsmo Maintenance (Обслуживание Fsmo) напечатайте connections(подключения).
  4. В окне команд Server Connections (Подключения сервера) напечатайте connect to server servername.domainname(соединиться с сервером servername.domainname), где servername - контроллер домена, на котором вы хотите захватить роль хозяина операций. Напечатайте quit(выход).
  5. В окне команд Fsmo Maintenance напечатайте seize operations_master_role(захватить роль хозяина операций). Где operations_master_role — это роли, которые вы хотите захватить: schema master(хозяин схемы), domain naming master(хозяин именования доменов), infrastructure master(хозяин инфраструктуры), RID-master(хозяин RID) или PDC.
  6. Примите предупреждение. Сервер сначала будет пробовать выполнить нормальную передачу роли хозяина операций. Если это не получится, потому что с вышедшим из строя контроллером домена нельзя войти в контакт, то роль будет захвачена. На рисунке 15-4 смотрите пример захвата роли хозяина RID.

Вывод утилиты Ntdsutil при захвате роли хозяина 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, потерпят неудачу.

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

Рис. 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-контроллером. Те же самые функциональные возможности существуют в 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). Это особенно актуально при развертывании Microsoft Exchange Server 2000. В случае сбоя единственного GC-сервера в сайте с Exchange Server 2000, потребуется настроить другой контроллер домена на том же сайте как GC-сервер и быстро восстановить функциональность.