We received lots of great feedback on my first blog post. With that, I think it is time to clear up the second largest area of confusion with Exchange SMTP transport: SMTP virtual servers.
The short of it is, with the exception of the gateway server scenario, I generally recommend staying away from modifying or adding SMTP virtual servers, particularly on mailbox servers. I'll explain my reasons by first providing some of the scenarios that are misunderstood. Below I will explain each of the following:
- Myth: Virtual Servers On The Same Machine Are Internally Connected
- Myth: Routing Happens Before Selecting A Virtual Server
- Myth: Modifying SMTP Virtual Servers Is Mostly Harmless
- Myth: Virtual Server IP Address Will Be Used For Outgoing Connections
Myth 1: Virtual Servers On The Same Machine Are Internally Connected
The largest source of misunderstanding is that on a mailbox server with multiple SMTP virtual servers, the SMTP virtual servers have some internal mechanism for communicating and selecting a route. In fact, there is no such mechanism. Treat SMTP virtual servers as if they were real servers. That is, running on different machines. The only thing that they share is system resources (which is why adding multiple virtual servers is unlikely to give you any performance boost). As such, if one SMTP virtual server is communicating on port 2525, and the other on port 25, they will not be able to communicate with each other, even if they are on the same physical machine.
Myth 2: Routing Happens Before Selecting A Virtual Server
Furthermore, there seems to be a conception that transport will select the right SMTP virtual server at the beginning of message processing. That is, all of the transport components for processing messages (categorizer, routing, queuing, sinks, etc.) must operate within an SMTP virtual server instance (VSI). How does the store know which one to pick? Well, as it turns out, the Exchange store driver picks the first one to start up and only registers that virtual server to monitor the store's SendQ (the queue the store uses to put messages that are waiting to be processed by SMTP Transport ). Since VSIs can start asynchronously, there are no guarantees which VSI this will be. Additionally, you can start and stop VSIs on the fly, which means that the store will then have to pick another VSI.
In other words, SMTP VSI 1 may or may not be the one to categorize and route the mail. When routing finally does kick in to match the destination with a route or connector, then there may be a need to reroute the message to another SMTP VSI on the same box. In this example, VSI 1 may very well get Internet bound email from the Information Store and then have to reroute it to VSI 2. This must take place via the network stack.
If the message originates on another server, then that server's routing stack will attempt to contact the next hop. All VSIs in the RG are treated equally and communicate directly with each other, no matter how many there are on a particular server. So, in the example above, if we're talking about mail coming from other servers in the same RG, then, VSI 2 would be chosen by the previous Exchange server. If for some reason other servers in the RG cannot communicate with VSI 2 directly, they will not then automatically attempt to contact VSI 1 instead. This is why in the gateway scenario, you must home the Internet SMTP connector on the internal VSI (not the external VSI), though this may not seem intuitive at first.
Myth 2b: Content Modifying SMTP Event Sinks Can Be Made Work On A Mailbox Server
If you've ever tried to write an SMTP transport sink to modify message contents, you know that you cannot do this on a mailbox server. The reason is that the message contents are not in modifiable with CDO until they are in SMTP format. Sometimes it is suggested that a second virtual server on the same physical machine could accomplish this. In reality, it can not be guaranteed on a mailbox server. If you register your sink on VSI 2, it is possible that the path might be VSI 1 -> SMTP -> VSI 2, and your sink would work. But what happens when VSI 2 gets the job of talking to the store and there is no longer an additional hop (try restarting SMTP VSI 1)? In that scenario, when VSI 2 gets the message, it still resides in the store and cannot be modified.
Myth 3: Modifying SMTP Virtual Servers Is Mostly Harmless
The next largest source of misunderstanding is that modifying the SMTP virtual server defaults is a good thing. We get a surprising number of cases in PSS that result in the support engineer simply putting the default settings back into place. In reality, there are few that you'll ever need to modify. There are some that you make sense only to modify on inbound or outbound gateway servers -- IP address, external DNS servers, filtering, FQDN, authentication settings, etc.. Modifying these on non-gateway servers may break internal routing functionality. And there are some that you should just stay away from all of the time -- smart host, forward unresolved messages, attempt direct delivery (I say this because generally you will use connectors to accomplish these things instead).
Myth 3b: Modifying The FQDN of the SMTP Virtual Server
I call this out, because it is one of the more dangerous and tempting to modify. You see the internal FQDN of your Exchange server in the headers of your messages, both in the hop history and the Message-id. So you decide that is undesirable and go change it. Well, there's some things you need to be aware of:
- Message-Id is almost always generated by the store (Outlook or OWA) or client (Outlook Express), long before SMTP gets a chance to generate one. The only scenario where SMTP generates one is if a message somehow comes into Exchange without it. SMTP will not under any circumstance modify a message-id if the message already has one -- even an SMTP event sink cannot do this.
- Hiding internal names rarely serves any real purpose, considering that the IP address is usually still in the header, and considering that if your firewall is compromised, it is probably too late to hide. It makes things harder to troubleshoot. It might break things that rely on it (message tracking and duplicate/loop detection). It is against the RFC. But, if you absolutely must modify this, it is often best to do it on an SMTP border machine. That way, message tracking and headers can still be used internally to troubleshoot internal routing type of issues.
- In order for internal routing to work, the FQDN generally *MUST* resolve in DNS to the IP address of the Virtual Server. Specifically, when routing has calculated next hop, it passes the FQDN of that next hop down to Advanced Queuing. Modifying the FQDN breaks this which works by default (since the STMP FQDN matches the machine name by default). Even if you create an entry in DNS -- unless it is a CNAME record -- you lose the dynamic capability of Windows DNS, should you modify the machine IP at a later date.
- To further complicate things, FQDN is one of those rare properties in SMTP that doesn't fully take effect until you restart. That is, you might modify it today, and everything could work just fine -- for months -- until you restart. By the time that happens, you've forgotten that anything was changed.
Allow me to call out an exception to the 3rd bullet point above. If you do have multiple virtual servers (e.g., a gateway server), you actually have to change the FQDN of each additional virtual server (more clearly, you probably need to change (n-1) SMTP FQDNs where n is the number of VSIs). Specifically, if you have multiple virtual servers, then in order for other servers in the RG to uniquely identify them, you should have unique FQDNs for each. Of course, this probably means creating a DNS entry to go along with it. Note: we loosened this requirement in Exchange 2003 because we now first attempt to bypass DNS resolution and try to first use the specified IP address of the virtual server. Clearly, however, we must fall back to DNS if the VSI is set to "All Unassigned."
Myth 4: Virtual Server IP Address Will Be Used For Outgoing Connections
The last source of misunderstanding is the socket which will be used to open an SMTP connection. This may seem confusing and somewhat contradictory of my first point, but SMTP simply tells the Windows network stack to provide SMTP with a socket. It does not provide a source IP address to use, and as such, you will notice that the source IP address assigned by Windows will be based on the Windows routing table, not taking into consideration the IP of the SMTP VSI that is delivering the message. A common observation of this is that on a cluster server we are using the physical machine IP as our source IP, not any of the virtual IP addresses.
This might be a more complete version of the picture I first drew, particularly when thinking about outbound connections.
Hopefully you've found this helpful. Now you know why I recommend extreme caution with regards to SMTP virtual servers on mailbox servers and will take this in mind when planning & configuring your environment.