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

Восстановление резервного контроллера домена (Domain Controller — DC), на самом деле, процедура довольно несложная, и описать её можно буквально в несколько строк. Однако, я постараюсь несколько структурировать процесс и пошагово применить его в практической части, дабы растянуть это на целую статью-шпаргалку. :)

Нередка ситуация, когда резервному контроллеру домена не уделяют особого внимания. Это не так страшно, если других ролей на сервере не выполняется — ведь он резервный, и случись с ним что — всегда есть основной. Сейчас, в поколении повальной виртуализации, ситуация несколько изменилась. Хотя бы уж наверняка резервный DC будет установлен на качественном железе, ибо на плохом железе организовывать хост для виртуальных машин дело весьма рисковое, но ещё не в столь давние времена очень многие организовывали резервный DC на каком-нибудь самом захудалом и дешевом железе — просто для того, чтобы он был.
Итак, свершилось:

1. Windows Server 2008 Std SP2 – основной DC
2. Windows Server 2003 R2 Std SP2 – резервный DC

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

План работ:

1. Резервное копирование основного DC.
2. Удаление данных о резервном DC из Active Directory (AD).
3. Создание виртуальной машины (vm) с Windows Server 2008 R2 на Hyper-V.
4. Создание нового резервного DC на vm.
5. Устранение ошибок.
6. И ещё несколько «вкусных плюшек».

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

Перед конфигурированием любого сервера я всегда рекомендую сделать резервное копирование. Для этого выбираем в меню администрирования систему архивации данных Windows Server, либо пишем в командной строке wbadmin.

wbadmin

В данном случае нам понадобится однократная архивация.

В мастере однократной архивации выбираем Другие параметры → Настраиваемый и выбираем системный том для архивации.

В качестве хранилища, для наших задач подойдет использование локального диска этого же сервера.

wbadmin

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

wbadmin

Затем выбираем тип архивации и начинаем архивацию по завершению которой, можем смело конфигурировать AD не боясь потерять единственный DC и целый домен, соответственно. Добавлю, что кроме использования резервного копирования системного раздела целиком, можно было бы использовать функцию snapshot утилиты для обслуживания базы AD — ntdsutil. Так как вносить изменения планируется только в Active Directory, в принципе, её снимка вполне хватило бы для восстановления нужного состояния на случай неудачи. Плюс к тому snapshot мы сняли бы гораздо быстрее, но я уж решил перестраховаться и всё-таки зарезервировать системный раздел целиком.

2. Удаление данных о резервном DC из AD.

Удаление данных из AD при неудачном понижении роли контроллера домена (наш случай тоже подходит) в Windows Server 2008 делается крайне просто! Припоминаю, что в Windows Server 2003 выход из подобной ситуации требовал гораздо больших навыков «колдовства» (в частности с ntdsutil), но, начиная с 2008, Microsoft успешно допилила этот сценарий, упростив его буквально до двух кликов мышкой! У MS есть полезная статья на этот счет: «Удаление данных из Active Directory после неудачного понижения роли контроллера домена». Так вот, цитата из неё всего в несколько строк:
Если объект NTDS Settings не был удален корректно (например, после попытки понижения роли), администратор может вручную удалить метаданные объекта сервера. В ОС Windows Server 2008 и Windows Server 2008 R2 администратор может сделать это, удалив объект сервера в оснастке "Пользователи и компьютеры Active Directory".
И всё. Всё остальное множество букв написано об использовании утилиты ntdsutil в Windows Server 2003. Не возбраняется также использовать ntdsutil и для Windows Server 2008, но мы пойдем простым путем. Убедиться в том, что резервный DC действительно мертв можно, например, с помощью команды dcdiag /e. После выполнения обязательных начальных проверок сразу видно, что живой сервер у нас srv, а тот, что нужно удалить — srv2.

dc_recovery07

Ниже, в основных проверках, там будет много подробной информации, среди которой сбои при попытках последних репликаций, даты возникновения сбоев и ещё много всего полезного, но для статьи не сильно важного. Итак, приступим к удалению. Открываем оснастку «Active Directory — пользователи и компьютеры», набрав в командой строке dsa.msc, либо выбрав её из меню Пуск → Администрирование → Active Directory – пользователи и компьютеры.

Открываем ветку домена, открываем контейнер Domain Controllers и просто-напросто удаляем второй контроллер домена, кликнув по нему правой кнопкой мыши и выбрав «Удалить».

Получаем вполне резонный вопрос, на что отвечаем помечанием галочкой ответа с описанием нашей ситуации и жмем «Удалить» ещё раз.

Эта простая процедура позволила нам сэкономить время на удалении через ntdsutil, но есть ещё несколько эстетических нюансов. Открываем оснастку «Active Directory – сайты и службы», набрав в командной строке dssite.msc, либо выбрав её из меню Пуск -> Администрирование → Active Directory – сайты и службы.

dc_recovery11

Открываем контейнер Sites, выбираем нужный сайт (в моем случае — единственный), Servers и видим, что объект srv2 пока по-прежнему находится на своём месте, хоть уже и без вложенного объекта NTDS Settings.

Также, просто удаляем его кликнув правой кнопкой мыши и выбрав «Удалить».

NTDS Settings

Теперь можно удалить все упоминания о старом сервере в DNS. Открываем оснастку «DNS», набрав в командной строке dssite.msc, либо выбрав её из меню Пуск -> Администрирование → DNS.

DNS

И также удаляем, кликая правой кнопкой мыши и выбрав «Удалить», везде где находим упоминания о нём по имени, или IP-адресу (srv2 – 192.168.2.250 в моем случае). Скорее всего, как минимум это будут сервера имен (NS) в зоне прямого и обратного просмотра, и А-записи узлов. Далее я выделил парочку претендентов на удаление для примера:

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

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

Тот же «dcdiag /e» теперь и не заикнется о существовании srv2 при выполнении обязательных начальных проверок и далее, в основных проверках, также не будет ни слова о неудачных репликациях.

dcdiag

При попытке сменить контроллер домена в оснастке «Active Directory – пользователи и компьютеры» кроме существующих контроллеров ничего быть не должно.

Заодно вернусь к утилите ntdsutil и способу удаления через неё. На определенном этапе, при подготовке к удалению DC также будет видно, что старого DC больше нет.

ntdsutil

Для примера, приведу полный скриншот до этого же места, но до удаления DC.

ntdsutil

И полную историю команд до удаления я привел не просто так. Дело в том, что после вышеперечисленных команд, до полного удаления DC средствами утилиты ntdsutil с этого места оставалось бы всего несколько команд — это:

select server 1 – выбор удаляемого сервера из списка
q – выход из процедуры select operation target в меню metadata cleanup
remove selected server – удаление выбранного сервера (srv2)
Кнопка Yes – подтверждение на удаление

Тоже не сильно сложно, но чуть дольше при одинаковом результате. Зато можно сделать это, как тру-админ через консоль под овации изумленной публики! :) Команды эти весьма полезны и лишний раз упомянуть их для закрепления, пожалуй, не лишне. Я склонен считать, что вообще любые команды полезны — всегда нужно стараться знать консольную альтернативу, чтобы понимать откуда ноги растут.

Создание VM на Hyper-V.

Тут всё просто и интуитивно понятно, но я вкратце опишу для тех, кто не имел дело с Hyper-V. Подключаемся к серверу Hyper-V (у меня это Windows Server 2008 R2 с Hyper-V ролью). Открываем оснастку Диспетчер Hyper-V через меню Пуск -> Администрирование -> Диспетчер Hyper-V, или набираем в командной строке vitrmgmt.msc, если Hyper-V установлен в Core версии.

запуск Hyper-V

В панели действий (справа) выбираем Создать -> Виртуальная машина.

создание VM на Hyper-V

В мастере создания виртуальной машины вводим имя (я выбрал более понятное srv-dc2, нежели старое srv2) и меняем, если нужно, расположение файлов виртуальной машины.

имя и расположение vm

Выделяем нужное количество оперативной памяти (RAM). Согласно минимальным системным требованиям к установке Windows 2008, можно использовать 512 МБ, рекомендуемые же требования предполагают использование 2 ГБ и выше. Я буду следовать рекомендуемым требованиям и выделю 2 ГБ.

выделение памяти RAM

Следующим этапом нужно выбрать подключение виртуальной машины к виртуальному свитчу (его название может быть произвольным). Выбираем сетевой адаптер, привязанный к виртуальной сети. (О создании виртуальной сети упомянуто в статье “Настройка роли Hyper-V и перенос Exchange 2007 на Hyper-V”).

vSwitch

Создаем виртуальный жесткий диск (VHD). Минимальные требования к дисковому пространству Windows Server 2008 — 10 GB, рекомендуемые — 40 GB и более. Под наши цели 60 Гб должно хватить с запасом.

размер vhd

И источник для установки — у меня это образ дистрибутива Windows Server 2008 R2 на жестком диске.

выбор ISO

Сверяем итоговые настройки, жмем готово — и виртуальная машина в полной готовности ждёт в выключенном состоянии. Выбираем её и в контекстном меню нажимаем Пуск, либо Пуск в панели действий.

включение vm

После запуска выбираем “Подключить” также в контекстном меню, либо в панели действий.

подключение к vm

Далее запускается стандартный процесс установки Windows, который описывать смысла нет. Скажу лишь, что для виртуальной машины подобного назначения нет смысла делить жесткий диск, по-моему мнению, так как бэкапиться она умеет целиком, а вот ситуация, когда, например, нужно 10 ГБ свободного объема, а у нас на диске C: осталось 8 ГБ и на D: 5 ГБ, либо на С: закончилось место для установки обновлений, а на D: его ещё куча — запросто могут возникнуть. Поэтому, в борьбе за каждый МБ и гибкость системы — я разметил диск одним разделом.

Будем считать, что Windows установлена, активирована, сеть настроена, vm введена в домен и все обновления установлены. Настало время сделать из неё контроллер домена.

Создание нового резервного DC на vm.

Поскольку на vm установлена более поздняя версия Windows, чем на существующем DC, сначала нужно зайти на существующий DC для подготовки леса и домена. Далее, на нём нужно будет запустить средство подготовки adprep, которое находится на установочном диске в папке support\adprep с ключом /forestprep для обновления данных леса и с ключом /domainprep для обновления данных домена. Запускаем командную строку от имени администратора и вводим команду adprep /forestprep.

adprep

Далее следует предупреждение о Windows 2000, которых у нас нет и в помине, поэтому смело жмем C и Enter.

adprep

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

adprep /forestprep

Теперь подготавливаем домен с помощью команды adprep /domainprep.

adprep /domainprep

На этом существующий DC можно покинуть и зайти на “новоиспеченный” сервер (srv-dc2) учетной записью с правами администратора домена для создания нового DC. Выбираем меню Пуск -> Выполнить (или нажимаем сочетание клавиш Win+R) и выполняем команду dcpromo.

dcpromo

Эта команда открывает мастер установки доменных служб Active Directory. На экране приветствия жмем Далее, не ставя галку на расширенном режиме установки.

экран приветствия dcpromo

Следующим этапом, читаем полезную информацию о совместимости операционных систем и также жмем Далее.

совместимость систем

Так как домен у нас остается тот же, добавляется лишь ещё один DC, выбираем — Существующий лес -> Добавить контроллер домена в существующий домен.

Вводим имя существующего домена и оставляем текущие учетные данные для выполнения процедуры.

имя домена

Если б доменов было несколько, то на этом шаге предстояло бы выбрать для какого именно домена мы делаем дополнительный DC, однако в моём случае выбор очевиден.

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

Выбор сайтов у меня тоже не блещет разнообразием.

выбор сайта

В качестве дополнительных параметров однозначно не повредит второй DNS-сервер, да глобальный каталог очень пригодится серверу Exchange в случае внезапной неисправности одного из DC.

DNS GC

Сообщение невозможности делегирования DNS-сервера игнорируем, нажав Да.

делегирование DNS-сервера

Не вижу смысла в изменении расположения файлов Active Directory на виртуальной машине — оставляем по умолчанию.

NTDS

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

обследование текущего леса

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

перезагрузка

5. Устранение ошибок.

Итак, резервный контроллер домена поднят. Собственно, на этом можно и закончить, но выполнив dcdiag /e с основного DC я получил несколько ошибок, которые также откомментирую на случай, если они попадутся и у вас. В основном это ошибки, связанные с доступом к журналу событий: ошибка 0x6ba “Сервер RPC недоступен”.

0x6ba

Согласно рекомендациям Microsoft данную ошибку можно просто игнорировать, но я привык к красоте в логах, поэтому попробую её устранить. Для устранения идём на srv-dc2 и запускаем брандмауэер Windows с помощью команды firewall.cpl, либо выбрав его через меню Пуск -> Панель управления -> Безопасность -> Брандмауэр Windows.

firewall

В нём, в левой части, выбираем “Разрешить запуск программы или компонента”

разрешить запуск программы

И ставим галку в столбце домена напротив “удаленного управления журналом событий”.

С журналом разобрались. Как видно по предпоследней ошибке в скрине вывода dcdiag, если развернуть картинку (да, все картинки в статье разворачиваются по клику, что даёт больше информации), системе не понравился тип запуска службы:
Неверный тип запуска службы: w32time на SRV-DC2, текущее значение - DEMAND_START, ожидаемое значение - AUTO_START.
На такую банальную проблему есть не менее банальное решение. Открываем меню Пуск -> Администрирование -> Диспетчер сервера. В диспетчере сервера открываем Конфигурация -> Службы. В службах ищем службу времени, выбираем правой кнопкой мыши Свойства и выбираем тип запуска службы: Автоматически.

w32time

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

Впереди у нас ещё одна интересная тема, так что — продолжение следует…

Запись опубликована в рубрике IT, Главная с метками . Добавьте в закладки постоянную ссылку.

4 комментария: Удаление и установка контроллера домена на практике.

  1. Denis говорит:

    Тема огромная. Одним словом, это инструкция создания виртуального сервера под домен?

    • Modicus говорит:

      Именно! С предварительным удалением умершего DC. Тут несколько частей: если кому-то нужно только создать DC на виртуалке — можно смотреть только одну эту часть, если кому-то нужны какие-то другие нюансы — другую. Тема действительно получается огромная. Вроде в уме прикидываешь — несколько кликов всего, а начинаешь писать — надо и то осветить, и про другое не забыть. Коль, вижу, возник интерес — в ближайшее время добью пару последних пунктов. ;)

      • Denis говорит:

        Огромное спасибо. Очень полезная тема-100% информации.
        А вариант расписать, как создавать ASP.net (Windows) сервер под домен? Я спрашивал у гугла, но там как-то гнило расписано. Но как тут расписано, это высший пилотаж. ) Хотелось бы и такую статейку. Сайт кидаю в избранное! Спасибо.

        • Modicus говорит:

          Всё может быть. Как с этой темой разгребусь — последуют другие. :) Спасибо на добром слове!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *