При беге Enter-PSSession COMPUTERNAME с участием Enable-PSWSManCombinedTrace, В журнале операций удаленного управления Windows я вижу следующие соответствующие сообщения:
Ошибка операции WSMan Get, код ошибки 2150859046
WinRM не может завершить операцию. Убедитесь, что указанное имя компьютера допустимо, что компьютер доступен по сети и что исключение брандмауэра для службы WinRM включено и разрешает доступ с этого компьютера. По умолчанию исключение брандмауэра WinRM для общедоступных профилей ограничивает доступ к удаленным компьютерам в той же локальной подсети.
Операция протокола WinRM завершилась неудачно из-за следующей ошибки: не удалось получить метаданные с сервера из-за следующей ошибки: WinRM не может завершить операцию. Убедитесь, что указанное имя компьютера допустимо, что компьютер доступен по сети и что исключение брандмауэра для службы WinRM включено и разрешает доступ с этого компьютера. По умолчанию исключение брандмауэра WinRM для общедоступных профилей ограничивает доступ к удаленным компьютерам в той же локальной подсети. .
И иногда:
Клиент получил тайм-аут от сетевого уровня (ERROR_WINHTTP_TIMEOUT)
COMPUTERNAME является основным сервером 2012 R2 в домене с той же групповой политикой, что и многие другие серверы, для которых Remote PowerShell, Server Manager, и другие работают нормально. Я могу подключиться к этой системе по протоколу RDP, я могу получить от нее данные WMI (например, Get-WmiObject -ComputerName COMPUTERNAME -Class Win32_OperatingSystem возвращает то, что должно), и во всех остальных случаях кажется, что все работает нормально.
Хотя он уже настроен с помощью групповой политики, я пытался (много раз разными способами) включить WinRM и Remote PowerShell, например Enable-PSRemoting, или вызывая сопутствующие шаги, эта команда выполняется индивидуально.
Я перешел на другой сетевой интерфейс, я убедился, что другие системы в том же сегменте сети не проявляют этих симптомов, я последовал совету Get-Help about_Remote_Troubleshootingи я принес в жертву Ваалу нужного козла. Ничего не помогает.
Эти симптомы воспроизводятся с любого клиента домена на этот сервер или если вы связываетесь с сервером по IP (после помещения его в TrustedHosts). Никакой другой сервер не демонстрирует эту проблему. Нет никакого программного обеспечения или конфигурации (вплоть до включенных правил FW и установленных функций), которых нет как минимум на 2 других серверах в моей среде.
Любые идеи?
НАИБОЛЕЕ ПОСЛЕДНИЕ РЕЗУЛЬТАТЫ:
netsh http show iplist возвращается 127.0.0.1 в нерабочей системе, но ничего не возвращает в рабочих системах.
Как правильно указал @ out-null в комментариях, тот факт, что 5985 слушает 127.0.0.1, является проблемой. С тех пор я исключил эту систему из GPO, настроив наши настройки WinRM, и вручную создал слушателя:
winrm create winrm/config/Listener?Address=*+Transport=HTTP
Однако результат в netstat такой же. Обратите внимание на вывод winrm e ниже, где IP указан как слушатель.
Все еще в тупике на этом ...
Оригиналы доказательств / проверки на вменяемость
$> winrm e winrm/config/listener
Listener [Source="GPO"]
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.11.10.117, 127.0.0.1, 169.254.34.30, 169.254.47.200, 169.254.236.165, ::1, fe80::5efe:10.115.63.10 7%16, fe80::5efe:169.254.34.30%45, fe80::28b8:be74:53c:2fc8%12, fe80::69a9:e404:12bd:63c0%15, fe80::7cf2:ec84:332f:221e%14, fe80::cdc6:5ca0:6ae2:eca5%13
$> netsh winhttp show proxy
Current WinHTTP proxy settings:
Direct access (no proxy server).
$> Get-NetFirewallRule WINRM-HTTP-In-TCP | fl *
Name : WINRM-HTTP-In-TCP
ID : WINRM-HTTP-In-TCP
Group : @FirewallAPI.dll,-30267
Platform : {}
LSM : False
DisplayName : Windows Remote Management (HTTP-In)
Enabled : True
Profile : Domain, Private
Direction : Inbound
Action : Allow
EdgeTraversalPolicy : Block
PrimaryStatus : OK
Status : The rule was parsed successfully from the store. (65536)
EnforcementStatus : NotApplicable
PolicyStoreSourceType : Local
Caption :
Description : Inbound rule for Windows Remote Management via WS-Management. [TCP 5985]
ElementName : @FirewallAPI.dll,-30253
InstanceID : WINRM-HTTP-In-TCP
CommonName :
PolicyKeywords :
PolicyDecisionStrategy : 2
PolicyRoles :
ConditionListType : 3
CreationClassName : MSFT|FW|FirewallRule|WINRM-HTTP-In-TCP
ExecutionStrategy : 2
Mandatory :
PolicyRuleName :
Priority :
RuleUsage :
SequencedActions : 3
SystemCreationClassName :
SystemName :
DisplayGroup : Windows Remote Management
LocalOnlyMapping : False
LooseSourceMapping : False
Owner :
Platforms : {}
PolicyStoreSource : PersistentStore
Profiles : 3
RuleGroup : @FirewallAPI.dll,-30267
StatusCode : 65536
PSComputerName :
CimClass : root/standardcimv2:MSFT_NetFirewallRule
CimInstanceProperties : {Caption, Description, ElementName, InstanceID...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties
COMPUTERNAME$> netstat -anp tcp
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49155 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49174 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49178 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49191 0.0.0.0:0 LISTENING
TCP 10.11.10.117:135 192.168.5.71:64570 ESTABLISHED
TCP 10.11.10.117:135 192.168.5.71:64571 ESTABLISHED
TCP 10.11.10.117:135 192.168.5.71:64572 ESTABLISHED
TCP 10.11.10.117:139 0.0.0.0:0 LISTENING
TCP 10.11.10.117:3389 10.1.1.2:57970 ESTABLISHED
TCP 10.11.10.117:49153 10.1.1.2:58100 ESTABLISHED
TCP 10.11.10.117:50601 192.168.5.111:8014 ESTABLISHED
TCP 10.11.10.117:56508 192.168.5.177:445 ESTABLISHED
TCP 127.0.0.1:5985 0.0.0.0:0 LISTENING
TCP 127.0.0.1:47001 0.0.0.0:0 LISTENING
TCP 169.254.34.30:139 0.0.0.0:0 LISTENING
SOME-WORKING-COMPUTER$> netstat -anp tcp
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49155 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49158 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49187 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49192 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49199 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49213 0.0.0.0:0 LISTENING
TCP 192.168.5.11:139 0.0.0.0:0 LISTENING
TCP 192.168.5.11:5985 10.1.1.2:58153 ESTABLISHED
TCP 192.168.5.11:5985 10.1.1.2:58154 ESTABLISHED
TCP 192.168.5.11:5985 10.1.1.2:58156 ESTABLISHED
TCP 192.168.5.11:49203 192.168.5.177:49210 ESTABLISHED
TCP 192.168.5.11:49213 192.168.5.177:52784 ESTABLISHED
TCP 192.168.5.11:49213 192.168.5.177:54507 ESTABLISHED
TCP 192.168.5.11:49213 192.168.5.177:59034 ESTABLISHED
TCP 192.168.5.11:52905 192.168.5.177:49210 TIME_WAIT
TCP 192.168.5.11:52906 192.168.5.177:49210 TIME_WAIT
TCP 192.168.5.11:52907 192.168.5.111:8014 ESTABLISHED
TCP 192.168.5.11:52910 192.168.5.177:49210 TIME_WAIT
TCP 192.168.5.11:52915 192.168.5.177:49210 TIME_WAIT
TCP 192.168.5.11:52918 192.168.5.177:49210 TIME_WAIT
TCP 192.168.5.11:52920 192.168.5.177:49210 TIME_WAIT
TCP 192.168.5.11:52922 192.168.5.177:49210 ESTABLISHED
TCP 192.168.5.11:52923 192.168.5.177:49210 ESTABLISHED
TCP 192.168.5.11:52924 192.168.5.177:49210 ESTABLISHED
TCP 192.168.5.11:52925 192.168.5.177:49210 ESTABLISHED
TCP 192.168.5.11:52926 192.168.5.177:49210 ESTABLISHED
TCP 192.168.5.11:52927 192.168.5.177:49210 ESTABLISHED
TCP 192.168.5.11:54938 192.168.6.8:49157 ESTABLISHED
TCP 192.168.5.11:62632 192.168.5.177:49210 ESTABLISHED
TCP 192.168.5.11:64307 192.168.6.8:389 ESTABLISHED
Наконец, решил эту проблему, чему способствовали доказательства, которые я недавно добавил к вопросу:
netsh http шоу iplist
IP addresses present in the IP listen list:
-------------------------------------------
127.0.0.1
В системах, где это работало, этот список был пуст. Поначалу это показалось мне довольно противоречивым. Тем не менее, я попробовал:
> netsh http delete iplisten ipaddress=127.0.0.1
Сразу после этого я заметил этот вывод из netstat:
>netstat -anp tcp
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49155 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49175 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49179 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49190 0.0.0.0:0 LISTENING
TCP 10.115.63.107:139 0.0.0.0:0 LISTENING
TCP 10.115.63.107:3389 10.115.13.25:64873 ESTABLISHED
TCP 10.115.63.107:49235 192.168.40.146:445 ESTABLISHED
TCP 10.115.63.107:49291 192.168.40.45:8014 ESTABLISHED
TCP 169.254.34.30:139 0.0.0.0:0 LISTENING
И действительно, WinRM работает как надо.
По результатам тестирования я предполагаю, что, если прослушиватель HTTP не настроен, все прослушиватели HTTP будут привязаны к объекту по умолчанию: 0.0.0.0. Поскольку адрес обратной связи был настроен как адрес слушателя, слушатель вместо этого привязывался к этому адресу.
В какой-то момент я, должно быть, предпринял какое-то действие, которое вызвало эту конфигурацию, хотя я не уверен, как это сделать. Во всяком случае, сейчас все работает нормально. Спасибо всем.