Message Flow | MCSA[s]MCSE

The flow of messages between components of an Exchange environment can be complicated. As an administrator, it would serve you well to learn how messages flow from one place (a sender) to another place (a recipient) in that environment. On a single Exchange server, component communication is relatively simple. As servers are added and grouped together into routing groups, this communication grows more complex. This section provides an introduction to the Exchange components involved in message flow and then examines the actual flow of messages in different situations.

Routing Architecture

Before we can look at the process of message flow in Exchange, it is first necessary to become familiar with some of the basic components that play a part in the routing of a message. Specifically, we will examine SMTP, the protocol used to transfer most messages in Exchange, routing groups that are used to define the routing topology of an organization, and connectors that are used to connect routing groups to one another and provide a way to transfer messages outside an Exchange organization altogether.

SMTP

SMTP is the native transport protocol in Exchange Server 2003 used to route messages within and between routing groups. In versions of Exchange Server prior to Exchange 2000 Server, a component named the Message Transfer Agent (MTA) used a protocol named X.400 to provide most routing functions. The MTA and X.400 still exist in Exchange Server 2003 but are now used only to provide communications with Exchange Server 5.5 and with foreign messaging systems using the X.400 protocol. SMTP has replaced X.400 over the past few years as the standard messaging protocol throughout the world, and so it has found acceptance in Exchange Server 2003 as the protocol of choice.

IIS handles SMTP and transfers information with Exchange via the ExIPC service that you learned about earlier in this chapter. The basic SMTP support in IIS is extended in a number of ways when Exchange Server 2003 is installed:

A secondary store driver, drviis.dll, is added that provides message pickup and drop-off using ExIPC.
An enhanced routing engine is installed that adds link-state information ‚ nearly instant information about the state of links to other servers.

Additional command verbs are added that support the exchange of link-state information with other servers.

The adoption of SMTP provides a great advantage to Exchange Server 2003. In versions of Exchange Server prior to Exchange 2000 Server, servers were divided into Exchange sites that served as both routing and administrative boundaries. Within a site, communications between servers took place using remote procedure calls (RPCs), a method for invoking services on a remote computer. While RPCs are effective for message transport, they require full-time , relatively high-bandwidth connections between computers. This means that Exchange sites could really only span groups of computers that were connected by high-speed networking.

SMTP offers an advantage over RPCs: SMTP does not require a high-performance network connection. This and the elimination of Exchange sites in Exchange Server 2003 have led to much greater flexibility in the deployment of servers. Exchange Server 2003 supports routing groups, which are groups of servers connected by a permanent connection, and administrative groups, which group servers and components according to administrative needs. The result of all this is that administrative needs can now be balanced with topology requirements in the deployment of Exchange servers.

Routing Groups

A routing group is a collection of servers with full-time, reliable connectivity. Topologically, a routing group is similar to the Exchange site used in previous versions of Exchange Server but, unlike the site, it imposes no administrative restrictions. Within a routing group, all messages are transferred directly between servers using SMTP. If you have a single Exchange server or if all your Exchange servers are connected over full-time, reliable connections, there will probably not be much reason for you to create more than one routing group. In fact, unless you create a second routing group, the fact that a routing group even exists is not evident in the Exchange System Manager. When a second routing group is added, the Routing Groups container appears in System Manager, and servers are grouped according to the routing group to which they belong.

There are several reasons why you may choose to set up multiple routing groups in your organization, such as the following:

Many Exchange servers do not have full-time, reliable, and direct SMTP connectivity to one another. This may be the case if your organization spans large geographic distances.
You must control the path that messages travel between servers. You can create a routing group boundary to force computers in one group to use a single bridgehead server (BHS) to send messages to another group.

You can learn more about using routing groups in Chapter 8, ‚“Building Administrative and Routing Groups. ‚½

Connectors

Communications between servers in different routing groups and with foreign messaging systems outside the Exchange organization are established using connectors . You ‚ ll learn more about configuring and managing connectors in Chapter 8, but a brief introduction is useful here.

Routing Group Connector
SMTP Connector
X.400 Connector

Three types of connectors can be used to connect routing groups to one another:

Routing Group Connector

The Routing Group Connector is the preferred method of connecting two routing groups in the same organization; it is fast, reliable, and the simplest to configure (since it has the fewest settings). SMTP is the native protocol used by the Routing Group Connector, and the connector consults Exchange Server ‚ s link-state table for routing information.

The Routing Group Connector is a unidirectional connection that goes from one server to another. Therefore, when you configure a Routing Group Connector, you ‚ ll need to create two connectors to form a logical bidirectional link between the two routing groups. However, to reduce administrative effort, you can autoconfigure the other side of a Routing Group Connector when installing the first end of the connector just like a Site Connector in Exchange Server 5.5.

A bridgehead server is a server that is designated to pass messages from one routing group to another, as shown in Figure 2.4. The Routing Group Connector offers a level of fault tolerance by allowing multiple source and destination bridgehead servers. Bridgehead servers can be used in one of three ways:

No bridgehead server is designated, and all of the servers in the routing group function as bridgehead servers for message transmission.
One bridgehead server is designated, and all mail destined for other routing groups flows through that one server. This gives the administrator great control over messaging configuration.
Multiple bridgehead servers are used, and all mail flows through one of these designated servers. This configuration offers the advantages of load balancing and fault tolerance. Should one bridgehead server be unavailable for message transport, another will be available.

Figure 2.4: Bridgehead servers are responsible for transferring messages between routing groups.

Routing Group Connectors offer administrators the ability to control connection schedules, message priority, and message size limits.

SMTP Connector

Although the Routing Group Connector uses SMTP as its native transport mechanism, Exchange Server 2003 also provides an SMTP Connector that can be used to link routing groups. There are three reasons why you might want to use an SMTP Connector instead of a Routing Group Connector:

The SMTP Connector is more configurable than the Routing Group Connector and thereby offers the ability to more finely tune the connection. The SMTP Connector also offers the ability to issue authentication before sending mail, specifying TLS encryption and removing mail from queues on remote servers.

The SMTP Connector always has to use SMTP. When you are connecting an Exchange Server 2003 with an Exchange 5.5 server, the Routing Group Connector uses RPCs to communicate because it has no way of knowing whether the Exchange 5.5 server is configured to use SMTP, which was provided through the Internet Mail Service in previous versions of Exchange. There is no way to force the Routing Group Connector to use SMTP, so an SMTP Connector may be used instead.

The SMTP Connector is also capable of connecting independent Exchange forests within an organization so that messages can be transferred.

Another advantage of the SMTP Connector is that it can be used to connect an Exchange organization to the Internet or to a foreign (non-Exchange) messaging system that uses SMTP.

When connected to the Internet, the SMTP Connector uses a smart host or mail exchange (MX) record in DNS for next-hop routing. When configured internally between two routing groups, this connector will relay link-state information between routing groups but will still depend on the MX records in DNS for next -hop information.

X.400 Connector

The X.400 Connector can be used to link Exchange routing groups and also to link an Exchange organization to a foreign, X.400-based messaging system. X.400 Connectors are useful for linking routing groups when there is very little bandwidth (less than 16 Kbps) available between servers or when X.400 is the only connectivity available. When linking routing groups with the X.400 Connector, a single server in each group must be designated as the bridgehead server. You must set up multiple X.400 Connectors between multiple servers in each routing group to gain a load-balancing feature. Note that you can also install a Routing Group Connector alongside an X.400 Connector.

Link State Algorithm

Whenever multiple routing groups are connected, the connections over which messages are transferred are referred to as links. Every link can exist in one of two states: up (available) or down (unavailable). In addition, every link is assigned a value that represents the cost of using that link relative to other available links. By default, the cost of any connector created is 1, but cost can range from 1 to 100, with lower number values being the preferred routes. You can configure the cost of connectors in your organization to create a bias for certain routes.

Exchange Server 2003 uses link-state tables to provide all servers in the system with information that lets the servers determine whether any given link is functioning. The link-state information also lets servers determine the best route to send a given message based on the total cost of all connectors a route will use. For example, a route that crossed two connectors whose individual costs were 2 (for a total cost of 4) would be favored over a route that crossed two connectors with individual costs of 3 (for a total cost of 6). Connectors that are in a down state are never considered . The information in these link-state tables is based on a protocol named the Link State Algorithm .

Support for the Link State Algorithm was first introduced in Exchange 2000 Server, though it has been around for many years elsewhere. In fact, it forms the foundation of the Open Shortest Path First (OSPF) protocol that is used extensively by routers today. Exchange Server 2003 still incorporates routes and costs but relies heavily on link-state information to route messages between routing groups.

The Link State Algorithm propagates the state of the messaging system in almost real time to all servers in the organization. There are several advantages to this:

Each Exchange server can make the best routing decision before sending a message downstream where a link might be down.
Message ping-pong is eliminated, because alternate route information is also propagated and considered in the routing calculations.
Message looping is eliminated.

In each routing group, one server is designated as the Routing Group Master and will become the bridgehead server to the other routing group. By default, the first server added to a particular routing group becomes that group ‚ s master. When one bridgehead server connects to another bridgehead server in a different routing group and link-state information is exchanged, this is done with SMTP. The Routing Group Master holds the information of who is up or down and propagates that information to each Routing Group Master in each routing group.

Message Transport

All good messaging systems rely on a strong transport and routing engine to deliver messages, and Exchange Server 2003 is no different. A solid understanding of how messages are transferred between Exchange Server components is essential to managing a reliable organization and to troubleshooting any failure in message transfer.

For the most part, messages are submitted to an Exchange server using the SMTP protocol. These messages may come from a client within the Exchange system or from an outside system such as the Internet. Though messages may also be submitted to the Exchange server via direct submission from a client using IFS or via the MTA from a foreign system, we will concern ourselves here with the SMTP process.

Here ‚ s the basic procedure that occurs when a client submits a message to the Exchange server (see Figure 2.5):

An SMTP client opens a connection on the SMTP Service.
The IIS process on the SMTP Service responds.
After negotiation, the SMTP process receives and processes the message.
The SMTP process hands the message to an advanced queuing engine, which places it into a Pre-Categorizer queue.
A Categorizer resolves the sender and recipient for the message, expanding any distribution lists as needed and resolving all recipients in the list. In previous versions of Exchange Server, this task was performed by the MTA.
Next, the advanced queuing engine passes the message to the routing engine, which parses the message against its Domain Mapping and Configuration table. The routing engine checks Active Directory and decides whether the message is destined for the local store or a remote server. If destined for a remote server, a Destination Message queue is created for the message as a temporary queue from which the SMTP service can read the message and pass it along.

Figure 2.5: A client submits a message to an Exchange server using SMTP.

Once the message has been submitted, the routing engine decides where the message is supposed to go. In all, Exchange Server 2003 messages can get from a sender to a recipient in one of four contexts. A message can be sent as follows :

From a sender to a recipient on the same server. This may be the case when two users have mailboxes on the same server and transfer messages between them, when a user posts a message to a public folder that exists on the same server, or when an Exchange Server component delivers a message to a local recipient.
Between different servers in the same routing group.
Between different routing groups.
From a sender in the Exchange organization to a user on a foreign messaging system outside the Exchange organization.

On the Same Server

If the message is destined for the local store, it is placed in the Local Delivery queue, and the store.exe process reads the message out of the queue and writes it to the local database. Thereafter, the message is associated with the destination mailbox, and the user is notified that new mail has arrived. This is the simplest of the message transport contexts.

Between Servers in the Same Routing Group

Messages routed between servers in the same routing group use SMTP as their transport. The steps involved in routing a message between two servers in the same group are slightly more complicated than on a single server:

Since the message is not intended for local delivery, the message is passed to the routing engine.
Once in the routing engine, the message is parsed against the Domain Mapping and Configuration table and then placed in the outgoing SMTP queue for the destination server.
The sending server looks up the recipient ‚ s home directory in Active Directory, conducts a DNS lookup for the MX record associated with the destination server on which the recipient ‚ s mailbox is stored, and then creates a TCP connection to that server.
The message is transmitted to the destination server.
Once the destination server receives the message, it processes it in different ways depending on the destination of the message. If it determines that the message goes to a recipient in its local store, it follows the procedure discussed in the previous section. If it determines that the message goes to a different server or outside the organization, the above process is repeated to route the message to the correct server.

Between Routing Groups

Messages routed between servers in multiple groups incur the use of a bridgehead server at each end of the connector. The steps involved in routing messages between servers in different routing groups are as follows (see Figure 2.6, where the solid line represents the flow of messages and the dashed line represents queries):

Since the message is not intended for local delivery, the message is passed to the routing engine.
The routing group information is gathered from the configuration naming context of Active Directory.
The link-state information is consulted to determine the best routing path.
The message is passed to the bridgehead server.
The bridgehead server passes the message to the destination bridgehead server in the other routing group.
The receiving bridgehead server passes the message to the destination server in its group.
The message is brought into the destination server via the SMTP service and placed in the Local Delivery queue.
The message is taken out of the queue by the store.exe process and associated with the recipient ‚ s inbox.

Figure 2.6: Routing messages between routing groups

Outside the Exchange Organization

Message delivery outside of the Exchange organization is similar to delivery to another routing group in that a connector must be used to pass the message. Here are the steps involved in routing to another e-mail system:

Since the message is not intended for local delivery, the message is passed to the routing engine.
The routing group information is gathered from the configuration-naming context of Active Directory.
The link-state information is consulted to determine the best routing path. In this case, the path must end with the connector to the foreign system.
The routing server then either sends the message over the appropriate connector to the foreign system or, if the connector is in a different routing group, sends the message to that routing group.
The message is passed over the appropriate connector to the foreign system.