Consider the scenario where a TMG 2010 Server is installed as Hyper-V guest on a Windows 2008 Server. You publish a website on port 80 or enable HTTP to HTTPS redirection on a Web Listener for an existing SSL publishing rule. When you try to access the published website you get an error: 10060 Connection Refused.

A quick look at the TMG Live Logging reveals the following:


Netstat output indicates that Process ID 4 (System) is listening on port TCP 80 as shown below:


This explains why Firewall Service was not able to bind itself to TCP port 80.In scenarios where IIS is installed on the same machine as the ISA/TMG Servers and IIS binds itself to port 80, it is common to such output. As part of the troubleshooting for issues of this nature, we checked and found that IIS was not installed on the TMG Server. We then used Process Explorer to check if any other process which hooks into System process was causing this behaviour and found that it was not the case.

We then used the netsh command line interface to check the state of HTTP Service with the following command:


Based on the above output, we can see that WSMAN is listening on port 80. WSMAN (Web Services-Management) is an open standard for SOAP based protocol management of servers, application and web services. WinRM (Windows Remote Management) is Microsoft’s implementation of WS-Management standard.

In this particular case the Windows Remote Management service was grabbing port 80 on the TMG guest machine which is why the Web Proxy service was not able to bind itself to port 80 and therefore, requests from external clients were failing. Disabling the Windows Remote Management service or changing the WinRM listener to listen on a port other than 80 resolved this issue.

This post explains a scenario where a service other than IIS grabs web ports used by TMG causing publishing rules to fail. In case connection to a particular port on TMG is failing, always check if TMG is listening on that port.