Хозяин именования доменов ошибка

Обновлено 10.11.2017

Всем привет, сегодня расскажу как передать fsmo роли другому контроллеру домена Active Directory. Что такое fsmo роли читайте тут. Так же мы уже рассматривали как определить FSMO хозяева операций. Задача следующая у нас есть домен Active Directory с контроллерами домена Windows Server 2008R2, мы с вами установили контроллер под управлением Windows Server 2012 R2. Нам нужно передать ему роли fsmo и в будущем заменить все W2008R2 на W2012R2.

Есть 3 домена dc01 и dc02 это контроллер домена windows 2008 r2 и dc3 это новый с Windows Server 2012 R2. Посмотрим кто хозяин ролей, делается это с помощью команды в командной строке:

Видим, что все 5 ролей (Хозяин схемы, Хозяин именования доменов, PDC, Диспетчер пула RID, Хозяин инфраструктуры) находятся на dc01.msk.pyatilistnik.org.

Первый способ который будет рассмотрен в первой части это через оснастки.

Как передать fsmo роли другому контроллеру домена Active Directory через оснастки

Передача ролей fsmo через оснастки самый быстрый и наглядный метод.

Передача PDC, Диспетчер пула RID, Хозяин инфраструктуры.

Открываем оснастку Active Directory Пользователи и компьютеры, это можно сделать через пуск набрав dsa.msc.

Видим 3 DC контроллера, у dc3 стоит windows Server 2012 R2

Щелкаем правым кликом на уровне домена и выбираем Хозяева операций

Видим, что реально PDC, Диспетчер пула RID, Хозяин инфраструктуры держит DC01

Если вы нажмете кнопку изменить, то выскочит ошибка:

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

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

Переходим на dc3 и открываем тоже ADUC

Выбираем хозяева операций

Видим текущий хозяин RID это dco1 и кому передаем это dc3, жмем изменить.

Подтверждаем

Роль успешна передана

Видим, что теперь хозяин RID dc3.msk.pyatilistnik.org

Тоже самое проделаем с PDC мастером

и с Инфраструктурой

Посмотрим кто хозяин ролей, делается это с помощью команды в командной строке:

и видим три роли fsmo принадлежат dc3

Передача Schema master (мастера схемы)

Открываем оснастку Active Directory Схема, как ее добавить Active Directory Схема читаем тут.

правым кликом по корню и выбираем Хозяин операций

Мы подключимся к dc01. Нажимаем сменить

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

Закрываем его. Щелкаем правым кликом опять по корню и выбираем Сменить контроллер домена Active Directory.

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

Снова выбираем хозяина схемы и видим, что теперь сменить дает.

Да.

передана успешно.

Посмотрим кто хозяин ролей, делается это с помощью команды в командной строке:

и видим уже 4 роли у dc3

Передача Хозяина именования доменов

Открываем оснастку Active Directory домены и доверие

Выбираем хозяин операций

Изменить

Да

Роль успешно передана

Проверяем

Теперь все роли FSMO у контроллер домена windows 2012 r2.

Вот так вот просто передать fsmo роли другому контроллеру домена Active Directory. Советую почитать Как передать fsmo роли другому контроллеру домена Active Directory — 2 часть через командную строку.

Материал сайта pyatilistnik.org

В предыдущих статьях:

— подключение и установка сервера;

— настройка контроллера домена.

Задача состоит в передаче ролей c основного контроллера домена Windows Server 2008 с Active Directory (AD) на резервный контроллер домена Windows Server 2012. Резервный контроллер домена (DCSERVER) должен стать основным, а тот, который сейчас основной (WIN-SRV-ST) должен стать резервным и в перспективе демонтироваться. Все действия выполняются на резервном сервере DCSERVER. Оба сервера работоспособны и «видят» друг друга.

Перед началом передачи ролей необходимо проверить, какой из серверов является хозяином ролей. Для этого вызываем командную строку Win+R >> cmd и вводим команду:

netdom query fsmo – запрос на определение хозяина ролей FSMO

По результату выполнения команды видно, что хозяин всех ролей контроллер домена, который у нас называется Win-srv-st, он сейчас основной.

Краткая справка:

FSMO (англ. Flexible single-master operations — «операции с одним исполнителем») — типы выполняемых контроллерами домена AD операций, требующие обязательной уникальности сервера, выполняющего данные операции (wiki). Это значит, что данные роли могут быть только на одном контроллере домена.

Хозяин схемы (Schema Master) – отвечает за возможность изменения существующей схемы AD (например добавление Exchange и тп.)

Хозяин именования доменов (Domain Naming Master) – добавляет/убавляет домены (если их несколько в одном лесу).

PDC (Primary Domain Controller Emulator) — эмулятор основного контроллера домена. Отвечает за смену паролей их репликацию, изменение групповой политики, синхронизацию время и совместимость с ранними версиями Windows.

Диспетчер пула RID (Relative ID Master) – создает ID для каждого объекта AD.

Хозяин инфраструктуры (Infrastructure Master) – передает информацию об объектах AD между другими  контроллерами домена (например, когда пользователи из одного домена попали в соседний).

Есть еще одна очень важная роль – Global Catalog (GC) – хотя она не является FSMO т.к. её держателем могут быть несколько DC одновременно, без неё невозможно нормальное функционирование домена и его служб. GC хранит у себя копии всех объектов AD и частичные реплики других доменов леса. Он позволяет находить пользователям и приложениям объекты в любом домене существующего леса, отвечает за проверку подлинности имени пользователя, предоставляет сведения о членстве пользователя в универсальных группах, может общаться с другим доменным лесом.

Далее, смотрим в Active Directory (AD) >> Пользователи и компьютеры >> Наш домен >> Managed Service Accounts, чтоб учетная запись, под которой мы работаем, обладала всеми необходимыми правами.

Учетная запись должна как минимум входить в группы:

— администраторы домена;

— администраторы предприятия;

— администраторы схемы.

Передача ролей хозяина операций RID, PDC и Инфраструктуры.

Нажимаем правой кнопкой мыши на имя домена в каталоге и выбираем пункт – Хозяева операций…

В открывшемся окне видим, что хозяином во всех трех вкладках RID, PDC и Инфраструктура является Win-Srv-St.SCRB.local. Ниже написано: Чтоб передать роль хозяина операций следующему компьютеру, нажмите кнопку «Изменить». Убеждаемся что в самой нижней строчке имя сервера, которому мы хотим передать роль хозяина и жмем изменить. Делаем это же на всех трех вкладках.

В появившемся вопросе подтверждения жмем Да.

Роль хозяина успешно передана. ОК. Хозяином операций стал DCSERVER.SCRB.local.

Делаем то же самое на оставшихся двух вкладках PDC и Инфраструктура.

Передача роли «Хозяин именования доменов».

Выбираем в AD DS нашего сервера пункт Active Directory – домены и доверие.

Правой кнопкой мыши жмем по названию и выбираем, как и ранее, строчку Хозяин операций…

Проверяем имена серверов, нажимаем изменить.

Хозяином операций стал DCSERVER.

Передача роли «Хозяин схемы».

Первоначально зарегистрируем в системе библиотеку управления схемой AD с помощью команды regsvr32 schmmgmt.dll

Нажимаем WIN+R >> cmd

Вводим команду и получаем ошибку: Модуль «schmmgmt.dll загружен, но не удалось выполнить вызов DLLRegisterServer, код ошибки: 0x80040201.

Ошибка, потому что командную строку нужно запускать от имени администратора. Сделать это можно, например из меню Пуск. Выбираем командную строку и нажимаем запуск от имени администратора.

Еще раз вводим команду regsvr32 schmmgmt.dll. Теперь всё прошло как нужно.

Нажимаем WIN+R, пишем mmc

В открывшейся консоли выбираем Файл >> Добавить или удалить оснастку… (или жмем CTRL+M)

Среди доступных оснасток выбираем Схема Active Directory, нажимаем добавить. ОК.

В корне консоли выбираем добавленную оснастку, нажимаем на неё правой кнопкой мыши и выбираем строчку «Хозяин операций…»

Текущим хозяином схемы значится Win-Srv-St.SCRB.local. В нижней строчке тоже его имя.

При нажатии кнопки «Сменить» появляется сообщение: Текущий контроллер домена Active Directory является хозяином операций. Чтоб передать роль хозяина другому DC, нужно нацелить на этот DC схему Active Directory.

Возвращаемся к оснастке и выбираем ПКМ Сменить контроллер домена Active Directory.

В открывшемся окне выбираем нужный сервер. В нашем случае DCSERVER.SCRB.local. ОК.

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

При этом в названии оснастки появился нужный нам сервер.

Снова жмем на неё правой кнопкой мыши и переходим к хозяину операций. Проверяем названия серверов, жмем кнопку «Сменить».

Роль хозяина операций успешно передана. ОК.

Для того, чтоб убедиться в передаче ролей, введем еще раз в командной строке netdom query fsmo

Хозяином ролей теперь является DCSERVER.SCRB.local.

Глобальный каталог.

Чтоб уточнить, где расположен GC нужно пройти по пути: AD – Сайты и службы >> Sites >>Default-First-Site-Name >> Servers >> DCSERVER

В появившейся службе NTDS Settings жмем ПКМ и выбираем – Свойства.

Если стоит галочка напротив надписи Глобальный каталог, то значит что он на этом сервере. А вообще, в нашем случае GC расположен на обоих DC.

Настройка DNS.

В настройке DNS нового основного DC пишем вот что:

В первой строчке IP адрес бывшего основного DC (Win-Srv-St), который теперь стал резервным 192.168.1.130.

Во второй строчке 127.0.0.1 т.е. самого себя (можно и свой IP написать, чтоб по конкретнее).

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

В первой строчке IP основного DC.

Во второй строчке свой IP. Все работает.

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

Цель лекции: Дать представление о возможных неполадках с Active Directory и способах их устранения.

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

Типичные проблемы с Active Directory

Перечислим некоторые типичные проблемы с Active Directory, с
которыми можно столкнуться, и их возможные решения
[
4
]
,
[
5
]
.

• Невозможно добавить или удалить домен. Возможная причина: хозяин именования доменов недоступен, что может быть вызвано проблемами с сетевым соединением или отказом компьютера, играющего роль хозяина именования доменов. Предлагаемое решение: решить проблему с сетевым соединением, или починить/заменить компьютер, играющий роль хозяина именования доменов, или переназначить роль хозяина именования доменов.
• Невозможно создать объекты в Active Directory. Возможная причина: недоступен мастер относительных идентификаторов, что может быть вызвано проблемами с сетевым соединением или отказом компьютера, играющего роль мастера относительных идентификаторов. Предлагаемое решение: решить проблему с сетевым соединением, или починить/заменить компьютер, играющий роль мастера относительных идентификаторов, или переназначить роль мастера относительных идентификаторов.
• Изменения членства в группе не вступают в силу. Возможная причина: недоступен хозяин инфраструктуры, что может быть вызвано проблемами с сетевым соединением или отказом компьютера, играющего роль хозяина инфраструктуры. Предлагаемое решение: решить проблему с сетевым соединением, или починить/заменить компьютер, играющий роль хозяина инфраструктуры, или переназначить роль хозяина инфраструктуры.
• Пользователи без программного обеспечения Active Directory не могут войти в систему. Возможная причина: недоступен эмулятор основного контроллера домена, что может быть вызвано проблемами с сетевым соединением или отказом компьютера, играющего роль эмулятора основного контроллера домена. Предлагаемое решение: решить проблему с сетевым соединением, или починить/заменить компьютер, играющий роль эмулятора основного контроллера домена, или переназначить роль эмулятора основного контроллера домена.
• Пользователю не удается локально войти в систему на контроллере домена. Вероятная причина: возможность локального входа в систему контроллера домена управляется политиками безопасности, которые устанавливаются в параметрах групповой политики. Предлагаемое решение: в используемом по умолчанию объекте «Политика контроллера домена» назначить определенному пользователю или группе право «Локальный вход в систему».
• Не удается подключиться к контроллеру домена, работающему под управлением Windows 2000. Возможная причина: на контроллере домена под управлением Windows 2000, к которому производится подключение, не установлен пакет обновления версии 3 или более поздней. Предлагаемое решение: установить на контроллер домена под управлением Windows 2000 пакет обновления версии 3 или более поздней.
• Сообщения об ошибках «Домен не найден», «Сервер недоступен» или «Сервер RPC недоступен». Возможная причина: ошибка регистрации или разрешения имени. Предлагаемое решение: проверить доступность и правильность работы службы DNS (в том числе регистрацию NetBIOS) на соответствующем сервере.

Ошибки репликации

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

Журнал службы каталога сообщает об ошибках репликации, которые
происходят после установления репликационной связи. Нужно
просматривать журнал регистрации событий службы каталога в поисках
событий репликации, имеющих тип Error (Ошибка) или Warning
(Предупреждение).

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

[
13
]
.

• Событие с ID 1311. Информация о конфигурации репликации, имеющаяся в инструменте Active Directory Sites And Services ( Сайты и службы Active Directory), не отражает точно физическую топологию сети. Эта ошибка указывает на то, что один или более контроллеров домена или сервер-плацдарм находятся в автономном режиме (либо отключены), или что серверы-плацдармы подключены, но не содержат нужных контекстов именования (NC), либо при репликации требуемого контекста наименования между сайтами Active Directory возникают ошибки. Также возможная причина данной ошибки заключается в том, что один или несколько узлов не включены в связи сайтов либо связи сайтов содержат все сайты, но не все взаимодействующие между собой связи сайтов.
• Событие с ID 1265 (Access denied — Доступ запрещен). Эта ошибка может возникать в том случае, если локальный контроллер домена не сумел подтвердить подлинность своего партнера по репликации при создании репликационной связи или при попытке реплицировать по существующей связи. Ошибка возникает тогда, когда контроллер домена был отсоединен от остальной части сети в течение долгого времени и его пароль учетной записи компьютера не синхронизирован с паролем учетной записи компьютера, хранящимся в каталоге его партнера по репликации.

Если получено сообщение о событии с ID 1265 и ошибке «Ошибка
поиска в DNS » или об ошибке «RPC-сервер недоступен» в
журнале службы каталогов, то возможная причина свидетельствует о
неполадках DNS.

Репликация Active Directory зависит от следующих факторов:

• Записи должны реплицироваться на DNS-серверы, используемые партнерами репликации.
• Каждая зона DNS должна иметь необходимое делегирование дочерних зон.
• В IP-конфигурации контроллеров доменов должны быть правильно заданы основные и альтернативные DNS-серверы.

Как правило, проблемы, которые можно устранить средствами консоли
Active Directory Sites and Services, таковы
[
4
]
:

• новая информация каталога не распространяется своевременно;
• запросы на обслуживание не обрабатываются вовремя.

Далее приведены некоторые типичные ошибки репликации и способы их
устранения
[
4
]
,
[
5
]
,
[
6
]
.

• Любой отказ в репликации между контроллерами домена. Возможная причина: неправильное функционирование инфраструктуры DNS. Предлагаемое решение: настроить DNS-сервер и правильно сконфигурировать службу DNS.
• Репликация информации каталога прекратилась. Возможная причина: сайты, включающие клиентов и контроллеры домена, не имеют связей с контроллерами доменов другого сайта сети, что вызывает сбои в обмене информацией каталога между сайтами. Предлагаемое решение: создать связь между текущим сайтом и сайтом, подключенным к остальным сайтам сети.
• Репликация информации каталога замедлилась, но не остановилась. Возможные причины и предлагаемые решения приведены в таблице 14.1.

• При попытке репликации вручную получено сообщение «Отказано в доступе» от оснастки Active Directory Sites And Services (Сайты и службы Active Directory). Возможная причина: принудительная репликация, выполняемая пользователем вручную, влечет за собой репликацию не всех общих каталогов приложений партнеров репликации, а возможна только для тех контейнеров, для которых разрешена синхронизация репликации, при этом репликация остальных каталогов приложений даст сбой. Предлагаемое решение: для принудительной репликации вручную указанного каталога приложений использовать средства командной строки Repadmin из набора инструментов поддержки Windows.
• Не удается подключиться к контроллеру домена под управлением Windows 2000 при помощи оснастки Active Directory Sites And Services (Сайты и службы Active Directory). Возможная причина: на контроллере домена, который работает под управлением Windows 2000 и к которому требуется подключиться, не установлен пакет обновления версии 3 или более поздний. Предлагаемое решение: установить на контроллер домена под управлением Windows 2000 пакет обновления версии 3 или более поздний.

Проверка топологии репликации заключается в том, что Active
Directory запускает процесс, который определяет стоимость межсайтовых
подключений, проверяет доступность известных контроллеров домена и
факт добавления новых. На основе полученных сведений Active Directory
добавляет или удаляет объекты-подключения для формирования эффективной
топологии репликации. Этот процесс не затрагивает объекты-подключения,
созданные вручную с помощью инструмента Active Directory Sites and
Services.

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

Для чего нужны FSMO роли в домене Active Directory?

Кратко попытаюсь напомнить для чего нужный роли FSMO (Flexible Single Master Operation, операции с одним исполнителем) в домене Active Directory.

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

Всего в домене Active Directory может быть пять ролей FSMO.

Две уникальные роли для леса AD:

1. Хозяин схемы (Schema master) – отвечает за внесение изменение в схему Active Directory, например, при расширении с помощью команды adprep /forestprep (для управления ролью нужны права “Schema admins”);
2. Хозяин именования домена (Domain naming master) – обеспечивает уникальность имен для всех создаваемых доменов и разделов приложений в лесу AD (для управления нужны права “Enterprise admins”);

И три роли для каждого домена (для управления этими ролями ваша учетная запись должна состоять в группе “Domain Admins”):

1. Эмулятор PDC (PDC emulator) – является основным обозревателем в сети Windows (Domain Master Browser – нужен для нормального отображения компьютеров в сетевом окружении); отслеживает блокировки пользователей при неправильно введенном пароле, является главным NTP сервером в домене, используется для совместимости с клиентами Windows 2000/NT, используется корневыми серверами DFS для обновления информации о пространстве имён;
2. Хозяин инфраструктуры (Infrastructure Master) — отвечает за обновление в междоменных объектных ссылок, также на нем выполняется команда adprep /domainprep;.
3. Хозяин RID (RID Master) —сервер раздает другим контроллерам домена идентификаторы RID (пачками по 500 штук) для создания уникальных идентификаторов объектов — SID.

Просмотр владельцев FSMO ролей в домене

Как определить какой контролер домена является хозяином/владельцем конкретной FSMO роли?

Чтобы найти всех владельцев FSMO ролей в домене AD, выполните команду:

netdom query fsmo

Schema master dc01.domain.loc
Domain naming master dc01.domain.loc
PDC dc01.domain.loc
RID pool manager dc01.domain.loc
Infrastructure master dc01.domain.loc

Можно просмотреть FSMO роли для другого домена:

netdom query fsmo /domain:contoso.com

В этом примере видно, что все FSMO роли расположены на контроллере домена DC01. При развертывании нового леса AD (домена), все FSMO роли помещаются на первый DC. Любой контроллер домена кроме RODC может быть хозяином любой FSMO роли. Соответственно, администратора домена может передать любую FSMO роль на любой другой контроллер домен.

Можно получить информацию о FSMO ролях в домене через PowerShell с помощью Get-ADDomainController (должен быть установлен модуль Active Directory для PowerShell из состава RSAT):

Get-ADDomainController -Filter * | Select-Object Name, Domain, Forest, OperationMasterRoles |Where-Object {$_.OperationMasterRoles}

Или можно получить FSMO роли уровня леса и уровня домена так:

Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster

Общие рекомендации Microsoft по размещении FSMO ролей на контроллерах домена:

1. Роли уровня леса (Schema master и Domain naming master) нужно расположить на контроллере корневого домена, который одновременно является сервером глобального каталога (Global Catalog);
2. Все 3 доменные FSMO роли нужно разместить на одном DC с достаточной производительностью;
3. Все DC в лесу должны быть серверами глобального каталога, т.к. это повышает надежность и производительность AD, при этом роль Infrastructure Master фактически не нужна. Если у вас в домене есть DC без роли Global Catalog, нужно поместить FSMO роль Infrastructure Master именно на него;
4. Не размешайте другие задачи на DC, владельцах FSMO ролей.

В Active Directory вы можете передать FSMO роли несколькими способами: с помощью графических mmc оснасток AD, с помощью утилиты ntdsutil.exe или через PowerShell. О переносе ролей FSMO обычно задумываются при оптимизации инфраструктуры AD, при выводе из эксплуатации или поломке контроллера домена с ролью FSMO. Есть два способа передачи FSMO ролей: добровольный (когда оба DC доступны) или принудительный (когда DC с ролью FSMO недоступен/вышел из строя)

Передача FSMO ролей с помощью PowerShell

Самый простой и быстрый способ передачи FSMO ролей в домене – PowerShell командлет Move-ADDirectoryServerOperationMasterRole.

Вы можете передать на указанный DC одну или несколько FSMO ролей за раз. Следующая команда выполнит передачу двух ролей на DC02:

Move-ADDirectoryServerOperationMasterRole -Identity dc02 -OperationMasterRole PDCEmulator, RIDMaster

В аргументе OperationMasterRole можно указать как имя FSMO роли, так и ее индекс в соответствии с таблицей:

Предыдущая команда в более коротком виде выглядит так:

Move-ADDirectoryServerOperationMasterRole -Identity dc02 -OperationMasterRole 0,1

А чтобы передать сразу все FSMO роли на дополнительный контроллер домена, выполните:

Move-ADDirectoryServerOperationMasterRole -Identity dc03 -OperationMasterRole 0,1,2,3,4

Передача FSMO ролей из графических оснасток Active Directory

Для переноса FSMO ролей можно использовать стандартные графические оснастки Active Directory. Операцию переноса желательно выполнять на DC с FSMO ролью. Если же консоль сервера не доступна, необходимо выполнить команду Change Domain Controller и выбрать контроллер домена в mmc-оснастке.

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

Для передачи ролей уровня домена (RID, PDC, Infrastructure Master) используется стандартная консоль Active Directory Users and Computers (DSA.msc)

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

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

Для переноса FSMO уровня леса Schema Master используется оснастка Active Directory Schema.

1. Перед запуском оснастки нужно зарегистрировать библиотеку schmmgmt.dll, выполнив в командной строке команду: regsvr32 schmmgmt.dll 2. Откройте консоль MMC, набрав MMC в командной строке;
   3. В меню выберите пункт File -> Add/Remove snap-in и добавьте консоль Active Directory Schema;
   4. Щелкните правой кнопкой по корню консоли (Active Directory Schema) и выберите пункт Operations Master;
   5. Введите имя контроллера, которому передается роль хозяина схемы, нажмите кнопку Change и OK. Если кнопка недоступна, проверьте что ваша учетная запись входит в группу Schema admins.

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

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

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

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

1. На контроллере домена откройте командную строку и введите команду:
   ntdsutil
2. Наберите команду:
   roles
3. Затем:
   connections
4. Затем нужно подключиться к DC, на который вы хотите передать роль. Для этого наберите:
   connect to server <servername>
5. Введите
   q
   и нажмите Enter.
6. Для передачи FSMO роли используется команда:
   transfer role
   , где <role> это роль которую вы хотите передать. Например:
   transfer schema master
   ,
   transfer RID
   и т.д.
7. Подтвердите перенос FSMO роли;
8. После переноса ролей нажмите
   q
   и Enter, чтобы завершить работу с ntdsutil.exe;
9. Перезагрузите контроллер домена.

Принудительный захват FSMO ролей Active Directory

Если DC с одной из FSMO ролью вышел из строя (и его не возможно восстановить), или недоступен длительное время, вы можете принудительно перехватить у него любую из FSMO ролей. Но при этом крайне важно убедиться, что сервер, у которого забрали FSMO роль никогда не должен появится в сети, если вы не хотите новых проблем с AD (даже если вы позднее восстановите DC из резервной копии). Если вы захотите вернуть потерянный сервер в домен, единственный правильный способ – удаление его из AD, чистая переустановка Windows под новым именем, установка роли ADDS и повышение сервера до контроллера домена

Вы можете принудительно захватить FSMO роли с помощью PowerShell или утилиты NTDSUtil.

Проще всего захватить FSMO роль через PowerShell. Для этого используется тот-же самый командлет Move-ADDirectoryServerOperationMasterRole, что и для переноса роли, но добавляется параметр –Force.

Например, чтобы захватить роль PDCEmulator и принудительно передать ее на DC02, выполните:

Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole PDCEmulator –Force

Также вы можете перенести роли FSMO на сервер DC02 с помощью утилиты ntdsutil. Процедура захвата роли через ntdsutil похожа на обычную передачу. Используйте следующие команды:

ntdsutil
roles
connections
connect to server DC02 (на этот сервер вы перенесете роль)
quit

Для захвата различных ролей FSMO используйте команды:
seize schema master
seize naming master
seize rid master
seize pdc
seize infrastructure master
quit

Fsmo-роль хозяин именования доменов (Domain naming master) является второй ролью уровня леса (наравне с хозяином схемы), то есть в каждом конкретном лесе Active Directory должен существовать лишь один контроллер домена — владелец роли.

Основная статья по Active Directory — Active Directory Domain Services. Читайте также другие статьи по ролям хозяев операций — FSMO — Fexible Single Master Operations.

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

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

Теория

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

1) Добавление или удаление доменов. Domain naming master отвечает за уникальность имен каждого домена в лесу и не позволяет добавить домены с дублирующими именами. Все операции, связанные с изменениями именования доменов, должны получить подтверждение у владельца этой роли fsmo. Разумеется если хозяин роли по каким-либо причинам недоступен, вы не сможете добавить/удалить/изменить имя домена.

2) Добавление или удаление разделов каталогов приложений. Для начала стоит немного рассказать о разделах каталогов приложений — это специальные разделы, которые могут быть созданы на контроллерах домена (версии 2003 и выше, в 2000 — только данные конфигурации и схемы) для хранения динамических данных в ldap-хранилище. Данные в этих разделах также реплицируются на все контроллеры домена, обеспечивая таким образом повышенный уровень сохранности и доступности. Разделы приложений например использует служба DNS (именно поэтому она называется Active Directory-Integrated DNS) — при установке она создает два раздела на уровне ниже корневого домена леса в иерархии доменов. Один раздел для леса (ForestDnsZones) и один для домена (DomainDnsZones). Вы можете увидеть эти зоны в оснастке DNS:

Использование раздела каталога приложений службами DNS дает массу преимуществ как в плане скорости и надежности репликации, так и безопасности. К тому же добавляется и некоторый новый функционал. Подробнее о интегрированных в AD службах DNS читайте в официальной документации ^{2 3}. Напоминаю, что использовать преимущества AD-Integrated DNS вы сможете только если все DC обновлены до версии 2003 ⁴:

Windows Server 2003 DNS Active Directory stores zone data in application directory partitions. The domain partition was the only Active Directory storage option in Windows 2000 Server, and it is available in Windows Server 2003 DNS for backward compatibility. The following DNS-specific application directory partitions are created during Active Directory installation:
— A forest-wide application directory partition, called ForestDnsZones.
— Domain-wide application directory partitions for each domain in the forest, named DomainDnsZones.

Просмотреть текущие разделы каталогов можно с помощью утилиты ntdsutil ⁵:

Подробнее о принципе работы разделов каталогов приложений и их администрировании читайте на Technet ⁶. Как было сказано выше, функционал разделов каталогов приложений в версии Windows Server 2000 отсутствует.

Если носитель роли Domain naming master недоступен, произвести операции с разделами каталогов приложений не получится.

3) Добавление или удаление перекрестных ссылок объектов к или от внешних каталогов. Перекрестные ссылки необходимы для того, чтобы каждый контроллер домена имел представление о всех разделах директорий в лесу, а не только о тех, которые он поддерживает. Перекрестные ссылки имеют формат записи crossRef и хранятся в разделе Configuration, который распространяется на все DC в домене.

Перекрестные ссылки бывают двух типов — внутренние и внешние. Внутренние ссылки создаются автоматически системой. Например во время создания нового леса, мастер создает три раздела каталогов — первичный раздел каталога домена, раздел каталога конфигурации, раздел каталога схемы. Для каждого раздела каталога автоматически создаются перекрестные ссылки и располагаются они в контейнере CN=Partitions,CN=Configuration,DC=corp,DC=bissquit,DC=com на примере моего домена — corp.bissquit.com (или контейнера CN=partitions,CN=configuration,DC=ForestRootDomain для общего случая, где CN — общее имя, OU — раздел, DC — класс объекта домена). Похожие разделы каталогов создаются и при добавлении нового домена к существующему лесу.

Внешние перекрестные ссылки создаются вручную администраторами при необходимости явным образом объявить расположения объектов, которые находятся вне леса AD. Создать перекрестные ссылки можно с помощью оснастки adsiedit.msc, подробнее читайте в документации ⁷.

4) Контроль и подтверждение инструкций на переименование доменов. Поскольку присутствует возможность переименования существующих доменов AD, этот процесс также должен жестко контролироваться и функцию контроля как раз выполняет хозяин именования доменов.  Сам процесс переименования условно делится на два этапа — подготовка к переименованию и сам по себе факт смены имени (все задачи выполняются с помощью утилиты rendom.exe). На первом этапе происходит генерация XML-скрипта, содержание которого записывается в атрибут msDS-UpdateScript контейнера CN=Partitions,CN=Configuration,DC=corp,DC=bissquit,DC=com на примере моего домена (или контейнера CN=partitions,CN=configuration,DC=ForestRootDomain для общего случая). Этот контейнер может быть обновлен только хозяином именования доменов.

После этого новые имена каждого переименованного домена записываются в атрибут msDS-DnsRootAlias перекрестных ссылок объектов, относящихся к этим доменам. Если бы я хотел переименовать свой домен corp.bissquit.com, то этот атрибут находился бы в CN=CORP,CN=Partitions,CN=Configuration,DC=corp,DC=bissquit,DC=com:

Этот атрибут также может быть обновлен только хозяином именования доменов. Подробнее о процессе переименования доменов читайте в официальной документации ⁸.

Лучшие практики

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

1) Перед любыми изменениями имен доменов, перекрестных ссылок, разделов каталогов приложений всегда делайте резервное копирование. Перед началом выполнения этих задач вы можете отключать все контроллеры домена, которые за эту роль не отвечают. После этого делаете резервную копию оставшегося контроллера домена, выполняете все необходимы изменения и если все прошло удачно, то просто включаете заглушенные ранее DC. Если же что-то пошло не так, просто поднимаете единственный работающий на это время контроллер из резервной копии, включаете остальные и далее исследуете проблему;

2) Рекомендуется держать роли хозяина именования доменов и хозяина схемы на одном и том же контроллере домена ^{9 10}:

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

Таким образом контроллер домена, поддерживающий роль хозяина именования доменов, должен также отвечать за роль хозяина схемы и являться глобальным каталогом (или находиться на одном сайте с контроллером домена-сервером глобального каталога).

3) Если вы по каким-либо причинам лишились сервера-хозяина именования доменов, то на любом другом контроллере домена вы можете принудительно захватить эту роль, но помните, что после этого изначальный хозяин роли не должен появиться в сети.

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

5) Процесс переименования существующих доменов хоть и полностью поддерживается, но является достаточно нетривиально задачей, требующей немало времени на подготовку ¹¹ и тестирование. Выполните эти задачи на изолированной среде и обязательно проверьте работоспособность доменнозависимых сервисов (например Exchange). В любом случае залогом отсутствия проблем с подобными задачами является изначально правильный подход к планированию именования доменов AD, подробнее об этом читайте в моей общей статье Active Directory Domain Services и непосредственно в Пара слов про именование доменов Active Directory.

Администрирование

Как и было сказано выше, все операции по управлению именами доменов выполняются в утилите командной строки rendom.exe. Пример работы программы ниже:

Некоторые задачи администрирования выполняются через оснастку Active Directory — домены и доверие. Например переносить роль с одного контроллера домена на другой нужно именно через эту оснастку. Допустим у вас два контроллера домена и вы хотите перенести роль хозяина схемы с DC01 на DC02:

1. Открываем оснастку на DC01, правой кнопкой нажимаем на Active Directory — домены и доверие и выбираем Сменить контроллер домена Active Directory;
2. Далее выбираем контроллер домена, на который мы хотим перенести роль (у меня это DC02, по умолчанию всегда выбирается сервер-владелец роли). Подтверждаем предупреждение;
3. Снова правой кнопкой на Active Directory — домены и доверие, но уже выбираем Хозяин операций…;
4. Нажимаем кнопку Сменить.

После этого необходимо подтвердить выбор и получить уведомление об успешном переносе роли.

На этом обзор fsmo-роли хозяин именования доменов завершен.

comments powered by HyperComments

Добрый день, коллеги!

Имею проблемы в работе домена. Такая ситуация:

Есть лес, состоящий из одного домена, в котором работают 2 контроллера домена:

1. ab12srv.AB12N.local, работающий под управлением MS Windows Server 2003 Enterprise Edition SP2. Он является мастером схемы и хозяином именования доменов + Глобальный каталог.

2. ab12srv1.AB12N.local, работающий под управлением MS Windows Server 2003 R2 Standard Edition SP2. Он является хозяином RID, PDC и мастером инфраструктуры + Глобальный каталог.

Сервер ab12srv — старый сервер, который хочу вывести из инфраструктуры и образно выражаясь «выкинуть на помойку». Для этого нужно передать 2 его роли на сервер ab12srv1 и далее понизить его до рядового сервера.

Но столкнулся со следующими проблемами:

1. Не передаются роли мастер схемы и хозяин именования доменов на сервер ab12srv1. Выдается следующая ошибка:

2. В журнале событий сервера ab12srv1 протоколируются предупреждения типа «Служба репликации файлов столкнулась с проблемами при включении репликации с «AB12SRV» на «AB12SRV1» для «c:windowssysvoldomain», использующего DNS-имя «ab12srv.AB12N.local». А
В журнале событий сервера ab12srv протоколируются предупреждения типа «Служба репликации файлов столкнулась с проблемами при включении репликации с «AB12SRV1» на «AB12SRV» для «c:windowssysvoldomain», использующего DNS-имя «ab12srv1.AB12N.local».

3. У пользователей появились проблемы с аутентификацией в домене (пользователи проходят аутентификацию не с первого раза) и с доступом к сетевым ресурсам по имени (по IP доступ к сетевым ресурсам есть), что указывает на некорректную работу DNS в частности или
домена в целом.

Я, конечно, могу принудительно передать эти 2 роли с сервера ab12srv на сервер ab12srv1 с помощью ntdsutil и команды seize, а затем понизить (может быть даже также принудительно, если по другому никак) сервер ab12srv до рядового сервера, но боюсь сломать
домен, т.к. на данный момент я до конца не понимаю, какой всё-таки из контроллеров домена «глючит» (ab12srv или ab12srv1)?

И очень прошу Вас помочь мне разобраться в этом.

Вот ipconfig -all и dcdiag с обоих контроллеров домена:

1. ipconfig -all с сервера ab12srv:

Настройка протокола IP для Windows

   Имя компьютера  . . . . . . . . . : ab12srv

   Основной DNS-суффикс  . . . . . . : AB12N.local

   Тип узла. . . . . . . . . . . . . : неизвестный

   IP-маршрутизация включена . . . . : нет

   WINS-прокси включен . . . . . . . : нет

   Порядок просмотра суффиксов DNS . : AB12N.local

AB12N — Ethernet адаптер:

   DNS-суффикс этого подключения . . :

   Описание  . . . . . . . . . . . . : Intel(R) PRO/100 S Server Adapter #2

   Физический адрес. . . . . . . . . : 00-30-48-24-8E-A3

   DHCP включен. . . . . . . . . . . : нет

   IP-адрес  . . . . . . . . . . . . : 10.12.0.200

   Маска подсети . . . . . . . . . . : 255.255.255.0

   Основной шлюз . . . . . . . . . . : 10.12.0.254

   DNS-серверы . . . . . . . . . . . : 127.0.0.1

2. dcdiag с сервера ab12srv:

Domain Controller Diagnosis

Performing initial setup:
   Done gathering initial info.

         SYSVOL has been shared.  Failing SYSVOL replication problems may cause

         Group Policy problems.
         ……………………. AB12SRV failed test frsevent
      Starting test: kccevent
         ……………………. AB12SRV passed test kccevent
      Starting test: systemlog
         An Error Event occured.  EventID: 0xC1010020
            Time Generated: 12/02/2012   20:44:24
            Event String: Dependent Assembly Microsoft.VC80.MFCLOC could

         An Error Event occured.  EventID: 0xC101003B
            Time Generated: 12/02/2012   20:44:24
            Event String: Resolve Partial Assembly failed for

         An Error Event occured.  EventID: 0xC101003B
            Time Generated: 12/02/2012   20:44:24
            Event String: Generate Activation Context failed for

         An Error Event occured.  EventID: 0x40000004
            Time Generated: 12/02/2012   20:54:49
            Event String: The kerberos client received a

         An Error Event occured.  EventID: 0x40000004
            Time Generated: 12/02/2012   20:56:31
            Event String: The kerberos client received a

         An Error Event occured.  EventID: 0x40000004
            Time Generated: 12/02/2012   21:19:56
            Event String: The kerberos client received a

         An Error Event occured.  EventID: 0x40000004
            Time Generated: 12/02/2012   21:35:42
            Event String: The kerberos client received a

         An Error Event occured.  EventID: 0x40000004
            Time Generated: 12/02/2012   21:35:43
            Event String: The kerberos client received a

3.  ipconfig -all с сервера ab12srv1:

Настройка протокола IP для Windows

   Имя компьютера  . . . . . . . . . : ab12srv1

   Основной DNS-суффикс  . . . . . . : AB12N.local

   Тип узла. . . . . . . . . . . . . : неизвестный

   IP-маршрутизация включена . . . . : нет

   WINS-прокси включен . . . . . . . : нет

   Порядок просмотра суффиксов DNS . : AB12N.local

Подключение по локальной сети 2 — Ethernet адаптер:

   DNS-суффикс этого подключения . . :

   Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 EB Network Connection with I/O Acceleration #2

   Физический адрес. . . . . . . . . : 00-15-17-63-B7-75

   DHCP включен. . . . . . . . . . . : да

   Автонастройка включена  . . . . . : да

   IP-адрес автонастройки. . . . . . : 169.254.180.233

   Маска подсети . . . . . . . . . . : 255.255.0.0

   Основной шлюз . . . . . . . . . . :

Подключение по локальной сети — Ethernet адаптер:

   DNS-суффикс этого подключения . . :

   Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 EB Network Connection with I/O Acceleration

   Физический адрес. . . . . . . . . : 00-15-17-63-B7-74

   DHCP включен. . . . . . . . . . . : нет

   IP-адрес  . . . . . . . . . . . . : 10.12.0.202

   Маска подсети . . . . . . . . . . : 255.255.255.0

   Основной шлюз . . . . . . . . . . : 10.12.0.254

   DNS-серверы . . . . . . . . . . . : 10.12.0.202

4. dcdiag с сервера ab12srv1:

Domain Controller Diagnosis

Performing initial setup:
   Done gathering initial info.

         SYSVOL has been shared.  Failing SYSVOL replication problems may cause

Что посоветуете сделать, чтобы восстановить нормальную работоспособность домена и затем корректно (без ущерба для домена) понизить сервер ab12srv до рядового сервера?