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

15.04.2019

Иногда случается что по тем или иным причинам необходимо передать или же насильно забрать роли FSMO с главного контроллера домена на резервный / новый контроллер домена. Рассмотрим на примере как это можно сделать.

Мы имеем:

Главный контроллер домена на базе Windows Server 2012 R2 (DC1, jakonda.local, 192.168.0.2)
Дополнительный контроллер домена на базе Windows Server 2012 R2 (DC2, jakonda.local, 192.168.0.3)

Главный контроллер домена DC1 начал глючить и необходимо передать права FSMO на резервный DC2. Понизить DC1 до уровня обычного сервера и вывести его использования.
Главный контроллер домена DC1 приказал долго жить и необходимо принудительно забрать роли FSMO на резервный DC2. На DC2 подчистить все упоминания о DC1.

Добровольная передача ролей FSMO с главного на резервный контроллер домена.

Перед тем как начать, нужно проверить состоит ли пользователь от которого будут выполнятся действия, в группах Domain Admins , Schema Admin . Запускаем от администратора командную строку на дополнительном контроллере домена DC2 (рекомендуется выполнять все действия на контроллере домена, которому назначаются роли FSMO). Смотрим список имеющихся контроллеров домена:

Dsquery server -forest

Проверим кто является владельцем ролей FSMO :

Netdom query fsmo

Видим что владельцем является DC1.jakonda.local

Переносить роли будем в командной строке при помощи утилиты NTDSUTIL (инструмент управления и обслуживания каталога Active Directory).

Перед тем как переносить FSMO роли на дополнительный контроллер домена, необходимо предварительно зарегистрировать в системе библиотеку управления схемой Active Directory . Если этого не сделать, то роль Schema перенести не удастся.

В командной строке вбиваем:

Regsvr32 schmmgmt.dll

Библиотека подключена.

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

Ntdsutil

Выбираем сервер котором назначать роли:

После подключения к серверу DC2 мы получаем приглашение к управлению ролями (fsmo maintenance ) и передаем ему роли:

Transfer naming master transfer infrastructure master transfer rid master transfer schema master transfer pdc q

Аналогично проделанные выше операции по передачи ролей, можно проделать с помощью графического интерфейса. Запускаем оснастку , нажимаем правой кнопкой мыши на домене и выбираем Operation Masters…

Во всех трех вкладках (RID , PDC , Infrastructure ) нажимаем Change… и выбираем кому передать права, в моем случае dc2.jakonda.local

По такой же схеме заходим в оснастку Active Directory Domain and Trusts , нажимаем Operations Master… и передаем права на dc2.jakonda.local

А для того чтобы передать права на роль Active Directory Schema , запускаем консоль управления Windows (MMC ), нажимаем Win + R , вбиваем mmc . В консоли управления добавляем оснастку, нажимаем File — Add/Remove Snap-in…

Выделяем оснастку Active Directory Schema , нажимаем Add > и подтверждаем добавление, ОК .

И теперь так же как и в предыдущих оснастках выполняем передачу роли.

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

Netdom query fsmo

Все роли переданы DC2.jakonda.local , как нам и нужно было.

Теперь понижаем роль AD DS на DC1 до обычного сервера. В Windows Server 2012 R2 понизить роль можно через PowerShell либо через Server Manager . Понижать роль будем через PowerShell , т.к. это удобней и быстрей. Запускаем PowerShell на DC1 и вводим:

Uninstall-ADDSDomainController

Будет предложено задать пароль Администратора, задаем его и подтверждаем удаление AD DS (Y ).

Запустится процесс удаления AD DS , по окончании появится уведомление и системам перезагрузится.

После понижения роли на DC1 , службы AD DS не удаляются и при желании можно вновь повысить DC1 до уровня контроллера домена. Теперь осталось на DC2 почистить оставшиеся следы от DC1 .

На DC2 открываем оснастку Service Manager — Tools — . Разворачиваем сайт где находился пониженный сервер DC1 , выделяем его и выбираем Delete .

Подтверждаем два раза удаление сервера DC1 . Нажимаем Yes , Yes .

Открываем оснастку Service Manager — Tools — Active Directory Users and Computers . Переходим в каталог Domain Controllers , если там отображается только наш DC2 , то все нормально. А если в данном каталоге присутствует DC1 , то его необходимо удалить из каталога (Мало вероятно что он там будет, после проделанных выше операций, но проверить стоит).

Открываем оснастку Service Manager — Tools — DNS . И удаляем все PTR и A DC1 .

Вот и все, мы полностью удалили из DNS и Active Directory неисправный контроллер домена и все ресурсы, связанные с ним. DC2 стал главным контроллером домена, а DC1 выведен из эксплуатации.

Принудительный захват ролей FSMO с главного на резервный контроллер домена.

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

Перед тем как начать, нужно проверить наличие состоит ли пользователя от которого будут выполнятся действия, в группах Domain Admins , Schema Admin .

Регистрируем в системе библиотеку управления схемой Active Directory . Запускаем от администратора командную строку и вбиваем:

Regsvr32 schmmgmt.dll

Выполняем захват ролей с неисправного DC1 . В командной строке запущенную от администратора вбиваем:

Ntdsutil

Входим в управление ролями и подключаемся к серверу (DC2 ) на который будем захватывать роли:

Roles connections connect to server DC2 q

После подключения к серверу DC2 захватываем роли:

Seize naming master seize infrastructure master seize rid master seize schema master seize pdc q

В процессе переноса каждой роли будет запрошено подтверждение.

Входим в управление очисткой мета-данных и подключаемся к серверу (DC2 ):

Metadata cleanup connections connect to server DC2 q

Смотрим список имеющихся сайтов:

Select operation target list sites

Выбираем сайт на котором у нас находится вышедший из строя контроллер домена DC1 и выводим список контроллеров домена в этом сайте:

Select site 0 list servers in site

Выбираем неисправный контроллер домена DC1 и выводим список доменов:

Select server 0 list domains

Выбираем домен и возвращаемся в меню metadata cleanup :

Select domain 0 q

Выполняем удаление выбранного сервера DC1 :

Remove selected server

Теперь подчищаем оставшиеся данные от удаленного контроллера домена DC1 на DC2 , как делали выше, при добровольной смене ролей FSMO.

Открываем оснастку Service Manager - Tools - Active Directory Sites and Services . Разворачиваем сайт где находился удаленный сервер DC1 , выделяем его и выбираем Delete . Подтверждаем два раза удаление сервера DC1 . Нажимаем Yes , Yes .

Открываем оснастку Service Manager - Tools - DNS . И удаляем все PTR и A записи оставшиеся от сервера DC1 .

Таким образом мы принудительно забрали права на роли FSMO с неисправного DC1 и полностью удалили следы его существования из DNS и Active Directory на DC2 и он же стал главным контроллером домена.

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

Давайте выполним в командной строке вот такую команду:

netdom query fsmo

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

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

Не удается передать роль хозяина операций по следующей причине: Ошибка требуемой операции FSMO. Нет связи с текущим владельцем FSMO.

Это я увидел в оснастке Active Directory - Пользователи и компьютеры, при попытке по правильному передать роль RID.

Если попытаться получить роль PDC эмулятора с недоступных контроллером, то он даст вам это сделать в ADUC, но вы увидите предупреждение.

Ошибка требуемой операции FSMO. Нет связи с текущим владельцем FSMO. Не удается связаться с текущим хозяином операций для передачи этой роли другому компьютеру. В некоторых случаях допускается принудительная передача роли. Вы хотите выполнить?

Говорим "Да"

Все роль PDC получена.

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

Теперь захватим роль RID, в этом нам поможет утилита ntdsutil. Открываем командную строку для принудительного захвата.

Вводим ntdsutil, попадем в исполняемую среду.
Далее пишем roles
в fsmo maintenance: пишем connections
в server connections: пишем connect to server имя сервера у меня это dc7
server connections: q
пишем в fsmo maintenance: seize RID master

Вам напишут: Попытка безопасной передачи RID FSMO перед захватом. Ошибка ldap_modify_sW, код ошибки 0x34<52 (Нет данных). Расширенное сообщение об ошибке LDAP 000020AF: SvcErr: DSID-03210F70, problem 5002, data 1722. Возвращенная ошибка Win32 0x20af (Ошибка требуемой операции FSMO. Нет связи с текущим владельцем FSMO).

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

Если нужно принудительно захватить с помощью ntdsutil оставшиеся роли, то их ключи для последней команды:

seize PDC
seize infrastructure master
seize domain naming master (Seize naming master)
seize schema master

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

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

Модель поддержки нескольких ведущих узлов в Windows 2000

База данных с поддержкой нескольких ведущих узлов (например, Active Directory) принимает изменения от любого контроллера домена в пределах предприятия, что потенциально может привести к возникновению конфликтов при репликации данных на остальные компьютеры. В качестве одного из методов устранения конфликтующих обновлений в Windows 2000 используется алгоритм «преимущество имеет запись, сделанная последней», в соответствии с которым принимается значение данных от измененного последним контроллера домена и отбрасываются значения на остальных контроллерах домена. Однако некоторые конфликты настолько сложны, что не могут быть решены таким способом. Их проще предотвратить, чем устранять постфактум.

Обработка некоторых типов изменений в Windows 2000 осуществляется методами, которые препятствуют конфликтам обновлений Active Directory.

Модель поддержки одного ведущего узла в Windows 2000

Чтобы предотвратить возникновение конфликтующих обновлений, Active Directory выполняет обновления определенных объектов, используя модель с поддержкой одного ведущего узла. Согласно этой модели только один контроллер домена во всем каталоге имеет право вносить обновления. Данный процесс подобен роли, которая присваивалась основному контроллеру домена (PDC) в ранних версиях Windows (например, в Microsoft Windows NT 3.51 и 4.0), по которой PDC отвечает за обработку всех обновлений в определенном домене.

Windows 2000 Active Directory расширяет модель с одним ведущим узлом, которая использовалась в ранних версиях Windows, для включения поддержки нескольких ролей и возможности передавать роли другим контроллерам в рамках предприятия. Поскольку роль Active Directory не имеет жесткой привязки к одному контроллеру домена, ее называют ролью FSMO (Flexible Single Master Operation, или операции одиночного гибкого хозяина). В Windows 2000 существует пять ролей FSMO:

хозяин схемы
хозяин именования доменов
хозяин RID
эмулятор PDC
демон инфраструктуры

Роль FSMO «Хозяин схемы»

Контроллер домена, выполняющий роль хозяина схемы, отвечает за обновление схемы каталога (т. е. контекста присвоения имен схемы или LDAP://cn=schema,cn=configuration,dc=). Вносить изменения в схему каталога может только этот контроллер домена. После обновления схемы она реплицируется с хозяина схемы на другие контроллеры домена в каталоге. В каталоге может быть только один хозяин схемы.

Роль FSMO «Хозяин именования доменов»

Контроллер домена, выполняющий роль хозяина именования доменов, отвечает за изменение пространства доменных имен каталога в рамках леса (т. е. контекста именования «разделы\конфигурация» или LDAP://CN=Partitions, CN=configuration, DC=). Только этот контроллер имеет право удалять и добавлять домены в каталог. Кроме того, он добавляет и удаляет перекрестные ссылки на домены во внешних каталогах.

Роль FSMO «Хозяин RID»

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

Когда контроллер домена создает основной объект-участник безопасности (например, пользователя или группу), он назначает ему идентификатор защиты (SID). Этот идентификатор состоит из SID домена (единый для всех идентификаторов защиты, созданных в одном домене) и относительного идентификатора (RID) (уникальный для каждого участника безопасности, созданного в одном домене).

Каждый контроллер домена Windows 2000 в домене имеет пул относительных идентификаторов (RID), которые он может назначать создаваемым участникам безопасности. Когда количество RID в пуле контроллера домена снижается ниже порогового значения, он запрашивает у хозяина RID новые идентификаторы. Хозяин RID извлекает идентификаторы из нераспределенного пула домена и назначает их в пул запрашивающего контроллера домена. В каждом домене каталога существует только один хозяин RID.

Роль FSMO «Эмулятор PDC»

Эмулятор основного контроллера домена необходим для синхронизации времени в рамках предприятия. В состав Windows 2000 входит служба времени W32Time (время Windows), используемая протоколом проверки Kerberos. Все компьютеры под управлением Windows 2000 в рамках одного предприятия используют общее время. Для обеспечения корректной синхронизации времени служба времени Windows должна использовать иерархическую структуру отношений, которая контролирует полномочия и не допускает возникновения «циклов» в управлении.

Эмулятор PDC домена выступает в роли главного эмулятора домена. Эмулятор PDC в корне леса становится главным эмулятором в пределах предприятия. Его следует настроить на получение значения времени от внутреннего источника. При выборе источника времени обладатели роли FSMO эмулятора основного контроллера домена следуют иерархии доменов.

В домене Windows 2000 обладатель роли эмулятора PDC сохраняет следующие функции: Произведенные другими контроллерами домена изменения паролей в первую очередь реплицируются на эмулятор PDC.

Произведенные другими контроллерами домена изменения паролей в первую очередь реплицируются на эмулятор PDC.

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

Случаи блокировки учетных записей обрабатывается на эмуляторе PDC.

Эмулятор PDC выполняет все функции серверного эмулятора PDC для Microsoft Windows NT 4.0, предыдущих версий эмуляторов на основе Windows NT 4.0 или клиентов более ранних версий.

Нет необходимости использовать данную часть роли эмулятора PDC, если все рабочие станции, серверы и контроллеры домена под управлением Windows NT 4.0 или более ранних версий обновляются до уровня Windows 2000. Эмулятор PDC выполняет все те же функции, что и в среде Windows 2000.

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

После обновления до уровня Windows 2000 резервных контроллеров (BDC) в доменах нижнего уровня эмулятор PDC перестает получать запросы на репликацию с нижнего уровня.

Клиенты под управлением Windows 2000 (рабочие станции, серверы) и клиенты более ранних версий, на которых установлен клиентский пакет распределенных служб, используют Active Directory для поиска сетевых ресурсов. Служба обозревателя Windows NT для них не требуется.

Роль FSMO «Инфраструктура»

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

Примечание.

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

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

Нет похожих постов...

Служба Active Directory содержит в себе роли FSMO (Flexible Single Master Operations — гибкие операции с одним хозяином), которые применяются для выполнения различных задач внутри леса и домена. Существуют две роли на уровне леса и три роли на уровне домена.

1. Schema Master (Хозяин схемы) / Лес / Содержит в себе схему леса
2. Domain Namiпg Master (Хозяин именования доменов) / Лес / Управляет именами доменов
3. lnfrastructure Master Домен (Хозяин инфраструктуры) / Домен / Обеспечивает меж-доменные ссылки на объекты
4. PDC Emulator (Эмулятор основного контроллера домена) / Домен / Отвечает за время в лесе
Обрабатывает изменения паролей, Является точкой подключения для управления объектами GPO, Блокирует учетные записи.
5. RID Master (Хозяин относительных идентификаторов (RID)) / Домен / Управляет и пополняет пулы RID (relative identifier — относительный идентификатор)

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

Чтобы передать роли FSMO домена, выполните описанные далее шаги:
1 . Откройте окно командной строки (cmd.eхе) . введите NTDSUtil и нажмите .
2. Введите roles и нажмите .
3 . Введите connections и нажмите .
connect to server [Имя_сервера ] и нажмите .
5. Введите quit и нажмите .
6. Первой будет передаваться роль PDС Emulator. Введите transfer pdc и нажмите . Вы должны подтвердить запрос, нажав на кнопке Yes (Да).
transfer rid master и нажать для перемещения роли RID Master. Вы должны подтвердить запрос, щелкнув на кнопке Yes (Да).
8. При необходимости можно ввести transfer infrastructure master и нажать для перемещения роли lnfrastructure Master. Вы должны подтвердить запрос, щелкнув на кнопке Yes (Да).
9. Теперь, когда передача всех ролей FSMO домена завершена, введите quit и нажмите затем снова введите quit и нажмите . чтобы закрыть окно командной строки.

Разумеется, приведенные шаги должны быть выполнены в каждом домене.
Если вы решите передать роли FSMO уровня леса, выполните следующие шаги:
Откройте окно командной строки (cmd.eхе ), введите NTDSUtil и нажмите .
2. Введите roles и нажмите .
3. Введите connections и нажмите < Enter>.
4. Теперь необходимо подключиться к серверу, который в будущем будет содержать эти роли FSMO. Введите connect to server [ Имя:_сервера ] и нажмите .
5. Введите quit и нажмите .
6. Первой будет передаваться роль Schema Master. Введите transfer schema master и нажмите . Вы должны подтвердить запрос, щелкнув на кнопке Yes (Да).
7. При необходимости можно ввести transfer naming master и нажать для перемещения роли Domain Naming Master. Вы должны подтвердить запрос, щелкнув на кнопке Yes (Да) .
8. Теперь, когда передача всех ролей FSMO леса завершена, введите quit и нажмите , затем снова введите quit и нажмите , чтобы закрыть окно командной строки.

В данной статье предлагаю поговорить о методиках передачи ролей FSMO между доменными контроллерами в среде Active Directory. Кратко попытаюсь напомнить что же такое роли FSMO (Flexible Single Master Operation, дословный перевод операции с одним исполнителем ) в домене Active Directory. Не секрет, что в Active Directory большинство типовых операций (таких как заведение учеток, групп) можно выполнять на любом контроллере домена. За распространение данных изменений по всему каталогу отвечает служба репликации AD, а всевозможные конфликты (например, одновременное переименование пользователя на нескольких контроллерах домена) разрешаются по простому принципу — кто последний тот и прав. Однако существует ряд операций, при выполнении которых недопустимо наличие конфликта (например, создание нового дочернего домена/леса и т.д). Именно поэтому и существуют контроллеры домена с ролями FSMO, основная задача которых – недопустить конфликты такого рода. Роли FSMO можно в любой момент передать другому контроллеру домена.

В Windows Server 2008 существует пять ролей FSMO:

Хозяин схемы (Schema master) – один сервер с этой ролью на весь лес. Роль нужна для расширения схемы леса Active Directory, обычно эта операция выполняется командой adprep /forestprep
Хозяин именования домена (Domain naming master) – один на весь лес. Сервер с данной ролью должен обеспечить уникальность имен для всех создаваемых доменов и разделов приложений в лесу AD.
Эмулятор PDC (PDC emulator) – один сервер на каждый домен. Выполняет несколько функций: является основным обозревателем в сети Windows, отслеживает блокировки пользователей при неправильно введенном пароле, является , предназначен для поддержки клиентов с ОС предшествующим Windows 2000.
Хозяин инфраструктуры (Infrastructure Master) — один сервер на каждый домен. Сервер с такой ролью нужен для успешного выполнения команды adprep /domainprep. Отвечает за обновление идентификаторов защиты (GUID, SID)и различающихся имен объектов в междоменных объектных ссылках.
Хозяин RID (RID Master) — один сервер на каждый домен. Сервер раздает другим контроллерам домена идентификаторы RID (по 500 штук) для создания уникальных SID.

Для управления ролью Schema master необходимо быть в группе «Schema admins».
Для управления ролью Domain naming master необходимо состоять в группе «Enterprise admins».
Для управления ролями PDC emulator, Infrastructure Master иRID Master необходимо иметь права администратора домена «Domain Admins»

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

Передать FSMO роль можно из командной строки с помощью утилиты ntdsutil. exe или же из графического интерфейса MMC оснасток. Нас интересуют следующие оснасти Active Directory ()

Active Directory Schema (для переноса роли Schema master)
Active Directory Domains and Trusts (для переноса роли Domain Naming)
(для переноса роли RID, PDC, Infrastructure)

Примечание: Все работы необходимо выполнять на контроллере с ролью, которую планируется перенести. Если же консоль сервера не доступна, то необходимо выполнить команду Connect to Domain Controller и выбрать контроллер домена в оснастке mmc.

Передача роли Schema Master

1. Зарегистрируйте библиотеку schmmgmt.dll , выполнив в командной строке команду:

Regsvr32 schmmgmt.dll.

2. Откройте консоль MMC, набрав MMC в командной строке.
3. В меню выберите пункт Add/Remove snap-in и добавьте консоль Active Directory Schema .
4. Правой кнопкой щелкните по корню консоли (Active Directory Schema ) и выберите пункт Operations Master.
5. Нажмите кнопку Change , введите имя контроллера, которому передается роль хозяина схемы и нажмите OK.

Передача роли Domain naming master

1. Откройте консоль управления доменами и доверием Active Directory Domains and Trusts .
2. Правой кнопкой щелкните по имени вашего домена и выберите опцию Operations Master.
3. Нажмите кнопку Change , укажите имяконтроллера и OK.

Передача ролей RID Master, PDC Emulator и Infrastructure Master

1. Откройте консоль the Active Directory Users and Computers .
2. Правой кнопкой мыши щелкните по имени вашего домена и выберите пункт Operations Master.
3. Перед вами появится окно с тремя вкладками (RID, PDC, Infrastructure ), на каждой из которых можно передать соответствующую роль, нажав кнопку Change.

Передача ролей FSMO из командной строки с помощью утилиты ntdsutil

Внимание: Использовать утилиту ntdsutil необходимо с осторожностью, четко понимая что вы делаете, иначе можно просто уложить ваш домен Active Directory!

1. На контроллере домена откройте командную строку и введите команду

Ntdsutil