O serviço WinRM está sendo executado, mas não responderá

Question

Eu tenho um ambiente com 16 vms em um host. Todos eles executam o Windows2008R2. Em um ponto eu tive o trabalho remoto de powershell em todos os servidores, exceto um. Então perdi contato com mais dois. Isso é chato, para dizer o mínimo. Toda vez que eu volto ao fato de que o WinRM está sendo executado como um serviço, mas ainda não funciona.

É configurado para usar ssl. Invoke-Command -ComputerName "BadMachine" -ScriptBlock {Get-Service | Where-Object {($_.Name -eq "WinRM") -and ($_.Status -eq "Running")}} -ErrorAction Stop -UseSSL -Credential(Get-Credential) resulta no bem conhecido

[BadMachine] Connecting to remote server BadMachine failed with the
following error message : WinRM cannot complete the operation. Verify...
etc.,etc.,etc.

Na máquina defeituosa, o 'winrm quickconfig' diz que o serviço WinRM já está em execução e mostra o erro acima.

Na máquina ruim, Get-Service "WinRM" retorna um objeto legal dizendo que o serviço está sendo executado.

Na máquina defeituosa winrm id não retorna nada (em boas máquinas dá uma IdentifyResponse completa).

winrm get wmicimv2/Win32_Service?Name=WinRM apresenta o erro acima (em uma boa máquina ele retorna o status).

cd wsman: me permite alternar para o provedor wsman e há localhost. Mas depois de navegar para o localhost, não há nada lá. Então, cd WSMan:\localhost\Listener resulta em Cannot find path .

netsh http show urlacl não resulta em nada (em uma boa máquina ele retorna reservas de URL.)

A maioria dos artigos descreve como configurar o remoting do PowerShell e pode discutir como solucionar algumas partes. Mas, aparentemente, há tanta coisa que pode dar errado sobre WinRM e PowerShell Remoting, que minhas perguntas são:

Como reparar esta instalação do WinRM? O fato de serem VMs em um host do Hyper-V complica as coisas? O que ainda resta testar para chegar ao cerne do problema?

    

Answer 1

Um artigo sobre a arquitetura WinRM levou-me a investigar o Http.sys. Como o IIS está funcionando normalmente, eu não suspeitaria do HTTP.sys. O comando netsh http show urlacl mostrou que não havia URLs reservadas.

link me ajudou a comparar o registro de a má máquina com uma boa máquina. Os valores de registro para HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ HTTP \ Parameters \ UrlAclInfo não existiam na máquina defeituosa. Além disso, os valores para HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ HTTP \ Parameters \ SslBindingInfo \ 0.0.0.0: 5986 (ligação para winrm) não existiam. Eu não tenho idéia do que causou isso.

Como todos os servidores no meu ambiente parecem os mesmos, eu exportei as chaves acima e importei as chaves no registro da máquina defeituosa. Eu acho que isso só é possível se as duas máquinas são semelhantes o suficiente. Mas resolveu o problema para mim. Depois de executar Enable-PSRemoting , agora posso acessar todas as minhas máquinas no ambiente.

Com a experimentação, descobri que SslBindingInfo ( netsh http show sslcert ) deve mostrar uma ligação para as portas 5986 (winrm, o certificado que você deseja usar para -UseSSL). O acl deve conter reservas para as portas 5357 & 5358 (http & https para descoberta de rede?), 47001 (http, wsman), 5985 & 5986 (http & https para winrm).