[Из песочницы] Как подменить контроллер домена и не сломать текущую инфраструктуру
Так уж получилось в нашей организации, что инфраструктуру надо было делать быстро, а на покупку лицензий требовалось время. Поэтому было решено использовать образы Windows Server 2012R2 Evaluation, а после тестового периода уже лицензировать. Тогда еще никто не знал, что нельзя просто так взять, прописать лицензию Standart в релизе Evaluation, и на выходе получить лицензионный Standart, иначе, думаю, сначала бы все таки купили лицензии. Но делать нечего, что имеем, с тем и работаем. Итак.
Задача: после покупки лицензий Microsoft на Windows server 2012R2 Standart необходимо активировать их на наших серверах. Приступаем.
При выполнении задачи была обнаружена проблема. Так как изначально мы устанавливали Windows server 2012R2 Standart Evaluation, то при попытке прописать ключ для Standart — сервер говорит, что ему этот ключ не подходит. Начали поиск решения проблемы перевода сервера из версии Evaluation в Standart. Ответ был найден на сайте microsoft в статье TechNet.
Частично статья помогла решить проблему. Мы смогли поменять версию на трех физических серверах и активировать их нашими лицензиями. Но, к сожалению, не все так просто складывалось с контроллерами домена. В вышеуказанной статье прямым текстом говорится, что контроллеры домена НЕВОЗМОЖНО перевести из выпуска Evaluation в Standart. Нам же это необходимо сделать в самые кратчайшие сроки, т.к. количество возможных /rearm у PDC закончилось, а дней до окончания ознакомительной версии осталось меньше 3-х дней.
Варианта решения вопроса я видел два. Либо поочередно между BDC и PDC передавать права хозяина схемы и прочие роли, понижать до рядовых серверов и после поднимать обратно. Но идею этого доменного волейбола я отмел, по причине того, что просто напросто делал все это впервые и боялся поломать.
Поэтому было решено поднимать новый сервер, повышать до контроллера домена и передавать ему хозяина схемы, а после выключать старый PDC и назначать новому его IP, этот вариант тогда мне показался проще и безопаснее. Замечу, что после описанных ниже событий, я по прежнему считаю это хорошим решением, по крайней мере все прошло без эксцессов, иначе бы статья имела совсем другой заголовок, или ее бы не было вовсе.
Схему можно без проблем воспроизвести в течение рабочего дня. Оставалось полтора дня, так что, помечтать о том, как я буду все это делать времени не было, надо было срочно приступать. Далее действия по пунктам.
1. Создаем новую виртуальную машину с параметрами соответствующими текущему PDC. Желательно создать на физическом сервере, на котором нет других контроллеров домена, но это если у вас несколько гипервизоров, как в моем случае, если нет, то это не принципиально, вопрос только в отказоустойчивости. Ну, а если вы работаете не с гипервизорами, а с реальными серверами, то отказоустойчивость PDC и BDC вещь и так само собой разумеющаяся.
2. Устанавливаем Windows Server 2012R2. Выбираем выпуск Standart с графическим интерфейсом. Настраиваем TCP/IP и переименовываем сервер в соответствии со стандартном наименований в IT инфраструктуре.
3. После установки в диспетчере серверов включаем серверу новые роли. Нас интересует AD, DNS и прочие роли и компоненты, используемые на текущих домен-контроллерах.
4. Повышаем сервер до контроллера домена. Проходит репликация между основным контроллером домена и новым.
5. Передаем роли хозяина схемы со старого DC на новый.
Для этого заходим на контроллер домена, которому будут назначаться роли FSMO, запускаем командную строку, и вводим команды в указанной ниже последовательности:
ntdsutil
roles
connections
connect to server <имя сервера PDC>
q
Успешно подключившись к серверу, мы получим приглашение к управлению ролями (FSMO maintenance), и можем приступать к передаче ролей:
transfer naming master — передача роли хозяина доменных имен.
transfer infrastructure master — передача роли хозяина инфраструктуры;
transfer rid master — передача роли хозяина RID;
transfer schema master — передача роли хозяина схемы;
transfer pdc — передача роли эмулятора PDC
Для завершения работы Ntdsutil вводим команду q.
6. После передачи хозяина схемы смотрим системный журнал и dcdiag на предмет ошибок. Их быть не должно. Если есть, исправляем. (я столкнулся с ошибкой dns, где сервер жаловался на неправильно указанные сервера пересылки. В этот же день я узнал, что в серверах пересылки DNS не должен быть указан сервер на котором установлен DNS (как правило указывают сервера DNS провайдера и Yandex (Google), что в общем-то логично, это по сути порождает петлю в DNS.
7. Если ошибки исправлены, или их нет. Приступаем к сменам IP-адресов. Назначаем старому PDC любой свободный IP-адрес в сети, а новому PDC назначаем адрес старого.
8. Снова проверяем на ошибки. Проводим тесты. Выключаем старый PDC и BDC. Проверяем возможность авторизации в домене. Затем оставляем включенным только BDC, проверяем принимает ли он на себя роль контроллера домена в случае недоступности PDC.
9. Если все тесты проходят удачно. Можно уничтожать старый PDC и приниматься за смену версии BDC.
10. В нашем случае cтарый PDC все еще нельзя было выкинуть на помойку так как на нем функционировала роль пространства имен DFS, а мы не знали, как ее реплицировать на новый сервер.
11. Все оказалось очень просто. Входим в графическую оснастку «Управление DFS». В «Пространстве имен» добавляем существующие пространства имен, затем каждому пространству имен добавляем сервер пространства имен и в общем-то все. Корень dfs автоматически вместе с ссылками на сетевые ресурсы появляется на c:\ и все работает. На всякий случай проверяем работу выключением старого PDC. Сначала сетевые ресурсы будут недоступны (DFS нужно 300 секунд для репликации). По истечении 5 минут сетевые ресурсы снова должны стать доступны.
12. Оставляем старый PDC выключенным и через какое то время понижаем до рядового сервера и после удаляем. Можно конечно и сразу, но мне было страшно и я до последнего не верил, что все получилось без проблем.
P.S.: Все вышеописанные действия проводились после внимательного изучения книги Windows server 2012R2 — Полное руководство. В частности глав посвященных конкретно AD, DNS и DFS, а так же контроллерам домена. Без понимания и планирования к данным действиям лучше не приступать, т.к. можно потерять рабочую инфраструктуру.
Надеюсь, для кого-то эта статья окажется полезной и нужной. Спасибо за внимание!
