Every now and then we find ways to forcibly remind ourselves of the basics. I had such a moment yesterday morning, and if my screwup can help someone else then it may have been worth it.
Sunday night I was troubleshooting some SMTP injection problems on my home network, and I was making changes to the configuration of my Exchange 2003 SMTP virtual server. At one point, I stopped the SMTP virtual server instance in the Exchange System Manager and was preparing to restart it when I decided that since I had email temporarily stopped anyway, I might as well take a few minutes and apply some patches. Ten minutes later, the patches were in place, the system looked good, so I rebooted the server. I stayed around just long enough to ensure that the system booted back up and that I could get to my mailbox, then I went to bed.
Monday morning, I got an IM from my wife telling me that she only had two spam messages in her Inbox. Since she’s on a couple of busy email lists, this was a good sign I’d broken something…and I immediately knew what it was.
On Exchange 2000 and 2003, the SMTP stack is made up of the IIS SMTP service (SMTPSVC) combined with several transport event sinks that add in the extended Exchange functionality. Each SMTP virtual server on the machine is another instance of the SMTP service. When you stop the SMTPSVC using net start or the Services Control Panel, you stop the base SMTP service, and all of the virtual servers are shut down. Should you reboot the server, the SMTP service will restart according to the state of the service (it’s set to Automatic by default), and all of the virtual server instances will also restart.
However, when you stop an Exchange SMTP virtual server instance via the ESM, you’ve only stopped that instance, just like stopping a web site in the IIS management console persists across restarts of the W3SVC. So when I ran updates and rebooted, I’d failed to restart the virtual server, and it sat there not running until I logged in yesterday morning and turned it on. No permanent harm done, an easy enough fix, and I even got a blog post out of it. My pain for your gain.
This is a design artifact of the IIS-based infrastructure I will not miss once we move to Exchange 2007, BTW. The new receive/send connector architecture makes multiple SMTP virtual servers a thing of the past. Of course, the times you’d want to use multiple SMTP virtual servers in Exchange 2003 were a lot fewer than most people thought, because they never worked the way most of us would at first assume they did. I remember the first time I had to deal with the concept that I could configure multiple SMTP virtual servers on a machine, set to different ports, and that they wouldn’t be able to communicate with each because they used the network interfaces to do it. Since SMTP expects to be used over port 25, you were pretty much limited to binding virtual servers to specific virtual interfaces. Exchange 2007’s receive connectors make all that a thing of the past; they are multiple pathways (with separate configuration sets) into the same hub transport goodness, allowing the SMTP submission port 587 architecture to not only be possible, but so easy that it’s included out of the box.