Information Flow and Routing

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : June 14, 2001

This article is a sample chapter (Chapter 8) from Introducing Microsoft® Exchange 2000 Server. In this chapter, we examine the essential concepts and tasks that you need to know to work with Exchange Server. To order a copy of Introducing Microsoft® Exchange 2000 Server, go to https://www.microsoft.com/mspress/books/4216.asp.

Networks, large and small, have two features in common. They move information from place to place, and they provide storage for that information when and as necessary. The information might flow from client to server, server to client, server to server, or client to server to a network device such as a printer. At some point on this route, the storage required might be permanent (for network-resident information) or temporary (for information as it travels from source to destination). Regardless, all networks move and store information. Message flow and routing determine when, where, and how that information gets moved from place to place.

On This Page

A Myriad of Destinations
Message Flow and Message Routing
Message Flow
SMTP
Message Routing

A Myriad of Destinations

Where Microsoft Exchange is involved, some information - such as directory replication data - passes only between servers. However, even though transferring such information is crucial, such transfers are secondary in the sense that they are needed to support the larger objective of Exchange: moving messages and other data from clients to the information store and from there to their intended destinations.

Of course, any given message could be destined for a host of locations, both within and outside the network. At one extreme, for example, a message might end up no further away than the office next door, even though the information itself must travel over the network from the sender to the Exchange server and then to the recipient. But even if the route itself is hardly a straight line, if both of these Exchange clients are in the same domain and on the same server, such next-door delivery is relatively simple. Exchange merely needs to log the message, check the directory, and pop the message directly into the recipient's mailbox.

At the other extreme, however, a message might need to be delivered to numerous recipients in different buildings, organizations, cities, or countries. Almost certainly, these recipients' mailboxes would be housed in different databases, and even those users in the same Exchange organization could well have mailboxes residing on different servers. Furthermore, the recipients themselves could be scattered throughout multiple domains and domain trees. Mail delivery in this situation is a more complicated matter. It can involve different protocols as well as routing based on connectors, multiple hops, and temporary queuing until a scheduled, nonpermanent connection can be established for delivery - say, from one country to another.

Simple or complex, direct or indirect, Exchange is responsible for both routing and delivering the mail.

Message Flow and Message Routing

There are, when you think about it, two different aspects to message transfer in Exchange. There is the movement - the flow - of messages through Microsoft Windows® and Exchange, and there is also the movement - the routing - of messages from server to server.

• Message flow in Windows and Exchange involves such features as built-in support for SMTP by the operating system and Exchange, as well as their built-in support for other Internet protocols, including IMAP4, POP3, and NNTP. Within Exchange itself, message flow also involves routing, queuing, categorizing, and communication between protocols and the information store.

• Message routing from server to server, on the other hand, involves routing groups, connectors, and link state tables. It might also involve the hosting of the Exchange protocol, storage, and directory subsystems on separate servers.

This chapter covers both types of message transfer.

Message Flow

Much ado has already been made, both here and in Microsoft white papers and documentation, about the tight integration of Exchange 2000 Server and Windows 2000 Server. This integration is most extensive where Windows 2000 Active Directory™ services is concerned, but it also affects other areas, including clustering, administration, and security.

Integration also has an effect on message flow, although in this area the connection between Windows and Exchange might be better described as a partnership than as integration. In other words, integration is highly visible in areas such as the complete reliance by Exchange on Windows 2000 for Active Directory services, cluster management, and security. But where messaging is concerned:

• Even though Windows 2000 installs core Internet protocol stacks, including SMTP, for handling tasks such as replication and basic messaging, it is Exchange 2000 that extends these stacks to boost functionality to the levels required by enterprise-class messaging, message transfer, and collaboration.

• Even though Windows 2000 runs Internet protocols as part of Internet Information Services 5.0 (IIS) process, it is Exchange that takes advantage of IIS to support front-end/back-end hosting that allows scalability up to millions of users.

Separation of Powers: IIS and the Information Store

Internet protocols were built into the information store in Exchange Server 5.5 primarily to ensure rapid access to messages. In Exchange 2000, these protocols, including SMTP, POP3, IMAP4, and NNTP, have been removed from the store and are handled separately by the IIS process.

Within Windows 2000, IIS runs as a service, making use of other Windows services, including security and, of course, Active Directory services. IIS is included in Windows to support tasks related to the World Wide Web, such as site creation and management. However, because it now contains SMTP, NNTP, and other Internet protocols formerly included in the Exchange information store, IIS is also needed by Exchange for message routing and the instant messaging.

Although Internet protocols are now separate from the information store and, in fact, are handled by a completely separate service, message flow in Exchange 2000 does not suffer. Both protocols and store can depend on rapid communication, thanks to the new Exchange queuing layer, the Exchange Interprocess Communication layer, or EXIPC ("Epoxy"). Situated between IIS and the information store, EXIPC serves as an intermediary between the two, as shown in the following illustration.

EXIPC relies on protocol DLLs on both the IIS and information store sides, as well as on shared memory and pairs of queues to create protocol-specific communication pathways between IIS and information store processes. Acting somewhat like reserved lanes on a freeway (carpool or bus lanes, for example), these pathways are what enable high-performance information exchange. A closer look at these links between EXIPC, IIS, and the store - illustrated by one protocol, SMTP - is shown in the following illustration.

SMTP

SMTP is now the native transport in Exchange 2000, and SMTP message flow in Exchange begins with message flow in Windows 2000 Server - specifically, with Windows listening in at port 25 (the default) for incoming SMTP mail.

Advantages of SMTP

Recall that SMTP runs in Exchange 2000 as a peer to X.400 and is, in fact, the default transport for traffic routing both within and between sites. Although X.400 is still used to connect Exchange computers with X.400 messaging systems, SMTP is the primary messaging protocol in Exchange 2000, for two reasons:

• SMTP has replaced X.400 over the past few years as a standard messaging protocol throughout the world. Thus, the use of SMTP as the primary protocol ensures that Exchange can interoperate well with both the Internet and other messaging systems.

• SMTP, along with the Exchange 2000 elimination of reliance on remote procedure, calls for intra-site communication and the new distinction between routing groups and administrative groups, provides for more flexibility in deployment. Deployment can now be based on administrative needs rather than on bandwidth availability.

SMTP from the Administrator's View

Although SMTP message flow happens invisibly, the Exchange Management console displays the SMTP servers that actually show the results of all the queuing, routing, and delivery required. These servers are the tools administrators use for configuring, viewing, and managing SMTP and its mail queues and message delivery.

SMTP Virtual Servers

At the heart of SMTP mail delivery are its virtual servers. Virtual servers are defined as single instances of the SMTP protocol service and, by default, each physical server hosts one virtual SMTP server. A physical server can be configured to host multiple virtual servers, but note that

• Each virtual server is multithreaded, so multiple virtual servers on a single physical server are generally configured to support different messaging services or authentication needs, rather than to increase scalability.

• All virtual servers on a physical server must belong to the same routing group. A single physical server can't cover more than one routing group.

Whether a physical server hosts one or more than one virtual server, each virtual machine is defined and distinguished by its own name, as well as its own configuration information, including IP address, port number, access settings, and message limits. The server is, by default, named Default SMTP Virtual Server, but it's easy to change the name to something more expressive with a right-click and the Rename command.

Note: To view a virtual server, open the Exchange Management console and then expand, in turn, the Servers node, the Exchange server on which the virtual server resides, and then the Protocols and SMTP nodes under the server name.

As shown in the following graphic, each virtual server includes three components: domains, current sessions, and the queues used for message handling and delivery.

The virtual server The virtual server itself is, of course, the primary SMTP component. It's the one through which administrators set and control such parameters as IP address, logging format, access restrictions, number of concurrent connections, message size, number of recipients per message, and directory used for "bad mail" (messages whose destination can't be determined and which thus provoke a non-delivery report, or NDR). The following illustration shows the Properties sheet and some of these items for the default SMTP server installed by Exchange.

Current sessions The Current Sessions node under each virtual server displays information about users. This information includes user, source location, and connection time for each session. Right-clicking the Current Sessions node also allows the administrator to use the Terminate All command if necessary.

Queues SMTP queues include pre-categorizing and pre-routing queues, as well as queues for messages to be delivered. Some queues, such as the one for delivery to the local domain, are static. Queues for outgoing mail, however, are dynamic, depending on where the messages are to be delivered. Administrators can administer both queues and the messages within them, and can also use queues as a means of resolving bottlenecks and other problems related to message flow in the organization.

Directories Although the term directories is used in this section, the objects of attention here are collections of messages, not Active Directory services information. Think of these directories as file folders.

The Exchange Management console doesn't display directories the way it displays domains and queues, but directories are nonetheless critical to message processing and delivery. Each time an SMTP virtual server is created, Exchange creates a folder for it. This folder is given the name vsi followed by a number. Thus, the default SMTP virtual server is assigned folder vsi 1, and folders vsi 2, vsi 3, and so on are assigned to additional virtual servers. Each vsi folder holds three default directories for its virtual server. These are:

• Badmail, for undeliverable messages. These are the messages that prompt the SMTP service to return the message to the sender along with an NDR. If the NDR can't be delivered, the message is sent to Badmail purgatory.

• Pickup, for outgoing RFC 822-formatted messages created as text files. Messages in this folder are picked up by SMTP and sent on for delivery.

• Queue, for messages that can't be delivered immediately. SMTP attempts to resend messages in the Queue directory at designated intervals.

SMTP Configuration Options

For each SMTP virtual server, administrators can control a number of options, which fall into the four broad categories identified by the tabs on the server properties sheet. These categories are:

• General

• Access

• Messages

• Delivery

The General tab The General tab covers properties of the server itself - its identity in terms of port number and IP address, the type of logging (the same as other IIS services) for messages handled by the server, and both the number of concurrent connections and the timeout period for each connection.

The Access tab The Access tab covers properties related to security and message relay. This is where, for example, administrators can restrict access to the SMTP port by

• Requiring authentication.

• Associating a certificate with the server.

• Allowing (and disallowing) connections from specific computers, as identified by IP address, subnet, or domain name.

In addition, the Access tab offers control over e-mail itself. Although the Windows 2000 SMTP server restricts message relay to authenticated users, administrators can use the Access tab to extend service to additional users through specification of, again, IP addresses, subnets, or domain names.

Conversely, the Exchange default allows anyone to relay messages through the SMTP server because Exchange installations are typically intranet rather than Internet. This behavior, however, opens the door to junk mail and spoofing (pretending to be someone else, or rather, someone else's computer). To give administrators control over such nuisances, the Access tab can be used to set up the virtual server to disable message relaying from any but a known host, as identified by its IP address, group IP address, or domain name.

The Messages tab Because SMTP server resources are so valuable, messages and message sessions have, by default, the following size and scope limits:

• Message size: 2048 KB

• SMTP session size: 10,240 KB

• Messages per connection: 20

• Recipients per message: 64,000

Messaging needs, however, vary with the organization, and so administrators can adjust these default values to customize Exchange performance and functionality. One organization, for example, might find it necessary to reduce the number of recipients per message to maintain optimal network performance.

Note: If the number of recipients exceeds the number allowed, the Exchange routing engine generates multiple copies of the message. For example, if 100 recipients are allowed and a message is addressed to 200, the routing engine would send one copy to the first 100 allowed individuals, and a second copy to the remaining 100 recipients. All recipients, however, would be listed on both copies.

Similarly, because additional connections are opened when the number of messages exceeds the number of connections, another organization might need to adjust the number of messages per connection to optimize network load or compensate for restricted bandwidth.

Finally, the Messages tab is also the place where administrators can specify the Badmail directory, tell Exchange whether and where to forward undeliverable messages, and where to send NDR reports.

The Delivery tab Message delivery is, of course, the reason SMTP exists in the first place. Delivery is not, however, a simple process of sending bits or bytes to a port and assuming they'll arrive as intended. Although SMTP does attempt to deliver a message immediately, there are times when a connection is down or the network experiences some temporary problem. The Delivery tab allows administrators to configure the server to handle such circumstances. Among the options on this tab are the ability to specify - for both local and remote deliveries - the number of delivery retries and the delay and expiration periods before Exchange sends an NDR to the sender.

The Delivery tab is also where administrators can set authentication and encryption requirements for outgoing connections to other SMTP servers and define both the number of connections and timeout (in minutes) for outbound connections.

And, finally, advanced properties on the Delivery tab allow for the following:

• Setting the maximum number of hops (to prevent messages from looping through the system) before an NDR is issued.

• Setting a masquerade domain, a domain name that replaces the local domain name on the Mail From line in the SMTP protocol.

• Identifying a smart host, which is a remote server that, as described in the "Reaching Other Systems" section of this chapter, both receives all outgoing messages from the SMTP server and takes responsibility for delivery.

• Enabling reverse DNS lookup on the addresses of incoming messages to verify the identity of the message sender.

Inside SMTP

Although administrators are not involved in the actual - electronic - message packaging, routing, and delivery, it certainly doesn't hurt to know what goes on inside the SMTP engine.

Exchange Extensions to SMTP

The basic SMTP support installed as part of Windows 2000 is designed to enable the operating system and other products to take advantage of a known transport for tasks such as replication (Windows) and document notification (Microsoft Office 2000). When Exchange is installed, it

• Adds a secondary store drive, DRVIIS.DLL, which provides for message pickup and "drop off" through communication with the information store by way of EXIPC.

• Installs a routing engine designed to enhance routing capabilities with link-state information (near real-time next-hop information about server availability) that allows cost-effective, efficient delivery between routing groups.

Exchange also extends SMTP functionality in several areas, including

• Additional command verbs that support transmission of link state information between servers.

• An advanced queuing engine that manages message-delivery queues.

• A message categorizer (a plug-in component of the advanced queuing engine) that determines where messages are to be delivered and, additionally, expands distribution lists.

Inbound Message Flow

All told, Exchange uses SMTP for three functions: as a protocol for client messages, for routing messages from server to server, and for exchanging replication and other information, as mentioned earlier.

The various SMTP components are the pieces required to ensure a smooth, reliable flow of messages. Essentially, these components work together as follows for incoming messages:

1. When a message arrives, the IIS SMTP server creates an envelope for it - a message structure called IMAILMSG.

2. On successful receipt of the message, the SMTP server writes both the envelope and the message to disk, in a Queue directory, with the help of the NTFS store driver.

3. The message is then handed over to the advanced queuing engine, which places the message in a pre-categorizing queue (PreCatQueue) and then sends it on to the message categorizer.

4. The message categorizer determines where the message is to be delivered and, if necessary, expands the message's distribution list. After determining whether the message should be sent to the local store, the Message Transfer Agent (for non-SMTP delivery), or the SMTP engine, it returns the message to the advanced queuing engine.

5. The advanced queuing engine places the message in a pre-routing queue (PreRoutingQueue) until its delivery route can be determined and sends the destination to the routing engine.

6. The routing engine now responds with a next-hop identifier for the message's destination (or the next stop in a multiple-hop destination).

   Finally, armed with destination information from the message categorizer and routing information from the routing engine, the advanced queuing engine sends the message on for delivery.

   • If the destination is a local domain, the Exchange store driver (on the store side of EXIPC) picks up the message and delivers it to the information store or, if so instructed by a custom application, to a drop directory specified by the administrator.

   • If the destination is remote, the message is passed along to SMTP for outbound messages or handed to the Message Transfer Agent for delivery.

Outbound Message Flow

Outgoing messages follow somewhat the same "route" as inbound messages, at least where the message categorizer and advanced queuing engine are concerned. The initial steps differ, however. Briefly, this is what happens:

1. The client submits a message to the information store.

2. The information store moves the message to a SendQ folder and informs the store driver.

3. The store driver picks up the message, constructs an IMAILMSG envelope, and hands it off to the advanced queuing engine.

4. At this point, the advanced queuing engine goes through the steps of sending the message to the message categorizer and routing engine to determine where and how the message should be delivered.

5. If the message is destined for the local store, it is now placed in the local delivery queue and delivered.

6. If the message is to be delivered to another server, it is placed in the appropriate queue for its destination identifier and linked with a connection to the next hop on its journey.

Message Routing

Understanding message flow within Exchange and Windows enhances understanding of the reliability, flexibility, and performance of these products. But although message delivery can begin and end with the local store and a single Exchange server, it often - perhaps usually - doesn't. Other servers, other mail systems, and even the Internet come into play. All told, Exchange messages can be routed from sender to receiver

• On the same server.

• In the same routing group.

• Between routing groups.

• To a server outside the Exchange organization.

This section of the chapter begins with an overview of these four delivery methods. The remaining sections then describe when multiple routing groups are needed, the types of connectors used in delivering mail outside a single routing group, and the new Exchange 2000 use of link state information for propagating network status and delivery information between routing groups.

Delivery on the Same Server

Routing, or rather delivery, when both the sender and the recipient are on the same server is a simple affair: client to server to recipient by way of the recipient's mailbox in the local store. The process can be diagrammed as a straight line from A to B, with a transfer from sender to recipient taking place at the Exchange server, as shown in the following illustration.

Delivery in the Same Routing Group

When the message sender and the message recipient are on different Exchange servers, but still within the same routing group, the delivery process becomes more involved, in that a second server, the recipient's mail server, becomes part of the process. An additional difference is related to the protocol used to send the message: If the recipient's mailbox resides on an Exchange 2000 server, SMTP is used; if the recipient's mailbox is on an Exchange 5.5 server (in an installation still running in mixed mode), the older remote procedure call method is used.

In either case, however, message transfer is still a straight-line, point-to-point communication between the sending and receiving servers, as shown in the following illustration.

Delivery to a Different Routing Group

When the sender and recipient are in different routing groups, message delivery becomes yet more involved, in that the actual route might require multiple hops through intervening routing groups between the sending and receiving servers.

When an Exchange server needs to deliver a message to a different routing group, it does so in three steps:

1. It determines that the recipient is, in fact, in a different routing group.

2. It consults link state information and identifies a route for delivery.

3. It sends the message to the connector linking it either to the receiving routing group itself or to the next routing group in the path it has identified.

Note: Exchange 2000 supports three routing connectors: Routing Group Connectors, SMTP Connectors, and X.400 Connectors. To keep from wandering off the "how Exchange routes messages from A to B" path, these connectors, as well as information on the link state database, are described later in the chapter in the sections "Connectors Linking Routing Groups" and "Link State Information."

In terms of actual delivery, if the sending server has been configured as a routing server, it has the ability to open a connection to the next routing group and send the message directly to a routing server in that group.

Message delivery between routing groups is shown in the following illustration.

Delivery Outside the Organization

Message delivery outside the Exchange organization is similar to delivery to another routing group, in that a connector is needed as a "pipeline" to the other server. In this case, however, even though the message might travel from one routing group to another, its destination lies in another organization or on a foreign messaging system. When it sends messages outside the organization, Exchange Server follows these procedures:

1. If it doesn't find the recipient listed in Active Directory services, it resolves the address by finding a connector that can be used to transmit the message.

2. It then sends the message to a routing server in the same routing group.

3. The routing server then either sends the message over the appropriate connector or, if the connector is in a different routing group, sends the message to the other routing group.

4. When a routing server receives the message, it transfers the message to the server hosting the connector being used for transmission.

This last form of delivery is shown in the following illustration.

Single vs. Multiple Routing Groups

Routing groups in Exchange 2000 are the topological equivalent of the Exchange 5.5 site concept, in that each routing group represents a collection of well-connected servers that can communicate over fast, permanent, and reliable connections. Message transfer is point-to-point, with each server able to transfer information directly to another server in the group.

Although network reliability is the most important criterion in defining a routing group, it's not the only one. There are three additional factors that apply to any routing group. All of the servers in the routing group must

• Be part of the same forest.

• Be linked by permanent SMTP connections.

• Be able to communicate with the server designated as routing group master. (As described in the "How It's Used" section of this chapter, this is the server in charge of tracking and propagating link state information within the group.)

Because Exchange assumes that all servers within a routing group do rely on high-speed, permanent connections, Exchange 2000 doesn't attempt to optimize use of network bandwidth.

So, when does an organization need one routing group, and when does it need more than one? Obviously, if the organization includes only a single group of servers and those servers can rely on reliable, high-bandwidth, permanent connections, one routing group is all that's required. If, however, any of the following factors apply, multiple routing groups may become necessary:

• Network connections don't provide the connectivity required.

• Problems often afflict the underlying network.

• A multi-hop path rather than a single-hop path is required for message transmission.

• Message transmission must be scheduled between different locations.

• Routing group structure controls client connections to public folders.

Connectors Linking Routing Groups

Exchange relies on connectors to route messages reliably and efficiently, both within and outside the organization. The primary (preferred) means is the Routing Group Connector, which, as the name states, connects two routing groups. Exchange 2000 does, however, also support an SMTP Connector and an X.400 Connector, both of which also provide connectivity to non-Exchange systems or (in the case of the SMTP Connector) to the Internet.

Routing Group Connectors

Routing Group Connectors are more or less the bread-and-butter pipelines that Exchange relies on for linking routing groups. These connectors are both efficient and easy to set up. Although the base transport is SMTP and these connectors consult the (new) link state database for routing information, in other respects Routing Group Connectors resemble the Site Connectors used in Exchange 5.5. In fact, a Routing Group Connector can be used to connect an Exchange 2000 routing group with an Exchange 5.5 site and, when used, will automatically revert to using the Message Transfer Agent and remote procedure calls when it determines that it's transmitting to the non-Exchange 2000 site.

Within a routing group, a Routing Group Connector can be configured to use zero, one, or multiple bridgehead servers (the servers that actually handle transmission of messages between routing groups). Differences between these approaches are as follows:

• If no such server is designated, all of the servers in the routing group act as bridgehead servers for message transmission.

• If one bridgehead server is defined, all mail flows through it and the administrator thus has control over such aspects of messaging as tracking and archiving.

• If multiple bridgehead servers are defined, the routing group gains in two areas: load balancing and stability. With multiple servers defined, if one goes down, Exchange can always find and use a server for message transmission.

Where configuration and use of Routing Group Connectors are concerned, administrators have the ability to control

• Connection schedules.

• Message priority (high, normal, or low).

• Message size limits.

Finally, as already mentioned, Routing Group Connectors are easy to set up. Although they are unidirectional and must be configured in pairs (inbound and outbound), the Exchange System Manager can automatically configure the required second connector when the first is set up. The following illustration shows the window used in creating a new Routing Group Connector.

SMTP Connectors

Both Routing Group Connectors and SMTP Connectors obviously use SMTP as the transport protocol. So why does Exchange offer both, even though either one can be used to connect routing groups? There are several answers, based on a number of differences between the two connectors.

Overall, even though Routing Group Connectors are the preferred (and recommended) method for linking routing groups, SMTP Connectors can be used for

• Connecting an Exchange organization with SMTP-compatible but non-Exchange systems, as well as with the Internet.

• Connecting independent Exchange forests within an organization.

• Creating more finely tuned connections between Exchange routing groups. SMTP Connectors can, for example, allow TLS encryption and authentication of remote domains before message transmission. It is also possible to configure an SMTP Connector to retrieve mail at specified times from a queue held for delivery on a remote server.

Reaching other systems Unlike Routing Group Connectors, SMTP Connectors rely on either a DNS mail exchanger (MX) record or a smart host for message transmission.

A mail exchanger record, used in sending messages to a non-Exchange system, points Exchange to one or more servers in the foreign system. Given this information, the SMTP Connector can then connect and send mail to the server or servers identified in the record.

As for smart hosts (as shown in the following illustration), one of the options available in configuring an SMTP Connector is the ability to designate a smart host by its fully qualified domain name or by its IP address. This smart host is a remote server to which the Exchange server can transmit messages intended for a particular remote domain or routing group. Essentially, the smart host acts as a relay station, in that the Exchange server sends mail to the smart host and it, in turn, takes responsibility for using DNS to send the mail on to its destination.

Specifying a smart host eliminates the DNS lookup that would otherwise be performed on all outgoing mail addresses.

MAPI and mail going to non-Exchange systems Within or between Exchange organizations, Microsoft Outlook (that is, MAPI) clients can rely on Rich Text Formatting (RTF) to include advanced formatting, as well as message options including calendar and task information. Exchange supports RTF by default by encapsulating RTF in a form known as Transport-Neutral Encapsulation Format, or TNEF. This encapsulated formatting is then included with the message as a MIME attachment called WINMAIL.DAT and sent over SMTP to the destination server. If the destination server is an Exchange server, it uses the RTF attachment to render the content correctly for the message recipient.

When such an encapsulated message is sent outside the Exchange organization, however, the information encapsulated in WINMAIL.DAT may not be readable, and other attachments included with the message might be lost.

Exchange 5.5 and the SMTP Connector The Exchange 2000 SMTP Connector is comparable to the Internet Mail Service in earlier versions. In fact, in systems upgraded from Exchange 5.5, the Internet Mail Service is turned into an SMTP Connector, and Internet Mail Service address spaces are added to a single SMTP Connector. Although it's possible that not all information will transfer over, the Exchange upgrade log will provide details on any such "lost" information.

X.400 Connectors

Like the SMTP Connector, an X.400 Connector can be used to link two Exchange routing groups. Unlike either the Routing Group Connector or the SMTP Connector, the X.400 Connector is also used to link an Exchange routing group with an X.400 messaging system.

Using an X.400 Connector between routing groups can be desirable in two situations:

• When X.400 is the only connectivity available

• When there is very little bandwidth available between the two routing groups

When an X.400 Connector is used between routing groups, one bridgehead server in each routing group provides the communication link.

Before an X.400 Connector can be established, however, an X.400 transport stack needs to be configured. There are three choices, depending on which underlying protocol is being used:

• A TCP/IP X.400 transport stack, if the connector will be running over TCP/IP - as, for example, when the connector is used over the Internet

• An X.25 X.400 transport stack, if the connector will be running over X.25

• A Dynamic RAS X.400 transport stack, if the connector will be relying on Remote Access Service and a dial-up modem

Communicating with Other Mail Systems

In the real world, or at least the online version of it, two facts hold true: First, everybody loves e-mail; second, not everybody uses Exchange. Furthermore, because people rather messily refuse to limit their electronic communication to only those who use the same mail system, it's up to Exchange to offer ways for people to communicate with whomever they choose.

So, of course, Exchange supports mail over the Internet, as can be seen from its use of SMTP as a native transport. And, it supports communication with X.400 systems. And, for those who rely on other mail systems, Exchange supports connectors to:

• Lotus Notes

• cc:Mail (which Lotus recently decided not to continue developing but which remains a player in the e-mail universe)

• Novell GroupWise

• Microsoft Mail

Link State Information

Now, after all this description of connectors and routing groups, it's time to take a fairly detailed look at the database that makes message routing and delivery economical and efficient: the link state table.

What It Is

To begin with, however, what's a link state? It sounds important, but at first glance the name doesn't really describe much about what it does. But that's just at first. When you examine the two parts of its name separately and then combine them, everything becomes crystal clear.

Whenever multiple routing groups are configured in an organization, those routing groups rely on links over which they route messages. There's part of the name. Now, each link can be in either of two states: UP (available) or DOWN (unavailable). Put the two together, and you have a term that describes the status of the connection between routing groups. The only part of its duties that its name doesn't mention is that this information on routing connections is near real-time, that it resides in a database table, and is propagated to all of the servers in the messaging system.

Why It's Needed

Exchange 2000 implements link state tables to provide all servers in the system with the vital information that allows them to determine:

• The cheapest route to delivery, in terms of the cost associated with each link in the route. (Cost here doesn't represent a financial value, but rather a preference that enables the system to determine the most efficient route. The lower the cost, the more desirable the route - kind of like "on a scale of 1 to 10, with 1 being the best….")

• Whether any link in a proposed route is not functioning.

This information, or rather the link state tables that contain the information, is based on a link propagation protocol known as the link state algorithm, or LSA. This algorithm is, in turn, based on the Open Shortest Path First (OSPF) algorithm used by network routers. Unlike OSPF, however, which runs at the very low network level of the OSI model, the link state algorithm operates at a higher level and is thus freed of reliance on the network infrastructure and low-level protocols.

Because the link state algorithm takes responsibility for telling the entire messaging system the current state of (link) affairs, it ensures that

• Each Exchange server has access to the information it needs to determine the best, most reliable route to a destination instead of simply sending a message along a route that, potentially, could include a nonfunctioning link.

• Messages do not "ping-pong" between servers, because each server is aware of alternate or redundant links, as well as their current state (UP or DOWN).

• Message looping - hop after hop after hop around the system - doesn't occur.

How It's Used

Link state information is most valuable in an Exchange messaging system that includes a number of routing groups with multiple available paths between and among them. At the heart of this system (mail delivery-wise) is a special server in each routing group that has been designated the routing group master. This master

• Receives and keeps track of link state information, for example, a "link down" message from a server in its routing group.

• Propagates that information to the other servers in its routing group.

Non-master servers are required to send new link state information to the master immediately, and the master in turn takes care of broadcasting that information to other servers. The method of propagating link state information depends on whether the information is being transmitted within or between routing groups.

• Within a routing group, the information moves between the routing group master and the other servers over TCP port 3044.

• Between routing groups, information travels through TCP port 25 over SMTP and is transferred ahead of any messages waiting for delivery.

As for the link state information itself, it's gathered and distributed in two ways:

• Within a routing group, servers report link state information to the routing group master and the master, in turn, immediately sends that information to the other servers in the routing group.

• Both within and between routing groups, servers transferring messages over SMTP compare link state information through an Exchange 2000 SMTP command verb that enables them to compare link state information and to update it as well. In addition, where X.400 Connectors are used to connect routing groups, the X.400 protocol has been extended in Exchange 2000 to enable the connectors to update link state information - either as messages are transferred or through periodic polling.

Finally, when links go down, what happens? This is the sequence of events:

1. To start, before a link is actually listed as nonfunctional, the server attempting to send a message over the link retries three times at one-minute intervals.

2. If, after those three tries, a connection still can't be made, the link is tagged as DOWN and the server notifies the routing group master.

3. The routing group master, in turn, immediately notifies all the other servers in the routing group.

4. The bridgehead server in the routing group calculates an alternative route to the message's destination.

5. The link DOWN information is propagated to the bridgehead server in the routing group that will receive the message and attempt to send it over the alternate route.

6. The bridgehead server in this routing group contacts its routing group master and informs it of the problem.

7. This routing group master, like the one in the group that originally noticed the problem, spreads the word to all servers in its group.

8. The link DOWN status is propagated to succeeding routing groups along the route to the message's final destination.

9. Meanwhile, back at the original routing group, the bridgehead server continues to try and connect over the down link every 60 seconds. When a connection is finally made, the bridgehead notifies its routing group master, and the routing group master notifies its servers that the link is once again available for use.

And that ends this overview of message flow, both within Exchange and to potentially every part of the world. If any part of Exchange can be considered its heart, the architecture, protocols, and supporting software described in this chapter must be it. They are, after all, what make Exchange a messaging and collaboration tool for organizations ranging from small businesses to enormous enterprises.