При развёртывании очередного агента System Center 2016 VMM на новых хостах виртуализации Hyper-V на базе Windows Server 2016 столкнулись с проблемой невозможности установки агента с консоли управления VMM. Несколько предпринятых попыток установки завершалась ошибкой 2927 следующего вида (в локализованном варианте консоли VMM):
Ошибка (2927)
При попытке связаться с сервером SCVMM1.holding.com произошла ошибка управления оборудованием: : .
WinRM: URL: [http://scvmm01.holding.com:5985], Verb: [INVOKE], Method: [AddPeerCertificate], Resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/scvmm/AgentManagement]
Unknown error (0x80338113)
Рекомендуемое действие
Убедитесь, что на сервере SCVMM01.holding.com установлена и запущена служба WinRM. Дополнительные сведения можно получить с помощью команды "winrm helpmsg hresult" и в статье http://support.microsoft.com/kb/2742275.
Из текста ошибки понятно, что на сервере VMM возникли проблемы с работой WinRM.
Для первичной диагностики проблемы можем воспользоваться статьёй, на которую ссылается текст ошибки: "Troubleshoot issues when you add a Hyper-V host in Virtual Machine Manager". В числе проверок, в первую очередь, убедимся в том, что не блокируется порт WinRM (TCP 5985) на стороне сервера VMM.
Однако, в нашем случае проблема была явно в чём-то другом, так как ещё недавно развёртывание агентов VMM работало без ошибок. Перейдя на сервер VMM, проверяем состояние текущей конфигурации WinRM.
winrm quickconfig
winrm enumerate winrm/config/listener
Первая команда выполняет быструю конфигурацию службы, если она ещё не была включена и настроена ранее. Вторая команда показывает текущее состояние TCP-прослушивателя WinRM.
Как видно в нашем примере, служба WinRM уже запущена и настроена. При этом обращаем внимание на то, что источником конфигурации являются групповые политики домена. Выполним команду просмотра общей конфигурации WinRM и обратим внимание на то, как настроены IP-фильтры для удалённого подключения:
winrm get winrm/config
Как видим, IPv4Filter настроен в групповой политике как "*", то есть подключение к WinRM разрешено с любых хостов. При этом IPv6Filter также идёт из GPO, но не задан. Казалось бы мелочь, но мелочь с точки зрения VMM важная.
Если обратимся к старой статье из архива блога VMM "SC VMM 2012 RC: Understanding the Hyper-V host addition operation if Window Remote Management (WinRM) is configured using Group Policy (GPO) settings", то обнаружим то, что для корректной работы VMM при условии настройки WinRM через GPO, требуется обращать внимание на три параметра в разделе административных шаблонов GPO Computer Configuration > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service:
1. Allow automatic configuration of listeners
2. Turn on Compatibility HTTP Listener
3. Turn on Compatibility HTTPS Listener
Первый параметр в современных версиях административных шаблонов звучит несколько иначе "Allow remote server management through WinRM".
При этом в выше упомянутой статье есть отдельное замечание о том, как должен быть настроен этот самый первый параметр GPO:
If "Automatic configuration of listeners" is enabled, it’s important that the IPv4 and IPv6 filter is set to *.
Ну и вот, как выяснилось в нашем случае, администратор домена, настраивающий GPO, включил IP-фильтрацию для IPv4, но не задал аналогичной настройки для IPv6.
Откорректируем эту политику с учётом выше обозначенного замечания:
Применим новые параметры GPO на сервере VMM и снова проверим общую конфигурацию WinRM:
gpupdate
winrm get winrm/config
Не смотря на то, что на сервере VMM у нас в явном виде не используется протокол IPv6, выполненное изменение GPO привело к тому, что развёртывание агентов VMM стало работать в штатном режиме и ранее описанная ошибка исчезла. При этом параметры GPO "Turn on Compatibility HTTP Listener" и "Turn on Compatibility HTTPS Listener" для дополнительной активации TCP-прослушивателей WinRM на портах 80 и 443 мы в своей конфигурации не использовали.
RSS - Записи
Добавить комментарий