Web Publishing Quits Working or Not Working as Expected on ISA/TMG Server

 

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.

Symptom:

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.

Fig. 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).

Fig. 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).

Fig. 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.

Fig. 4

Fig. 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.

Solution:

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.

Conclusion:

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.

Comments

• Anonymous
  January 01, 2003
  thanks for sharing.

• Anonymous
  January 20, 2012
  Thanks a lot ! It helped me. Best Regards Conrad

• Anonymous
  January 20, 2012
  For info, in my case, it was just IIS default web site binded to 80 ! As there was installed on the same machien : TMG Forfornt for Exchange Exchange EDGE SQL 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 Regards Conrad

• Anonymous
  January 09, 2013
  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. Solution 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.

• Anonymous
  April 03, 2014
  THANK YOU!!!
  Owe you a beer

• Anonymous
  May 27, 2014
  "netsh http show servicestate"
  
  Search site on port 80
  
  HTTP://+: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

• Anonymous
  September 16, 2014
  Thank you, man! You're genius!

• Anonymous
  December 04, 2014
  A Million Thanks !!

• Anonymous
  May 17, 2017
  Much appreciated- thanks!