I cannot even begin to tell you how many calls are generated by an all too common mistake that I will discuss today. I have been seeing it for years and continue to see it so I thought I would post a quick blog about it. It is one of the first things I look at when someone tells me their web publishing rules are not working as they should or have stopped working suddenly.
Any or all Web Publishing rules (including OWA and Sharepoint) do not behave as expected or are not functioning. Monitoring shows that the traffic is being denied by the Default rule. These could be web publishing rules that are newly created or may have been working correctly for some time but are now suddenly not working (usually after a recent reboot).
Cause: IIS (World Wide Web Publishing Service) or some other program that uses commonly used web publishing ports (80 and 443) is running on the same machine as ISA/TMG.
Diagnosing the issue: One of the first places you want to look is at the Alerts tab. The Alerts tab in under the Monitoring branch in the ISA/TMG MMC.
You may see an Alert that says “Resource Allocation Conflict” The description will be something worded as below.
Description: The Web Proxy filter failed to bind its socket to 10.1.1.250 port 80. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.
The failure is due to error: An attempt was made to access a socket in a way forbidden by its access permissions.
In your MMC you will see something similar to Figure 1.
Also, if you use the Live Logging feature in ISA/TMG and you see the traffic being denied by the Default rule when you expect it to be picked up by the Web Publishing rule, this may be a strong indicator that something else is binding to that port (See Figure 2).
Running a netstat at a command prompt will tell us which Process ID is using those ports.
You can run
Netstat –ano |findstr :80
Netstat –ano |findstr :443
The output will look something like below (Figure 3).
As we can see in Figure 3, the process ID that is listening on port 80 is 4. To figure out what that process ID corresponds to, open your task manager. You will need to go to View and then add PID (Process Identifier) as a column. It does not show up by default. See Figures 4 and 5.
As you can see in Figure 5, Process ID 4 is being used by the System. If the Web Listener on ISA/TMG was properly binding to this port we would expect a process called wpsrv.exe to be using it.
Fortunately, this is usually a very easy fix. First, pull up your Services.msc on the ISA/TMG server and verify that the World Wide Web Publishing Service is indeed running. If it is, stop it, then set it to either Manual or Disabled. At a later time you may just want to uninstall it from that machine.
After you have stopped the World Wide Web Publishing Service you will need to restart the Firewall Service on your ISA Server or your Forefront TMG Server.
On ISA Server it is listed as “Microsoft Firewall” in your Services MMC. On Forefront TMG it is listed as “Microsoft Forefront TMG Firewall”
By stopping IIS and then restarting the Firewall service this will allow the Web Listener to bind to the appropriate port.
I hope that this article helps you and hopefully prevents the need to open a support incident. Remember, if you don’t absolutely need IIS on the machine, it should not be on an ISA Server or a TMG Server. In my experience, it only causes issues such as this.
Thanks a lot ! It helped me.
For info, in my case, it was just IIS default web site binded to 80 !
As there was installed on the same machien :
Forfornt for Exchange
One of these did install some IIS requirements, creating a default web site.
-> install IIS console (not already done)
-> change default Web site port
-> All's OK
With all services runing
When trying to publish HTTP websites (on port 80), the published websites aren't working. Published HTTPS websites (on port 443) are working normally.
The following error message is written to the eventlog:
The Web Proxy filter failed to bind its socket to A.B.C.D port 80. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.
A.B.C.D is the TMG's external IP address.
When trying to disable rules for this IP the following message is written to the eventlog:
"A problem preventing the Web Proxy filter from binding its sockets was resolved"
When checking the listeners with netstat -ano, you see PID 4 is listening on port 80 on all the IPs. PID 4 is a system process.
The problem is caused because the http service is listening to port 80 on all IPs.
Opening "Command Prompt" and running the following command:
netsh http add iplisten ipaddress=127.0.0.1
and restarting the TMG services (or rebooting the server) solves the problem.
THANK YOU!!!Owe you a beer
"netsh http show servicestate"
Search site on port 80
In my way this is msdepsvc .....
Stop this service "net stop msdepsvc"
And disable start : Server manager/Services/Web Deployment Agent Service/Startup type - Disabled
Thank you, man! You're genius!
thanks for sharing.
A Million Thanks !!