WinRM Has Connection Issues When Using a Custom HTTP.sys Inclusion List


Solutions

If you've ever set your Internet Information Services (IIS) to only bind or listen on certain IP addresses using the httpcfg set iplisten command (e.g., to have Apache & IIS running on the same server), you may have inadvertently caused an issue for yourself if you want to use Windows Remote Managment (WinRM) from the command line or using PowerShell. A good idea of whether or not you have an issue is if running commands using WinRM (e.g., "winrm quickconfig") fail with the following error:

 

Message = The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests.

Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service,

run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".

Error number:  -2144108526 0x80338012
The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests.

Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service,

run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".

 

To get WinRM to start working again, continue on reading...

Note that httpcfg is for IIS 6 in Windows Server 2003. Newer versions of IIS (7+) use the NETSH command, but the fundamentals are still the same.

You can tell if you've ever set IIS to only listen on certain IPs by using the httpcfg query iplisten command. If you've never set any IPs, it will return a code of "1168" and if you have used the command it will return a list of IPs you are allowing into IIS. Another good test is to use the netstat -an | more command to see what ports are being listened on. If you see ports such as 80, 443, 5985 (WinRM), & 47001 (also WinRM) being listened on specific IPs, you've probably set this config. If those ports are being listened on an IP address of 0.0.0.0 that means these ports are bound to all available IPs and you did not set this config.

 

The solution is simple. Add the loopback address of 127.0.0.1 to this list of allowed IPs in IIS.

  1. Open a command prompt window as an administrator.
  2. Type the command httpcfg set iplisten -i 127.0.0.1 to add the loopback address.
    •  If you've run this command before to cause the issue this article addresses, you should already have httpcfg installed.
  3. Restart the Windows server.
    • Alternatively, you can try stopping the http services using the net stop http /y command and then starting Windows Remote Management and the w3svc services manually, but I've had issues with these settings not taking effect until after a full reboot.
  4. From the command prompt, run netstat -an | more and verify that ports 80, 443, 5985, & 47001 are being listened to on the IP address of 127.0.0.1.
  5. Try running a WinRM command such as winrm quickconfig and hopefully it goes through properly.

Please note that this article is to assist others running into this specific issue with WinRM and the HTTP.sys IP Inclusion List and is not for troubleshooting other general WinRM issues.

Be careful when running the httpcfg set iplisten command because as soon as you do and restart Web services, your sites in IIS will only listen on the IPs added to the inclusion list. To listen to all available IPs again, you need to remove any added IPs (use the httpcfg query iplisten command to see what IPs IIS is being restricted to) by typing httpcfg delete iplisten -i xxx.xxx.xxx.xxx. You should then restart the appropriate services --- or the entire server if you continue to have issues.

Tag: microsoft microsoft internet information services iis windows remote management winrm powershell

Share It!

Thank you for this - I've spent so many hours trying figure this one out. Early on I had tried telnet'ing to 5985 and 47001 from my client machine and it worked fine; it wasn't until I tried it locally on the server to localhost and confirming in netstat that we could fix it. Damn, what a pain in the ass this was. Microsoft needs to update their support documentation to make the 127.0.0.1 requirement more explicit.

Thanks again!

-Dan Ward
Glad I could help. I was in a similar boat, spending hours trying to figure this one out. I had finally nailed it down to probably being the IP inclusion list and added the loopback address as a shot in the dark (though still one that had been aimed logically)!
One billion thanks !!! You are rock!!!
You saved the day, thank you
Thanks - this was exactly what I was looking for!
Thank you. Thank you, thank you, thank you; thank you.

I was really scratching my head on this one as installing features via PowerShell seemed to work, but the Server Manager GUI just sat there forever.

Thank you for taking the time to post this solution to your blog.
On Windows systems newer than Win2003 or XP use the command below.
netsh http show iplisten
netsh http add iplisten ipaddress=127.0.0.1