клонирование windows 7 домене

Клонирование виртуального контролера домена в Windows Server 2012

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

Если вы помните, в Windows Server 2008 R2 существовали следующие проблемы с виртуализацией контроллеров домена Active Directory:

Большинство из этих проблем связано с работой механизма USN (update sequence numbers). Вкратце напомним, в чем же была загвоздка. Для отслеживания обновлений между партнерами по репликации в лесу Active Directory используются идентификаторы USN. С помощью USN и ID вызова любой контроллер домена однозначно определяет, когда нужно принять и применить изменения в AD от партнеров по репликации, а когда переслать свои изменения. С помощью этого механизма обеспечивается непротиворечивость и актуальность базы AD.

В том случае если создать снапшот виртуального контроллера домена, а потом восстановить сервер из него, то мы получим контроллер домена с устаревшим USN. В результате, изменения на таком контроллере не реплицируются на другие сервера в лесу, т.к. партнеры по репликации считают, что их копия базы Active Directory актуальна. В итого это может привести к проблемам несоответствия паролей, противоречивым значениям атрибутов и т.д.

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

Данный функционал основывается на новой функции в Windows Server 2012 под названием VM-GenerationID. На данный момент эта функция поддерживается только в гипервизоре Hyper-V, но Microsoft рекомендует и другим производителям платформ виртуализации интегрировать данную функцию (в частности VMware уже заявила о поддержке технологии в следующей версии VSphere).

VM-Generation ID является функцией гипервизора и генерируется им при клонировании и или создании снапшота контроллера домена. VM-Generation ID представляет собой уникальный 128 битный идентификатор, который доступен приложениям через драйвер Windows Server 2012. Контроллер домена хранит значение VM-Generation ID в нереплицируемом атрибуте базы Active Directory. И перед применением изменений в базу Active Directory, контроллер домена сравнивает значение VM-Generation ID в своей базе AD со значением, полученным от гипервизора через драйвер Windows Server 2012. Если значения отличаются, осуществляется сброс параметров invocation ID и аннулирование RID. Таким образом контроллер домена определяет, что применен снапшот или контроллер домена клонирован, и актуализирует свою базу в соответствии с другими контроллерами домена AD.

Как клонировать виртуальный контроллер домена

Подготовка к клонированию DC

Чтобы контроллер домена можно было клонировать, его нужно добавить в группу Cloneable Domain Controllers. Сделать это можно с помощью консоли Active Directory Users and Computers, панели управления Active Directory Administrative Center или же команды PowerShell.

Команда PowerShell будет выглядеть так:

Примечание: в данном случае новый контроллер домена будет находится в этом же сайте. Более подробно о других параметрах клонирования можно прочитать на TechNet-е ).

После этого из графического GUI Hyper-V Manager запускаем импорт виртуальной машины, выбрав в качестве параметра опцию Copy the virtual machine (create a new unique ID).

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

Источник

Клонирование windows 7 домене

Необходимо ли менять SID ПК при клонировании Акронисом?
Видел статью на чьем-то блоге, что необходимости такой нет, потому и приказал долго жить проект NewSID от Симантека.
Хотелось бы услышпть более авторитетный ответ.
Речь идет о ПК (не серверах) под управлением Windows 7 x64. Т.е. там нет никакого серверного ПО типа WSUS. Есть только традиционные офисные программы и специальные прикладухи для рабочих станций.
Машины в домене (не в рабочей группе).

Вы себя хотите убедить наверное.

Нашел статью, видимо, переводную Руссиновича. Наверное, про неё идет речь.

«Чем больше я думал об этом, тем больше убеждался в том, что дублирование SID компьютера (т.е. наличие нескольких компьютеров с одинаковыми идентификаторами SID) не влечет за собой каких-либо проблем, связанных с безопасностью или чем-либо еще. Я обсудил свое заключение с командами разработчиков Windows, занимающихся вопросами безопасности и развертывания систем, и никто не смог придумать сценарий, при котором две системы с одинаковыми SID, работающие в пределах рабочей группы или же домена, могли бы стать причиной ошибки. «

Дак надо или не надо, если надо, то зачем?

Да, я хочу убедиться. Процедура длительная, и поэтому хочется понимать её смысл.

Руссинович: «Чем больше я думал об этом, тем больше убеждался в том, что дублирование SID компьютера (т.е. наличие нескольких компьютеров с одинаковыми идентификаторами SID) не влечет за собой каких-либо проблем, связанных с безопасностью или чем-либо еще. Я обсудил свое заключение с командами разработчиков Windows, занимающихся вопросами безопасности и развертывания систем, и никто не смог придумать сценарий, при котором две системы с одинаковыми SID, работающие в пределах рабочей группы или же домена, могли бы стать причиной ошибки. «

Нашел статью, видимо, переводную Руссиновича. Наверное, про неё идет речь.

«Чем больше я думал об этом, тем больше убеждался в том, что дублирование SID компьютера (т.е. наличие нескольких компьютеров с одинаковыми идентификаторами SID) не влечет за собой каких-либо проблем, связанных с безопасностью или чем-либо еще. Я обсудил свое заключение с командами разработчиков Windows, занимающихся вопросами безопасности и развертывания систем, и никто не смог придумать сценарий, при котором две системы с одинаковыми SID, работающие в пределах рабочей группы или же домена, могли бы стать причиной ошибки. «

Дак надо или не надо, если надо, то зачем?

Источник

Политика Майкрософт для дублирования дисков Windows установок

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

Применяется к: Windows 10, версия 2004, Windows 10, версия 1909, Windows 10, версия 1903, Windows 10, версия 1809, Windows 7 Пакет обновления 1, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 314828

Сводка

Дополнительная информация

Sysprep отвечает за удаление системных данных из Windows, таких как компьютерный SID. При установке Windows компьютерный SID вычисляется, чтобы содержать статистически уникальный 96-битный номер. СИД компьютера — это префикс СИД учетной записи пользователя и группы, созданных на компьютере. Для создания уникального идентификатора учетной записи с помощью идентификатора relative ID (RID) учетной записи создается идентификатор компьютера.

В следующем примере отображаются СИД для четырех учетных записей локальных пользователей. При добавлении новых учетных записей добавляются только последние четыре цифры.

HKEY_USERS локальной машине

S-1-5-21-191058668-193157475-154284998-500 Администратор S-1-5-21-191058668-193157475-154284998-1000 User 1a-S1a-S1a 1-5-21-191058668-193157475-154284998-1001 Пользователь 2 S-1-5-21-191058668-193157475-154284998-1002 User 3

Клонирование или дублирование установки без принятия рекомендуемых действий может привести к дублированию siD-данных. Для съемных мультимедиа дубликат SID может предоставить учетной записи доступ к файлам, даже если разрешения NTFS для учетной записи конкретно не дают доступа к этим файлам. Так как SID идентифицирует компьютер или домен и пользователя, для поддержки текущих и будущих программ необходимы уникальные СИД. Дополнительные сведения о проблемах, которые могут возникнуть, если клонировать установку Windows 8 или Windows Server 2012, перейдите в раздел Windows 8 и Windows Server 2012 сведения.

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

Это не полный список.

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

Мы не предоставляем поддержку компьютерам, которые настроены с помощью средств дублирования SID, кроме средства подготовки системы. Например, это включает в себя следующие:

Контактные данные сторонних организаций предоставлены в этой статье с целью помочь пользователям получить необходимую техническую поддержку. Эти данные могут быть изменены без предварительного уведомления. Корпорация Майкрософт не дает гарантий относительно правильности приведенных контактных данных сторонних производителей.

Если изображение было создано без использования Sysprep, мы не поддерживаем работу Sysprep после развертывания изображения в качестве способа вернуть компьютер в соответствие требованиям. Sysprep необходимо запустить перед захватом изображения.

Windows 8 и Windows Server 2012 сведения

Если вы клонировать Windows 8 или Windows Server 2012 или виртуальную машину без запуска, P2V и сохранить физический компьютер и запуск или создать резервное копирование компьютера, но сохранить исходный компьютер работает вы можете возникнуть проблемы, в которых push-уведомления не sysprep.exe /generalize работают. Например, у вас могут возникнуть следующие проблемы:

Ссылки

Дополнительные сведения о Windows средстве подготовки системы посетите следующие веб-сайты Майкрософт:

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

Источник

Смена SID при клонировании и массовом развёртывании

Привет, Хабр! Упомянутая в заголовке тема всё ещё порождает множественные дискуссии и недопонимание между системными администраторами. В своей статье я постараюсь ответить на следующие вопросы:

В основу рассуждений была взята популярная статья Марка Руссиновича (доступна также на русском языке), которую довольно часто неправильно интерпретируют (судя по комментариям и «статьям-ответам»), что приводит к неприятным последствиям. Добро пожаловать под кат.

Что такое SID, его типы и чем отличается Machine SID от Domain SID?

В первую очередь, важно различать SID компьютера (Machine SID) и SID домена (Domain SID), которые являются независимыми и используются в разных операциях.

Machine SID и Domain SID состоят из базового SID’а (base SID) и относительного SID’а (Relative SID = RID), который «приклеивается» в конец к базовому. Базовый SID можно рассматривать как сущность, в рамках которой можно определить группы и аккаунты. Машина (компьютер) является сущностью, в рамках которой определяются локальные группы и аккаунты. Каждой машине присваивается machine SID, и SID’ы всех локальных групп и аккаунтов включают в себя этот Machine SID с добавлением RID в конце. Для примера:

Именно SID’ы (а не имена) хранятся в токенах доступа (access tokens) и дескрипторах безопасности (security descriptors), и именно SID’ы используются при проверке возможности доступа к объектам системы Windows (в том числе, например, к файлам).

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

Когда машина добавляется в домен, в игру вступает новый SID, который генерируется на этапе добавления. Machine SID никуда не девается, так же как и локальные группы, и пользователи. Этот новый SID используется для представления аккаунта машины в рамках домена. Для примера:

Таким образом, машина DEMOSYSTEM теперь имеет два независимых SID’а:

• Machine SID, определяющая машину как сущность, в рамках которой заданы группы и аккаунты (первая строчка в первой таблице).

• SID аккаунта машины (computer account SID) в рамках домена BIGDOMAIN (вторая строчка во второй таблице).

Основная суть в том, что SID’ы должны быть уникальны в пределах окружения (authority), к которому они применимы. Другими словами, если машине DEMOSYSTEM присвоен machine SID S-1-5-21-3419697060-3810377854-678604692-1000, то неважно, что у другой машины в той же сети будет идентичный machine SID, т.к. этот SID используется только локально (в пределах машины DEMOSYSTEM). Но в пределах домена BIGDOMAIN computer SID у обоих машин должен быть уникальным для корректной работы в этом домене.

Смена SID при клонировании или развёртывании

В применении к продукту Acronis Snap Deploy 5 (основное предназначение — массовое развёртывание систем из мастер-образа), в котором функциональность смены SID-а присутствовала с самой первой версии, это означает, что мы, как и многие пользователи, ошибочно пошли на поводу у устоявшегося мнения, что менять SID нужно.

Однако исходя из вышесказанного, ничего страшного в развёртывании (или клонировании) машины без изменения Machine SID вовсе нет, в случае если это развёртывание происходит до добавления машины в домен. В противном случае — возникнут проблемы.

Из этого правила есть одно исключение: нельзя клонировать машину, если в дальнейшем роль этого клона планируется повышать (promote) до уровня домена контроллера. В этом случае Machine SID домен контроллера будет совпадать с computer SID в созданном домене, что вызовет проблемы при попытке добавления оригинальной машины (из которой производилось клонирование) в этот домен. Это, очевидно, относится только к серверному семейству Windows.

Проблемы, связанные со сменой SID

Пересмотреть точку зрения на функциональность смены SID нас подтолкнул выпуск новой версии Windows. При первом тестовом развёртывании образа Windows 10 со сменой SID на получившейся машине обнаружилось, что кнопка Start перестала нажиматься (и это оказалось только вершиной «айсберга»). Если же развёртывать тот же образ без смены SID, то такой проблемы не возникает.

Основная причина в том, что эта опция вносит изменения практически во всю файловую систему развёртываемой машины. Изменения вносятся в реестр Windows, в разрешения NTFS (NTFS permissions) для каждого файла, в SID’ы локальных пользователей (так как SID пользователя включает в себя в том числе и machine SID; подробнее тут) и т.д.

В случае с Windows 10 большая часть ключей реестра не могла быть модифицирована («Error code = C0000005. Access violation» и другие ошибки) и, как следствие, наша функция смены SID’а отрабатывала не до конца, что и приводило к трагической гибели практически нерабочей копии Windows 10.

Было принято решение убрать эту опцию в случае, если в мастер-образе мы находим Windows 10 (или Windows Server 2016). Решение было принято на основе теоретических выкладок описанных выше плюс, естественно, было подтверждено практикой при тестировании недавно вышедшего обновления Acronis Snap Deploy 5 во множестве комбинаций: с и без переименования машин после развёртывания, с добавлением в домен и рабочую группу, развёртывание из мастер-образов снятых от разных состояний мастер-машины (она была добавлена в домен или рабочую группу в разных тестах) и т.д.

Использование Sysprep

Начиная с Windows NT клонирование (развертывание) ОСи с использованием только NewSID никогда не рекомендовалось самим Microsoft. Вместо этого рекомендуется использовать родную утилиту Sysprep (см. KB314828), которая, помимо смены SID’а, также вносит большое число других изменений, и с каждой новой версией Windows их становится только больше. Вот небольшой (неполный) список основных вносимых изменений:

Таким образом, клонирование/развертывание без использования Sysprep может повлиять (читай «скорее всего, сломает») на функциональность Windows Update, Network Load Balancing, MSDTC, Vista и выше Key Manager Activation (KMS), который завязан на CMID (не путать с Machine SID), также изменяемый Sysprep’ом, и т.д.

Итого

Повторяя TL;DR из начала статьи, основной вывод можно сделать такой: для подготовки образа машины к клонированию/развёртыванию следует использовать sysprep в подавляющем большинстве случаев.

Источник

Развертывание и настройка виртуализированного контроллера домена

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

В этой статье рассматриваются следующие вопросы.

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

Этот раздел содержит подробное описание всего процесса клонирования виртуализированного контроллера домена.

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

Рекомендации по установке

Для виртуализированных контроллеров домена не требуется установка специального компонента или роли; все контроллеры домена автоматически получают возможности клонирования и безопасного восстановления. Вы не можете удалить или отключить их.

Для использования контроллеров домена Windows Server 2012 требуется схема доменных служб Active Directory версии 56 или выше Windows Server 2012, а также режим работы леса, соответствующий основному режиму Windows Server 2003 или выше.

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

Во время начала клонирования владелец роли FSMO эмулятора PDC должен работать.

Требования к платформе

Виртуализированный контроллер домен предъявляет следующие требования:

Роль FSMO эмулятора PDC размещается на контроллере домена Windows Server 2012

Эмулятор PDC доступен во время выполнения операций клонирования

Как клонирование, так и безопасное восстановление предъявляет следующие требования:

Виртуализированные гости Windows Server 2012

Платформа узла виртуализации, поддерживающая ИД создания виртуальной машины (VMGID)

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

Хотя корпорация Майкрософт реализует поддержку Windows 7 Virtual PC, Virtual PC 2007, Virtual PC 2004 и Virtual Server 2005, эти компоненты не могут запускать 64-разрядные гости и не поддерживают ИД создания виртуальной машины.

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

Важные замечания

Виртуализированные контроллеры домена не поддерживают безопасное восстановление следующих элементов:

Файлы VHD и VHDX, вручную скопированные поверх существующих файлов VHD.

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

Файлы VHDX появились Windows Server 2012 Hyper-V впервые.

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

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

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

Дополнительные сведения о нарушениях последовательности в номерах последовательного обновления и устаревших объектах см. в разделе Устранение неполадок с операциями Active Directory, завершающимися с ошибкой 8606: «Задано недостаточно атрибутов для создания объекта».

Клонирование виртуализированного контроллера домена

Клонирование виртуализированного контроллера домена при использовании как графических средств, так и Windows PowerShell состоит из нескольких этапов. При наиболее общем рассмотрении можно выделить три этапа:

Подготовка среды

Шаг 1. Проверка поддержки ИД создания виртуальной машины и клонирования гипервизором.

шаг 2. убедитесь, что роль эмулятора PDC размещена на контроллере домена, на котором работает Windows Server 2012 и что он подключен к сети и доступен клонированному контроллеру домена во время клонирования.

Подготовка исходного контроллера домена

Шаг 3. Авторизация исходного контроллера домена для клонирования.

Шаг 4. Удаление несовместимых служб или программ либо их добавление в файл CustomDCCloneAllowList.xml.

Шаг 5. Создание файла DCCloneConfig.xml.

Шаг 6. Перевод исходного контроллера домена в автономный режим.

Создание клонированного контроллера домена

Шаг 7. Копирование или экспорт исходной виртуальной машины и добавление XML, если это еще не сделано.

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

Шаг 9. Запуск новой виртуальной машины для начала клонирования.

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

В процедуре существует несколько мест, где вы можете выбрать, как именно создать клонируемый компьютер и как добавить файлы XML; эти этапы указаны ниже. В остальном процесс выполняется в полном соответствии с описанием.

На следующей схеме показан процесс клонирования виртуализированного контроллера домена, при котором домен уже существует.

Шаг 1. Проверка низкоуровневой оболочки

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

если гипервизор Microsoft Hyper-V, убедитесь, что он работает на Windows Server 2012. Это можно проверить с помощью диспетчера устройств.

Откройте Devmgmt.msc и просмотрите раздел Системные устройства на наличие установленных драйверов и устройств Microsoft Hyper-V. Для виртуализированного контроллера домена требуется системное устройство Microsoft Hyper-V Generation Counter (драйвер: vmgencounter.sys).

Шаг 2. Проверка роли PDCE FSMO

Прежде чем пытаться клонировать контроллер домена, вам следует убедиться, что контроллер домена, где размещается эмулятор основного контроллера домена FSMO, работает под управлением Windows Server 2012. Эмулятор PDC (PDCE) необходим по нескольким причинам:

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

Клонирующий контроллер домена обращается к PDCE напрямую, используя протокол RPC DRSUAPI, чтобы создать объекты-компьютеры для клонированного контроллера домена.

Windows Server 2012 расширяет возможности имеющегося удаленного протокола (UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2) службы репликации каталогов (DRS), включая в него новый метод удаленного вызова процедур (RPC) IDL_DRSAddCloneDC (Opnum 28). Метод IDL_DRSAddCloneDC создает новый объект контроллера домена, копируя атрибуты из имеющегося объекта контролера домена.

Состояния контроллера домена включают объекты компьютера, серверы параметры NTDS, FRS, DFSR и подключение, сохраняемые для каждого контроллера домена. При дублировании объекта этот метод RPC заменяет все ссылки на исходный контроллер домена соответствующими объектами нового контроллера домена. Вызывающий объект должен иметь право управления доступом DS-Clone-Domain-Controller в контексте именования доменов.

Для использования этого нового метода вызывающий объект всегда должен иметь прямой доступ к эмулятору PDC контроллера домена.

Поскольку это новый метод, вашему программному обеспечению анализа сети требуются обновленные средства синтаксического анализа, чтобы включить поля для нового Opnum 28 в существующий UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2. В противном случае вы не сможете анализировать данный трафик.

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

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

Метод для Пользователей и компьютеров Active Directory

Используя оснастку Dsa.msc, щелкните правой кнопкой мыши домен и выберите пункт Хозяева операций. Запомните контроллер домена, указанный на вкладке PDC, и закройте диалоговое окно.

Щелкните объект-компьютер этого контроллера домена правой кнопкой мыши и выберите пункт Свойства, а затем проверьте информацию об операционной системе.

Метод с Windows PowerShell

Вы можете совместить следующие командлеты модуля Windows PowerShell Active Directory, чтобы возвратить версию эмулятора PDC:

Если домен не указан, эти командлеты используют домен того компьютера, где они запущены.

Следующая команда возвращает сведения о PDCE и операционной системе:

Приведенный ниже пример показывает задание имени домена и фильтрацию возвращенных свойств перед конвейером Windows PowerShell:

Шаг 3. Авторизация исходного контроллера домена

Исходный контроллер домена должен иметь право управления доступом Разрешить контроллеру домена клонировать себя в заголовке контекста именования домена. По умолчанию известная группа Клонируемые контроллеры домена имеет такое разрешение и не содержит членов. PDCE создает эту группу, когда роль переносится FSMO на контроллер домена Windows Server 2012.

Метод для центра администрирования Active Directory

Запустите Dsac.exe и перейдите к исходному контроллеру домена, а затем откройте страницу сведений о нем.

В разделе Член групп добавьте группу Клонируемые контроллеры домена для этого домена.

Метод с Windows PowerShell

Вы можете совместить следующие командлеты модуля Windows PowerShell Active Directory get-adcomputer и add-adgroupmember, чтобы добавить контроллер домена в группу Клонируемые контроллеры домена:

Например, эта команда добавляет DC1 сервера в группу, не требуя указывать различающееся имя члена группы:

Повторное создание разрешений по умолчанию

Если удалить разрешение из заголовка домена, клонирование завершается с ошибкой. Вы можете воссоздать разрешение с помощью центра администрирования Active Directory или Windows PowerShell.

Метод для центра администрирования Active Directory

Откройте Центр администрирования Active Directory, щелкните заголовок домена правой кнопкой мыши, выберите Свойства, откройте вкладку Расширения, щелкните Безопасность и Дополнительно. Щелкните только для этого объекта.

Щелкните Добавить, в поле Введите имена выбираемых объектов введите имя группы Клонируемые контроллеры домена.

В области «Разрешения» щелкните Разрешить контроллеру домена клонировать себя и нажмите кнопку ОК.

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

Метод с Windows PowerShell

Используйте следующие команды в командной строке консоли Windows PowerShell для администратора с повышенными правами. Эти команды определяют имя домена и добавляют разрешения по умолчанию:

Кроме того, запустите образец FixVDCPermissions.ps1 в консоли Windows PowerShell, при этом консоль должна запускаться для администратора с повышенными правами на контроллере домена в требуемом домене. Он устанавливает разрешения автоматически. Этот пример находится в приложении данного модуля.

Шаг 4. Удаление несовместимых приложений или служб (если не используется CustomDCCloneAllowList.xml)

Любые программы или службы, которые были возвращены Get-ADDCCloningExcludedApplicationList и не были добавлены в CustomDCCloneAllowList.xml, перед копированием необходимо удалить. Рекомендуется удалить приложение или службу.

Любые несовместимые программы или службы, которые не были удалены или добавлены в CustomDCCloneAllowList.xml, препятствуют выполнению клонирования.

Используйте командлет Get-AdComputerServiceAccount, чтобы определить, имеются ли в домене автономные управляемые учетные записи службы и использует ли какую-либо из них данный компьютер. При наличии установленных управляемых учетных записей службы используйте командлет Uninstall-ADServiceAccount для удаления локально установленной учетной записи службы. После перевода исходного контроллера домена в автономный режим в соответствии с описанием из шага 6 вы можете повторно добавить управляемую учетную запись службы с помощью Install-ADServiceAccount, когда сервер возвращается в рабочий режим. Дополнительные сведения см. в разделе Uninstall-ADServiceAccount.

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

Шаг 5. Создание DCCloneConfig.xml

Файл DcCloneConfig.xml требуется для клонирования контроллеров домена. Его содержимое позволяет указать уникальные сведения, такие как имя и IP-адрес нового компьютера.

Файл CustomDCCloneAllowList.xml необязателен к использованию, если только вы не устанавливаете приложения и потенциально несовместимые службы Windows на исходном контроллере домена. Для этих файлов требуется в точности соблюдать правила именования, форматирования и размещения, в противном случае клонирование завершится со сбоем.

Поэтому вам всегда следует создавать файлы XML с помощью командлетов Windows PowerShell и помещать их в правильное расположение.

Создание с помощью New-ADDCCloneConfigFile

Модуль Windows PowerShell Active Directory в Windows Server 2012 содержит новый командлет:

Тесты, выполняемые при работе в :

Эмулятор PDC работает в Windows Server 2012 или более поздней версии

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

Исходный контроллер домена не содержит никаких исключенных приложений или служб

Исходный контроллер домена уже не содержит файл DcCloneConfig.xml по указанному пути

Шаг 6. Перевод исходного контроллера домена в автономный режим

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

Графический метод

Используйте кнопку завершения работы в выполняемом контроллере домена или кнопку завершения работы в диспетчере Hyper-V.

Метод с Windows PowerShell

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

Stop-computer — это командлет, поддерживающий завершение работы компьютеров без учета виртуализации, он аналогичен устаревшей служебной программе Shutdown.exe. Stop-vm — это новый командлет в модуле Windows PowerShell Windows Server 2012 Hyper-V, который по возможностям аналогичен диспетчеру Hyper-V. Второй командлет удобно использовать в лабораторных средах, где контроллер домена часто работает в частной виртуализированной сети.

Шаг 7. Копирование дисков

На этапе копирование необходимо принять решение административного характера:

Копирование дисков вручную без использования Hyper-V

Экспорт виртуальной машины с помощью Hyper-V

Экспорт объединенных дисков с помощью Hyper-V

Необходимо скопировать все диски виртуальной машины, а не только системный диск. Если исходный контроллер домена использует разностные диски и вы планируете переместить клонированный контроллер домена на другой узел Hyper-V, необходимо выполнить экспорт.

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

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

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

Копирование дисков вручную

Метод для диспетчера Hyper-V

Используйте оснастку диспетчера Hyper-V, чтобы определить, какие диски сопоставлены с данным исходным контроллером домена. Используйте параметр «Проверить», чтобы проверить, использует ли контроллер домена разностные диски (что также требует копирования родительского диска).

Чтобы удалить моментальные снимки, выберите виртуальную машину и удалите поддерево снимков.

После этого вы можете вручную скопировать файлы VHD или VHDX с помощью проводника, Xcopy.exe или Robocopy.exe. Никакие специальные действия при этом не требуются. Рекомендуется изменять имена файлов даже при перемещении в другую папку.

Если копирование осуществляется между главными компьютерами по локальной сети (со скоростью 1 Гбит/с или выше), параметр Xcopy.exe /J позволяет копировать файлы VHD/VHDX значительно быстрее, чем в любом другом средстве, за счет существенно более интенсивного использования пропускной способности.

Метод с Windows PowerShell

Чтобы определить диски с помощью Windows PowerShell, используйте модули Hyper-V:

Например, вы можете возвратить все жесткие диски IDE из виртуальной машины с именем DC2 с помощью следующего примера:

Если путь к диску указывает на файл AVHD или AVHDX, это моментальный снимок. Чтобы удалить сопоставленные с диском моментальные снимки и объединить все в реальный файл VHD или VHDX, используйте следующие командлеты:

Например, чтобы удалить все снимки из виртуальной машины с именем DC2-SOURCECLONE, используйте следующее:

Чтобы скопировать файлы с помощью Windows PowerShell, используйте следующий командлет:

Совместите с командлетами виртуальной машины в конвейерах, чтобы упростить автоматизацию. Конвейер — это канал, используемый несколькими командлетами для обмена данными. Например, чтобы скопировать диск автономного исходного контроллера домена с именем DC2-SOURCECLONE на новый диск c:\temp\copy.vhd, не зная точный путь к системному диску, используйте следующее:

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

Дополнительные сведения о других операциях Windows PowerShell с конвейерами см. в разделе Конвейерная передача и конвейер в Windows PowerShell.

Экспорт виртуальной машины

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

Метод для диспетчера Hyper-V

Порядок экспорта виртуальной машины с помощью диспетчера Hyper-V:

Щелкните исходный контроллер домена правой кнопкой мыши и выберите пункт Экспорт.

Выберите существующую папку в качестве контейнера экспорта.

Дождитесь, пока в столбце «Состояние» не пропадет слово Экспорт.

Метод с Windows PowerShell

Чтобы экспортировать виртуальную машину с помощью модуля Windows PowerShell Hyper-V, используйте командлет:

Например, для экспорта виртуальной машины с именем DC2-SOURCECLONE в папку C:\VM:

Windows Server 2012 Hyper-V поддерживает новые возможности импорта и экспорта, выходящие за рамки данного материала. Дополнительные сведения см. в статьях на сайте TechNet.

Экспорт объединенных дисков с помощью Hyper-V

Метод для диспетчера Hyper-V

Порядок создания объединенного диска с использованием диспетчера Hyper-V:

Щелкните изменить диск.

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

Выберите параметр Объединить, чтобы создать отдельный диск из всей структуры родительских и дочерних элементов.

Выберите новый виртуальный жесткий диск и укажите путь. При этом имеющиеся файлы VHD/VHDX комбинируются в новый отдельный портативный блок, который не подвержен риску восстановления предыдущих снимков.

Метод с Windows PowerShell

Чтобы создать объединенный диск из комплексного набора родительских элементов с помощью модуля Windows PowerShell Hyper-V, используйте командлет:

Например, для экспорта всей цепочки снимков дисков виртуальной машины (на этот раз без разностных дисков) и родительского диска в новый отдельный диск с именем DC4-CLONED.VHDX используйте следующее:

Добавление XML в автономный системный диск

Если вы скопировали Dccloneconfig.xml на работающий исходный контроллер домена, теперь необходимо скопировать обновленный файл dccloneconfig.xml на автономный скопированный/экспортированный системный диск. В зависимости от того, какие приложения ранее обнаружил Get-ADDCCloningExcludedApplicationList, вам также может потребоваться скопировать на этот диск файл CustomDCCloneAllowList.xml.

Файл DcCloneConfig.xml может находиться в следующих расположениях:

Съемные носители с возможностью чтения и записи в порядке букв дисков; в корне диска

Эти пути нельзя настроить. После начала клонирования соответствующая операция проверяет эти расположения в указанном порядке и использует первый найденный файл DcCloneConfig.xml независимо от содержимого других папок.

Файл CustomDCCloneAllowList.xml может находиться в следующих расположениях:

Съемные носители с возможностью чтения и записи в порядке букв дисков; в корне диска

Вы можете запустить New-ADDCCloneConfigFile с аргументом -offline (это также называется автономным режимом), чтобы создать файл DcCloneConfig.xml и поместить его в подходящее расположение. В следующих примерах показано, как запустить New-ADDCCloneConfigFile в автономном режиме.

Чтобы создать клонированный контроллер домена с именем CloneDC1 в автономном режиме, на сайте с именем «REDMOND» со статическим IPv4-адресом введите:

Чтобы создать клонированный контроллер домена с именем Clone2 в автономном режиме со статическим адресом IPv4 и статическими параметрами IPv6, введите следующее.

Чтобы создать клонированный контроллер домена с именем Clone2 в автономном режиме со статическим IPv4 и динамическими параметрами IPv6, а также указать несколько DNS-серверов для параметров распознавателя DNS, введите следующее.

Чтобы создать клонированный контроллер домена с именем Clone1 в автономном режиме с динамическим адресом IPv4 и статическими параметрами IPv6, введите следующее.

Чтобы создать клонированный контроллер домена в автономном режиме с динамическим адресом IPv4 и динамическими параметрами IPv6, введите следующее.

Метод для проводника

Windows Server 2012 теперь предоставляет графические средства для подключения файлов VHD и VHDX. Для этого требуется установить в Windows Server 2012 компонент «Возможности рабочего стола».

Щелкните только что скопированный файл VHD/VHDX, содержащий системный диск исходного контроллера домена или папку рабочего каталога DSA, а затем щелкните Подключить в меню Средства работы с образами дисков.

Скопируйте файлы XML в подходящее расположение на подключенном диске. Вы можете получить запрос на наличие разрешений для этой папки.

Щелкните подключенный диск и выберите Извлечь в меню Средства работы с образами дисков.

Метод с Windows PowerShell

Кроме того, вы можете подключить отключенный диск и скопировать файл XML с помощью командлетов Windows PowerShell:

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

Кроме того, вы можете использовать новый командлет Mount-DiskImage для подключения файла VHD (или ISO).

Шаг 8. Создание новой виртуальной машины

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

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

Импорт экспортированной виртуальной машины

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

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

Метод для диспетчера Hyper-V

Создайте новую виртуальную машину.

Укажите имя, память и сеть виртуальной машины.

Укажите скопированный системный диск на странице «Подключить виртуальный жесткий диск».

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

При наличии нескольких дисков, сетевых адаптеров или других настраиваемых компонентов настройте их перед запуском контроллера домена. Метод копирования дисков «экспорт-импорт» рекомендуется применять для сложных виртуальных машин.

Метод с Windows PowerShell

Вы можете использовать модуль Windows PowerShell Hyper-V для автоматизации процесса создания виртуальной машины Windows Server 2012 с помощью следующего командлета:

Например, здесь создается виртуальная машина DC4-CLONEDFROMDC2, которая использует 1 ГБ ОЗУ, загружается из файла c:\vm\dc4-systemdrive-clonedfromdc2.vhd и использует виртуальную сеть 10.0:

Импорт ВМ

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

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

Важно использовать параметр Копировать, так как при экспорте сохраняются все сведения из источника, импорт сервера с помощью параметра Переместить или На месте при выполнении на сервере узла Hyper-V приведет к информационному конфликту.

Метод для диспетчера Hyper-V

Порядок импорта с помощью оснастки диспетчера Hyper-V:

Щелкните Импорт виртуальной машины.

На странице Выбор папки выберите файл определения экспортированной виртуальной машины с помощью кнопки «Обзор».

На странице Выбор виртуальной машины щелкните исходный компьютер.

На странице Выбор типа импорта щелкните Копировать виртуальную машину (создать новый уникальный идентификатор), а затем нажмите копку Готово.

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

Не забудьте удалить все импортированные снимки с помощью оснастки управления Hyper-V:

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

Метод с Windows PowerShell

Вы можете использовать модуль Windows PowerShell Hyper-V для автоматизации процесса импорта виртуальной машины Windows Server 2012 с помощью следующих командлетов:

Например, здесь экспортированная виртуальная машина DC2-CLONED импортируется с помощью автоматически определенного файла XML, а затем ей сразу же назначается новое имя DC5-CLONEDFROMDC2:

Не забудьте удалить все импортированные снимки с помощью следующих командлетов:

Убедитесь, что при импорте компьютера статические MAC-адреса не были назначены исходному контроллеру домена. Если клонируется исходный компьютер со статическим MAC-адресом, скопированные компьютеры не смогут правильно отправить или принимать сетевой трафик. В такой ситуации задайте новый уникальный статический или динамический MAC-адрес. Чтобы определить, использует ли виртуальная машина статический MAC-адрес, воспользуйтесь следующей командой:

Get-VM-VMName — Тестовая виртуальная машина | Get-VMNetworkAdapter | FL\*

Шаг 9. Клонирование новой виртуальной машины

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

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

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

Если для запуска виртуальной машины используется Windows PowerShell, в модуле Hyper-V доступен новый командлет:

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

Меры безопасности виртуализации

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

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

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

Проверка низкоуровневой оболочки

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

Сведения об известной поддержке ИД создания виртуальной машины см. в предыдущем разделе Требования к платформе.

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

Проверка топологии репликации

Меры безопасности виртуализации инициируют непринудительную репликацию входящего трафика для разницы репликации Active Directory, а также непринудительную повторную синхронизацию всего содержимого SYSVOL. Благодаря этому контроллер домена возвращается из моментального снимка полнофункциональным и согласованным с остальной частью среды.

Эта новая возможность имеет несколько требований и ограничений:

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

Не следует одновременно восстанавливать все контроллеры домена в домене.

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

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

Доступность контроллера домена, доступного для записи

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

Одновременное восстановление

Не восстанавливайте одновременно все контроллеры домена в отдельном домене. В случае одновременного восстановления всех моментальных снимков репликация Active Directory работает правильно, однако репликация SYSVOL прерывается. Архитектура восстановления для FRS и DFSR требует установки их экземпляра реплики в непринудительный режим синхронизации. Если все контроллеры домена восстанавливаются одновременно и каждый из них помечает себя в качестве не заслуживающего доверия для SYSVOL, все они попытаются синхронизировать групповые политики и скрипты с партнера, однако в этот момент все партнеры также будут не заслуживающими доверия.

Если все контроллеры домена восстанавливаются одновременно, используйте материал следующих статей, чтобы задать один контроллер домена — обычно это эмулятор PDC — в качестве заслуживающего доверие, чтобы другие контроллеры домена могли вернуться к нормальной работе:

Не запускайте все контроллеры домена в лесу или домене на одном узле низкоуровневой оболочки. При этом создается единая точка отказа, нарушающая работу доменных служб Active Directory, Exchange, SQL и выполнение других операций корпоративного уровня при каждом переходе низкоуровневой оболочки в автономный режим. Это ничем не отличается от использования одного контроллера домена для всего домена или леса. Несколько контроллеров домена на нескольких платформах помогают обеспечить избыточность и отказоустойчивость.

Репликация после получения моментального снимка

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

Используйте Repadmin.exe, чтобы отобразить все нереплицированные исходящие изменения между контроллером домена и его партнерами:

Для возврата имен партнеров контроллера домена и GUID объектов DSA используйте следующее:

Для возврата ожидающей входящей репликации с партнерского контроллера домена на восстанавливаемый контроллер домена используйте следующее:

Кроме того, можно просто просмотреть число нереплицированных изменений:

Например, здесь вы отображаете партнерства репликации контроллера домена DC4 (выходные данные изменены для облегчения восприятия, важные записи выделены курсивом):

Теперь вы знаете, что он осуществляет репликацию с DC2 и DC3. После этого вы отображаете список изменений, которые DC2 все еще не получил с DC4, и видите одну новую группу:

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

Кроме того, если вас волнуют только оставшиеся объекты, а не то, какие объекты не были реплицированы, вы можете использовать параметр /statistics:

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

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

Командлеты моментальных снимков Windows PowerShell

Следующие командлеты модуля Hyper-V Windows PowerShell реализуют возможности работы с моментальными снимками в Windows Server 2012:

Источник