Remote PowerShell, WinRM Falhas: o WinRM não pode concluir a operação

5

Ao executar Enter-PSSession COMPUTERNAME com Enable-PSWSManCombinedTrace , vejo as seguintes mensagens relevantes no log operacional do Gerenciamento Remoto do Windows:

WSMan operation Get failed, error code 2150859046

WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet.

The WinRM protocol operation failed due to the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. .

E às vezes:

The client got a timeout from the network layer (ERROR_WINHTTP_TIMEOUT)

COMPUTERNAME é um servidor Core 2012 R2 no domínio, sob as mesmas diretivas de grupo de muitos outros servidores para os quais o Remote PowerShell, o Gerenciador de Servidores, et al estão funcionando bem. Eu posso RDP para este sistema, eu posso obter dados WMI dele (por exemplo, Get-WmiObject -ComputerName COMPUTERNAME -Class Win32_OperatingSystem retorna o que deveria), e em todos os outros aspectos, parece estar funcionando bem.

Embora já tenha sido definida pela Diretiva de Grupo, tentei (várias vezes de uma forma) ativar o WinRM e o Remote PowerShell, como Enable-PSRemoting , ou invocar as etapas do atendente que esse comando executa individualmente.

Eu mudei para uma interface de rede diferente, assegurei que outros sistemas no mesmo segmento de rede não apresentam esses sintomas, segui o conselho de Get-Help about_Remote_Troubleshooting e sacrifiquei a cabra necessária para Baal. Nada ajuda.

Estes sintomas são reproduzíveis de qualquer cliente de domínio para este servidor, ou se você contatar o servidor por IP (depois de colocá-lo em TrustedHosts). Nenhum outro servidor apresenta esse problema. Não há software ou configuração (até as regras do FW ativadas e recursos instalados) que não estão em pelo menos dois outros servidores no meu ambiente.

Alguma idéia?

ACHADOS MAIS RECENTES:

netsh http show iplist retorna 127.0.0.1 no sistema não funcional, mas não retorna nada nos sistemas de trabalho.

Como @ out-null corretamente apontado nos comentários, o fato de 5985 estar escutando em 127.0.0.1 é um problema. Desde então, excluí esse sistema do GPO que configura nossas configurações do WinRM e criei manualmente o listener:

winrm create winrm/config/Listener?Address=*+Transport=HTTP

No entanto, o resultado no netstat é o mesmo. Observe a saída de winrm e abaixo, em que o IP está listado como ouvinte.

Ainda perplexo com este aqui ...

Evidências originais / verificações de sanidade

$> 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
    
por Tohuw 10.02.2015 / 23:21

1 resposta

1

Finalmente resolvi isso, ajudado pelas evidências que eu adicionei recentemente à pergunta:

netsh http show iplist

IP addresses present in the IP listen list:
-------------------------------------------

127.0.0.1

Nos sistemas em que isso estava funcionando, essa lista estava vazia. Isso pareceu bastante contra-intuitivo para mim a princípio. No entanto, eu dei um presente:

> netsh http delete iplisten ipaddress=127.0.0.1

Imediatamente depois, percebo essa saída de 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

E, de fato, o WinRM funciona como deveria.

Suponho, por meio de testes, que, se nenhum ouvinte HTTP estiver configurado, todos os ouvintes HTTP se ligarão à entidade padrão: 0.0.0.0 . Como um endereço de loopback foi configurado como um endereço de ouvinte, o ouvinte foi vinculado a esse endereço.

Em algum momento, devo ter tomado algumas medidas que causaram essa configuração, embora não tenha certeza de como. De qualquer forma, está funcionando bem agora. Obrigado a todos.

    
por 17.02.2015 / 20:25