Контроллер домена на виртуальной машине hyper v

Особенности развертывания виртуализированных контроллеров домена

В данном разделе описаны некоторые аспекты, на которые необходимо обратить внимание при развертывании контроллеров домена на виртуальных машинах. Имеется несколько распространенных действий с виртуальными машинами, которых необходимо избегать при развертывании контроллеров домена. Также имеются особые условия синхронизации времени и условия хранения. Эти особенности описаны в приведенных ниже разделах.

Недопустимые действия при развертывании виртуализации

Платформы виртуализации, например Hyper-V, предоставляют ряд удобных возможностей, облегчающих управление, обслуживание, резервное копирование и миграцию компьютеров. Однако имеется несколько распространенных функций и приемов развертывания, которые нельзя использовать для виртуальных контроллеров домена. Действия, которых следует избегать при развертывании контроллеров домена, приведены в следующем списке.

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

Миграция из физической в виртуальную среду

System Center Virtual Machine Manager (VMM) 2008 обеспечивает единое управление физическими компьютерами и виртуальными машинами. Кроме того, это решение предоставляет возможность миграции физического компьютера на виртуальную машину. Это процесс известен как преобразование физического компьютера в виртуальную машину (P2V). Во время процесса преобразования P2V физический контроллер домена, миграция которого осуществляется, не должен быть включен одновременно с новой виртуальной машиной, чтобы избежать ситуации отката номера последовательного обновления, как описано в Приложение A: виртуализированные контроллеры домена и проблемы репликации.

Преобразование P2V необходимо выполнить в автономном режиме, чтобы данные каталога были согласованы, когда контроллер домена вновь включится. Вариант автономного режима предлагается и рекомендуется в мастере преобразования физического сервера. Описание различий между автономным и оперативным режимами см. в статье «P2V: преобразование физических компьютеров в виртуальные машины в VMM» (страница может быть на английском языке) (http://go.microsoft.com/fwlink/?LinkId=155072). Во время преобразования P2V виртуальная машина не должна быть подключена к сети. Сетевой адаптер виртуальной машины следует включать только после завершения процесса преобразования P2V и его проверки. На этом этапе исходный физический компьютер будет отключен. Не подключайте исходный физический компьютер обратно к сети, пока жесткий диск не будет переформатирован.

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

Использование миграции P2V для создания тестовых сред

Для создания тестовых сред можно использовать миграцию P2V с помощью VMM. Можно осуществлять миграцию рабочих контроллеров домена с физических компьютеров на виртуальные машины для создания тестовой среды без вывода рабочих контроллеров домена из использования на длительное время. Однако если должно быть два экземпляра одного контроллера домена, тестовая среда должна находиться в сети, отличной от рабочей среды. Необходимо проявлять повышенную осторожность при создании тестовых сред с помощью миграции P2V, чтобы избежать откатов номера последовательного обновления, которые могут повлиять на состояния тестовой и рабочей сред. Ниже описан способ, который можно использовать для создания тестовых сред с помощью преобразования P2V.

Выполняется миграция на тестовую виртуальную машину одного рабочего контроллера домена из каждого домена преобразованием P2V согласно рекомендациям, приведенным в подразделе Миграция из физической в виртуальную среду. Физические рабочие компьютеры и тестовые виртуальные машины должны находиться в разных сетях, когда они вновь будут подключаться к сети. Чтобы избежать в тестовой среде откатов номера последовательного обновления, все контроллеры домена, миграция которых выполняется с физических компьютеров на виртуальные машины, должны быть отключены от сети. (Для этого необходимо остановить службу NTDS или перезагрузить компьютер в режиме восстановления служб каталогов (DSRM).) После отключения контроллеров домена от сети в среде не должны производиться обновления. Компьютеры должны оставаться отключенными от сети в процессе миграции P2V; ни один компьютер нельзя вновь подключать к сети, пока полностью не завершена миграция всех компьютеров. Дополнительные сведения об откате номера последовательного обновления см. в Приложение A: виртуализированные контроллеры домена и проблемы репликации.

Последующие тестовые контроллеры домена должны создаваться как реплики в тестовой среде.

Служба времени

Отключите через службы интеграции синхронизацию времени с узлом для виртуальных машин, настроенных в качестве контроллеров домена. Вместо этого используйте синхронизацию времени доменной структуры с помощью службы времени Windows (W32time), установленной по умолчанию.

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

Чтобы отключить синхронизацию времени с узлом в параметрах виртуальной машины, в разделе Службы интеграции диспетчера Hyper-V снимите флажок Синхронизация времени.

Дополнительные сведения об установке и использовании служб интеграции см. в руководстве «Начало работы с Hyper-V» (страница может быть на английском языке) http://go.microsoft.com/fwlink/?LinkId=137146.

Хранение

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

Чтобы уменьшить вероятность повреждения данных Active Directory, используйте SCSI-контроллеры или отключите кэширование записей на ATA/IDE-дисках.

Источник

Поддержка использования реплики Hyper-V для виртуализированных контроллеров домена

— DC1 и DC2 работают Windows Server 2012.

-DC2 завершает работу и отработка отказа выполняется на DC2-REC. Отработка отказа может быть запланированной или незапланированной.

-После запуска DC2-Rec проверяет, совпадает ли значение Вмженид в его базе данных со значением из драйвера виртуальной машины, сохраненного на сервере реплики Hyper-V.

-DC2-Rec сохраняет новое значение Вмженид в своей базе данных и фиксирует все последующие обновления в контексте нового InvocationID.

В результате сброса InvocationID DC1 будет объединять все изменения AD, появившиеся DC2-Rec даже в случае отката времени, что означает, что все обновления AD, выполненные на DC2-Rec после отработки отказа, безопасно сходятся.Данный тестовый случай аналогичен случаю для запланированной отработки отказа, за исключением следующего:

— Все обновления AD, полученные на DC2, но еще не реплицированные AD на партнера репликации до тех пор, пока не будет потеряно событие отработки отказа.

— Обновления AD, полученные на DC2 после момента точки восстановления, реплицированной AD на DC1, будут реплицированы с DC1 обратно на DC2-REC.

Windows Server 2008 R2 и более ранних версий

В следующей таблице поясняется поддержка виртуализированных контроллеров домена, работающих под управлением Windows Server 2008 R2 и более ранних версий.

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

В данном разделе поясняется поддержка использования реплики Hyper-V для репликации виртуальной машины, которая работает в качестве контроллера домена. Реплика Hyper-V — это новый компонент Hyper-V, появившийся в Windows Server 2012, который предоставляет встроенный механизм репликации на уровне виртуальных машин.

Реплика Hyper-V асинхронно реплицирует выбранные виртуальные машины с основного узла Hyper-V на узел реплики Hyper-V по каналам локальной или глобальной сети. После завершения начальной репликации последующие изменения реплицируются с интервалом, заданным администратором.

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

Дополнительные сведения о Hyper-V Replica см. в разделе Обзор Hyper-V Replica и Развертывание Hyper-V Replica.

Реплика Hyper-V может выполняться только в Windows Server Hyper-V, в версии Hyper-V под управлением Windows 8 этот компонент не работает.

требуются Windows Server 2012 или более новые контроллеры домена

Windows Server 2012 Hyper-V представил VM-GenerationID (вмженид). ИД создания виртуальной машины предоставляет низкоуровневой оболочке средство взаимодействия с гостевой ОС при внесении существенных изменений. Например, низкоуровневая оболочка может сообщить виртуализированному контроллеру домена, что было выполнено восстановление из моментального снимка (технология восстановления моментальных снимков Hyper-V, а не резервных копий). AD DS в Windows Server 2012 и более новых версиях осведомлены о технологии виртуальных машин вмженид и использует ее для обнаружения выполнения операций гипервизора, таких как восстановление моментальных снимков, что позволяет ит-специалистам лучше защищать себя.

эти меры безопасности, полученные из вмженид, обеспечивают только AD DS на Windows Server 2012 DCs или более поздней версии. контроллеры доменов, на которых выполняются все предыдущие выпуски Windows Server, подвержены таким проблемам, как откат USN, который может произойти при восстановлении виртуального контроллера домена с помощью неподдерживаемого механизма, такого как восстановление моментальных снимков. Дополнительные сведения об этих мерах безопасности и условиях их активации см. в разделе Архитектура виртуализированных контроллеров доменов.

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

Учитывая наличие двух экземпляров одного удостоверения контроллера домена, существует вероятность одновременного выполнения как основного, так и реплицированного экземпляра. Хотя реплика Hyper-V снабжена управляющими механизмами, предотвращающими одновременное выполнение основной виртуальной машины и виртуальной машины реплики, такая ситуация все же возможна в случае обрыва канала связи между ними после репликации виртуальной машины. Если такая маловероятная ситуация все же возникнет, в виртуализированных контроллерах домена под управлением Windows Server 2012 предусмотрены специальные меры безопасности для защиты доменных служб Active Directory, в виртуализированных контроллерах домена, работающих под управлением предыдущих версий Windows Server, такие меры отсутствуют.

При использовании Hyper-V Replica убедитесь, что выполнены рекомендации для работающих виртуальных контроллеров доменов на Hyper-V. Среди прочего, в этом разделе рассматриваются рекомендации по хранению файлов Active Directory на виртуальных дисках SCSI, что позволяет гарантировать сохранность данных.

Поддерживаемые и неподдерживаемые сценарии

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

Виртуальные машины под управлением предыдущих версий Windows Server поддерживаются для запланированной отработки отказа, однако не поддерживаются для незапланированной отработки отказа в связи с риском отката номера последовательного обновления. Дополнительные сведения об откате USN см. в разделе USN и откат USN.

Требования к режиму работы для домена или леса отсутствуют, имеются требования только требования к операционной системе для контроллеров домена, работающих в качестве виртуальных машин, которые реплицируются с использованием реплики Hyper-V. Виртуальные машины можно развернуть в лесу, содержащем другие физические или виртуальные контроллеры домена, которые работают под управлением предыдущих версий Windows Server и также могут как реплицироваться, так и не реплицироваться с помощью реплики Hyper-V.

Данное заявление о поддержке основано на тестах, проведенных в лесе с одним доменом, однако конфигурации леса с несколькими доменами также поддерживаются. Для этих тестов виртуализированные контроллеры домена DC1 и DC2 являются партнерами репликации Active Directory на одном сайте, размещенном на сервере, где выполняется Hyper-V в Windows Server 2012. В операционной системе виртуальной машины, где выполняется DC2, включена реплика Hyper-V. Сервер-реплика размещается в другом географически удаленном центре обработки данных. Чтобы упростить восприятие приведенных ниже процедур тестового случая, для виртуальной машины, выполняемой на сервере-реплике, используется имя DC2-Rec (хотя на практике она сохраняет имя исходной виртуальной машины).

Windows Server 2012

В следующей таблице поясняется поддержка виртуализированных контроллеров домена, работающих под управлением Windows Server 2012, и тестовых случаев.

Источник

P2V конвертация физического контроллера домена на базе Windows Server 2012 R2 в виртуальную машину Hyper-V Generation 2

В этой заметке мы рассмотрим пример Physical-to-Virtual (P2V) конвертации физического сервера в виртуальную среду на базе гипервизора Hyper-V в составе ОС Windows Server 2012 R2. В рассматриваемом примере физический сервер представляет из себя серверную платформу HP ProLiant DL 360 G5 с ОС Windows Server 2012 R2 и основными серверными ролями AD DS и DNS. И как наверное понятно, с инфраструктурной точки зрения сервер представляет собой действующий контроллер домена.

1. P2V конвертация физического сервера с помощью MVMC.
2. Преобразование виртуальных дисков в формат VHDX.
3. Настройка сети в гостевой ОС виртуальной машины.
4. Проверка обновления компонент интеграции Hyper-V
5. Удаление ПО поддержки аппаратных компонент сервера.
6. Конвертация виртуальной машины в формат Generation 2.
7. Удаление несуществующих устройств из ОС виртуальной машины.

Чтобы сократить время конвертации, все операции будем выполнять непосредственно на одном из хостов виртуализации. При выборе хоста следует учитывать пару простых правил, соблюдение которых поможет избежать ошибок связанных с нехваткой дискового пространства как в процессе P2V конвертации, так и в последующем процессе преобразования ВМ G1 в G2:

А) Для операций P2V хост виртуализации должен иметь свободное дисковое пространство объёмом не менее, чем общий размер занятого пространства на дисках виртуализуемого сервера. А с учётом временных операций MVMC желательно вообще ориентироваться на двойной объём данных.

Б) Для последующих операций конвертации ВМ G1 в G2 на системном диске хоста виртуализации, где предположительно расположены папки профилей пользователей, должно присутствовать свободное дисковое пространство объёмом не менее, чем общий размер занятого пространства на дисках виртуализуемого сервера. В процессе конвертации будет создана временная копия виртуального диска в виде wim-образа в каталоге %LOCALAPPDATA%\Temp или C:\Users\%USERNAME%\AppData\Local\Temp )

P2V конвертация физического сервера с помощью MVMC

Как и условились, устанавливать MVMC будем на тот хост виртуализации, который будет получателем новой виртуальной машины. На выбранном хосте должна быть установлена роль Hyper-V и включена «фича» BITS Compact Server. Роль Hyper-V была установлена ранее, так как это действующий хост виртуализации, а вот BITS нам нужно будет установить дополнительно, так как по умолчанию она выключена. Сделаем это с помощью PowerShell:

После установки, запускаем MVMC и на первом экране выбираем тип конвертации – Physical machine conversion

Далее на появившейся вкладке Source вводим полное доменное имя физического сервера подлежащего процедуре виртуализации, а также учетные данные для административного доступа к этому серверу. Так как в нашем случае речь идёт о контроллере домена, используются учетные данные администратора домена.

На следующем шаге нажимаем кнопку Scan System, и ждём когда в информационном окне System Information появится информация о конвертируемом сервере.

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

На шаге VM Configuration вводим имя создаваемой виртуальной машины (не должно совпадать с именами существующих на хосте виртуализации виртуальных машин), количество виртуальных процессоров (ядер) и объём оперативной памяти.

Далее вводим имя хоста виртуализации, на котором будет создана соответствующая виртуальная машина. В моём случае указано имя сервера виртуализации, на котором запущен конвертор.

На следующем шаге Disk по умолчанию предполагается выбор сетевой папки на хосте виртуализации для сохранения создаваемого виртуального диска. И опять же, так как экземпляр MVMC и хост назначения в нашем случае это одна и та же система, – можем указать локальную папку на этом хосте.

На шаге Workspace указываем имя любой локальной папки, которая будет использоваться MVMC как промежуточное место при конвертации физических жёстких дисков в виртуальные.

Далее на шаге Network Configuration указываем виртуальный коммутатор Hyper-V, к которому будет подключён сетевой адаптер создаваемой виртуальной машины.

На шаге Summary просматриваем краткую сводную информацию и запускаем процесс конвертации кнопкой Finish

Дожидаемся успешного окончания процесса конвертации…

Сразу после того, как процесс конвертации завершён, выключаем физический сервер-источник.

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

Также создана виртуальная машина формата Generation 1, у которой виртуальные диски подключены к виртуальному IDE-контроллеру. Виртуальный диск с длинным названием (по метке тома с физической системы) используется для запуска ОС со второго, основного виртуальном диска.

Теперь нужно выполнить первый проверочный запуск виртуального сервера, чтобы убедиться в том, что виртуализованная система стартует и работает успешно. На всякий случай перед первым запуском можно отключить сетевой адаптер виртуальной машины от виртуального коммутатора Hyper-V.

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

Если первичный запуск прошёл успешно, можно считать что основная стадия виртуализации выполнена и все последующие действия можно выполнять лишь по желанию.

Преобразование виртуальных дисков в формат VHDX

Так как виртуальная машина была создана MVMC с дисками в формате VHD мы можем самостоятельно выполнить преобразование дисков в более «продвинутый» формат VHDX. Для этого выключим виртуальную машину и в консоли Hyper-V Manager из меню Actions выберем пункт Edit disk. Выбрав виртуальный диск на шаге мастера Choose Action выберем режим конвертирования – Convert

Далее выберем формат VHDX и дождёмся завершения процедуры преобразования.

После того как диски преобразованы изменим путь к дискам в свойствах виртуальной машины

Сохраним настройки и снова проверим запуск виртуальной машины с виртуальными дисками нового формата.

Настройка сети в гостевой ОС виртуальной машины.

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

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

Проверка обновления компонент интеграции Hyper-V

Чтобы убедиться в том, что в «новоиспечённой» виртуальной машине используются компоненты интеграции Hyper-V самой актуальной версии, доступной на хосте виртуализации, откроем консольное подключение к виртуальной машине и в меню Action выберем пункт монтирования образа диска с компонентами интеграции – Insert Integration Services Setup Disk

В смонтированном в виртуальной системе диске найдём и запустим файл \support\amd64\setup.exe

Если компоненты интеграции имеют актуальную версию, то мы получим примерно следующее сообщение:

В противном случае необходимо будет произвести установку компонент с последующей перезагрузкой гостевой ОС виртуальной машины.

Удаление ПО поддержки аппаратных компонент сервера

После того как наш сервер стал виртуальным, нужно позаботиться о том, чтобы всё программное обеспечение, которое ранее было установлено на этот сервер для поддержки аппаратных компонент, было аккуратно удалено. В нашем примере удалению подлежат все приложения из состава HP Insight Software. Также мы можем удалить установленного ранее агента ИБП, так как теперь выключением гостевой ОС виртуальной машины в случае отключения электропитания будет управлять хост виртуализации.

После удаления ПО снова перезагрузим гостевую систему, чтобы убедиться в её успешном запуске.

Конвертация виртуальной машины в формат Generation 2

На данном этапе наш виртуальный сервер полноценно работает в штатном режиме, однако если мы хотим улучшить его путём преобразования в формат Generation 2, предварительно стоит позаботиться о создании резервной копии рабочей ВМ. Просто и удобно это можно сделать например с помощью System Center 2012 R2 Data Protection Manager (DPM)…

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

Итак, скачиваем и копируем скрипт Convert-VMGeneration.ps1 на хост виртуализации, где в данный момент работает наша виртуальная машина.

Перед началом конвертации ещё раз убедимся в том, что на диске с профилями пользователей (как правило это диск C:\ ) достаточно места для создания временной копии виртуального диска ВМ (в процессе конвертации будет создан временный wim-образ в каталоге %LOCALAPPDATA%\Temp )

Дополнительно убедимся в том, что внутри виртуальной машины выключена поддержка среды восстановления WinRE (требование автора скрипта конвертации). Сделать это можно консольной командой:

Выключим виртуальную машину.

Запустим на хосте виртуализации скрипт конвертации:

Как видим, первая попытка запуска скрипта завершается ошибкой.

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

На первом диске (Disk 0) содержится информация необходимая для загрузки ОС, но не содержится самой ОС. При этом скрипт пытается использовать для конвертации именно этот диск. Так как в результате работы скрипта загрузочный раздел фактически будет создан заново, мы можем попробовать удалить имеющийся загрузочный диск. Для этого выключим виртуальную машину и удалим из конфигурации ВМ первый виртуальный диск, который имеет метку тома в виртуальной ОС “System Reserved” (диск объёмом примерно в 350MB).

То есть мы оставим в свойствах ВМ только один диск, тот на котором расположена гостевая ОС Windows Server 2012 R2. После этих изменений не нужно пытаться запустить виртуальную машину (из этого всё равно не выйдет ничего хорошего), а сразу пробуем выполнить скрипт конвертации:

Ключ IgnoreWinRE здесь добавлен для того, чтобы избежать сообщения после которого преобразование прекращалось с ошибкой (несмотря на то, что в гостевой ОС поддержка WinRE выключена):

После начала работы скрипта конвертации нам будет задано устрашающее предупреждение о том, все данные на одном из дисков доступных на текущий момент в хостовой системе будут уничтожены. Утвердительный ответ подразумевает продолжение работы скрипта :

Прежде, чем нажать Yes, откроем на хосте виртуализации оснастку управления дисками и убедимся в том, что в системе появился новый виртуальный диск, который смонтирован под порядковым номером указанным в сообщении скрипта (в нашем примере это Disk 7). Это и есть тот новый виртуальный диск, который создан скриптом конвертации, для клонирования на него исходного виртуального диска (он также смонтирован скриптом в нашем примере как Disk 6)

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

По окончании работы скрипта соответствующие разделы будут автоматически отмонтированы

При необходимости переименуем исходную виртуальную машину первого поколения…

Проверим конфигурацию вновь созданной виртуальной машины второго поколения.

Как и раньше, перед первым запуском отключим на всякий случай виртуальный сетевой адаптер от виртуального коммутатора Hyper-V. После попробуем запустить виртуальную машину. На первый запуск уйдёт какое-то время, так как гостевая система снова должна обновить информацию об оборудовании.

Если гостевая ОС загрузилась успешно, аутентифицируемся в ней и проверим настройки сетевой карты. Они должны быть сохранены. Если всё в порядке, в свойствах виртуальной машины вернём доступ сетевого адаптера к виртуальному коммутатору и снова перезагрузим виртуальную машину. На данном этапе наш виртуальный сервер будет загружен уже полностью в продуктивном виде и его сервисы станут доступны из сети.

Теперь можно спокойно удалить старую виртуальную машину (в нашем случае это исходная ВМ, ранее переименованная в KOM-DC01-OLD ) поколения G1 и перенести готовую ВМ G2 в кластер, если он используется.

При необходимости можно включить выключенный до конвертации в G2 WinRE

Удаление несуществующих устройств из ОС виртуальной машины

На текущий момент наш виртуальный сервер уже является виртуальной машиной Hyper-V второго поколения. Завершающим немаловажным действием является удаление из гостевой ОС всех старых устройств-«фантомов» и относящихся к ним драйверам с помощью оснастки управления устройствами (Device Manager).

И опять же, перед манипуляциями с диспетчером устройств желательно создать резервную копию виртуальной машины на DPM.

Удалять старые устройства будем описанным ранее методом.

Устанавливаем системную переменную для включения отображения устройств-призраков в оснастке управления устройствами и следующей командой (не закрывая окна командной строки) запускаем оснастку:

В открытой оснастке в меню View выбираем пункт «Show hidden devices«…

Разворачиваем каждый узел типов устройств и удаляем все устройства отображаемые как неактивные.

В процессе удаления некоторых устройств может быть доступна опция удаления драйвера устройства “Delete the driver software for this device”. Так как эти драйверы более не нужны в гостевой виртуальной системе, можно включать советующую опцию.

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

На этом этапе можно сказать, что работы по конвертации физического контроллера домена на базе Windows Server 2012 R2 в виртуальную машину Hyper-V Generation 2 завершены и теперь, всё что нам остается сделать – убедиться в работоспособности прикладной части виртуального сервера, например проверить состояние роли контроллера домена с помощью таких инструментов как DCDIAG.

Источник