Вопрос или проблема
У меня есть виртуальная среда тестирования для разработки скриптов. Поскольку .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 может быть сброшен к настройкам по умолчанию:
-
winrm d winrm/config/listener?address=*+transport=http
-
netsh http del iplisten ipaddress=127.0.0.1
-
rm -v wsman:\localhost\listener\listener*\ -fo -r
-
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 соединением, а с конфигурацией слушателей или политиками безопасности, применёнными на сервере.
Применение
Шаги для диагностики и решения проблемы:
-
Проверка и настройка локальной групповой политики:
- Откройте редактор локальной групповой политики (
gpedit.msc
). - Перейдите в
Компьютерная конфигурация
->Административные шаблоны
->Компоненты Windows
->Windows Remote Management
. - Убедитесь, что разрешено удаленное управление сервером через WinRM и добавьте
*
в IP-фильтр, чтобы слушать на все IP.
- Откройте редактор локальной групповой политики (
-
Перезапуск службы WinRM:
- После внесения изменений выполните
gpupdate
для обновления политик. - Перезапустите сервис WinRM для применения изменений.
- После внесения изменений выполните
-
Ручная настройка слушателей:
- Удалите существующие слушатели через
winrm d winrm/config/listener?address=*+transport=http
. - Перезапустите службу через
restart-service winrm
. - Настройка новых слушателей с
winrm qc -q
.
- Удалите существующие слушатели через
-
Неправильное исплользование привилегий:
- Проверьте, было ли задействовано отсутствие или неправильная настройка привилегий для NT Authority\Network Service & Remote Management Users.
- Используйте команду
set-pssessionconfiguration
для корректной конфигурации прав доступа через SDDL.
-
Проверка корректности сетевых настроек:
- Используйте
netstat -ano | Select-String "5985"
для проверки, что WinRM слушает на правильном порту (0.0.0.0:5985). - Убедитесь, что список IP-слушания пуст через
netsh http show iplisten
, если он не требуется для конкретного конфигурационного запроса.
- Используйте
Заключение
Последовательное выполнение вышеописанных шагов, а также проверка изменений, примененных по примерам, в большинстве случаев приведут к успешной настройке доступа к WinRM.
Этот опыт подчеркивает важность понимания работы сетевых протоколов и сервисов Windows в сложных ИТ-средах. Способность находить и устранять причины проблем является ключевой компетенцией для IT-специалистов, так как многие бизнес-процессы зависят от надежности и устойчивости этих соединений.