The Anti-Epic Tale of Making IIS Play Nice with Apache

The Mission

To run an Apache server (on Windows) on the same machine that was already hosting IIS.

The Strategy

The plan was to alter each virtual host defined in IIS to not bind to the typical HTTP/HTTPS ports (80 & 443), but instead have it use arbitrary ports (was to be 8080 & 4433). With that in place, I could then run Apache normally. In order to get traffic to hit the right sites as hosted by IIS, the apache server would have it’s own virtual host definitions for each IIS site. In those definitions, there would be a Reverse Proxy config to get Apache to pass the traffic internally over to the arbitrary ports.

False Sense of Security

Just to be on the safe side, I setup a Windows 2003 Server Virtual Machine to simulate the windows environment I was dealing with. I then installed Apache (via WAMP Server), configured IIS and tested. Everything worked according to plan. After some other minor testing I decided I was ready to make the actual switch.

It hit the fan

So, I RDPed in to the Windows Webserver and installed Apache, of course, at first there was a conflict in ports as the IIS service was already bound to 80/443 that Apache was after. I turned off IIS, let Apache take the ports and reconfigured IIS to use the arbitrary ports I had specified. When I tried to restart IIS it complained about it’s ports being used. I checked and re-checked the config to find that there was no reference to the old ports (now used by Apache). Nevertheless, IIS insisted on using those ports.

I then decided that since someone awhile ago had setup several IPs for the same one network interface on the machine, that I could just as easily get IIS to use one IP and Apache on the other. I’d just get my Apache Reverse Proxy to connect to the other IP rather than obsecure ports. To make that work, I’d have to edit the hosts file to make sure the machine resolved the hostnames to the IP I wanted. I didn’t like the increased complexity, but it didn’t matter…. I found that IIS was still complaining when I told it to only use one specific IP (that wasn’t touched by Apache). WTF.

After some digging, I found this very helpful article that relieved that Microsoft seems to have a cruel sense of humor when it comes to interfaces. It would seem that inspite of the GUI for IIS showing that the virtual hosts on the machine are configured to use whatever ports & IPs I had picked, the IIS service was still trying to grab ports 80/443 on ALL NICs on the machine when it started.

Me:	Microsoft, why would you bother making a UI like that?
Imaginary Microsoft Response:	We develop software that “works” as fast/cheap as possible. And if you try to USE it in some regard that we don’t get hounded to patch until it works, then you’re SOL. Not that we care, the harder it is for you to migrate away from our shit products, the longer you’ll pay us to use them.

The Resolution

The jist of that article is that in order to actually configure IIS to bind ONLY to a given list of IPs, you need to manually declare what those IPs are through a command line utility called httpcfg.exe. I found this wonderful little application included with this package.

To get things working properly I learned first that shutting down the IIS service and reconfiguring it at the command line with the GUI for IIS still open will lead you down a road of pain.

After that all I had to do was add the right IPs that I wanted IIS to use, and run that little line:
cscript adsutil.vbs set /smtpsvc/1/DisableSocketPooling true

A swift reboot sealed the deal and all appears well now.

Next time

I think if I ran in to this sort of project in the future, I’d push to run with a Linode or something. The way I’ve got it going now works fine and we’ll continue on from there. But my suggestion is avoid running IIS period. If you have to use it, then try to keep it on it’s own machine. If you must run Apache with it, you can, just expect a Windows Update to eventually break everything and make you go become a sheep herder.