I have an environment with 16 vms on a host. They all run Windows2008R2. At one point I had powershell remoting work on all servers but one. Then I lost contact with two more. This is annoying, to say the least. Every time I come back to the fact that WinRM is running as a service, but it still doesn't work.

It is setup to use ssl. Invoke-Command -ComputerName "BadMachine" -ScriptBlock {Get-Service | Where-Object {($_.Name -eq "WinRM") -and ($_.Status -eq "Running")}} -ErrorAction Stop -UseSSL -Credential(Get-Credential) results in the well known

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

On the bad machine, 'winrm quickconfig` says that the WinRM service is already running and then shows the above error.

On the bad machine, Get-Service "WinRM" returns a nice object saying the service is running.

On the bad machine winrm id doesn't return anything (on good machines it gives a full IdentifyResponse).

winrm get wmicimv2/Win32_Service?Name=WinRM gives the above error (on a good machine it returns the status).

cd wsman: allows me to switch to the wsman provider, and there is localhost. But after navigating to localhost, there is nothing in there. So, cd WSMan:\localhost\Listener results in a Cannot find path.

netsh http show urlacl does not result in anything (on a good machine it returns URL reservations.)

Most articles describe how to setup the powershell remoting and may discuss how to troubleshoot some parts. But, apparently there is so much that can go wrong about winrm and powershell remoting, that my questions are:

How to repair this WinRM installation? Does the fact that they are VMs on a Hyper-V host complicate things? What is still left to test to get to the heart of the problem?

  • What is the version of %systemroot%\system32\WsmSvc.dll?
    – Greg Askew
    Feb 16, 2017 at 21:28
  • @Greg Askew - [System.Diagnostics.FileVersionInfo]::GetVersionInfo("c:\windows\system32\WsmSvc.dll").FileVersion results in: 6.3.9600.16406 (winblue_gdr_oob.130926-1103)
    – Albert
    Feb 17, 2017 at 20:46
  • @Albert if you edit from the same account that created the question you don't have to wait for your edits to be approved.
    – chicks
    Feb 17, 2017 at 21:15
  • 1
    @chick I asked this question just before I had to go to a meeting. I registered for this site only after the meeting. I think that messed it up a bit.
    – Albert
    Feb 17, 2017 at 21:54

1 Answer 1


An article on the WinRM architecture led me to investigate Http.sys. Since IIS is running normally, I wouldn't have suspected Http.sys. The command netsh http show urlacl showed there were no reserved urls.

https://support.microsoft.com/en-us/help/820129/http.sys-registry-settings-for-windows helped me compare the registry of the bad machine with a good machine. The registry values for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\UrlAclInfo did not exist on the bad machine. Also the values for HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\SslBindingInfo\ (binding for winrm) did not exist. I don't have a clue what caused this.

Since all servers in my environment look rather the same, I exported the above keys and imported the keys in the registry of the bad machine. I guess this is only possible if the two machines are similar enough. But, it solved the problem for me. After running Enable-PSRemoting I can now reach all my machines in the environment.

With experimentation, I found that SslBindingInfo (netsh http show sslcert) should show a binding for ports 5986 (winrm, the certificate you want to use for -UseSSL), The acl should contain reservations for ports 5357 & 5358 (http & https for network discovery?), 47001 (http, wsman), 5985 & 5986 (http & https for winrm).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.