Ошибка Hyper-V 0x80070569 — как исправить

Что такое ошибка 0x80070569?

Код ошибки 0x80070569 обычно сопровождается одним из сообщений:

• “‘VM_NAME’ failed to start worker process: Logon Failure: The user has not been granted the requested logon type at this computer.”
• “Failed to create Planned Virtual Machine at migration destination: Logon failure: the user has not been granted the requested logon type at this computer.”

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

Причины ошибки 0x80070569

Кратко — ошибка вызвана проблемой с правами или соединением. Основные факторы:

• Проблемы политик групп (GPO): отсутствует право «Log on as a service» или «Log on as a batch job» для идентичности NT Virtual Machine\Virtual Machines.
• Разрыв связи между Hyper‑V-хостом и доменом: сбой учётных данных, потеря доверия к домену, рассинхронизация времени.
• Локальные ограничения безопасности или сторонний антивирус/файрвол блокирует вход.

Важно: ошибка проявляется либо при старте VM, либо при переносе VM на другой хост (live migration).

Быстрые проверки перед исправлением

1. Проверьте, что служба Hyper‑V Virtual Machine Management запущена: откройте Services и убедитесь, что статус — Running.
2. Убедитесь, что host подключён к домену и доверие к домену не потеряно: выполните в PowerShell:

Test-ComputerSecureChannel -Verbose

При проблемах попробуйте восстановить канал:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

3. Проверьте системное время и синхронизацию с контроллерами домена (Kerberos чувствителен к рассинхронизации).
4. Отключите временно сторонний антивирус/файрвол и повторите попытку запуска VM.
5. Попробуйте запустить VM через PowerShell, чтобы увидеть расширенные ошибки:

Start-VM -Name "VM_NAME"

6. Просмотрите журнал событий на хосте: Event Viewer → Applications and Services Logs → Microsoft → Windows → Hyper‑V‑Worker и System.

Пошаговые решения

Ниже — проверенные шаги от простого к более сложному. Выполняйте в указанном порядке и тестируйте запуск VM после каждого шага.

1. Обновите политики на хосте: gpupdate /force

1. Войдите на Hyper‑V‑хост как Domain Administrator.
2. Установите Group Policy Management через Server Manager, если ещё не установлен.
3. Откройте GPMC (Console) и найдите политику, которая управляет правами пользователя (User Rights).
4. Отредактируйте политику и в секцию Log on as a service добавьте запись:

NT Virtual Machine\Virtual Machines

5. Закройте редактор политики.
6. Откройте Командную строку от имени администратора и выполните:

gpupdate /force

Это обновит GPO на хосте и позволит локальным правам вступить в силу, если GPO нарушало их применение.

2. Ручная настройка через локальную политику (gpedit.msc)

Используйте этот метод, если у вас нет доступа к GPMC или если нужно быстро подтвердить локальные права.

1. Нажмите Win + R, введите gpedit.msc и нажмите ОК.
2. Перейдите: Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
3. Откройте политику Log on as a batch job и/или Log on as a service.
4. Нажмите Add User or Group и добавьте: NT Virtual Machine\Virtual Machines.
5. Примените изменения и закройте редактор.

3. Проверка и исправление доверительных отношений с доменом

Если gpupdate и локальные права не помогли, восстановите доверие к домену:

• Выполните Test-ComputerSecureChannel с параметром -Repair, см. выше.
• При необходимости удалите хост из домена и заново присоедините (в плановом окне обслуживания).

Важно: перед повторной привязкой к домену сохраните конфигурации Hyper‑V и убедитесь, что сетевые настройки корректны.

4. Проверка прав специдентичности NT Virtual Machine\Virtual Machines

1. Убедитесь, что специальная идентичность действительно присутствует в списке прав (Local Security Policy / gpedit или GPMC).
2. Если запись отсутствует в доменной политике, добавьте её на уровне GPO, а затем примените gpupdate /force на каждом хосте.

5. Альтернативный путь: запуск VM под другим аккаунтом

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

Дополнительные рекомендации и сценарии

Когда эти шаги не помогают

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

Альтернативные подходы

• Автоматизировать проверку прав и применение GPO с помощью PowerShell (например, удалённо выполнять gpupdate и проверять наличие записи в User Rights Assignment).
• Использовать централизованный мониторинг (SIEM) для выявления изменений в политике, которые предшествуют ошибкам.

Роль‑ориентированные чеклисты

Для быстрого использования в рабочем процессе — чеклисты по ролям.

• Для Domain Admin:

  • Проверить GPO, которые управляют Log on as a service / Log on as a batch job.
  • Убедиться, что NT Virtual Machine\Virtual Machines присутствует в GPO.
  • Выполнить gpupdate /force на проблемном хосте.

• Для Host Admin:

  • Проверить службы Hyper‑V и журналы событий.
  • Выполнить Test-ComputerSecureChannel и проверить синхронизацию времени.
  • Проверить локальную политику через secpol.msc/gpedit.msc.

• Для Оператора виртуальных машин:

  • Попробовать Start-VM через PowerShell и сохранить вывод ошибок.
  • Пробовать временно запускать VM на другом хосте (если доступна миграция).

Мини‑методология для устранения (SOP)

1. Быстрые проверки (службы, домен, время, журналы).
2. Применить gpupdate /force и проверить локальные права.
3. Если не помогает — проверить доверие к домену и восстановить канал.
4. Если всё ещё не решено — сравнить GPO между рабочим и исправным хостом, применить исправления и повторно протестировать.

Критерии приёмки

• VM успешно стартует через Hyper‑V Manager и через PowerShell (Start-VM).
• Live migration проходит успешно без 0x80070569.
• В журналах событий ошибка 0x80070569 больше не появляется при попытках старта или миграции.

Частые ошибки и подводные камни

• Добавление пользователя в локальную политику без применения GPO приведёт к рассинхронизации настроек в доменной среде.
• Временные изменения в политике безопасности нужно документировать и откатывать после устранения причины.
• Не отключайте длительно антивирус/файрвол в продуктивной среде — используйте временное окно.

Тесты и критерии приёмки

• Start-VM — должен завершаться без ошибок.
• Live migration тест: перенести тестовую VM с минимальными ресурсами — миграция должна выполниться.
• Проверка журналов: отсутствие записей о Logon Failure для NT Virtual Machine\Virtual Machines.

Однострочный глоссарий

• NT Virtual Machine\Virtual Machines — специальная системная идентичность Windows для сервисов Hyper‑V, которой необходимы права входа для запуска VM.

Заключение

Ошибка 0x80070569 обычно означает проблему с правами входа или с соединением с доменом. Чаще всего её решает добавление NT Virtual Machine\Virtual Machines в права Log on as a service / Log on as a batch job и применение gpupdate /force. Если проблема сохраняется, последовательно проверяйте доверие к домену, синхронизацию времени и журналы событий. Применяйте роль‑ориентированные чеклисты и документируйте изменения в политиках.

Important: всегда тестируйте изменения в контролируемой среде перед применением на продуктивных хостах.

Понравилась статья? Напишите в комментариях, какой из способов помог в вашей среде.