“There is an Edge Transport and a Hub Transport, correct? When there is an Edge Transport the Hub Transport is no longer in the e-mail loop or is it?”
Quick Answer: “It is.”
And now for the slightly longer answer. But first, I should mention that you might want to go read my earlier blog article on “Five Things About Exchange Server 2007 You Probably Don’t Know (part 4)” or the in the Global Knowledge whitepaper (see <http://www.globalknowledge.com/training/whitepaperlist.asp?pageid=502&country=United+States> and select the Microsoft category).
The hub transport and edge transport roles perform different roles in an Exchange organization with remarkable similarities, not quite like Dr. Jekyll and Mr. Hyde, but let’s go with the analogy anyway.
Dr. Jekyll is the refined professional, visible in the community as an upstanding participant in the public health. Similarly, servers running Exchange Server 2007 with the Hub Transport role installed (and perhaps other roles as well) performs four main functions, as follows:
- pick up messages waiting in people’s Outboxes,
- route messages between mailboxes within the organization,
- exchange messages with server outside the organization, such as inbound and outbound messages from/to the public Internet,
- deliver messages to mailboxes (e.g. Inbox folder) within the organization.
In addition, it’s true that Hub Transport servers can also do AntiSPAM and AntiVirus filtering, but those extra functions are sometimes reserved for other servers which are outside, or at the edge of the organization. We’ll talk more about those other servers in just a moment.
Servers with the Hub Transport role can also do journaling and perform extra work according to a list of transport rules. These are immensely powerful features which we shall not elaborate on at the moment.
As a part of pickup and delivery from and to mailboxes within the organization, the Hub Transport role will communicate with the Mailbox server role within the same server or within the same Active Directory site using the messaging application programming interface (MAPI). This involves not only the actual transfer of messages using MAPI over the remote procedure call (RPC), but lookup of information in Active Directory as well. As a part of routing messages within the organization, the Hub Transport role also needs to get information from Active Directory and then communicate with other Hub Transport servers within other Active Directory sites within the organization using the Simple Mail Transfer Protocol (SMTP) and external servers via SMTP as well.
We need to protect our servers which run the Hub Transport role. Not because they speak SMTP, but because they use MAPI/RPC for pickup/delivery with mailbox servers, and Active Directory protocols such as the lightweight directory access protocol (LDAP) which could provide access to security-sensitive information. Like the Mailbox (MB), Client Access (CA), and Unified Messaging (UM) roles, the servers hosting the Hub Transport (HT) role should be located on intranet network segments which are protected by firewalls from the outside world. Access to LDAP and MAPI/RPC are not allowed from outside these protected intranets.
Enter Mr. Hyde. Unlike Dr. Jekyll who probably took an oath to protect, preserve, and uphold the health of messages in the community, Mr. Hyde is more commonly known for unsavory activities such as altering and eliminating certain messages. But like Dr. Jekyll, Mr. Hyde is very intelligent, and skilled with a knife. Where is this analogy going? Oh, right.
Like Hub Transport servers, Edge Transport servers are quite adept with the SMTP and use it as often as they can. But they lurk in the shadows. Edge Transport servers wouldn’t be seen in broad daylight at a social gathering with the leaders in society. Edge Transport servers are not allowed to communicate via LDAP (directly at least) with the intranet-based Active Directory Domain Services nor use MAPI/RPC to directly access mailboxes. Mr. Hyde, like Edge Transport servers, does not live on the intranet. In the shadows of the extranet, the perimeter network, the demilitarized zone (DMZ), the edge network, the Edge Transport server(s), like Mr. Hyde, can perform other activities however.
Edge Transport servers can secretly remove messages without anyone’s knowledge (e.g. AntiSPAM protection), and alter the body of messages which they find interesting or attractive (e.g. AntiVirus functionality). Well, perhaps Edge Transport servers aren’t quite as evil as Mr. Hyde. But there’s another essential aspect of the relationship. Mr. Hyde needs Dr. Jekyll, and is in essence another aspect of Dr. Jekyll then the one we normally see in another environment. Similarly, Edge Transport servers, with their SMTP, transport rules, journalling, are cut of the same cloth as Hub Transports. Yet Edge Transport servers work in the extranet, outside the internal networks and outside the Active Directory forests and Exchange organization(s) of the intranet(s) of the organization. Hub Transport servers are needed on the inside whether or not Edge Transports exist at all.
Let’s think about that again. Hub Transport servers are needed for pickup, transfer, delivery, and gateways to/from the outside world. Having Edge Transport servers does not replace the need for Hub Transports any more than having Mr. Hyde could replace Dr. Jekyll. Simplistically speaking, Hub Transport servers are very much in the message path between Edge Transport servers and the Mailbox servers.
But can a Hub Transport server transform into an Edge Transport server by drinking a potion, or with entrainment, even without the potion?