Живая миграция сломалась после апгрейда на Windows Server 2025: настраиваем ограниченное делегирование Kerberos

Обновили пару хостов Hyper-V до Windows Server 2025 — и «Переместить» перестало работать. Хосты пингуются, WinRM отвечает, шары открываются, а живая миграция падает на источнике с жалобой на учётные данные. Ниже — почему это происходит (виноваты не сеть и не DNS), как настроить ограниченное делегирование Kerberos в Active Directory для обоих хостов так, как это описано в Microsoft Learn, чем проверить результат и стоит ли вместо этого просто выключить Credential Guard. Пример — турагентство «Меридиан-Тур» на 11 рабочих мест: два хоста, семь виртуалок, около сорока минут работы.

Симптом: хосты видят друг друга, а миграция падает на источнике

После in-place апгрейда хостов Hyper-V на Windows Server 2025 эта картина повторяется почти дословно. Два хоста, раньше стояла Windows Server 2022, живая миграция работала годами без единой настройки в Active Directory. Диспетчер Hyper-V видит соседний хост, консоль подключается, SMB-шары открываются, Test-NetConnection до портов 445 и 6600 зелёный, WinRM отвечает. А «Переместить» не работает, и на источнике появляется такое сообщение:

Virtual machine migration operation failed at migration Source.
Failed to establish a connection with host HV02: No credentials are available in the security package (0x8009030E).

Дальше админ обычно идёт чинить не туда: проверяет DNS, перезаводит хост в домене, открывает порты, сносит и ставит заново роль Hyper-V. Всё это время потеряно зря, а вывод хоста из домена ещё и добавляет рисков — после перезагрузки можно остаться без доменного входа на машину, на которой крутится вся инфраструктура. Ошибка при этом вообще не про сеть. Она буквально означает: «в пакете безопасности нет учётных данных, которые я мог бы делегировать».

Причина в одной строчке из документации Microsoft: начиная с Windows Server 2025, Credential Guard включается по умолчанию на всех доменных серверах, которые не являются контроллерами домена, если железо удовлетворяет требованиям VBS. А Credential Guard запрещает CredSSP использовать сохранённые и SSO-учётные данные — только явно введённые. CredSSP же был протоколом живой миграции по умолчанию в Windows Server 2022 и раньше. Получается, апгрейд сам себе выключает миграцию, и никакого предупреждения при этом не показывает.

• Ошибка появляется ровно на стороне источника — того хоста, с которого вы двигаете ВМ.
• Состояние Credential Guard на приёмнике в большинстве случаев на исход не влияет.
• В кластере и в SCVMM ломается «в обе стороны»: источником может оказаться любой узел.
• Перенос выключенной ВМ и экспорт/импорт при этом обычно проходят — что окончательно сбивает с толку.

Пример: турагентство «Меридиан-Тур» на 11 рабочих мест

Разберу на условном клиенте. Турагентство «Меридиан-Тур», 11 рабочих мест: менеджеры по продажам, бухгалтер, руководитель. Два хоста Hyper-V для такого офиса выглядят избыточно, и сначала я сам так думал. Но у агентства сезонная работа без выходных: в мае и перед новогодними праздниками менеджеры бронируют туры у туроператоров до ночи, и остановка терминального сервера на час — это сорванные брони и звонки клиентов, которые уходят к конкурентам. Второй хост появился не ради красоты: при замене старого сервера его не списали, а оставили резервом. Итог — основной Dell PowerEdge T350 с Xeon E-2378 и 64 ГБ памяти и прежний сервер на 48 ГБ, между ними прямой 10-гигабитный линк без коммутатора, локальные SSD на каждом и репликация Hyper-V. Failover-кластера нет: общее хранилище агентству не по карману и не нужно. Живая миграция без кластера решает главную задачу — увести виртуалки с хоста, чтобы накатить обновления и перезагрузить его днём, не выгоняя менеджеров из программ.

Виртуалок семь: контроллер домена, терминальный сервер на 11 сессий, сервер 1С с PostgreSQL для бухгалтерии и учёта договоров с туристами, файловый сервер со сканами паспортов и договоров, сервер резервного копирования, АТС и небольшая служебная ВМ. Домен meridian.local, контроллер на Windows Server 2019, функциональный уровень леса 2016. Апгрейд хостов 2022 → 2025 делали in-place в субботу, по одному, с проверкой после каждого. Обновление прошло чисто: роли на месте, виртуалки поднялись, версии конфигураций ВМ подняли позже отдельным шагом. В понедельник понадобилось увести нагрузку с HV01 — и выяснилось, что миграции нет. В субботу её проверили только на первом этапе: второй хост ещё был на 2022, и перенос с 2022 на 2025 прошёл нормально, потому что источник был старым, без Credential Guard. Типичная ловушка поэтапного апгрейда: поломка проявляется только после того, как на 2025 переедет второй хост.

Диагностика заняла минут пять. Сначала посмотрел состояние Credential Guard на обоих хостах:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
# 1 — Credential Guard запущен

Get-VMHost | Format-List Name, VirtualMachineMigrationEnabled, `
    VirtualMachineMigrationAuthenticationType, VirtualMachineMigrationPerformanceOption
# VirtualMachineMigrationAuthenticationType : CredSSP

Единица в SecurityServicesRunning и CredSSP в типе аутентификации — диагноз поставлен. То же видно в msinfo32: в строке «Службы Virtualization-based security, которые запущены» появляется Credential Guard. В журнале «Система» есть событие WinInit с кодом 13 — «Credential Guard (LsaIso.exe) was started and will protect LSA credentials». Дальше — работа в AD и на хостах, суммарно около сорока минут вместе с ожиданием репликации. Итог: виртуалка 1С с 16 ГБ памяти по прямому 10-гигабитному линку в режиме Compression переехала меньше чем за минуту, а у бухгалтера открытая база не отвалилась.

• Масштаб: 11 рабочих мест, 7 виртуалок, 2 хоста без общего хранилища и без кластера.
• Зачем второй хост: сезонная работа без выходных, простой терминального сервера днём стоит сорванных броней.
• Что сломалось: миграция после апгрейда второго хоста на Windows Server 2025.
• Диагностика: Win32_DeviceGuard, Get-VMHost, событие WinInit 13 — пять минут.

Ограниченное делегирование Kerberos: что и куда прописать в AD

Правильное лечение — перевести живую миграцию с CredSSP на Kerberos с ограниченным делегированием. Это то, что Microsoft рекомендует и в статье про настройку хостов, и в списке известных проблем Credential Guard. Логика простая: при CredSSP хост-источник получает ваши учётные данные и предъявляет их приёмнику — отсюда и требование быть залогиненным именно на источнике. При Kerberos источник получает от KDC билет на службу приёмника от вашего имени, а в AD заранее описано, кому и к каким службам такие билеты выдавать. Никаких паролей по проводу, никакой зависимости от того, где вы открыли консоль.

Делегирование настраивается на объекте компьютера в AD и обязательно в обе стороны: HV01 должен доверять делегированию к службам HV02, и HV02 — к службам HV01. Забыть про вторую сторону — самая частая ошибка, после которой миграция «туда» идёт, а «обратно» падает. Служб две. Microsoft Virtual System Migration Service нужна для переноса самой виртуальной машины. cifs нужна, если вы переносите ещё и хранилище — то есть файлы ВМ, а не только память. Я всегда прописываю обе: сегодня storage migration не используется, а завтра понадобится увести диски с забитого NVMe, и никто не вспомнит, почему не работает.

Через оснастку это делается так: «Active Directory — пользователи и компьютеры», контейнер Computers, свойства компьютера HV01, вкладка «Делегирование», переключатель «Доверять компьютеру делегирование указанных служб», ниже — «Использовать любой протокол проверки подлинности», кнопка «Добавить», выбираем компьютер HV02 и отмечаем cifs и Microsoft Virtual System Migration Service. Затем то же на HV02, указывая HV01. Для двух хостов это терпимо, для четырёх уже утомительно и чревато опечатками, поэтому я делаю скриптом:

$Pairs = @(
    @{ Source = 'HV01'; Target = 'HV02' },
    @{ Source = 'HV02'; Target = 'HV01' }
)
$Domain = 'meridian.local'

foreach ($p in $Pairs) {
    $t     = $p.Target
    $tFqdn = "$t.$Domain"
    $spns  = @(
        "Microsoft Virtual System Migration Service/$tFqdn",
        "Microsoft Virtual System Migration Service/$t",
        "cifs/$tFqdn",
        "cifs/$t"
    )
    Set-ADComputer -Identity $p.Source -Add @{ 'msDS-AllowedToDelegateTo' = $spns }
    # «Использовать любой протокол проверки подлинности» (protocol transition), как в Microsoft Learn
    Set-ADAccountControl -Identity "$($p.Source)$" -TrustedToAuthForDelegation $true
}

# проверяем, что записалось
Get-ADComputer HV01 -Properties msDS-AllowedToDelegateTo |
    Select-Object -ExpandProperty msDS-AllowedToDelegateTo

SPN прописываются в двух формах — по короткому имени и по FQDN. Kerberos не нормализует имена: если в Диспетчере Hyper-V вы подключились к соседу как HV02, а в делегировании есть только HV02.meridian.local, билет не выдадут. Добавить обе формы ничего не стоит, а целый класс «мистических» отказов исчезает.

Отдельно про выбор между «Использовать только Kerberos» и «Использовать любой протокол проверки подлинности». Инструкция Microsoft Learn по настройке хостов для живой миграции прямо указывает второй вариант — он выставляет флаг TrustedToAuthForDelegation, то есть разрешает протокольный переход (S4U). Причина описана в блоге команды виртуализации ещё к Windows Server 2016: управление Hyper-V перешло на WMI v2 поверх WinRM, а WinRM принимает ваш входящий Kerberos-билет так, что пересылаемый (forwardable) билет недоступен службе VMMS. Когда миграцию запускают удалённо — из Диспетчера Hyper-V на рабочей станции админа, из Windows Admin Center, скриптом с сервера управления или из SCVMM, — у источника просто нет билета, который можно делегировать, и «только Kerberos» падает. Поэтому основной вариант у меня — как в документации. Да, флаг даёт хосту чуть больше возможностей, но делегирование всё равно ограничено двумя службами одного конкретного соседа. «Только Kerberos» я оставляю как необязательное ужесточение: включать его стоит лишь если миграцию всегда запускают локально на источнике и вы проверили перенос в обе стороны после смены. Вернуть флаг, если ужесточение не прижилось, можно одной командой:

# снять protocol transition (режим «только Kerberos») — только после проверки
Set-ADAccountControl -Identity 'HV01$' -TrustedToAuthForDelegation $false

# вернуть вариант из документации Microsoft
Set-ADAccountControl -Identity 'HV01$' -TrustedToAuthForDelegation $true

• Настраивать делегирование нужно под учётной записью члена группы «Администраторы домена» — на локальных правах хоста это не сделать.
• Направления: HV01 → службы HV02 и HV02 → службы HV01.
• Службы: Microsoft Virtual System Migration Service (перенос ВМ) и cifs (перенос хранилища).
• Имена: короткое и FQDN.
• Режим по документации: «Использовать любой протокол проверки подлинности» (TrustedToAuthForDelegation).
• Никогда не используйте «Доверять компьютеру делегирование любых служб» — это неограниченное делегирование, оно само по себе дыра, и Credential Guard его всё равно блокирует.

Переключаем хосты и заставляем изменения вступить в силу

После AD — хосты. Три команды на каждом, ничего сложного. Включаем миграцию, при желании прибиваем её трафик к конкретной сети и меняем протокол аутентификации:

Enable-VMMigration

# трафик миграции — только по выделенному линку 10.20.30.0/24
Set-VMMigrationNetwork 10.20.30.0/24

Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos `
           -VirtualMachineMigrationPerformanceOption Compression `
           -MaximumVirtualMachineMigrations 2 `
           -MaximumStorageMigrations 2

Про сеть скажу отдельно, потому что этим часто пренебрегают. Трафик живой миграции не шифруется. Это память работающей виртуалки, идущая по проводу открытым текстом: пароли, ключи, содержимое сессий терминального сервера, у турагентства — ещё и паспортные данные туристов в открытых документах. Гнать это по той же VLAN, где сидят пользователи и гостевой Wi-Fi для клиентов в офисе, — плохая идея. Отдельный VLAN или, как в «Меридиан-Туре», прямой линк между хостами закрывают вопрос и заодно ускоряют перенос.

Про режим производительности: по умолчанию стоит Compression — сжатие памяти перед отправкой по TCP/IP. На одном линке 1–10 гигабит без RDMA это разумный выбор: упираетесь вы в сеть, а процессор сжимает страницы памяти быстрее, чем они уходят в провод. Режим SMB выигрывает прежде всего при картах с RDMA (SMB Direct) и/или нескольких сетевых путях между хостами, когда работает SMB Multichannel. На одиночном 10GbE без RDMA он обычно не быстрее Compression. Чистый TCP/IP оставьте для отладки. Тюнинг числа одновременных миграций даёт заметный эффект на 25–100 гигабитах, а на паре хостов с десяткой это косметика.

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

# 1. форсируем репликацию AD
repadmin /syncall /AdeP

# 2. чистим билеты: пользовательские и системного контекста (VMMS работает как LocalSystem)
klist purge
klist -li 0x3e7 purge

# 3. проверяем, что хост реально переключился
Get-VMHost | Format-List VirtualMachineMigrationEnabled, `
    VirtualMachineMigrationAuthenticationType, MigrationNetworks

Если после чистки кэша всё равно мимо — перезагрузите хост. Это надёжнее любых klist purge, а хост после свежего апгрейда перезагрузки всё равно просит. В «Меридиан-Туре» я перезагрузил оба по очереди в обед, в тихий час, заранее предупредив менеджеров и один раз остановив виртуалки на время ребута, — больше тема не всплывала.

• Enable-VMMigration и Set-VMMigrationNetwork — на обоих хостах.
• Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos — на обоих хостах.
• Compression по умолчанию оставить, если нет RDMA и нескольких путей.
• repadmin /syncall, затем klist purge и klist -li 0x3e7 purge.
• Проверка Get-VMHost и тестовая миграция в обе стороны.

Не заработало: куда смотреть по порядку

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

Первое — прочитайте атрибут обратно. Get-ADComputer HV01 -Properties msDS-AllowedToDelegateTo должен показать четыре записи с именем HV02, а на HV02 — четыре с именем HV01. Если пусто на одной из сторон, вы знаете, что делать. Второе — дубликаты SPN. setspn -X по домену находит записи, зарегистрированные дважды; при дубликате KDC просто отказывается выдавать билет, и никакого внятного сообщения вы не увидите. Такое случается после переустановки хоста с тем же именем, когда старый объект компьютера остался в AD.

Третье — время. Kerberos допускает расхождение часов в пять минут, и хост, который после апгрейда потерял источник NTP и ушёл на встроенный CMOS, ломает вообще всё, а не только миграцию. w32tm /query /status и w32tm /stripchart /computer:dc01.meridian.local /samples:3 дают ответ за десять секунд. Четвёртое — прямая и обратная зоны DNS: у обоих хостов должны быть корректные A-записи и PTR, иначе SPN по FQDN не совпадёт с тем, что запросит клиент.

Пятое — журналы. Смотрите Журналы приложений и служб → Microsoft → Windows → Hyper-V-VMMS → Admin на обоих хостах: там события миграции с человеческими причинами отказа. Состояние самого Credential Guard проверяется в «Системе» по источнику WinInit: событие 13 — запустился, 14 — конфигурация (0x1 — с UEFI-замком, 0x2 — без замка), 15 — настроен, но безопасное ядро не работает. И шестое, банальное: правила брандмауэра группы «Hyper-V» должны быть включены на обоих хостах — Get-NetFirewallRule -DisplayGroup 'Hyper-V' | Where-Object Enabled -eq 'False'.

• msDS-AllowedToDelegateTo пуст на одной из сторон — самая частая причина «туда мигрирует, обратно нет».
• Дубликат SPN после переустановки хоста с прежним именем — setspn -X.
• Расхождение времени больше 5 минут — Kerberos отказывает молча.
• Нет PTR-записи или A-запись указывает на старый IP после переезда.
• Отключены правила брандмауэра группы Hyper-V (порт живой миграции TCP 6600 и SMB 445).
• Хост подключён к соседу по короткому имени, а в делегировании только FQDN.

Соблазн просто выключить Credential Guard

Первое, что предлагает половина форумных веток: выключить Credential Guard и жить как раньше. Технически это работает и делается быстро, потому что при автоматическом включении в Windows Server 2025 замок UEFI не ставится — значит, отключить можно удалённо, без физического присутствия у сервера.

# HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
    -Name 'LsaCfgFlags' -Type DWord -Value 0

# HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard
New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' `
    -Name 'LsaCfgFlags' -Type DWord -Value 0

Restart-Computer

То же самое из групповой политики: «Конфигурация компьютера → Административные шаблоны → Система → Device Guard → Включить средства обеспечения безопасности на основе виртуализации» перевести в «Отключено». Важная деталь: удаление параметров реестра Credential Guard не отключает — их нужно именно выставить в 0. И ещё одна: если вы явно отключили Credential Guard ДО апгрейда, автоматическое включение не перезапишет вашу настройку. Для парка, который вы обновляете партиями, это удобный аварийный тормоз.

Теперь моя позиция. Отключать Credential Guard на хосте виртуализации, где крутится вся инфраструктура компании, ради экономии времени на делегировании — плохая сделка. Credential Guard изолирует NTLM-хеши, TGT и сохранённые доменные учётки в защищённом виртуализацией окружении; именно это мешает атакам pass-the-hash и pass-the-ticket. На хост Hyper-V обычно входят администраторы домена — то есть ровно те учётные данные, за которыми охотится шифровальщик. Отключив CG, вы возвращаете их в LSASS, в досягаемость любого, кто получит на хосте права администратора.

Где отключение всё-таки оправдано: короткое окно на несколько дней, когда миграция нужна прямо сейчас, а учётки с правами на делегирование нет под рукой; несовместимый сторонний софт (реализации MSCHAPv2 вроде Cisco ISE, Java GSS API — Microsoft перечисляет их в известных проблемах); тестовые стенды. Во всех этих случаях выключение — временная мера с датой возврата, а не решение. И ещё: на контроллерах домена Credential Guard по умолчанию не включается, так что искать эту поломку на DC не нужно.

• Credential Guard при автоматическом включении в Windows Server 2025 ставится без UEFI-замка — отключается удалённо.
• Отключать — значениями LsaCfgFlags = 0, а не удалением ключей.
• Явное отключение до апгрейда сохраняется после обновления.
• Любое отключение — с датой возврата и записью в журнале изменений.

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

Всё вышеописанное решается ещё проще, если сделать это ДО обновления. Ограниченное делегирование Kerberos прекрасно работает на Windows Server 2022, 2019 и 2016 — механизм старый, ничего специфичного для 2025 в нём нет. То есть вы можете спокойно, в рабочее время, настроить делегирование и переключить VirtualMachineMigrationAuthenticationType на Kerberos на действующих хостах, убедиться, что миграция работает, и только потом идти в апгрейд. Тогда включившийся Credential Guard ничего не сломает, и вы даже не заметите, что он появился.

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

Отдельно про кластеры и SCVMM. Для хостов без кластера делегирование настраивается по схеме «каждый с каждым», и с ростом числа хостов объём быстро растёт: при четырёх хостах это 12 направлений и 48 SPN, поэтому только скриптом с циклом по всем парам. В Failover Cluster миграцию внутри кластера оркестрирует кластерная служба, но Microsoft в известных проблемах Credential Guard прямо называет кластерные сценарии и SCVMM затронутыми, а переносы между кластерами и между кластером и одиночным хостом идут по той же схеме, что и в этой статье. Поэтому перед rolling upgrade кластера 2022 → 2025 я переключаю аутентификацию на Kerberos и проверяю перенос заранее, а не выясняю совместимость посреди процесса.

И про то, на что можно не тратить время. Не подбирайте MaximumVirtualMachineMigrations и SMBBandwidthLimitFactor, если у вас 1–10 гигабит и два-три хоста: значения по умолчанию адекватны, выигрыш будет в пределах погрешности. Не ждите ускорения от режима SMB на одиночном линке без RDMA — Compression там обычно не хуже. Не гоняйтесь за совместимостью процессоров, если хосты одинаковые. Всё это имеет смысл на 25 гигабитах и разнородном парке, а в офисе на 10–50 рабочих мест решают ровно две вещи: рабочий Kerberos и выделенная сеть под миграцию.

• На действующих хостах (2022 и старше) настроить ограниченное делегирование в AD — в обе стороны, для двух служб, по короткому имени и FQDN, с режимом «любой протокол проверки подлинности».
• Переключить хосты на Kerberos: Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos.
• Дождаться репликации AD, почистить билеты, протестировать миграцию в обе стороны туда-обратно.
• Только после этого обновлять хосты до Windows Server 2025 — по одному, с проверкой миграции после КАЖДОГО.
• После апгрейда проверить, что Credential Guard действительно включился (SecurityServicesRunning = 1) — и оставить его включённым.
• Зафиксировать в документации: тип аутентификации, сеть миграции, список SPN. Через год никто не вспомнит, почему в AD стоит делегирование.

Частые вопросы