Устранение неполадок при клонировании виртуальных контроллеров домена Windows Server 2012

В Windows Server 2012 появилась новая функция — виртуальный контроллер домена Virtualized Domain Controller (VDC). Мы уже рассказывали об этом на страницах нашего журнала, в статье «Клонирование виртуальных контроллеров домена в Windows Server 2012», опубликованной в Windows IT Pro/RE № 12 за 2012 год. Вам больше не придется разворачивать подготовленные с помощью Sysprep образы серверов, чтобы затем вручную повысить их до контроллера домена (DC). Вместо этого клонированный DC самостоятельно выполняет часть операций Sysprep, а также собирает данные о существующей локальной инфраструктуре Active Directory Domain Services (ADDS) и сохраняет их в виде установочного носителя, вместе с информацией, предоставленной администратором, такой как имя компьютера и IP-адрес. Это позволяет быстрее разворачивать контроллеры домена в рабочей или тестовой среде, упрощает восстановление после сбоев и обеспечивает возможность быстрого масштабирования, если дело касается предоставления услуг хостинга или развертывания удаленных офисов.

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

Этапы клонирования

В большинстве случаев проблемы при клонировании оказываются следствием человеческой ошибки. Основная мысль, которую я хочу донести до читателей в этой статье, заключается в том, что если у администратора не получается клонировать DC, обычно оказывается, что он пропустил один из подготовительных шагов. Существует определенное количество необходимых для клонирования условий и шаги, которые нужно выполнять в строго определенно порядке. Мастера клонирования не существует, поэтому ответственность за выполнение этой процедуры ложится на вас. Если вы допустите ошибку на какой-нибудь стадии, клонирование завершится неудачей.

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

1. Убедитесь, что гипервизор поддерживает идентификатор виртуальной машины VM-Generation ID и, таким образом, клонирование.
2. Убедитесь, что роль эмулятора PDC находится на сервере под управлением WindowsServer 2012 и что эмулятор PDC функционирует и доступен через удаленный вызов процедур (RPC).
3. Разрешите исходному DC быть источником для клонирования.
4. Удалите несовместимые программы и службы или укажите их в файле CustomDCCloneAllowList.xml.
5. Создайте файл DCCloneConfig.xml.
6. Выключите исходный DC.
7. Скопируйте или экспортируйте исходный DC, добавьте файлы XML, если еще не скопировали их.
8. Создайте новую виртуальную машину из копии.
9. Запустите новую виртуальную машину для начала процесса клонирования.

Пошаговые инструкции можно найти в статье «Развертывание и настройка виртуальных контроллеров домена» на Technet (technet.microsoft.com/en-us/library/jj574223.aspx). Поверьте, эта статья стоит того, чтобы ее прочитать.

Изучите симптомы

Если вы совершите ошибку на каком-либо шаге, то клонирование завершится неудачей, и виртуальная машина загрузится в режиме восстановления служб каталогов (DSRM). Этот режим защищает вашу среду от случайного дублирования контроллеров домена. После того, как вы устраните проблему и уберете флаг загрузки в режим DSRM, вы можете перезагрузить DC и попробовать повторить процесс клонирования. Естественно, при этом необходимо знать пароль режима восстановления. Вы можете установить его в процессе развертывания исходного контроллера или же использовать Ntdsutil.exe позже. Особо изобретательные автоматизируют процесс управления паролем – посмотрите статью «Управление паролем режима восстановления» (blogs.technet.com/b/askds/archive/2009/03/11/ds-restore-mode-password-maintenance.aspx).

Если вы пропустите шаг 5 и у вас используется автоматическое назначение IP-адресов, то у вас появится дублированный контроллер домена. Решение этой проблемы – дело хлопотное, посмотрите статью по адресу support.microsoft.com/kb/2742970. Так что помните о шаге 5, даже если вы больше ничего не усвоите из данной статьи. Эта проблема стара, как AD, но в эпоху VDC ее возникновение более вероятно.

И последнее: вам нужно понимать, где заканчивается клонирование и начинается повышение до уровня контроллера домена. Клонирование обязательно завершается повышением и репликацией, и если что-то пойдет не так, вам придется вернуться к классическому методу устранения неполадок в работе DC, который использовался в течение последнего десятилетия.

Осваиваем методологию

На рисуноке показана диаграмма, которую я держу при себе на тот случай, если мне необходимо освежить память. Она составлена на основе наиболее распространенных проблем, с которыми мне приходилось сталкиваться в ходе внутреннего тестирования, публичного бета-тестирования и тренингов для инженеров Microsoft по всему миру. Поэтому ничего страшного, если вы столкнетесь с одной или несколькими проблемами из этого списка – вы в хорошей компании.

Рисунок. Диаграмма поиска неисправностей в процессе клонирования/повышения статуса

Прежде всего, убедитесь, что клонирование завершилось успешно. Если нет, определите, загрузился ли сервер в режиме восстановления DSRM. Если сервер не в режиме восстановления, то этот контроллер теперь является дубликатом, и вам необходимо выполнить шаги, описанные в статье Microsoft по адресу support.microsoft.com/kb/2742970. Если он загрузился в режиме восстановления, значит, защита от дублирования сработала и вам нужно просмотреть журнал событий Directory Services.

Это напоминает мне еще об одном совете, который я все время повторяю: просматривайте журнал событий Directory Services. Он содержит все события, относящиеся к клонированию (2160–2228 и 29218–29267), и поиск неисправностей должен начинаться именно с него. В журнале будет информация о том, совершили ли вы одну из распространенных ошибок.

* Поддерживается ли гипервизор?

* Есть ли неподдерживаемое приложение, которое необходимо поместить в файл CustomDCCloneAllowList.xml? Записи в файле CustomDCCloneAllowList.xml корректны?

* Функционирует ли эмулятор PDC и есть ли к нему доступ по протоколу RPC?

* Является ли контроллер домена членом группы CloneableDomainControllers? Установлено ли для этой группы разрешение «Разрешить контроллеру домена создать клон себя самого» на уровне корня домена?

* IP-адрес или имя компьютера, указанные в файле dccloneconfig.xml, либо повторяются, либо некорректны?

* Корректно ли указано имя сайта AD в файле dccloneconfig.xml?

* В файле dccloneconfig.xml не указан IP-адрес и сервер DHCP недоступен?

* Неверный синтаксис в файле dccloneconfig.xml мешает его корректной обработке?

* Повышение до уровня контроллера домена завершилось неудачей после успешного клонирования?

Возможны и менее распространенные проблемы. Превышено ли максимально допустимое количество автоматически сгенерированных имен контроллеров домена (9999)? Дублируется ли MAC-адрес? Работает ли репликация на эмуляторе PDC, чтобы он знал об изменениях членства в группе и другие контроллеры знали, что он является PDC-эмулятором?

Я настоятельно рекомендую использовать команду WindowsPowershell New-AdDcCloneConfigFile, потому что она позволит вам избежать ошибок в синтаксисе XML, но не полагайтесь только на нее. Команда не поймет, что вы указали неверный IP-адрес или неверное имя компьютера. Разработчики Microsoft приложили большие усилия, чтобы сделать этот журнала максимально информативным. Например, из первого примера (таблица 1) понятно, что я пытался клонировать исходный сервер Server 2012 с помощью гипервизора, который не поддерживается (в данном случае это был Hyper-V на Windows Server 2008 R2). Во втором примере (таблица 2) я случайно добавил имя существующего компьютера в файл dccloneconfig.xml. Поскольку я не могу создать новый контроллер домена с тем же именем, что и существующий контроллер, клонирование заканчивается неудачей.

Журнал событий Systemи %systemroot%debugdcpromo.log также может содержать полезную информацию о причинах неудач при клонировании. Запомните, что после окончания клонирования еще необходимо дождаться завершения процесса повышения сервера до уровня DC. Полный список событий можно найти в статье «Устранение неполадок с виртуализованными контроллерами домена» (technet.microsoft.com/en-us/library/jj574207.aspx).

Серверы в режиме Core

Теперь вы уже знаете, что по умолчанию Server 2012 устанавливается в режиме Core, без графического интерфейса, который требует выполнения операций в командной строке или из Powershell. Это отлично вписывается в философию VDC о развертывании масштабируемых, управляемых сред с минимальными накладными расходами на операционную систему. Но когда последний раз вы просматривали журнал событий из командной строки? На серверах в режиме Core нет утилиты eventvwr.exe. У вас есть несколько вариантов.

— Запустить Wevtutil.

— Выполнить команду Poweshell Get-WinEvent.

— Включить правила в сетевом экране Windows для группы Remote EventLog Management, чтобы разрешить входящие подключения. Это позволит подключаться таким утилитам, как просмотровщик событий Eventviewer с удаленных компьютеров. Вы можете использовать групповые политики, чтобы включить это правило на всех своих контроллерах домена, как показано на экране.

Экран. Использование групповой политики для?разрешения входящих подключений

Важно: не пытайтесь обратно включить графический интерфейс на сервере, когда он находится в режиме DSRM. Microsoft не поддерживает это действие. Сервер не загрузится корректно, вам придется удалить виртуальную машину и начать все сначала.

Повторная попытка клонирования

После того, как вы просмотрите журнал событий DirectoryServices и устраните проблему, у вас все еще будет клонированный сервер, всегда загружающийся в режиме DSRM. Вы можете воспользоваться утилитой MSConfig, чтобы снять флажок, запускающий этот режим: выберите вкладку загрузки и в параметрах загрузки снимите флажок безопасного режима. Если вы используете сервер в режиме Core, то вам поможет BCDEdit:

bcdedit.exe /deletevaluesafeboot

В обоих случаях после того, как вы перезагрузите компьютер, процесс клонирования прочитает файл dccloneconfig.xml и попробует начать все с начала. Ограничений на число попыток нет, но будем надеяться, что у вас все получится сразу!

Не забывайте о базе знаний

Если журнал событий Directory Service не помогает или вы просто не можете разобраться, что именно пошло не так, не забывайте о базе знаний Microsoft. В ней содержатся все известные проблемы с VDC, вместе с руководствами для решения проблем. Надеюсь, вы найдете функцию VDC в Windows Server 2012 очень интересной, ведь при ее разработке мы старались учесть потребности вашего бизнеса и многочисленные отзывы.