Now matter how well written and tested, every piece of software has bugs; it’s practically guaranteed. Most people are willing to give the developers a pass on the esoteric use-cases they never considered when writing it (or round-peg/square-hole problems a lot of us get hired to support); but the more mundane issues tend to get annoying rather quickly, especially when it’s commonly used software that’s suddenly acting in a completely different manner from what we expect. We IT professionals occasionally fall into the trap of assuming “Well it’s [insert name of scapegoat] software, what did we expect” and writing it off as unfixable, while less savvy users seem to insist on assigning agency and randomness to something that, by definition, must give the same result for the same inputs. Often, both groups seem to forget that the computer is doing exactly what we told it to do. We just didn’t tell it do the right thing.
For example, I was recently asked to change the port number for the SSL site of a new application. Simple enough task: we had replaced a piece of software with a different package that did the same thing and just wanted to get the new package using the same ports as the old one to ease training; should have taken 5 min at most, with testing and documentation. My attempt went something like this:
Open IIS manager, edit site properties, change port numbers. Open browser and get an error.
Hrm, must have to restart something for that take effect.
Stop site, start site. Get an error about port being in use
That’s not right, the old software isn’t even installed anymore
Open cmd, run netstat -nao | findstr /L “:portnumber”
Yeah, nothing’s using that port. Machine’s been up a while, maybe it just needs a reboot.1
Reboot server, open IIS manager, change port numbers again. Open browser and get an error.
Stop site, restart site. Get error about port being in use.
Eventually, in desperation, I open the properties on the site and started digging around to see if there’s anything obviously wrong with how the software installer had created it. I quickly found the “Advanced” button in the “Web site identification” block on the “Web site” tab. Clicking that, I was handed the solution and a bit a head-scratcher. The advanced properties for the web site identification allow you bind the site to different ports on different IP addresses: e.g. the same site could be on port 80 on NIC 1 but 8085 on NIC 2 with SSL sites on 4343 on NIC 1 and 4433 on NIC 3, if you needed to do that for some bizarre reason.
In this case, the original installer had brought up the unencrypted site on the port we wanted to use for the SSL site. When I changed the ports in the normal properties dialog it didn’t remove the old mappings, just created new ones. So the site was trying to host both a non-SSL version and an SSL version of the site on the same port on the same NIC. Everything I know about HTTP says this will never work, even if IIS was a able to actually re-use a port, which it can’t.
Long story, short: the solution in this case was to remove all the identities (both SSL and unencrypted) from the site except the two I wanted. Restarted the site and everything starts working normally. There’s a debate to be had about whether that constitutes a bug in IIS (i.e., should it have been smart enough to know that configuration could not work and prevent me from creating it in the first place) but the main take-away here is that software does what you tell it to do. Sometimes it will let you create a configuration that does not actually make sense; it’s rarely a bad idea to take a couple minutes and review that configuration before assuming it’s a bug and blaming some nameless developer.
1Generally, I don’t suggest rebooting servers without a scheduled maintenance window and notifications to affected parties. In this case, the work was being done after-hours and the affected users were 4 other people who all new I was supposed to be doing this and expected that software to be down anyway.