Message Routing

In earlier versions of Exchange (2000 and 2003), if more than physical or geographic location existed, the Exchange servers could be broken up based on their physical location. The architecture of message routing is based on routing groups. By placing Exchange servers in different routing groups, the administrator can control messaging traffic between those locations and can more accurately focus public folder connectivity by Outlook clients. In almost all situations, the servers located in routing groups correspond to the location of an Active Directory site, though not all Active Directory sites might actually have an Exchange server.

Exchange 2007 simplifies the management of the physical layout of Exchange by eliminating the need for routing groups and relying on the Active Directory site architecture instead. Servers with the Hub Transport role accept messages from Mailbox servers, determine the location of the destination mailbox database, and deliver the message to a Hub Transport server in the remote Active Directory site.

Message Routing and the Hub Transport Server

The Hub Transport server role is at the center of the message transport architecture. The Hub Transport server maintains Send and Receive connectors that are responsible for receiving mail from the Internet, sending mail to the Internet, sending mail to remote Hub Transport servers, and receiving mail from remote Hub Transport servers. All messages must be processed by the Hub Transport system regardless of whether they will be delivered to a local mailbox or a remote recipient.

Note 

In Exchange 2000/2003 there was the concept of SMTP virtual servers, which could either send or receive SMTP mail. Send connectors are responsible for outbound SMTP mail only and Receive connectors are responsible for inbound mail only. One big advantage of this is separation of logging.

The message transport architecture and dependencies are illustrated in Figure 2.7. Messages enter the Exchange 2007 message transport system through one of three possible mechanisms: a message can be submitted to the Hub Transport via SMTP, a Mailbox server's store driver, or the file system's Pickup folder on the Hub Transport server. The Hub Transport relies on Active Directory for configuration, topology, and recipient information and thus must have access to domain controllers and global catalog servers.

Figure 2.7: Basics of the Hub Transport architecture

Once a message is submitted to the Hub Transport system, it enters the message queuing system where the message Categorizer reviews it and determines how to deliver it. There are five possible queues that can be found on a Hub Transport server:

• The submission queue is the queue in which messages are placed when they enter the Hub Transport server (via SMTP, store driver, or pickup folder). The categorizer processes the messages as they arrive in this queue. The submission queue is also called the categorizer queue or the submit queue.

• The poison message queue is the queue in which messages are placed if there is a problem that prevents the message from being categorized.

• The unreachable domain queue is the queue in which messages are placed if there is no route available.

• Local delivery queues are queues in which messages are placed if they are to be delivered to a Mailbox server in the same Active Directory site.

• Remote delivery queues are queues in which messages are placed to be delivered to remote Hub Transport servers or outside of the organization. The remote delivery queue is the only type of queue available on the Edge Transport server role.

The Categorizer component is the Hub Transport component that watches the submission queue. As messages arrive in the submission queue, the Categorizer picks them up and processes them. The following are some of the steps involved in message categorization:

• Expand any distribution lists, if applicable, by querying the global catalog.

• Resolve recipient addresses to determine which recipients are local, remote, or outside of the organization.

• Apply message transport rules to the message.

• Split the message into multiple parts if the message is going to local and remote recipients; this process is called bifurcation.

• Examine the message sender, recipients, header, body, and attachments and apply message transport rules that apply to the message.

• Convert the message to the appropriate message format (Summary-TNEF, MIME, or UUENCODE) depending on its destination.

• Determine the next "hop" for the message.

• Place the message in to appropriate local or remote delivery queue.

Note 

With a few exceptions, such as application transport rules, the Categorizer function has not changed from Exchange 2000/2003.

Message Transport Security

One of the intentions of the design of Exchange 2007 was to make messaging more secure. One of the outcomes of this was to ensure that message content is secured as it is being transmitted from one server to another. This includes authenticated connections and encrypting the data as it crosses the network. Figure 2.8 shows the possible places a message may be passed across the network and how protection is or may be implemented.

Figure 2.8: Security when messages are being transmitted

As messages are transmitted via MAPI over RPC between Mailbox servers and Hub Transport servers, RPC encryption is automatically used. When a message is transmitted from one Hub Transport server to another, the Hub Transport servers authenticate using Kerberos and the data stream is encrypted using Transport Layer Security (TLS). When messages are transmitted from a Hub Transport server to an Edge Transport server, mutual authentication using certificates is used and messages can be encrypted using TLS. Optionally, an organization that is sending messages to another organization also using Edge Transport services can configure authenticated connections and TLS encryption to these remote organizations. Messaging security and Edge Transport is going to be covered in more detail in Chapter 20, "Securing Exchange Server."

Inter Site Message Routing

In previous versions of Exchange, in order to deliver mail from one Exchange 2000/2003 routing group to another, a connector needed to be created (for example, Routing Group connector, SMTP connector, and X.400 connector). The Exchange 2007 equivalents of routing group connectors are SMTP Send and SMTP Receive connectors.

One feature that will surprise some Exchange 2000/2003 administrators is that, by default, Exchange 2007 Hub Transport servers will behave as if connectivity between them is a full mesh. In previous versions of Exchange, messages flowed only between Exchange servers with explicit routing group connectors.

Take, for example, the organization in Figure 2.9. This organization has four Active Directory sites. In three of them, there is a Mailbox server and a Hub Transport server.

Figure 2.9: Sample message routing architecture

The Active Directory site link architecture defines the site links as shown in Table 2.9.

Table 2.9: Sample Active Directory Site Links and Costs
Open table as spreadsheet

Link Name	Cost
Site Link H-A	1
Site Link H-B	1
Site Link H-C	2
Site Link A-C	100
Site Link A-B	100
Site Link B-C	100

Clearly, this Active Directory design intended for all replication to go through the "hub" site known as Site H. Thus, a logical assumption would be that messages would be routed using this site link cost architecture. However, if a message originates on a Mailbox server in Site C and is intended for a recipient in Site B, the Hub Transport server will always attempt to route the message directly first. If the direct path is not available, then the message will be routed to the Hub Transport server in Site H. The site link costs are used to determine message routing paths only if the direct connection fails.