Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Managing Message Transfer and Routing Within the Organization

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 : September 4, 2001

from Chapter 12, Microsoft Exchange 2000 Administrator's Pocket Consultant by William R. Stanek.

Every Microsoft Exchange 2000 Server administrator should have a solid understanding of message transfer and message routing. The X.400 message transfer agent handles message transfer, both within the organization and to servers outside it—unless you configure a different connector. The Message Transfer Agent (MTA) provides the necessary addressing and routing information for sending messages from one server to another; it's the functional equivalent of the Microsoft Exchange Message Transfer Agent used in previous versions of Exchange Server. The MTA relies on X.400 transfer stacks to provide additional details for message transfer. The purpose of X.400 stacks is similar to that of the Exchange virtual servers used with Simple Mail Transfer Protocol (SMTP), Post Office Protocol 3 (POP3), and Internet Message Access Protocol 4 (IMAP4).

Messaging settings for the MTA determine how connections are made, when transfer timeouts occur, and more. The MTA doesn't manage message delivery, however. Message delivery is handled by SMTP or other mail transfer protocols.

Message routing within the organization is managed either by Exchange Server itself or manually by the administrator. When you add an Exchange server to an organization and place it in an existing routing group, Exchange 2000 Server automatically configures the connection between the new server and other servers in the routing group. If you have multiple routing groups, however, Exchange 2000 Server doesn't configure connections between the routing groups. You must manually connect two routing groups using Exchange connectors.

Three types of routing group connectors are available:

  • Routing group connectors

  • SMTP connectors

  • X.400 connectors

Routing group connectors are preferred because they're the easiest to configure. For fault tolerance and load balancing, you can configure multiple connectors between routing groups. The key to load balancing is to use the same routing cost for all connectors that form the messaging link.

Configuring the X.400 Message Transfer Agent

Proper configuration of the X.400 message transfer agent is essential to the smooth operation of Exchange Server. The MTA handles message transfers to the Internet and to servers within the organization. The values you set for the MTA become the default values for other X.400 connectors used within the organization as well. Keep in mind that the MTA isn't responsible for message delivery, which is handled by SMTP or another messaging protocol.

Setting Local MTA Credentials

The local MTA credentials set the local X.400 name and an optional password for a server. The X.400 name identifies the MTA to foreign systems, and if you don't provide an alternate name, the setting defaults to the name of the server. The X.400 password provides a password that other servers use when connecting to the X.400 agent. Use a password when you want to prevent unauthorized servers from connecting to the MTA.

You usually won't need to change the MTA credentials. However, if you want to identify the server using different credentials, you'll need to update the related settings by completing the following steps:

  1. Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.

  2. Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.

  3. Right-click X.400, and then select Properties. This displays the X.400 Properties dialog box shown in Figure 12-1.

  4. The Local X.400 Name field shows the current setting for the X.400 name. Click Modify. Type a new X.400 name, and then, if desired, type a password in the Password field and the Confirm Password field.

  5. Click OK twice.

    Note: The X.400 name can be up to 32 characters. The X.400 password can be up to 64 characters.

    Cc722520.exch1201(en-us,TechNet.10).gif

    Figure 12-1: . Use the General tab of the X.400 Properties dialog box to set the Local X.400 Name and other message options.

Expanding Remote Distribution Lists and Converting Messages

The X.400 MTA has limited control over how incoming messages are handled. You can configure whether remote distribution lists are expanded and whether incoming messages are converted to Exchange contents.

Expanding remote distribution lists makes the lists available to users on the local server. This is the optimal setting and is enabled by default. Only in rare circumstances, when you want to expand lists elsewhere, should you disable this option.

Converting incoming messages changes the message addressing and contents to a form compatible with Exchange and Messaging Application Programming Interface (MAPI) clients. If you experience problems with message addressing from foreign systems, you may want to enable this option temporarily to see if this resolves the problem. Otherwise, this option is usually disabled.

To change these messaging settings, follow these steps:

  1. Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.

  2. Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.

  3. Right-click X.400, and then select Properties. This displays the X.400 Properties dialog box shown in Figure 12-1.

  4. Select Expand Remote Distribution Lists Locally to make remote lists available. Or clear this field to disable this option.

  5. Select Convert Incoming Messages To Exchange Contents to convert incoming message contents. Or clear this field to disable this option.

  6. Click OK.

Setting Connection Retry Values for X.400

Connection retry values for the X.400 MTA play a key role in determining how Exchange Server connects to other servers and how messages are transferred. Retry values do not, however, control message delivery. Message delivery is controlled by the messaging protocol.

You can configure four message retry values. These values are:

  • Maximum Open Retries Controls the maximum number of times Exchange Server tries to open a connection before failing and generating a nondelivery report. The default is 144 retries.

  • Open Interval Controls the number of seconds Exchange Server waits before attempting to reopen a failed connection. The default is 600 seconds.

  • Maximum Transfer Retries Controls the maximum number of times Exchange Server tries to transfer a message across an open connection before failing and generating a nondelivery report. The default is two retries.

  • Transfer Interval Controls the number of seconds Exchange Server waits before attempting to resend a message across an open connection. The default is 120 seconds.

Based on these values, a typical connection looks like this:

  1. Exchange Server attempts to open a connection to the destination mail system. If it's unable to establish a connection, Exchange Server waits for the open interval and then tries to open a connection again—as long as the maximum retry value hasn't been reached. If the maximum retry value has been reached, Exchange Server generates a nondelivery report that gets returned to the sender.

  2. Once a connection has been established, Exchange Server attempts to transfer the message. If it's unable to transfer the message, Exchange Server waits for the transfer interval and then tries to transfer the message again—as long as the maximum retry value hasn't been reached. If the maximum retry value has been reached, Exchange Server generates a nondelivery report that gets returned to the sender.

To view or change connection retry values for the X.400 MTA, follow these steps:

  1. Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.

  2. Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.

  3. Right-click X.400, and then select Properties. This displays the X.400 Properties dialog box shown in Figure 12-1.

  4. Click the Messaging Defaults tab. You'll see the current connection retry values. You can enter new values or click Reset Default Value to restore the default connection values.

  5. Click OK.

    Note: The default connection retry values are less than optimal in many situations, and you can often improve the performance of Exchange Server by adjusting these values for your environment.

Setting RTS Values for X.400

Reliable transfer service (RTS) values for the X.400 MTA play a key role in determining how Exchange Server transfers message data. You can configure three RTS values. These values are:

  • Checkpoint Size (KB) Controls the amount of data Exchange Server transfers before performing a checkpoint. If the checkpoint results in an error being generated, Exchange Server restarts the message transfer from the most recent checkpoint. The default value is 15 KB.

  • Recovery Timeout (Sec) Controls the amount of time Exchange Server waits for a broken connection to be reestablished. If the wait exceeds the timeout value, Exchange Server restarts the message transfer. The default value is 60 seconds.

  • Window Size Controls the maximum number of unacknowledged checkpoints that can occur. If this value is exceeded, message transfer is suspended. The default is five.

Based on these values, a typical data transfer looks like this:

  1. Exchange Server begins transferring data across an open connection. The transfer continues until a checkpoint is reached. After performing a checkpoint (and assuming an error didn't occur), Exchange Server continues the data transfer.

  2. If the checkpoint is acknowledged, Exchange Server resets a counter tracking the current window size against the maximum value allowable. If the checkpoint isn't acknowledged, Exchange Server increments the tracking counter. Anytime the value of the counter exceeds the maximum allowable window size, an error occurs.

  3. If an error is generated at the checkpoint, the transfer stops and Exchange Server waits for the recovery timeout interval before restarting the message transfer from the most recent checkpoint that was acknowledged.

To view or change RTS values for the X.400 MTA, follow these steps:

  1. Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.

  2. Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.

  3. Right-click X.400, and then select Properties.

  4. Click the Messaging Defaults tab, and then click Additional Values. As shown in Figure 12-2, the RTS Values panel displays the current RTS values. You can enter new values as necessary or click Reset Default Values to restore the default settings for RTS, association parameters, and transfer timeouts.

    Tip If you have an unreliable connection, you may want to decrease the checkpoint size, which forces Exchange Server to perform checkpoints more frequently. However, you should rarely (if ever) set the checkpoint size to zero. Setting the checkpoint size to zero tells Exchange Server not to perform checkpoints and, as a result, message transfer may become unreliable.

  5. Click OK.

    Cc722520.exch1202(en-us,TechNet.10).gif

    Figure 12-2: . Use the Additional Values dialog box to configure RTS values, association parameters, and transfer timeouts.

Setting Association Parameters for X.400

Association parameters for the X.400 MTA play a key role in determining how Exchange Server handles connections once they've been established. You can configure three association parameters. These values are:

  • Lifetime (Sec) Controls the amount of time Exchange Server maintains an association for a remote system. A key property of the association is the identification of an open connection to a remote system. If the lifetime expires, the association is terminated but the related connection isn't broken until the disconnect period expires. The default value is 300 seconds.

  • Disconnect (Sec) Controls the amount of time Exchange Server waits before disconnecting a connection that no longer has an association. Typically, you want connections to remain open for a short period after the association is terminated. The default is 120 seconds.

  • Threshold (Messages) Controls the maximum queue size for each association. When the number of queued messages for the association exceeds this value, Exchange Server establishes a new connection and creates a new association. The default is 50 messages.

Here's how Exchange Server uses these values to handle open connections:

  1. Exchange Server creates an association for each open connection to a remote system. It creates new associations as new messages enter the queue and new connections are established. It also creates new associations when the number of queued messages to any single remote server exceeds the threshold value.

  2. When there are no more messages to send to a particular remote server, Exchange Server starts tracking the association lifetime. If the lifetime expires, the association is terminated but the connection remains open.

  3. The open connection to the server isn't broken automatically. If a new message is queued for a server whose association was terminated and the connection is still open, Exchange Server creates a new association and transfers the message. Otherwise, the open connection is broken when the disconnect value is reached.

You can view or change association parameters for the X.400 MTA by completing the following steps:

  1. Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.

  2. Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.

  3. Right-click X.400, and then select Properties.

  4. Click the Messaging Defaults tab, and then click Additional Values. The Association Parameters panel displays the current parameters. You can enter new values as necessary or click Reset Default Values to restore the default settings for RTS, association parameters, and transfer timeouts.

  5. Click OK.

Setting Transfer Timeout for X.400

Generating lots of nondelivery reports in a short amount of time can seriously degrade the performance of Exchange Server. To prevent this from happening, Exchange Server doesn't immediately generate nondelivery reports. Instead, Exchange Server generates the nondelivery report based on the message priority, the associated transfer timeout value, and the size of the message. The default transfer timeout values are

  • Urgent 3000 seconds per KB

  • Normal 2000 seconds per KB

  • Not Urgent 1000 seconds per KB

    Note: At first glance, the default values seem reversed. But you'd logically want to allow longer transfer times for urgent messages and shorter transfer times for less important messages. More time may ensure that an important message makes it across an unreliable link.

You can view or change transfer timeouts for the X.400 MTA by completing the following steps:

  1. Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.

  2. Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.

  3. Right-click X.400, and then select Properties.

  4. Click the Messaging Defaults tab, and then click Additional Values. The Transfer Timeouts panel displays the current parameters. You can enter new values as necessary or click Reset Default Values to restore the default settings for RTS, association parameters, and transfer timeouts.

  5. Click OK.

Using Routing Group Connectors

Routing group connectors are the easiest connectors to configure and, as such, they're the preferred connectors for Exchange Server. You use a routing group connector to link two routing groups. These routing groups must be within the same organization. For those of you familiar with previous versions of Exchange Server, this concept is similar to a Site Connector.

Understanding Routing Group Connectors

Routing group connectors establish links between routing groups using one or more designated bridgehead servers. Bridgehead servers act as communication relays for routing groups and you define them both locally and remotely.

Local bridgehead servers serve as the originator of message traffic, and remote bridgehead servers serve as the destination for message traffic. By default, all servers in the originating routing group act as local bridgehead servers. You can, however, select specific servers to act as bridgeheads. Selecting multiple servers as local bridgeheads provides load balancing and fault tolerance, which is essential when high availability is a concern. Selecting a single server as the local bridgehead ensures that all mail flows through the designated server, but it doesn't provide redundancy.

For the routing group connector, delivery options control when messages are sent through the connector. One of the key features is your ability to set connection schedules for all messages or specifically for standard-sized and large-sized messages. If you have a relatively fast and reliable link between the two routing groups, you probably want to set the same delivery schedule for all messages. On the other hand, if you have a relatively slow link between the two routing groups, you may want to set a separate schedule for large messages to ensure that oversized messages don't take all the available bandwidth during peak usage hours.

The routing group connector can deliver messages at many intervals. The interval you use depends on your reliability and availability needs:

  • If you want message delivery to be highly reliable and the link to be highly available, you probably want to set the delivery interval to Always Run or Run Every Hour. You may also want to set a custom schedule that has an interval of every 30 minutes.

  • If you want message delivery to be reliable and available but don't want message delivery to be a priority, you probably want to set the delivery interval to Run Every Two Hours or Run Every Four Hours.

  • If the link is used to distribute message digests or public folder data infrequently, you probably want to set a specific delivery time, such as Run Daily At 11:00 P.M., Run Daily At 12:00 A.M., Run Daily At 1:00 A.M., or Run Daily At 2:00 A.M.

Installing Routing Group Connectors

To install a routing group connector, complete the following steps:

  1. Start System Manager. If Administrative Groups are enabled, expand the administrative group you want to work with.

  2. To install a routing group connector, you must have at least two routing groups in the organization. Expand Routing Groups, and then expand the routing group you want to use as the originator of the connection.

  3. Right-click Connectors, click New, and then choose Routing Group Connector. This displays the dialog box shown in Figure 12-3.

    Cc722520.exch1203(en-us,TechNet.10).gif

    Figure 12-3: . Use the Routing Group Connector Properties dialog box to configure connectivity between two routing groups.
  4. In the General tab, type a descriptive name for the connector.

  5. Choose the destination routing group by selecting it in the Connect This Routing Group With list box.

  6. If you want all servers in the originating routing group to act as bridgehead servers, select Any Local Server Can Send Mail Over This Connector. Otherwise, select These Servers Can Send Mail Over This Connector, and then designate the local bridgehead servers that you want to use by clicking Add, and then selecting servers from the list provided.

  7. In the Remote Bridgehead tab, click Add. You'll see a list of available routing groups and servers. In the destination routing group, select the server that you want to act as the remote bridgehead.

  8. Click OK to install the connector. Later, you may want to set connector cost, delivery options, delivery restrictions, and content restrictions.

Configuring Routing Group Connector Delivery Options

To set the delivery options for an existing routing group connector, follow these steps:

  1. Start System Manager. If Administrative Groups are enabled, expand the administrative group you want to work with.

  2. To install a routing group connector, you must have at least two routing groups in your organization. Expand Routing Groups, and then expand the routing group you want to use as the originator of the connection.

  3. Expand Connectors, right-click the routing group connector you want to configure, and then select Properties.

  4. Click the Delivery Options tab, as shown in Figure 12-4. Use the Connection Time list box to specify the times when messages are sent through the connector. The available options are: Always Run, Run Daily At 11:00 P.M., Run Daily At 12:00 A.M., Run Daily At 1:00 A.M., Run Daily At 2:00 A.M., Run Every Hour, Run Every 2 Hours, Run Every 4 Hours, Never Run, and Use Custom Schedule.

    Cc722520.exch1204(en-us,TechNet.10).gif

    Figure 12-4: . Use the Delivery Options tab to control when messages are sent through the routing group connector.
  5. To set separate delivery options for standard and large messages, select Use Different Delivery Times For Oversize Messages. In Oversize Messages Are Greater Than (KB), type the minimum size, in kilobytes, of messages you want to designate as oversized. The default is 2000 KB. Finally, use the options in the second Connection Time list box to set the delivery times for large messages.

  6. Click OK.

Performing Other Routing Group Connector Tasks

You perform most other routing group connector tasks in the same way that you perform tasks for other connectors. The section of this chapter entitled "Handling Core Connector Administration Tasks" explains these common tasks.

from Microsoft Exchange 2000 Administrator's Pocket Consultant by William R. Stanek. Copyright © 1999 Microsoft Corporation.

Link
Click to order


Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.