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.