Wow. It's been over two months since I last blogged. All I can say is that I've been really busy lately -- but I've got a great backlog of material I've been waiting to get written up and blogged. So, let's kick it off!
I've been hearing several people, including fellow MVPs (Hi, Bharat!), drawing analogies between the new Exchange 2007 connectors and legacy Exchange objects. At first blush, these analogies seem to be pretty accurate:
- Ex2007 Send Connectors are more or less the same as Ex2000 SMTP Connectors.
- Ex2007 Receive Connectors are more or less the same as Ex2000 SMTP Virtual Servers.
Like most analogies, they're performing the comparison at some level of abstraction. If you take the analogy too far and confuse it for reality ("the map is not the territory"), you'll logic yourself into mistakes.
If you're not clear on what I mean, I've got two tables to help illustrate my point. Let's first look at Table 1:
Table 1: E2K SMTP Virtual Servers vs. E2K7 Receive Connectors
| Feature |
Exchange 2000 SMTP
Virtual Servers |
Exchange 2007
Receive Connectors |
| Required on server roles |
All |
Hub Transport
Edge Transport |
| Created on |
Server |
Server |
| Scope |
Server |
Server |
| Required for SMTP server |
Yes |
Yes |
| Controls SMTP server settings |
Yes |
Yes |
| Controls inbound routing [1] |
Yes |
Yes |
| Required for SMTP client |
Yes |
No |
| Controls SMTP client settings |
Yes |
No |
| Controls outbound routing [2] |
Yes |
No |
We should already be seeing some of the major differences between the legacy Exchange way of doing things and the Exchange 2007 way. For starters, the SMTP virtual server on legacy Exchange servers is in the middle of every SMTP transaction. This isn't unsurprising; the SMTP virtual server is the actual SMTP implementation for the Exchange server. If you create multiple SMTP virtual servers on a legacy Exchange server, you're essentially creating multiple instances of the IIS SMTP service (plus SMTP transport event sinks that provide Exchange's advanced behaviors).
Now, look at Table 2:
Table 2: E2K SMTP Connectors vs. E2K7 Send Connectors
| Feature |
Exchange 2000
SMTP Connectors |
Exchange 2007
Send Connectors |
| Required on server roles |
Bridgehead |
Hub Transport
Edge Transport |
| Created on |
Routing Group |
Organization |
| Scope |
Routing Group
Organization [3] |
Organization |
| Required for SMTP server |
No |
No |
| Controls SMTP server settings |
No |
No |
| Controls inbound routing |
No |
No |
| Required for SMTP client |
No |
Yes |
| Controls SMTP client settings |
Yes |
Yes |
| Controls outbound routing [4] |
Yes |
Yes |
The interesting thing here to me is that the legacy SMTP connectors are at their core a routing mechanism -- that's it. They sit on top of the SMTP virtual server and change how it behaves, according to whether the outbound message matches the connector's defined parameters. Depending on how you have things configured, outbound SMTP routing will be affected by a connector or the underlying virtual server. This leads to all sorts of interesting complications that can be very hard to troubleshoot and track down -- especially since SMTP connectors can be defined as RG scope, which means behavior could change from machine to machine in the organization.
By contrast, there is a very clean and sharp break of functionality in Exchange 2007. Inbound SMTP handling is always performed by the receive connectors; outbound SMTP handling is always performed by the send connectors. If you need multiple behaviors, define multiple connectors -- but in the case of send connectors, they will always apply to all Exchange 2007 servers in the organization, so you will always have consistent routing behavior. You only have to figure out which send connector applies, not track down two or three layers of configuration.
Having pointed this out, I would say that the initial analogies are adequate for most cases, because they match with the way most people I've talked to understand the role of the legacy Exchange objects. In Exchange 2007, Microsoft finally changed the behavior so that it matches the way people intuitively think about these issues -- which will make it easier to understand and use.
[1] SMTP virtual servers control inbound routing only from the standpoint of unique combination of IP address and port determines which virtual server will handle the message. Putting multiple virtual servers on the same machine can cause problems with intra-organization mail flow, though, depending on how they are configured. By contrast, multiple receive connectors will never break intra-org mail flow (althoug blindly changing settings on the default receive connector may).
[2] If no SMTP connector in the server's scope matches the address space of the recipient, then the underlying virtual server settings determine the next hop for the message.
[3] This in theory allows fine-tuning of routing on a per-routing group basis, by allowing a lower-cost routing group scoped connector to override a higher-cost organization scoped connector. However, this usually just leads to a mess, especially if you have multiple connectors for specific address spaces.
[4] When an SMTP connector matches the address space and is in the same scope as the server (anywhere in the organization for organization scope, or within the same routing group for routing group scope), the connector's settings override the virtual server.