Системный администратор
0,0
рейтинг
14 декабря 2015 в 16:29

Администрирование → Как подменить контроллер домена и не сломать текущую инфраструктуру из песочницы

Так уж получилось в нашей организации, что инфраструктуру надо было делать быстро, а на покупку лицензий требовалось время. Поэтому было решено использовать образы Windows Server 2012R2 Evaluation, а после тестового периода уже лицензировать. Тогда еще никто не знал, что нельзя просто так взять, прописать лицензию Standard в релизе Evaluation, и на выходе получить лицензионный Standard, иначе, думаю, сначала бы все таки купили лицензии. Но делать нечего, что имеем, с тем и работаем. Итак.

Задача: после покупки лицензий Microsoft на Windows server 2012R2 Standard необходимо активировать их на наших серверах. Приступаем.

При выполнении задачи была обнаружена проблема. Так как изначально мы устанавливали Windows server 2012R2 Standard Evaluation, то при попытке прописать ключ для Standard — сервер говорит, что ему этот ключ не подходит. Начали поиск решения проблемы перевода сервера из версии Evaluation в Standard. Ответ был найден на сайте microsoft в статье TechNet.

Частично статья помогла решить проблему. Мы смогли поменять версию на трех физических серверах и активировать их нашими лицензиями. Но, к сожалению, не все так просто складывалось с контроллерами домена. В вышеуказанной статье прямым текстом говорится, что контроллеры домена НЕВОЗМОЖНО перевести из выпуска Evaluation в Standard. Нам же это необходимо сделать в самые кратчайшие сроки, т.к. количество возможных /rearm у PDC закончилось, а дней до окончания ознакомительной версии осталось меньше 3 дней.

Варианта решения вопроса я видел два. Либо поочередно между BDC и PDC передавать права хозяина схемы и прочие роли, понижать до рядовых серверов и после поднимать обратно. Но идею этого доменного волейбола я отмел, по причине того, что просто напросто делал все это впервые и боялся поломать.

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

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

1. Создаем новую виртуальную машину с параметрами соответствующими текущему PDC. Желательно создать на физическом сервере, на котором нет других контроллеров домена, но это если у вас несколько гипервизоров, как в моем случае, если нет, то это не принципиально, вопрос только в отказоустойчивости. Ну а если вы работаете не с гипервизорами, а с реальными серверами, то отказоустойчивость PDC и BDC вещь и так само собой разумеющаяся.

2. Устанавливаем Windows Server 2012R2. Выбираем выпуск Standard с графическим интерфейсом. Настраиваем 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, а так же контроллерам домена. Без понимания и планирования к данным действиям лучше не приступать, т.к. можно потерять рабочую инфраструктуру.

Надеюсь, для кого-то эта статья окажется полезной и нужной. Спасибо за внимание!
Николай @Osennij_Lis
карма
4,0
рейтинг 0,0
Системный администратор
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

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

Комментарии (22)

  • +5
    1. Никаких PDC и BDC уже нет 15 лет. Забудьте эти термины, это было актуально ДО появления Active Directory, которая появилась в Windows 2000. Судя по всему, вам не приходилось сталкиваться с доменами Windows NT 4, поэтому я не понимаю, откуда вы вообще эти термины взяли?
    2. Слово «Standard» пишется с «d» на конце.
    3. Если вы понижаете сервер, являющийся исполнителем какой-то роли FSMO, он сам передаёт эту роль (спросит кому, если есть выбор).
    4. Чехарда с IP-адресами совершенно лишняя. Вы можете просто сделать новый DC с новыми адресами, даже можно в другой сети — главное, чтобы был доступен всем рабочим станциям (в общем, пинговался бы с них) и появился в DNS-сервере, который настроен на этих рабочих станциях. Положение всех служб указано в DNS. (Есть особенность — Exchange — но похоже это не про ваш случай.)

    В общем, вам нужно было просто поставить два новых DC, с установкой на них службы DNS, а потом понизить и удалить старые. Если их просто удалить, пришлось бы захватывать роли FSMO, что не очень хорошо, хотя в данном случае даже это не страшно — если вы уверены, что старый хозяин роли никогда не оживёт, роль не просто можно, а нужно перехватить.
    • 0
      Что-то с ходу не пойму, почему Exchange — особый случай. Вроде ведь тоже в DNS autodiscover указывается.
    • 0
      Спасибо за конструктивную критику. Вы совершенно правы, Windows NT 4 я в глаза не видел, моей первой серверной ОС была Windows Server 2003. А вот обучал меня человек работавший и с NT 4 и с более древними вещами, отсюда и тяга к архаичным названиям. Я понимаю, что сделал слишком много перестраховочных пунктов, но в этом случае я 100% знал, что ничего не сломаю в текущей инфраструктуре. В любом случае, думаю, это все равно неплохой опыт, но теперь я еще и знаю как сделать проще.
      • 0
        Ну раз поняли про PDC/BDC, то уберите «P» и «B», пусть будет просто «DC». Уровень статьи ниже плинтуса: оказывается можно вводить новые контроллеры в домен и выводить старые, вот сюрприз…
    • 0
      Ошибку из второго пункта, со словом Standard — исправил. Неловко. Не то это слово, написание которого легко забыть.
    • +1
      Гораздо веселее при переезде с одного DC на другой, если нужно еще и DHCP мигрировать, а языки редакций разные. Так мне в свое время достался 2008R2 Rus с DC, DNS, DHCP (с зарезервированными адресами) и нужно было переехать на 2012R2 Eng. Если мне не изменяет память, то проблема возникла из-за русских названий вендор классов, и бэкап настроек импортироваться не желал. Думал никогда не забуду, что сделал, но нет — забыл уже. Помню только, что найденный сценарий действий для 2003 Server не желал работать на 2008 и 2012, и быстрее всего оказалось быстро поставить пустой 2003 на вирт машину, залить туда дамп настроек ДХЦП от 2008, снова выгрузить с правильными классами и загрузить на 2012 :) С тех пор о русской WinServer в среде даже думать не хочется.
      • 0
        Помню, игрался когда-то давнов с ранними релизами Samba4, даже ещё не с релизами, а с кандидатами.

        Там была проблема — оно вообще думало, что никаких символов, кроме ASCII 7-бит не существует. В результате, добавить её контроллером в домен, сделанный в рускоязычной винде было нельзя. А наоборот — винду в AD, сделанный в самбе, можно.
  • +3
    13. Ловим ошибки, т.к. начиная с 2008 ntdsutil не вычищает данные о бывших КД.
    • 0
      Совершенно согласен, стоит добать в статью с небольшим дополнением: не всегда вычищает, а ещё точнее не удаляет такой сервер из AD, а информацию из каталога чистит 50/50.
      Честно признаться, статья слабая, но за человека порадоваться стоит, научился чему-то новому.
      ЗЫ.
      Я бы просто ввёл два новых сервера в домен сразу и перехватил бы роли.
  • 0
    5.
    ntdsutil
    Activate instance NTDS
    дальше по тексту

    хинт:
    nstdsutil замечательно воспринимает неполное написание команд. Вместо transfer infrastructure master можно писать tra infra mast меньше шансов опечататься.
  • 0
    Ну и есть ещё такая замечательная вещь: Windows Server Migration Tools
  • 0
    «Перенос мастера ролей на новый ad dc » гугл отвечает простыней релевантных статей, а если перевести на английский то еще и technet статьей соответствующей похвастаться может, вы пробовали гугл прежде чем в книжки зарываться? Ну и присутствие в статье «transfer pdc — передача роли эмулятора PDC», а после этого обзывание ad dc ничем иным как «PDC» вызывает легкое недомогание.
    • 0
      кстати, кто-то может объяснить, зачем вообще эта роль до сих пор имеется? Кто-то использует рабочие станции Windows NT вместе с Windows Server 2012 R2?
      • 0
        Как минимум, смена паролей на нём как на единой точке обрабатывается. А название, да, унаследованное.
    • 0
      А мы с коллегами давно хозяина FSMO зовем PDC. И знаем что это не верно, но как-то привычно…
      • 0
        Дело в том, что ролей FSMO пять. И всех они могут быть на разных DC. Какой из них станете называть PDC? Или все сразу?
        • 0
          Вы меня поставили в тупик) У лес маленький, всё как-то совсем просто, хозяин один.
  • 0
    По-моему, указанная в статье книга была прокурена не достаточно хорошо.
  • 0
    т.е. у вас стояли не активированные ОС в продакшине?
    • 0
      Не страшно, я тоже так делаю, поднимаю сервер, полностью настраиваю, даю на обкатку пару недель — потом активирую.
    • 0
      В одном госучреждении они вообще все неактивированные стояли. Один из КД год проработал неактивированный. И ничего не сломалось. Ну, фон рабочего стола чёрный и предлагал активироваться при каждом входе. Никаких ограничений функионала не заметили.

      Причём придраться было трудно — всё честно купленное, просто разворачивали (считай осваивали) очень долго и разные организации, никто не был уверен, что это последняя версия, всё не будет завтра снесено до основания а затем построено с нуля, поэтому никто и не решался активировать.
      • 0
        Спустя более чем месяц скажу. «Не бери ОЕМ — не будет проблем». При корп лицензиях KMS навсегда решает проблему активации внутри корпоративной сети. При том, что ключ от 2012R2 даже на KMS-сервере 2008R2 с определенным апдейтом, активирует все версии windows ниже 2012R2, включительно, десктопные тоже. При условии что они вообще умеют активироваться через KMS.

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