Управление ролями FSMO при помощи стандартных оснасток MMC не совсем удобный процесс, так как для доступа к разным ролям приходится использовать различные оснастки, а к некоторым из них еще и не так просто добраться. Кроме того оснастки MMC не позволяют производить операции захвата ролей в случае выхода из строя контроллера домена на котором они были расположены. Гораздо удобнее для этих целей использовать утилиту ntdsutil, о чем и пойдет речь в данной статье.
Прежде чем приступать к практической части, вспомним что такое роли FSMO и рассмотрим что именно произойдет с ActiveDirectory при их отказе. Всего ролей FSMO пять, две для леса и три для домена.
Роли уровня леса существуют в единственном экземпляре и, несмотря на свою важность, наименее критичны для функционирования AD. Что произойдет при недоступности каждой из них:
- Хозяин схемы – невозможно изменить схему. Однако данная процедура проводится раз в несколько лет при введении в сеть контроллеров на более новой ОС или установке некоторых иных серверных продуктов, таких как Exchange. На практике отсутсвие хозяина схемы можно не замечать годами.
- Хозяин именования домена – невозможно добавить или удалить домен. Аналогично с хозяином схемы его отсутвие может быть незамеченным довольно длительное время.
- Роли уровня домена существуют по одной в каждом домене и являются более критичными для функционирования AD.
- Хозяин инфраструктуры – при наличии нескольких доменов на контроллерах которые не являются глобальными каталогами может быть нарушено членство в локальных группах домена. Если все контроллеры домена – глобальные каталоги (сегодня именно такая конфигурация является рекомендуемой Microsoft), то про существование хозяина инфраструктуры можно смело забыть, точно также как и при единственном домене в лесу.
- Хозяин RID – через некоторое время будет невозможно создать новый объект в AD, время зависит от оставшегося количества свободных SID, которые выдаются пачками по 500 заготовок. Если в вашей AD небольшое количество объектов и вы не каждый день заводите новые, то отсутствие хозяина RID останется незамеченным на протяжении длительного времени.
- Эмулятор PDC – самая критичная роль. При его недоступности сразу станет невозможным вход в домен клиентов до Windows 2000 (если они где-то еще остались), прекратится синхронизация времени и не будут действовать некоторые политики при вводе неправильного пароля. На практике отсутствие эмулятора PDC будет замечено при первой рассинхронизации времени более чем на 5 минут, а это может произойти раньше, чем вы можете предполагать.
Вместе с тем, как можно увидеть, нет ни одной роли FSMO отказ которой приводил бы к существенной потере функциональности AD, даже при отказе всех ролей FSMO инфраструктура может нормально работать в течении нескольких дней, недель или даже месяцев.
Поэтому, если вы собираетесь на некоторое время вывести контроллер, содержащий некоторые или все роли, из эксплуатации (например на профилактику), то нет необходимости их передавать, ваша AD нормально проживет и без них.
Передача ролей уместна в том случае, если вы планируете вывести данный сервер из эксплуатации на длительное время или передать его в другое подразделение (например в другой сайт), либо планируемые операции могут привести к его выходу из строя (например апгрейд железа).
В случае отказа контроллера не спешите захватывать роли, вы всегда успеете это сделать, в противном случае при восстановлении и подключении в сеть сервера, ранее содержавшего роли FSMO, вы получите много неприятных моментов связанных с USN Rollback и восстановлением нормального функционирования домена. Если все таки роли были захвачены, а затем вы восстановили старый контроллер, то наилучшим решением будет переустановить на нем систему и ввести в домен заново.
Также еще один не очевидный момент, если у вас несколько доменов и не все контроллеры являются глобальными каталогами не размещайте хозяина инфрастурктуры на контроллере с глобальным каталогом. Это равносильно его отсутствию.
Узнать какие именно контроллеры обладают ролями FSMO можно командой:
netdom query fsmo
Для управления ролями FSMO запустите утилиту ntdsutil на любом контроллере домена:
ntdsutil
Затем перейдем к управлению ролями:
roles
Следующим шагом следует соединиться с контроллером домена, которому мы собираемся передать роли, для этого перейдем в подменю соединения с серверами:
connections
и соединимся с нужным сервером:
connect to server SERVERNAME
где SERVERNAME – имя необходимого нам контроллера домена. Затем выйдем из подменю:
q
При этом следует помнить, что мы можем запустить утилиту на любом из контроллеров домена и присоединиться к любому другому КД для передачи или захвата ролей. В нашем примере мы физически находясь на сервере SRV-DC01 соединились с сервером SRV-DC02 и попробуем передать ему какую нибудь роль.
Для передачи ролей служит команда transfer в качестве аргумента которой выступает имя передаваемой роли, для каждой из ролей используются следующие имена:
naming master - хозяин именования домена
infrastructure master - хозяин инфраструктуры
PDC - эмулятор PDC
RID master - хозяин RID
schema master - хозяин схемы
Внимание! В системах до Windows Server 2008 R2 для хозяина именования домена использовалось имя domain naming master.
Например для передачи роли хозяина именования домена выполним команду:
transfer naming master
Появится диалоговое окно, которое попросит нас подтвердить действие, советуем всегда внимательно изучать его содержимое.
Получив утвердительный ответ утилита передаст выбранную роль другому серверу.
Теперь представим, что сервер SRV-DC02 безвозвратно выбыл из строя и нам требуется захватить роль хозяина именования назад. Для захвата ролей служит команда seize, которая имеет аналогичный синтаксис…