Light-electric.com

IT Журнал
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Перенос контроллера домена

Перенос контроллера домена на новый сервер

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

  • Домен: company.local;
  • Старый сервер: Win2003, AD, DNS, DHCP, IP=192.168.0.100, имя=dc01;
  • Новый сервер: Win2003, IP=192.168.0.101, имя=dc02;

1. Проверка действующего контроллера домена

На старом сервере запускаем утилиты dcdiag и netdiag и убеждаемся что никаких ошибок они не находят. Эти утилиты входят в состав Support Tools и если при запуске одной из утилит выскакивает сообщение

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

2. Установка дополнительного контроллера домена

Далее необходимо поднять дополнительный контроллер домена на новом сервере (тот который 192.168.0.101). Для этого нужно запустить (Пуск—>Выполнить или Start—>Run) на нем команду

и в появившемся окне выбрать Additional domain controller for an existing domain

После установки AD, перезагружаемся.

3. Установка DNS и DHCP

Устанавливаем DNS и если нужно, то DHCP на новый сервер. Заходим в Установку и удаление программ (Add or Remove Programs) и выбираем пункт установка компонентов Windows (Add/Remove Windows Components). В разделе Сетевые службы (Network Services) ставим галочки напротив DNS и DHCP и устанавливаем их.

Вполне вероятно что при установке AD, заодно поставился и DNS, поэтому не пугайтесь если DNS уже установлен.

На обоих контроллерах домена выставляем в настройках DNS, адрес нового сервера.

4. Перенос базы DHCP

Если нужно перенести базу DHCP, на старом сервере выполняем команду:

переносим полученный файл на новый сервер и на новом сервере выполняем команду:

Ну и соответственно в настройках DHCP выставляем всем клиентам DNS адрес нового сервера 192.168.0.101

5. Проверка контроллеров домена на ошибки

После всех предыдущих манипуляций, ждем минут 15-20, чтобы дать новому серверу перенести все настройки и записи в AD со старого. После чего, запускаем на обоих серверах уже знакомые нам утилиты dcdiag и netdiag и убеждаемся в отсутствии ошибок.

6. Перемещение Global Catalog

Теперь настала очередь перенести Global Catalog на новый сервер. Открываем на новом сервере Active Directory — сайты и службы (Sites and Services) —> Сайты (Sites) —> имя_сайта —> Серверы (Servers). Выбираем новый контроллер домена и в правом окне на объекте NTDS Settings выбираем Свойства (Properties). В появившемся окне ставим галку Global Catalog.

Ждем минут 5-10, в логах должно будет появиться сообщение This domain controller is now a global catalog, после чего можно удалять Global Catalog на старом сервере. Процедура таже, только теперь выбираем старый сервер и снимаем галку Global Catalog.

7. Перенос ролей FSMO

Для начала посмотрим, кто же все таки является держателем ролей FSMO-ролей в домене, в этом нам поможет команда:

Результат будет примерно таким:

Как видно из вывода, держателем ролей является наш старый сервер dc01. Исправим это недоразумение. Все дальнейшие действия производим на новом сервере.

Передача ролей хозяин RID, основной контроллер домена и хозяин инфраструктуры

Открываем оснастку Active Directory — пользователи и компьютеры (Users and Computers), щелкаем правой кнопкой по имени сайта и выбираем меню Хозяева операций (Operations Masters). В появившемся окне, на всех 3-х вкладках жмем на кнопку изменить (change) и соглашаемся с применением изменений.

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

Открываем оснастку Active Directory — домены и доверие (Domain and Trusts), и точно так же выбираем меню Хозяева операций (Operations Masters). В появившемся окне жмем на кнопку изменить (change) и соглашаемся с применением изменений.

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

С передачей этой роли все происходит немного посложнее. Для начала нужно зарегистрировать в системе библиотеку schmmgmt.dll. Для этого выполняем команду:

Далее запускаем оснастку mmc:

и в появившемся окне в меню файл выбираем пункт Добавить или удалить оснастку (Add/Remove Snap-in). Далее Добавить (Add) и Схема Active Directory (Active Directory Schema).

И добавляем схему. Далее так же выбираем меню Хозяева операций (Operations Masters). В появившемся окне жмем на кнопку изменить (change) и соглашаемся с применением изменений. Если в поле изменить будет стоять адрес старого сервера, то достаточно выбрать пункт меню Изменение контролера домена (Change Domain Controller) и выбрать новый домен контроллер, после чего опять попытаться изменить хозяина.

Ну что, все роли успешно перенесены на новый сервер.

8. Удаление старого контроллера домена

Теперь настала пора удалить старый домен контроллер из сети. Запускаем:

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

Перенос контроллера домена ActiveDirectory на новый сервер

В этой статье хочу рассмотреть процесс переноса контролера домена ActiveDirectory c Windows 2003 на Windows Server 2008.

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

Дальше необходимо удостовериться, что пользователь под которым мы будем все переносить состоит в следующих группах:

  • Enterprise admins
  • Schema Admins
  • Domain Admins

Дальше берем с установочного диска Windows 2008 папку support, находим в ней папку adprep и переходим в нее на исходнос сервере. При миграции с 2003 на 2008 нужно брать adprep с 2008-й винды.

Подготавливаем все к миграции:

Если исходный сервер имеет операционку x64, тогда используем вот такие команды. Первая может выполняться довольно долго:

Так же рекомендуется выполнить вот такую команду. Даже если вы и не собираетесь использовать в вашей сети контроллеры домена только для чтения (Read Only Domain Controller — RODC), она уберет ненужные сообщения об ошибках в журнале событий.

С исходным севером все готово. Подключаемся к серверу №2 — тот на который переезжаем. Запускаем консоль от и выполняем:

Это открывает окно установки AD. Жмем Next .

Я добавлял контроллер в уже существующий лес, поэтому выбрал соответствующий пункт.

Дальше установщик предложит имя домена и имя пользователя от которого устанавливается служба.

Дальше Вы получите возможность выбрать сайт в который должен быть добавлен контролер. Менеджер установки сам предложит это на основе ip адреса, в зависимости от того к какому из сайтов относится подсеть.

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

Осталось перенести роли FSMO на новый сервер. Для Этого нужно запустить консоль под названием Active Directory Schema . Для этого переходим в меню Пуск/Start и выбираем пункт Запуск/Run. В появившееся окно вводим mmc.exe и жмем OK .

В появившемся окне из меню File выбираем пункт Add/Remove Snap-In:

Из списка в левой колонке выбираем Active Directory Schema жмем кнопку Add-> потом OK .

В результате таких телодвижений в левой колонке консоли появится элемент Active Directory Schema . Жмем правой кнопкой и выбираем Change Active Directory Domain Controller .

В появившемся окошке выбираем контролер домена на котором крутятся роли FSMO:

С выбором трудно ошибиться. Если Вы выберете КД который не управляет FSMO, получить вот такую ошибку:

Теперь мы подключены к главному держателю ролей. Жмем правой кнопкой на Active Directory Schema и выбираем пункт Operations Master :

В окошке выбираем куда перенести FSMO и жмем ОК.

Для переноса ролей RID, PDC и Infrastructure Master запускаем Active Directory Users and Computers (Пуск/Start->Панель Управления/Control Panel->Администрирование/Admin tools). Дальше по аналогии с предыдущим шагом подключаемся к исходному серверу. Правой кнопкой мыши жмем на Active Directory Users and Computers и выбираем пункт Operations Master . В появившемся окне переходим на нужную вкладку RID, PDC или Infrastructure и выбираем новый серсер для роли.

Читать еще:  Установите a запись для домена

Для того, что бы перенести роль DNS нужно запустить консоль Active Directory Domains and Trusts . Дальше по аналогии с предыдущим шагом подключаемся к исходному серверу. Правой кнопкой мыши жмем на Active Directory Domains and Trusts и выбираем пункт Operations Master . В появившемся окне выбираем новый серсер для роли.

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

Updated: April 30, 2014

You May Also Enjoy

Установка nginx из исходников

В разных случаях приходится компилировать ПО имея его исходники. Опять же хочу разводить демагогию на эту тему. Хочу рассказать как собрать nginx последней в.

Уникальные IP адреса в access.log Apache

less than 1 minute read

Получить список уникальных IP адресов в лог файле вэбсервера Apache можно с помощью:

Установка WireShark на Ubuntu 16.04/14.04

less than 1 minute read

WireShark предоставляет удобный функционал для анализа сетевого трафика.

Проблемы с ttf-mscorefonts-installer на Ubuntu 16.04

Сегодня меня в конец достало назойливое уведомление о том, что ttf-mscorefonts-installer не смог установить все, что ему нужно.

Переезд на новый домен Active Directory

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

Во втором случае все относительно понятно, а вот границы наступления первого для многих очень размыты. Это может быть например миграция с одноуровневого домена (single-label domain) или что-то другое. Ниже в статье постараюсь пролить свет на эти окутанные туманом рассуждения.

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

Переезд на новый домен Active Directory

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

Объективные причины

В каждом случае потребность переезда нужно решать индивидуально, основываясь на многих факторах, но что можно сказать относительно точно: необходимость переезда в связи с архитектурными особенностями вашего домена сильно преувеличена. Даже в случае с SLD сильно перегибают палку — такой домен поддерживается во многих продуктах последних версий (например Exchange 2016 поддерживает).

На мой взгляд обязательно нужно переезжать с доменов а-ля microsoft.com, то есть если вы умудрились взять для AD имя реально существующего домена, ещё и очень популярного. Во всех остальных случаях оставайтесь спокойно на существующих доменах.

А может оставить все как есть?

Действительно, а почему бы и нет? Но даже если у вас все в состоянии «работает — не трогай», то все равно находятся системные администраторы, которые скажут: «Надо переехать на новый домен, чтобы начать с чистого листа, чтобы все было сделано правильно.» И таких товарищей достаточно много (например одно из последних обсуждений на форуме Technet).

Справедливости ради надо отдать должное тем людям, которые стремятся сделать что-то лучше, но в случае переезда на другой домен AD можно пойти другим путем. А именно допилить существующий домен до приемлемого состояния.

Именно об этом варианте я и собираюсь рассказать на примере доведения до ума старого домена, который был поднят ещё на Windows Server 2000.

Задачи

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

Начнем разбор с самого начала.

Резервное копирование

Первое, о чем вам нужно задуматься — как вы будете бэкапить КД. Если у вас уже настроено регулярное резервное копирование, это значительно упрощает ситуацию. В моем случае использовался DPM 2012 R2 с резервным копированием контроллеров домена целиком как виртуальных машин, а также их содержимого (например в случае, если понадобится провести полномочное восстановление, то состояние системы будет как нельзя кстати).

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

  • Выполняйте контрольное резервное копирование между важными изменениями в ядре инфраструктуры;
  • Сохраняйте резервные копии до тех пор, пока вы не убедитесь в нормальном функционировании всех КД;
  • Резервное копирование выполняйте поддерживаемыми средствами (например VSS);
  • Обязательно убедитесь, что вы имеете восстанавливаемые резервные копии! Да, забэкапить мало, надо ещё и проверить а восстанавливаются ли бэкапы нормально или нет.

Я советую все изменения обкатывать на тестовой инфраструктуре, которую вы как раз сможете создать из существующих бэкапов.

Диагностика AD

Обязательно пройдитесь по всем КД и проверьте состояние их здоровья:

  • Проанализируйте ошибки AD DS, DNS и др. служб в просмотре осбытий;
  • Проверьте репликацию 2 и состояние КД командами repadmin и dcdiag;
  • Установите все обновления ОС.

Только при отсутствии проблем приступайте ко всем изменениям.

Имя домена

Некрасивое или «неправильное» по мнению сисадминов имя домена наиболее часто является главным аргументом для переезда на другой домен. С другой стороны, что такое «правильное» имя домена? Да такого нет в принципе! Есть рекомендации какие домены лучше не использовать (например те же SLD), но это всего лишь рекомендации, которые к исполнению не обязательны. Все зависит от вашего окружения и преследуемых целей.

Админы говорят: «У меня домен domain.local, а я хочу domain.ru как основной домен организации«. То есть они считают домен domain.ru правильным. Дак вот, я скажу, что нет, это неправильное имя домена. Как минимум потому что вам придется очень сильно запариться с разруливанием запросов DNS к реальному DNS-имени domain.ru.

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

Теперь суть вопроса: чтобы пользоваться красивыми именами и логиниться во все доменные сервисы по адресу электронной почты достаточно создать дополнительный UPN-суффикс и назначить его всем нужным учеткам. При этом неважно какое у вас имя домена. Для переезда в облако доп. суффиксов достаточно (если у кого сомнения, читайте Локальная инфраструктура и Azure AD)

Перенос DNS-зоны _msdcs.ForestName

Это первое, с чего я начал. Почему? Нужно привести DNS в нормальное состояние, ведь от этого сервиса зависит здоровье AD в целом.

Для доменов, созданных на Windows Server 2000, зона _msdcs.ForestName располагается на уровне домена и желательно её перетащить на уровень леса, как это по умолчанию сделано на новых доменах AD на Windows Server 2003 и старше:

Сам процесс подробно расписан в официальной документации и на моем блоге в статье DNS-зона _msdcs.ForestName отсутствует.

Изменения вполне можно проводить в рабочее время, но все же обкатайте все на лабе.

Настройка защищенных динамических обновлений DNS

Вероятнее всего большинство разрешают незащищенные обновления DNS 3 . Тем не менее, согласно лучшим практикам рекомендуется разрешать динамические обновления только для авторизованных клиентов 4 .

Раз уж вы решили привести домен к эталонному виду, займитесь и DNS-записями. Тем не менее, не включайте слепо защищенные обновления, возможно в вашей инфраструктуре есть устройства со статикой вне домена, которым необходимо обновлять записи самостоятельно.

Не забывайте, что вы можете настроить обновление клиентских DNS-записей на стороне DHCP-сервера, если он развернут на Windows Server. Изменения можно проводить в рабочее время (я бы даже сказал рекомендуется проводить в рабочее время), будет возможность оперативно отлавливать проблемы пользователей.

Читать еще:  Постоянно блокируется учетная запись в домене

Настройка зон обратного просмотра

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

Изменения можно проводить в рабочее время.

Обновление уровней леса и домена

Нет никаких причин сидеть на старых уровнях леса и домена 5 и лишь ограничивать себя в функциональности AD. Например пользуйтесь корзиной AD 6 , повысив уровень леса до 2008 R2 и активировав соответствующую функцию.

Повысьте до максимально возможных значений уровни леса и домена (зависит от того на каких версиях ОС у вас работают КД) 7 . Задача относительно безболезненная, можно выполнять её в рабочее время.

Переезд с FRS на DFS-R

Уже с Windows Server 2008 FRS не считается надежной и устарела, а на дворе 2017 год. Смело переезжайте на DFS-R, к тому же последние на сегодняшний момент версии ОС уже перестали поддерживать FRS вообще (то есть даже новые КД на Windows Server 2016 в домен вам не запилить).

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

Процесс миграции вполне возможно проводить в рабочее время.

Настройка межсайтовой топологии (если актуально)

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

Сайты AD 8 созданы для того, чтобы «рассказать» Active Directory о реальной физической топологии сети, на основе которой AD построит топологию репликации оптимальным образом. По идее разбивать инфраструктуру на сайты нужно сразу как только один любой КД появляется в удаленном расположении (то есть вне локальной сети). Но и тут не все так просто, о чем мягко намекает объем гайда (см. статью Active Directory Design Guide) по планированию AD, в котором много внимания уделено именно сайтам.

Выполняйте плановый вывод контроллеров домена на устаревших ОС.

Рекомендации по best practice

Если соберетесь перелопатить инфраструктуру ради приведения ядра к идеальному виду, то вам непременно придется выводить старые КД из работы и вводить новые. Когда будете выводить старые КД, не забудьте:

  • Предварительно заранее исключить из раздачи DHCP его адрес;
  • Предварительно перенастроить сетевые настройки клиентов (в том числе и рядовые серверы) для исключения адреса КД (например сделайте это просто удаленно Заметки: Удаленное изменение сетевых настроек);
  • Если выводимый КД является ещё и держателем ролей FSMO, позаботьтесь об их переносе (подробнее об FSMO читайте в FSMO — Fexible Single Master Operations), не забудьте о перенастройке времени;
  • После понижения измените сетевые настройки каждого КД, убрав адрес старого;
  • После понижения вычистите этот бывший КД из DNS — уберите из списка серверов имен каждой зоны (в том числе и делегирований, например _msdcs);
  • После понижения удалите КД из оснастокПользователи и компьютеры или Сайты и службы (при этом сервер останется в списке обычных).

Как только введете новый КД в работу:

  • Отредактируйте сетевые настройки каждого КД для включения в список DNS-серверов адрес нового КД;
  • Добавьте адрес нового КД (если он является ещё и DNS-сервером, что желательно) в списки серверов имен каждой зоны DNS;
  • Проверьте корректность работы нового КД согласно официальным инструкциям 10.

Передача/захват ролей FSMO на другой контроллер домена Active Directory

В этой статье мы рассмотрим, как определить контроллеры домена с ролями 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

Можно просмотреть 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

Или можно получить 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 недоступен/вышел из строя)

Читать еще:  Домен outlook com

Передача 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

  1. На контроллере домена откройте командную строку и введите команду: ntdsutil
  2. Наберите команду: roles
  3. Затем: connections
  4. Затем нужно подключиться к DC, на который вы хотите передать роль. Для этого наберите: connect to server
  5. Введите q и нажмите Enter.
  6. Для передачи FSMO роли используется команда: transfer 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

Перенос роли хозяина операций на контроллере домена Windows 2012

Содержание

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

  • MYDOMAIN.LOCAL — наш домен под управлением Active Directory в Windows 2012 Server
  • DC1 — единственный контроллер домена
  • DC2 — новый добавляемый сервер, который будет вторым контроллером домена и впоследствии хозяином операций

После установки на Windows 2012 Server роли «Доменные службы Active Directory» и повышения уровня сервера до контроллера домена (см офиц инструкцию) необходимо перед дальнейшими действиями дать несколько часов на синхронизацию между контроллерами доменов.

Затем следует проверить насколько гладко новый котроллер вошёл в домен.

Можно альтернативно запросить туже информацию непосредственно из каталога Active Directory:

Посмотрим краткий отчёт о проведённых между контроллерами репликациях, есть ли что-нибудь в очереди, можно также посмотреть более подробный отчёт:

Если репликации не были успешными, то можно запустить репликацию принудительно, но при этом командный интерпритатор cmd должне быть запущен с административными правами:

Командой dcdiag можно более подробно диагностировать состояние контроллера домена, а также отдельно запустить более подробные тесты для проверки разных служб (офиц. описание)

Прежде чем начать перенос ролей, желательно добиться отсутствия ошибок в dcdiag!

Алгоритм переноса ролей FSMO (Flexible Single-Master Operations) такой же как и при захвате. В первом случае используется работающий главный контроллер домена (PDC), и переносимые роли на нём отключаются, если же он потерян, то роли захватываются новым контроллером принудительно.

Посмотрим список контроллеров домена mydomain.local:

Выясняем, кто из контроллеров является хозяином операций:

Перенос ролей можно сделать двумя способами:

1. через оснастку «Active Directory — Домены и доверие», открыв её из Диспетчера серверов — Средства.

2. консольной утилитой управления доменом ntdsutil (офиц. документация). Если роли передаются, то используем команду transfer, если же захватываются, то seize. Ниже приведён алгоритм захвата ролей новым контроллером dc2:

Находясь в разделе fsmo maintenance можно узнать список всех ролей, послав команду ?.

В случае успешного захвата мы должны увидеть следующее

Некоторые примеры диагностики проблем с контроллерами домена рассмотрены в примерах команды dcdiag

DNS не удаётся разрешить IP-адрес

dcdiag выдаёт ошибку DNS:

Нужно проверить существует ли обратная DNS зона и синхронизирована ли она между контроллерами.

  • Детальная проверка службы DNS (может занять пару минут):
  • Рекомендации по настройке службы DNS на контроллере домена
  • DNScmd — консольная утилита для управления DNS сервером (офиц. описание)

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

repadmin /showrepl выдаёт ошибку:

Запустить репликацию вручную и командной строки с административными правами

На контроллере нет сетевых ресурсов NetLogon и SysVol

Эта ошибка означает, что репликация данных с главного контроллера домена (хозяина операций) на проблемный не была произведена до конца.

Доступность сетевых ресурсов можно проверить командой:

Исправность ресурсов SysVol и NetLogon можно проверить командой:

Официальную инструкцию по пересозданию ресурсов NetLogon и SysVol на английском можно прочесть в статье Restoring and Rebuilding SYSVOL. Ниже приведён краткий алгоритм этого процесса.

Ссылка на основную публикацию
Adblock
detector