Служба WinRM запущена, но недоступна.

Вопрос или проблема

У меня есть виртуальная среда тестирования для разработки скриптов. Поскольку .NET не способен на все возможности, которые предлагает PowerShell, я использую удаленные PowerShell Runspaces.

Моя проблема заключается в том, что я не могу подключиться к службе WinRM на FileShare-Memberserver, хотя служба запущена.

сообщение об ошибке

Начальная ситуация:

  • winrm quickconfig сообщает мне, что служба запущена и
    настроена на всех участниках.
  • Если я запускаю команду Test-wsman на самом FileShare, проблем тоже нет.
  • Я, очевидно, перезапускал службу несколько раз
  • С помощью моего удаленного скрипта я могу подключиться к Exchange Shell на FileShare, но не к MS PowerShell
  • Я могу подключиться к серверу вручную с помощью приложения “Удаленный рабочий стол”
  • В какой-то момент я отключил все брандмауэры, потому что хотел исключить возможность остановки запроса там.

Я сделал быстрый рисунок структуры сервера в моей виртуальной тестовой среде. (Красные стрелки означают, что команда Test-WSMan не сработала)

Структура сервера

У меня нет идей, как продолжать решать эту проблему. Я прочитал много информации в Интернете, но она не помогла. Я прошел все шаги блога TechNet “about_Remote_Troubleshooting”. В частности, что мой скрипт может подключиться к Exchange PS на том же сервере, просто поражает меня. Я задавал вопрос по этой теме на SO несколько месяцев назад, потому что думал, что ShellUri моего скрипта неправильный, хотя он работал для PS на DC.

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

Как обсуждалось в комментариях, локальная политика безопасности блокирует выполнение winrm quick config для создания HTTP слушателя на сервере – для решения этой проблемы:

подключитесь к удаленному серверу,
запустите редактор групповой политики (начать >> выполнить >> gpedit.msc)

Разверните Конфигурацию компьютера, Административные шаблоны, Компоненты Windows, Удаленное управление Windows, и затем выберите ‘Разрешить удаленное управление сервером через WinRM’*

* В Windows Server 2008 может быть написано ‘разрешить автоматическую настройку слушателей’

включите его/разрешите его.
введите * в IP фильтр, чтобы слушать на всех IP

введите описание изображения здесь

выполните gpupdate

перезапустите WinRM

WinRM полагается на WS-Man, который может связываться с портом 80, так как это протокол на основе SOAP. Если это происходит, WinRM может быть сброшен к настройкам по умолчанию:

  1. winrm d winrm/config/listener?address=*+transport=http

  2. netsh http del iplisten ipaddress=127.0.0.1

  3. rm -v wsman:\localhost\listener\listener*\ -fo -r

  4. winrm invoke restore winrm/config

    5. set-pssessionconfiguration Microsoft.powershell -SecurityDescriptorSddl "O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)"

    6. restart-service winrm

    7. winrm qc -q

Недостаточно просто удалить и заново добавить слушателя. Разрешения NT Authority\Network Service и Remote Management Users должны быть правильно настроены, чтобы привязать слушающий порт к маршруту по умолчанию 0.0.0.0 вместо обратной петли 127.0.0.1. После сброса WinRM правильные настройки могут быть проверены несколькими способами.*

Netstat может подтвердить, что порт WinRM был правильно настроен:

PS C:\> netstat -ano|sls 5985
        TCP    0.0.0.0:5985           0.0.0.0:0              LISTENING       4
        TCP    [::]:5985              [::]:0                 LISTENING       4

Поставщик WS-Man может подтвердить, что порт WinRM был правильно настроен:

PS C:\> ls wsman:\localhost\listener\listener_GUID\
Type            Name                           SourceOfValue   Value
----            ----                           -------------   -----
System.String   Address                                        *
System.String   Transport                                      HTTP
System.String   Port                                           5985

Netsh также должен быть пуст:

PS C:\> netsh http show iplisten
IP addresses present in the IP listen list:
-------------------------------------------

Надеюсь, это сэкономит кому-то 12+ часов, которые я потратил, чтобы все это понять!

.

Ответ или решение

Когда возникает проблема доступа к службе Windows Remote Management (WinRM), несмотря на ее работающий статус, это может стать значительной задачей для ИТ-специалиста. Виртуальная тестовая среда, в которой разворачиваются PowerShell Runspaces, должны быть безупречно настроены для правильного выполнения задач удаленного администрирования, особенно в случае, если функциональность .NET Framework ограничена и требует использования возможностей PowerShell.

Теория

WinRM — это служба, которая обеспечивает связь через Windows Remote Management. Она использует протоколы SOAP и WS-Management для обмена данными по сети. Основные порты, используемые WinRM, это 5985 для HTTP и 5986 для HTTPS. Неполадки с доступностью WinRM обычно связаны с конфигурацией слушателей, сетевыми ограничениями или неправильно настроенными группами безопасности и политиками.

Пример

В описанной ситуации, несмотря на то, что все базовые настройки конфигурации выполнены (например, предварительное выполнение winrm quickconfig, успешное тестирование с помощью Test-wsman на локальном сервере и деактивация фаервола), возникли сложности с доступом к WinRM на определённом сервере — FileShare-Memberserver.

Более того, можно было подключиться к серверу через Remote Desktop Connection и получить доступ к Exchange Shell на том же сервере. Это указывает на то, что проблема скорее всего связана не с сетевой доступностью или TCP/IP соединением, а с конфигурацией слушателей или политиками безопасности, применёнными на сервере.

Применение

Шаги для диагностики и решения проблемы:

  1. Проверка и настройка локальной групповой политики:

    • Откройте редактор локальной групповой политики (gpedit.msc).
    • Перейдите в Компьютерная конфигурация -> Административные шаблоны -> Компоненты Windows -> Windows Remote Management.
    • Убедитесь, что разрешено удаленное управление сервером через WinRM и добавьте * в IP-фильтр, чтобы слушать на все IP.
  2. Перезапуск службы WinRM:

    • После внесения изменений выполните gpupdate для обновления политик.
    • Перезапустите сервис WinRM для применения изменений.
  3. Ручная настройка слушателей:

    • Удалите существующие слушатели через winrm d winrm/config/listener?address=*+transport=http.
    • Перезапустите службу через restart-service winrm.
    • Настройка новых слушателей с winrm qc -q.
  4. Неправильное исплользование привилегий:

    • Проверьте, было ли задействовано отсутствие или неправильная настройка привилегий для NT Authority\Network Service & Remote Management Users.
    • Используйте команду set-pssessionconfiguration для корректной конфигурации прав доступа через SDDL.
  5. Проверка корректности сетевых настроек:

    • Используйте netstat -ano | Select-String "5985" для проверки, что WinRM слушает на правильном порту (0.0.0.0:5985).
    • Убедитесь, что список IP-слушания пуст через netsh http show iplisten, если он не требуется для конкретного конфигурационного запроса.

Заключение

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

Этот опыт подчеркивает важность понимания работы сетевых протоколов и сервисов Windows в сложных ИТ-средах. Способность находить и устранять причины проблем является ключевой компетенцией для IT-специалистов, так как многие бизнес-процессы зависят от надежности и устойчивости этих соединений.

Оцените материал
Добавить комментарий

Капча загружается...