Concepts and Planning | << | >> |
---|
Messages sent to recipients in other sites or systems are delivered through connectors. To determine which connectors to use, how many connectors to use, and how to configure them for efficient delivery, you need to understand how routing works. The Microsoft Exchange Server MTA can route messages to:
Two processes are used to determine which connector a message is sent through: routing determines all the connectors that can deliver the message; selection determines the most efficient connector to use.
Connectors and the Internet Mail Service are used to create paths for messages to be sent outside a site. These paths are represented by address spaces. An address space is a set of address components used by a connector or service to identify messages that it is responsible for processing.
Messages to other systems are routed through the appropriate address for the system, such as an SMTP address for a message traveling through the Internet. Each connector has at least one address space and can have one or more connected sites associated with it. You define address space and connected sites information by using the Address Space and Connected Sites property pages in the Microsoft Exchange Server Administrator program. These associations create the Gateway Routing Table (GWART). The GWART is replicated throughout the organization, so each server is aware of all possible routes.
When a message is sent, the MTA compares the recipient's address type with data in the GWART to determine the connectors that can deliver the message. There are three groups of address types:
Distinguished Name (DN) This address type is only searched when a DN for
the recipient is found in the directory. This Microsoft Exchange Server address
type is EX.
Domain Defined Attribute (DDA) The DDA is the format for a custom recipient address. The address types MS and SMTP are created automatically. However, other DDA addresses can be used with custom or third-party gateways.
Originator/Recipient (O/R) Address This is the X.400 address. The address type is X400.
Each line of the GWART indicates an available path that the MTA can use to route messages. The MTA scans the GWART to find an address space that matches the recipient's address and chooses connectors with address spaces similar to the recipient's address. You can view the contents of the GWART, including the address type each connector routes, in the Routing property page of the Site Addressing object as shown in the following illustration.
If more than one connector can send the message, a connector selection process determines the most efficient connector to use. If no connectors can service the address space, the message is returned to the originator with a non-delivery report (NDR).
A selection process is used to identify the connector that can most efficiently deliver the message. Each time a connector or group of connectors meets the connector selection criteria, it is passed to the next step. Each of these steps applies to MTA-to-MTA connections, which include the X.400 Connector, the Dynamic RAS Connector, and the Site Connector. Connectors and gateways for foreign systems are chosen based only on the address spaces they process and the address space cost. Although Microsoft Exchange Server is designed to make routing decisions automatically, you can influence which connectors are chosen by adjusting specific connector settings used in the process.
The flow chart at left shows the steps the MTA uses to select a connector:
Comparing open retry count to max open retries The open retry count is the number of times the MTA has attempted to transfer a message through a specific connector. Max open retries is a setting on each connector (except foreign system connectors) that specifies the number of times a message can attempt to be transferred through that connector. Connectors that have an open retry count less than the max open retry value are chosen.
Choosing active connectors Site Connectors, Internet Mail Services, and Microsoft Mail Connectors are always active. X.400 Connectors and Dynamic RAS Connectors have activation schedules that have four settings: active now, active in the future, never active, and remote initiated.
All active connectors are chosen first; a group of connectors that will become active is chosen next. If no connectors are active and none will become active, connectors that are initiated remotely are chosen.
Choosing connectors with low retry counts The open retry count starts when the connection to the remote MTA fails. The connector attempts to establish the connection again when the open retry timer expires. The number of times the connector attempts the connection is based on the configuration of the max open retries setting. The open retry counters are compared with each other, and connectors with the lowest number of open retries are chosen.
Choosing connectors that have not failed Each MTA maintains an open retry timer for each connector that is on the same server. Connectors on other servers skip this step. The open retry timer begins as soon as a connection fails. Any connector that is not in a retry state is chosen. The open interval value determines how long the connector waits before attempting the connection again. This prevents the MTA from routing a message to a connector that failed the last time it tried to establish a connection.
For example, if you are using a Site Connector and Dynamic RAS Connector and the LAN is down, a message is routed to the Site Connector because it has a lower cost. The connection fails because the LAN is down so the message is routed to the Dynamic RAS Connector. The next message to arrive before the open retry timer expires on the Site Connector is routed directly to the Dynamic RAS Connector.
Comparing costs You specify costs when the address space is determined for each connector. Connectors with the lowest cost are chosen first. For more information, see "Routing Costs," later in this chapter.
Choosing local connectors A local connector can send the message directly to the remote site, as in a messaging bridgehead server. Remote connectors require the MTA to pass the message to a messaging bridgehead server before the message can be passed to the remote site. Using local connectors reduces the need for the additional processing power and increased bandwidth required to transmit the message.
If more than one connector is chosen to deliver a message, load balancing is implemented. In load balancing, one of the connectors is chosen randomly, rather than by queue size, message size, or other variables.
In the case of the Site Connector, if more than one Site Connector is selected, the MTA chooses a connector based on cost. Target MTAs with a cost of 0 are tried first, and target MTAs with a cost of 100 are tried last. Random selection is used only after all target MTAs with a cost of 0 have been tried. All target MTAs are tried before the message is rerouted. You can influence which Site Connectors are used more frequently by adjusting the cost value assigned to each connector. A connection cost is not a dollar amount; instead, it represents the desirability of one route compared to other routes.
If the message is not sent to the connector, the MTA attempts to reroute the message. When a message is rerouted, the MTA performs routing and selection again to find the most efficient connector.
When a message is sent to a connector or gateway for a foreign system, such as the Microsoft Mail Connector or the Internet Mail Service, the MTA considers the message delivered when it reaches the connector. Rerouting does not occur, even if the foreign system connector cannot deliver the message.
A message routed to a connector with an activation schedule of never active or remote initiated is not rerouted unless the activation schedule is changed while the message is waiting to be delivered.
The max transfer retries and transfer interval settings in the Override property page for the Site Connector, Dynamic RAS Connector, and X.400 Connector determine how many times and at what intervals the MTA sends a message through the connector. A retry count is stored on each message for each connector that has been tried.
When a message is routed to a connector that fails to connect to the other MTA, the retry count is incremented and the message is immediately rerouted. If the message cannot be delivered after all connectors have been tried, the message is returned with an NDR.