(Listen up: This is material not included in our book. So if you have the book, print this out and stick it in the book! -Tom)

Do you sometimes feel that ISA Server was designed to drive you crazy? If so, when were those times? I bet you felt like you were going nuts when you tried to do one of the following things:

• Publish an FTP Server running on the ISA Server itself
• Publish a Web Site running on the ISA Server itself
• Publish a NNTP server running on the ISA Server itself
• Publish a SMTP server running on the ISA Server itself
• Publish an Outlook Web Access site running on the ISA Server itself

Notice something that all of these things have in common? That right! They all have the service in question running on the ISA Server itself. It makes you think they should have called it Server Punishing rather than Publishing.

What is maddening about this situation is that the Help File says that it’s no problem to publish services running on the ISA Server. Just make a couple of changes to the listening IP address for the particular service, then publish the service using that IP address. And away you go! The problem is that it doesn’t work.

The Misery of Socket Pooling

All of these problems are related to a little known issue with IIS 5.0. The current version of IIS uses something called Socket Pooling which, if I understand the issue correctly, putatively improves performance. While it may improve performance, it completely whacks your ability to publish services on the ISA Server itself.

What Socket Pooling does is allow a particular service to listen on all IP addresses on a particular computer. For example, if you have one internal IP address bound to the internal interface and two IP addresses bound to the external interface, then Socket Pooling will allow the service, such as the IIS 5.0 FTP Service, to listen on all three IP addresses.

Let’s take a closer look at this example.

Open the Internet Information Services console from the Administrative Tools menu.

1. Right click on the default FTP site and click Properties.
2. In the Default FTP Site Properties dialog box you will see what appears below. Actually, you won’t see what appears below until you click the down-arrow in the drop-down list box for TCP Port. Note that I have two IP addresses on this particular computer. I will select 192.168.1.186 with the intent of having the FTP service listen on that IP address only. After making the selection, click Apply and then OK.

4. Open a command prompt window. at the command prompt type netstat -na. You’ll see something like what appears below. Notice the top entry that says:

   TCP     0.0.0.0:21        0.0.0.0:0          LISTENING

   What this means is that port 21 is listening on all IP addresses, not just 192.168.1.186. This happens in spite of our configuring the IIS FTP service to use only 192.168.1.186 for the FTP service. This is the “benefit” of socket pooling.
   
   
   
   

What do you think will happen if I have packet filtering enabled and try to publish the FTP service on 192.168.1.186? It won’t work! I could enable a packet filter to allow inbound TCP 21, but then we’re not publishing the server. Is just listening on the interface that is directly connected to the Internet, and if I tried to put the server, the publishing rule would still not work.

Fixing the Socket Pooling Problem

In order to get the IIS W3SVC, FTPSVC and NNTPSVC to play nice with Web and Server Publishing Rules, we have to disable Socket Pooling. To do this, perform the following steps:

1. Open a command prompt and navigate to the \Inetpub\Adminscripts\ folder
2. Type net stop msftpsvc and press [ENTER]
3. Type in the following command:

   cscript adsutil.vbs set msftpsvc/disablesocketpooling true

   
   and then press [ENTER]

4. You should see what appears below.

5. At the command prompt type net start msftpsvc and press [ENTER].
6. Now let’s run netstat -na again. You should see what appears below.

7. Notice that TCP port 21 is now listening on 192.168.1.186 and is no longer listening on 0.0.0.0. No more socket pooling for Port 21! Now you can publish the FTP service on the internal interface (almost, you actually have to make a registry change too).

This same procedure will work for the WWW and NNTP services. Just replace msftpsvc with w3svc or nntpsvc. However, this procedure will not work with the SMTP service.

How to Disable SMTP Service Socket Pooling

To disable Socket Pooling for the SMTP service, you have to use a utility called Mdutil.exe. You can download this utility from the ‘Tools’ section of the ‘Learning Zone‘

1. Put the Mdutil.exe executable in the \Inetpub\Adminscripts folder.
2. Open a command prompt window and type the following command:

mdutil set -path smtpsvc/1 -value 1 -dtype 1 -prop 1029 -attrib 1

3. Go to the Internet Information Services console, right click on the SMTP service, and click Properties. Change the listening address to the internal interface of the ISA Server.

For more information on Socket Pooling and the SMTP service, check out:

http://msdn.microsoft.com/library/psdk/iisref/apro9zon.htm

Conclusion

IIS 5.0 Socket Pooling has caused a great deal pain for budding ISA Server administrators. It would have been nice to have this issue mentioned in the Help File. But then if they did that, I wouldn’t have had a good reason to write this article.

After disabling Socket Pooling using the methods described, you will be able to publish services located on the ISA Server itself. Although it is always preferable to remove all unnecessary services on the ISA Server, sometimes you can’t get around the problem because of financial limitations. In that case, you have to run extra services on the ISA Server.

A special note for you Outlook Web Access admins. This solution will fix the problem you have had with publishing Outlook Web Access when it is located on the ISA Server itself. If you are trying to do this, I highly recommend that you read Martin Grasdal’s article – “OWA and ISA Server” on this subject.

I hope this article was interesting and/or helpful to you. If you have any comments or suggestions related to this article, please post them on the www.isaserver.org message boards. You can also send me email at [email protected]; be sure to put the title of this article in the subject line. Thanks! -Tom.