Every Microsoft Exchange Server 2003 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 either managed by Exchange Server itself or handled manually by the administrator. When you add an Exchange server to an organization and place it in an existing routing group, Exchange Server 2003 automatically configures the connection between the new server and other servers in the routing group. If you have multiple routing groups, however, Exchange Server 2003 doesn’t configure connections between the routing groups. You must manually connect two routing groups using Exchange connectors.
Three types of Exchange 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.
Proper configuration of the X.400 MTA 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.
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:
Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
Right-click X.400, and then select Properties. This displays the X.400 Properties dialog box shown in Figure 14-1.
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.
Click OK twice.
Note
The X.400 name can be up to 32 characters long. The X.400 password can be up to 64 characters long.
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 them available to users on the local server. This is the optimal setting and it 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 might 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:
Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
Right-click X.400, and then select Properties. This displays the X.400 Properties dialog box shown in Figure 14-1.
Select the Expand Remote Distribution Lists Locally check box to make remote lists available, or clear this check box to disable this option.
Select the Convert Incoming Messages To Exchange Contents check box to convert incoming message contents, or clear this check box to disable this option.
Click OK.
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:
Maximum Open Retries. Controls the maximum number of times Exchange Server tries to open a connection before failing and generating a nondelivery report (NDR). The default is 144 retries.
Maximum Transfer Retries. Controls the maximum number of times Exchange Server tries to transfer a message across an open connection before failing and generating an NDR. The default is two retries.
Open Interval. Controls the number of seconds Exchange Server waits before attempting to reopen a failed connection. The default is 600 seconds.
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:
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 an NDR that gets returned to the sender.
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 an NDR that gets returned to the sender.
To view or change connection retry values for the X.400 MTA, follow these steps:
Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
Right-click X.400, and then select Properties. This displays the X.400 Properties dialog box shown in Figure 14-1.
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.
Click OK.
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:
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 30 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:
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.
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. If the value of the counter exceeds the maximum allowable window size, an error occurs.
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:
Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
Right-click X.400, and then select Properties.
Click the Messaging Defaults tab, and then click Additional Values. As shown in Figure 14-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.
Figure 14-2. Use the Additional Values dialog box to configure RTS values, association parameters, and transfer timeouts.
Tip
If you have an unreliable connection, you might 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 because this tells Exchange Server not to perform checkpoints and, as a result, message transfer might become unreliable.
Click OK.
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:
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:
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.
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.
The open connection to the server isn’t broken automatically. If a new message is queued for a server with an association that 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:
Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
Right-click X.400, and then select Properties.
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.
Click OK.
Generating lots of NDRs in a short amount of time can seriously degrade Exchange Server performance. To prevent this from happening, Exchange Server doesn’t immediately generate NDRs. Instead, Exchange Server generates the NDR based on the message priority, the associated transfer timeout value, and the size of the message. The default transfer timeout values are as follows:
Urgent. 1000 seconds per KB
Normal. 2000 seconds per KB
Not Urgent. 3000 seconds per KB
The transfer timeouts are configured this way because messages flagged as urgent have processing precedence over normal messages, and normal messages have precedence over not-urgent messages. Because of this, urgent messages should get processed in less time than other types of messages and normal messages should get processed in less time than not urgent messages. Note also that the transfer timeout defaults have changed from previous Exchange installations. Previously, Exchange versions allowed longer transfer times for urgent messages and shorter transfer times for less important messages. You can view or change transfer timeouts for the X.400 MTA by completing the following steps:
Start System Manager. If Administrative Groups are enabled, expand the administrative group in which the server you want to use is located.
Navigate to the X.400 container in the console tree. Expand Servers, expand the server you want to work with, and then expand Protocols.
Right-click X.400, and then select Properties.
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.
Click OK.
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, which must be within the same organization. For those of you familiar with Exchange Server 5.0 and Exchange Server 5.5, this concept is similar to a site connector.
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 function as the originator of message traffic, and remote bridgehead servers function 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, 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 might want to set a separate schedule for large messages to ensure that oversized messages don’t use 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 might 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 2 Hours or Run Every 4 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 Midnight, Run Daily At 1:00 A.M., or Run Daily At 2:00 A.M.
You must have at least two routing groups in the organization to install a routing group connector. If you do, you can install a routing group connector by completing the following steps:
Start System Manager. If Administrative Groups are enabled, expand the administrative group you want to work with.
Expand Routing Groups, and then expand the routing group you want to use as the originator of the connection.
Right-click Connectors, click New, and then choose Routing Group Connector. This displays the dialog box shown in Figure 14-3.
On the General tab, type a descriptive name for the connector.
Choose the destination routing group by selecting it in the Connect This Routing Group With list box.
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.
On 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.
Click OK to install the connector. Later, you might want to set connector cost, delivery options, delivery restrictions, and content restrictions.
To set the delivery options for an existing routing group connector, follow these steps:
Start System Manager. If Administrative Groups are enabled, expand the administrative group you want to work with.
Expand Routing Groups, and then expand the routing group you want to use as the originator of the connection.
Expand Connectors, right-click the routing group connector you want to configure, and then select Properties.
Click the Delivery Options tab, as shown in Figure 14-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 Midnight, 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.
To set separate delivery options for standard and large messages, select the Use Different Delivery Times For Oversize Messages check box. For 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.
Click OK.
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.
SMTP connectors are another type of Exchange connector. SMTP connectors transfer messages from local bridgehead servers to remote servers. You use SMTP connectors to connect Exchange servers, non-Exchange servers, routing groups, and organizations.
SMTP connectors are a bit more complex than routing group connectors, but the additional settings they make available gives them definite advantages over routing group connectors. With SMTP connectors, you can encrypt message traffic sent over the link and require stricter authentication than with routing group connectors. You can transmit messages to a designated server—called a smart host, which then transfers the message—or you can use Domain Name System (DNS) mail exchanger (MX) records to route messages. If the other mail system supports Extended Simple Mail Transfer Protocol (ESMTP), you can enable extended options as well.
When you install an SMTP connector, you must define which local bridgehead servers the connector will use as well as the connector scope, message routing technique, and address space. SMTP virtual servers act as local bridgehead servers for SMTP connectors. This means that the virtual servers are responsible for routing the message traffic. Multiple local bridgeheads provide load balancing and fault tolerance, which is essential when high availability is a concern. A single bridgehead, on the other hand, ensures that all mail flows through a designated server, but it does’t provide redundancy.
SMTP connectors have a specific scope that controls how the connector routes messages. You use an SMTP connector with a routing group scope to transfer messages within your organization. You can use an SMTP connector with an organizational scope to connect independent Exchange organizations, to connect Exchange servers with other SMTP-compatible servers (such as UNIX Send-mail servers), and to connect Exchange Server 2003 with earlier versions of Exchange Server.
SMTP connectors use smart hosts or DNS MX records to route mail. If you use a smart host, Exchange Server 2003 transfers messages directly to the smart host, which then sends out messages over an established link. The smart host allows you to route messages on a per domain basis. If you use DNS MX records, Exchange Server 2003 performs a DNS lookup for each address to which the connector sends mail.
When you install an SMTP connector, you must also define the address space for the connector. The address space determines when the connector is used. For example, if you want to connect two domains in the same Exchange organization—dev.microsoft.com and corp.microsoft.com—you could create the SMTP connector in dev.microsoft.com, and then add an SMTP address type for the e-mail domain corp.microsoft.com.
You can define multiple address types for a single SMTP connector. The address types can be any combination of SMTP, X.400, MS Mail, cc:Mail, Lotus Notes, and Lotus GroupWise addresses. These address types can point to different domains. Thus, you could use an SMTP connector to connect dev.microsoft.com with sales.microsoft.com, bizdev.microsoft.com, and eng.microsoft.com. You could also use an SMTP connector to connect two specific routing groups.
For load balancing and high availability, you could configure multiple SMTP connectors to handle the same address space. For example, if a large volume of traffic is routinely sent between corp.microsoft.com and support.microsoft.com, you could install two SMTP connectors to handle the message routing between these domains.
To install an SMTP connector, complete the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group you want to work with.
If available, expand Routing Groups, and then expand the routing group you want to use as the originator of the connection.
Right-click Connectors, click New, and then choose SMTP Connector. This displays the dialog box shown in Figure 14-5.
On the General tab, type a descriptive name for the connector.
To use a smart host for routing, select Forward All Mail Through This Connector To The Following Smart Hosts, and then type the fully qualified domain name or Internet Protocol (IP) address of the server through which you’d like to route messages. The SMTP connector then uses this smart host to route messages to the remote server.
Tip
You can enter multiple smart hosts as well. Separate each entry using a comma or semicolon. If you use an IP address, be sure to enclose the address in brackets, as in [192.168.12.99]. The brackets tell Exchange Server that the value is an IP address and, as a result, Exchange Server doesn’t try to perform a DNS lookup on the value.
To use DNS MX records for routing, select Use DNS To Route To Each Address Space On This Connector. The precedence order of MX records determines which servers are used in a particular domain.
You must specify at least one local bridgehead server. Click Add, and then select the SMTP virtual server that you want to use as the local bridgehead server. Repeat this step if you want to use additional bridgehead servers.
Connector scope is set on the Address Space tab. If you’re connecting two Exchange organizations, set the Connector Scope as Entire Organization, click Add on the Address Space tab, and then set the properties for the address space. Be sure to set the cost for the address space. Connector costs range from 1 to 100, with the lowest cost having the highest priority for routing. Repeat for other address types the connector should handle.
If you’re connecting two routing groups, set the Connector Scope as Routing Group, and then click Add on the Address Space tab and set the properties for the address space. Be sure to set the cost for the address space. Connector costs range from 1 to 100, with the lowest cost having the highest priority for routing. Repeat for other address types the connector should handle. Afterward, click Add on the Connected Routing Groups tab, and then select the routing group to which you want to connect.
If you want to allow the local server to relay messages to domains in the other organization or routing group, select Allow Messages To Be Relayed To These Domains.
Click OK to install the connector. Later, you might want to set delivery options, outbound security, delivery restrictions, content restrictions, and advanced controls, which I’ll explain in the following sections.
SMTP connectors have delivery options that determine when messages are sent through the connector as well as whether messages are queued for remote delivery. To control when messages are sent, you set connection schedules. You can have separate schedules for standard-sized and large-sized messages. To control message queuing, you can enable or disable message queuing for remote delivery on a per user basis. From then on, when a specified user logs on to the network, Exchange Server triggers delivery of all queued messages for this user. In this way, you can more efficiently manage how messages are delivered to remote clients with temporary connections.
You configure delivery options for SMTP connectors by completing the following steps:
In System Manager, navigate to Connectors. Right-click the SMTP connector you want to configure, and then select Properties.
Click the Delivery Options tab, as shown in Figure 14-6. Use the Connection Time list box to specify the times when messages are sent through the connector.
To set separate delivery options for standard and large messages, select the Use Different Delivery Times For Oversize Messages check box. For 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.
Message queuing is ideal for clients who connect periodically to download messages. To enable message queuing for remote users, select Queue Mail For Remote Triggered Delivery. Click Add, and then use the Select Recipient dialog box to specify users who should have this option.
Click OK.
By default, SMTP connectors don’t authenticate connections to remote domains. This means that the connectors anonymously access remote domains to send messages. You can, however, configure an SMTP connector to pass authentication credentials to remote domains. The key reason to do this is that you require a specific level of authentication to access a remote domain or you’re sending messages to a specific address in the remote domain that requires authentication.
Exchange Server 2003 supports three types of authentication:
Basic. Standard authentication with wide compatibility. With basic authentication, the user name and password specified are passed as cleartext to the remote domain.
Integrated Windows Authentication. Secure authentication for Microsoft Windows–compatible domains. With integrated Windows authentication, the user name and password are passed securely to the remote domain.
TLS Authentication. Encrypted authentication for servers with smart cards or X.509 certificates. Transport Layer Security (TLS) authentication is combined with basic or integrated Windows authentication.
To configure SMTP outbound security, follow these steps:
In System Manager, navigate to Connectors. Right-click the SMTP connector you want to configure, and then select Properties.
Click the Advanced tab, and then click Outbound Security. This displays the dialog box shown in Figure 14-7.
If you want to set standard authentication for wide compatibility, select Basic Authentication, and then click Modify. Otherwise, to set secure authentication for Windows-compatible domains, select Integrated Windows Authentication, and then click Modify. The Outbound Connection Credentials dialog box should be displayed.
Use the Account, Password, and Confirm Password fields to set the authentication credentials. Click OK.
If you want to encrypt message traffic and the destination servers in the remote domain support smart cards or X.509 certificates, select the TLS Encryption check box.
Click OK.
Advanced options for SMTP connectors control whether Exchange Server uses standard SMTP or ESMTP, as well as how mail delivery is initiated using SMTP or ESMTP. The ESMTP standard is more efficient and secure than SMTP, but some messaging systems, particularly older ones, don’t support ESMTP, and you might need to disable ESMTP support to prevent errors.
By default, SMTP connectors always try to initiate ESMTP sessions, but you can change this behavior using the HELO and EHLO start session commands. SMTP connectors initiate SMTP sessions with other mail servers by issuing the HELO start command. SMTP connectors initiate ESMTP sessions with other mail servers by issuing an EHLO start command.
By default, SMTP connectors don’t force delivery of queued messages. Forced delivery is necessary when you queue mail for remote triggered delivery. Not forcing delivery causes delays as clients first wait for a connection timeout, and then have to retry the connection. Two commands control delivery of queued messages: TURN and ETRN. TURN is a command for SMTP, and ETRN is a command for ESMTP. These commands allow a mail client to ask a remote server to start processing mail queued for delivery to the client.
You can configure these advanced options by completing the following steps:
In System Manager, navigate to Connectors. Right-click the SMTP connector you want to configure, and then select Properties.
Click the Advanced tab. This displays the dialog box shown in Figure 14-8.
The Send HELO Instead Of EHLO check box controls whether SMTP or ESMTP is used. To use SMTP, select this check box. To use ESMTP (which is the default), clear this option.
Configure remote triggered delivery of messages using the following options:
Do Not Send ETRN/TURN. Prevents clients from requesting that remote mail servers start processing queued mail. On the Delivery Options tab, you should ensure that Queue Mail For Remote Triggered Delivery isn’t selected.
Request ETRN/TURN When Sending Messages. Enables remote triggered delivery of messages. If you want to automatically request messages at a specified interval, select the Additionally Request Mail At Specified Times check box and then set the interval using the Connection Time drop-down list.
Note
If you request ETRN/TURN when sending messages, you must also forward all mail going through this connector using a smart host. You specify the smart host on the General tab using the field labeled Forward All Mail Through This Connector To The Following Smart Hosts.
Request ETRN/TURN From Different Server. Requests that messages are triggered for delivery from a server other than the one to which the messages are sent. If you select this option, you must specify the server name in the Server field. You must also set the interval for message delivery using the Connection Time drop-down list.
If you enabled remote triggered delivery and requested ETRN/TURN, you must specify how the requests are submitted to remote servers. Select either Issue ETRN or Issue TURN. To specify domains for which ETRN should be used, click Domains, and then add the domains.
Click OK.
You perform most other SMTP connector tasks in the same way you perform tasks for other connectors. The section of this chapter entitled "Handling Core Connector Administration Tasks" explains these common tasks.
In the beginning of this chapter, you learned that the X.400 MTA handles message transfer both within the organization and to servers outside it. Normally, the X.400 message transfer is handled within routing groups and not between them. You can, however, configure X.400 connectors to connect two routing groups in the same Exchange organization. The primary reason to do this is when you need to strictly control bandwidth usage between the routing groups. You can also use X.400 connectors to connect an Exchange routing group with a foreign X.400 messaging server.
The key reason for using an X.400 connector instead of another type of connector is that the X.400 connector incurs less overhead than other connectors when sending large messages. This means that sending large messages through an X.400 connector requires less bandwidth than sending the same messages through other types of connectors.
Because X.400 connectors are more complex than other types of connectors, they’re difficult to use. Unlike other connectors, X.400 connectors have several variations, including these:
TCP/IP X.400 connectors. Used to transfer messages over a standard TCP/IP network. Use this connector when you have a dedicated connection such as a T1 line. Because most X.400 messaging systems support TCP/IP, this is the most common type of X.400 connector used.
X.25 X.400 connectors. Configured to connect to an X.25 adapter on a remote mail server. With this connector, you can support standard X.25 protocols as long as an X.25 adapter is available and you know the X.121 address of the remote server.
Before you configure an X.400 connector, you must install and configure an X.400 transport stack that is the same type as the connector. The transport stack contains configuration information that the connector needs to properly transport messages. The available transport stacks include the TCP/IP X.400 stack and the X.25 X.400 stack.
Unlike other connectors, you can define only a single local and remote bridgehead server for an X.400 connector. This means you can’t build fault tolerance or load balancing into the connector configuration. Instead, you need to install multiple X.400 connectors to achieve these goals.
Each X.400 connector type has a corresponding X.400 stack. Unlike mail connectors, which you install at the administrative group level, transport stacks are installed on specified Exchange servers. The server on which you install the stack processes all messages from X.400 connectors that reference the stack.
The sections that follow examine how X.400 stacks are configured.
When you install a TCP/IP X.400 stack on an Exchange server, the server can process messages for one or more TCP/IP X.400 connectors configured for use in the organization. The stack works with standard TCP/IP protocols configured for use on the server. If necessary, you can create and configure multiple TCP/IP X.400 stacks. Each of these stacks can have a different configuration.
You can create a TCP/IP X.400 stack by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group you want to work with.
Expand Servers, and then expand the node for the server you want to work with.
Expand Protocols, and then right-click X.400. Choose New, and then choose TCP/IP X.400 Service Transport Stack. This displays the dialog box shown in Figure 14-9.
On the General tab, type a descriptive name for the stack. The default is TCP (servername). You can’t change this name after you create the stack.
If applications other than Exchange Server will use the transport stack, set OSI address information for the connector by using either hexadecimal or text characters. The T Selector field sets the transport service access point. The S Selector field sets the session service access point. The P Selector field sets the presentation service access point.
Click OK.
When you install an X.25 X.400 stack on an Exchange server, the server can process messages for one or more X.25 X.400 connectors for use in the organization. The stack relies on the installation of a dedicated X.25 device. If necessary, you can create and configure multiple X.25 X.400 stacks. Each of these stacks can have a different configuration.
You can create an X.25 X.400 stack by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group you want to work with.
Expand Servers, and then expand the node for the server you want to work with.
Expand Protocols, and then right-click X.400. Choose New, and then choose X.25 X.400 Service Transport Stack. This displays the dialog box shown in Figure 14-10.
On the General tab, type a descriptive name for the stack. The default is X.25 (servername). You can’t change this name after you create the stack.
All other steps are optional, so you can click OK to create the stack or continue with the configuration, and then click OK. The primary values you can set are as follows:
Call User Data. Sets additional connection data for users.
Facilities Data. Sets X.25 provider options.
X.121 Address. Sets the X.121 address of the remote server. This designator is defined in the X.25 network service setup on the remote server.
I/O Port. Sets the X.25 adapter port number. Type a number between 0 and 255. The default port is 1. The I/O port you specify must not match the value used by any other X.25 X.400 transport stack on the same server.
If applications other than Exchange Server will use the transport stack, set OSI address information for the connector by using either hexadecimal or text characters. The T Selector field sets the transport service access point. The S Selector field sets the session service access point. The P Selector field sets the presentation service access point.
Click OK.
Once you’ve created a stack for the transport you want to use, you can create one or more X.400 connectors that use the stack to transport messages to a remote host that you designate. Unlike other connectors, X.400 connectors have only one local bridgehead and one remote bridgehead. Essentially, the connector creates a direct link between a server in one routing group and a server in another routing group or organization.
TCP X.400 connectors depend on TCP services being installed on both the local server and the remote server you’re connecting. Once these services are installed and you’ve created the necessary transport stacks, you can install a TCP X.400 connector by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group you want to work with.
If available, expand Routing Groups and then expand the routing group you want to use as the originator of the connection.
Right-click Connectors, click New, and then choose TCP X.400 Connector.
On the General tab, type a descriptive name for the connector, as shown in Figure 14-11.
On the General tab, under Remote X.400 Name, click Modify. This displays the Remote Connection Credentials dialog box.
In the Remote X.400 Name field, type the name of the X.400 connector on the remote server. In most cases, the remote connector name defaults to the remote server name.
In both the Password and Confirm Password fields, type the password for the remote X.400 connector. Click OK.
On the General tab in the Properties dialog box, use the X.400 Transport Stack drop-down list to choose the X.400 transport stack that the connector should use.
Click the Address Space tab in the Properties dialog box.
If you’re connecting two Exchange organizations, set the Connector Scope as Entire Organization, click Add, and then set the properties for the address space. Be sure to set the cost for the address space. Connector costs range from 1 to 100, with the lowest cost having the highest priority for routing. Repeat for other address types the connector should handle.
If you’re connecting two routing groups, set the Connector Scope as Routing Group, click Add, and then set the properties for the address space. Be sure to set the cost for the address space. Connector costs range from 1 to 100, with the lowest cost having the highest priority for routing. Repeat for other address types the connector should handle. Afterward, click Add on the Connected Routing Groups tab and then select the routing group to which you want to connect.
On the Stack tab, select Remote Host Name or IP Address, and then in the Address box, type the fully qualified domain name of the remote X.400 server to which you’re connecting or enter the remote server’s IP address.
Click the Schedule tab, and then set the schedule for the connector. The available options are as follows:
Never. Disables the connector.
Always. Allows the connector to continuously transfer messages over the link.
Selected Times. Allows you to set a custom schedule for the transfer of messages over the link. A custom schedule is useful when you want to control the timing of message transfers.
Remote Initiated. Messages are transferred only when the remote server initiates the transfer.
If the remote system isn’t an Exchange server, click the Advanced tab, and then clear the Allow Exchange Contents check box. If you don’t clear this check box, messages are sent with e-mail addresses in domain name form and not in X.400 form, making it impossible to reply.
To override default X.400 settings, click the Override tab and then set connection values, RTS values, association parameters, and transfer timeouts for the connector as described in the section of this chapter entitled "Configuring the X.400 Message Transfer Agent."
Click OK to install the connector. Later, you might want to set delivery restrictions, content restrictions, and advanced controls.
X.25 X.400 connectors depend on X.25 adapters being available and the existence of an X.25 transport stack. Once you’ve installed these items and made them available, you can install an X.25 X.400 connector by completing the following steps:
Start System Manager. If administrative groups are enabled, expand the administrative group you want to work with.
If available, expand Routing Groups, and then expand the routing group you want to use as the originator of the connection.
Right-click Connectors, click New, and then choose X.25 X.400 Connector.
On the General tab, type a descriptive name for the connector, as shown in Figure 14-12.
On the General tab, under Remote X.400 name, click Modify. This displays the Remote Connection Credentials dialog box.
In the Remote X.400 Name field, type the name of the X.400 connector on the remote server. In most cases, the remote connector name defaults to the remote server name.
In both the Password and Confirm Password fields, type the password for the remote X.400 connector. Click OK.
Use the X.400 Transport Stack drop-down list to choose the X.400 transport stack that the connector should use.
Click the Address Space tab to define the connector’s address type and scope.
You have two options:
If you’re connecting two Exchange organizations, set the Connector Scope as Entire Organization, click Add on the Address Space tab, and then set the properties for the address space. Be sure to set the cost for the address space. Connector costs range from 1 to 100, with the lowest cost having the highest priority for routing. Repeat for other address types the connector should handle.
If you’re connecting two routing groups, set the Connector Scope as Routing Group, click Add on the Address Space tab, and then set the properties for the address space. Be sure to set the cost for the address space. Connector costs range from 1 to 100, with the lowest cost having the highest priority for routing. Repeat for other address types the connector should handle. Afterward, click Add on the Connected Routing Groups tab and then select the routing group to which you want to connect.
On the Stack tab, use the X.121 Address field to set the X.121 address of the remote server. This designator is defined in the X.25 network service setup on the remote server. Optionally, set additional connection data for users in the Call User field and X.25 provider options in the Facilities field.
Click the Schedule tab and then set the schedule for the connector. The available options are as follows:
Never. Disables the connector.
Always. Allows the connector to continuously transfer messages over the link.
Selected Times. Allows you to set a custom schedule for the transfer of messages over the link. A custom schedule is useful when you want to control the timing of message transfers.
Remote Initiated. Messages are transferred only when the remote server initiates the transfer.
If the remote system isn’t an Exchange server, click the Advanced tab, and then clear the Allow Exchange Contents check box. If you don’t clear this check box, messages are sent with e-mail addresses in domain name form and not in X.400 form, making it impossible to reply.
To override default X.400 settings, click the Override tab, and then set connection values, RTS values, association parameters, and transfer timeouts for the connector as described in the section of this chapter entitled "Configuring the X.400 Message Transfer Agent."
Click OK to install the connector. Later, you might want to set delivery restrictions, content restrictions, and advanced controls.
X.400 connectors follow a very specific schedule that determines how and when they are used. You can set the connection schedule by completing the following steps:
Start System Manager, and then navigate to the Connectors tab.
Right-click the X.400 connector you want to work with and then select Properties.
On the Schedule tab, use the following options to set the connection schedule:
Never. Disables the connector.
Always. Allows the connector to continuously transfer messages over the link.
Selected Times. Allows you to set a custom schedule for the transfer of messages over the link. A custom schedule is useful when you want to control the timing of message transfers.
Remote Initiated. Messages are transferred only when the remote server initiates the transfer.
Click OK.
X.400 connectors automatically inherit settings from the X.400 MTA. You can override these settings on a per connector basis by completing the following steps:
Start System Manager, and then navigate to the Connectors tab.
Right-click the X.400 connector you want to work with, and then choose Properties.
On the Override tab, set connection values, RTS values, association parameters, and transfer timeouts for the connector as described in the section of this chapter entitled "Configuring the X.400 Message Transfer Agent."
X.400 connectors configure default options for text wrapping and remote client support. The default options aren’t always optimal, and you might want to examine them.
By default, text word wrapping is disabled, which means the connector enforces no maximum line length. If you’d like message text to wrap at a specific line length, you can enable text word wrapping at a specific column position, such as 72 characters.
By default, X.400 connectors send messages in their original text formatting, which can include Rich Text Format. This setting works well with most MAPI-compliant mail applications, but not with noncompliant applications. With noncompliant applications, you usually want the connector to convert message text to ASCII text prior to delivery. To do this, disable support for remote MAPI clients.
You can control text word wrapping and MAPI client support by completing the following steps:
Start System Manager, and then navigate to the Connectors tab.
Right-click the X.400 connector you want to work with, then choose Properties.
The General tab should be selected.
Under Message Text Word-Wrap, select At Column to enable word wrap, and then type the column position in the field provided. To disable word wrap, select Never.
The Remote Clients Support MAPI check box controls MAPI client support. Select the check box to enable MAPI client support or clear the check box to disable MAPI client support.
Click OK.
You perform most other X.400 connector tasks in the same way you perform tasks for other connectors. The next section of this chapter, "Handling Core Connector Administration Tasks," explains these common tasks.
Regardless of which type of connector you use, you’ll perform a common set of administrative tasks. This section examines these tasks.
Bridgehead servers act as the communication relays for routing groups, and you define them locally and remotely. Local bridgehead servers serve as the originator of message traffic, and remote bridgehead servers serve as the destination for message traffic. Each connector has a slightly different way of handling bridgehead servers.
With routing group connectors, you can have multiple local bridgeheads but only a single remote bridgehead, and you can designate the bridgehead servers as described in Steps 6 and 7 of the section of this chapter entitled "Installing Routing Group Connectors."
With SMTP connectors, you can have one or more local bridgehead servers. These bridgeheads are identified using the SMTP virtual servers that are available on the local server for which you’re configuring the connector. You don’t specifically define remote bridgehead servers, however. Instead, you designate a smart host or use DNS MX records to locate remote mail servers in a specific routing group. These mail servers then act as remote bridgehead servers. To specify bridgeheads for SMTP connectors, follow Steps 5 through 8 in the section of this chapter entitled "Installing SMTP Connectors."
With X.400 connectors, you have one local bridgehead server and one remote bridgehead server. Because of this, you can build fault tolerance and load balancing into the connector configuration only by configuring multiple connectors. You specify bridgeheads for X.400 connectors through the local and remote X.400 names you designate for the connector.
Delivery restrictions enable you to accept or reject messages before transferring them over the connector. You accept or reject messages based on the sender’s e-mail address. By default, no delivery restrictions are set and, as a result, connectors accept all messages from all senders unless configured otherwise.
To configure the connector to accept messages only from specific senders, follow these steps:
Start System Manager, and then navigate to the Connectors tab.
Right-click the connector you want to work with and then choose Properties.
Click the Delivery Restrictions tab, as shown in Figure 14-13.
Under Accept Messages From, click Add, and then use the Select Recipient dialog box to choose users, contacts, and groups from which messages can be accepted. All other senders are rejected automatically.
Under Reject Messages From, select any name listed, and then click Remove. Repeat this process for all other names listed under Reject Messages From.
Click OK.
To configure the connector to reject messages from specific senders and to accept all other messages, follow these steps:
Start System Manager, and then navigate to the Connectors tab.
Right-click the connector you want to work with and then choose Properties.
Click the Delivery Restrictions tab, as shown in Figure 14-13.
Under Reject Messages From, click Add, and then use the Select Recipient dialog box to choose users, contacts, and groups from which messages are rejected. All other senders are accepted automatically.
Under Accept Messages From, select any name listed, and then click Remove. Repeat this process for all other names listed under Accept Messages From.
Click OK.
Content restrictions determine the allowed priorities, types, and sizes for messages transferred by a connector. By default, no content restrictions are set.
To set content restrictions, follow these steps:
Start System Manager, and then navigate to the Connectors tab.
Right-click the connector you want to work with and then choose Properties.
Click the Content Restrictions tab, as shown in Figure 14-14.
Use the options provided to set allowed message priorities and types. System messages include NDRs and other types of system messages. Nonsystem messages include all messages sent by users.
To restrict the size of messages that can be transferred by the connector, select the Only Messages Less Than (KB) check box, and then type the maximum message size in kilobytes.
Click OK.
Routing cost plays a key role in optimizing message routing. When two or more connectors link the same servers or routing groups, the connector with the lowest routing cost has preference over the other connectors. If the connector with the lowest cost is unavailable for any reason, Exchange Server uses the connector with the next lowest routing cost. By having multiple connectors and setting routing costs, administrators can ensure that messages are delivered even when a primary connector fails.
You can also use routing cost to balance the messaging load over two or more servers. In this example, you configure multiple connectors with the same routing cost, which tells Exchange Server to distribute the load as evenly as possible among the connectors.
To set routing cost for a connector, follow these steps:
Start System Manager, and then navigate to the Connectors tab.
Right-click the connector you want to work with and then choose Properties.
For routing group connectors, you set the routing cost using the Cost field on the General tab.
For SMTP and X.400 connectors, each address space and connected routing group has an associated cost. You configure these costs in the Address Space and Connected Routing Groups tabs, respectively.
Click OK.
Public folder referrals allow users on remote servers to access public folders on local servers. Public folder referrals are made possible through transitive affinities, which are enabled by default in Exchange Server 2003. If you don’t want users in other routing groups to be able to access public folders through a connector, you’ll need to disable public folder referrals. You can do this by completing the following steps:
Connectors can be disabled or removed at any time. To disable a connector, follow these steps:
Start System Manager, and then navigate to the Connectors tab.
Right-click the connector you want to work with and then select Properties.
On the Schedule tab, select Never as the connection schedule.
Click OK.
To remove a connector, follow these steps: