Routing Group Connector

[Previous] [Next]

The Routing Group Connector is, in most environments, the best choice for connecting routing groups. It is easy to administer and uses the Simple Mail Transport Protocol (SMTP), which means that it can be used even when bandwidth is either slow or unreliable.

The Routing Group Connector is a unidirectional connection from one server in one routing group to another server in a different routing group. Therefore, if bidirectional communication is necessary, you'll need to create two connectors to form the logical, bidirectional link between the two routing groups.

Because Routing Group Connectors are always one-way connections, after you have created one end of the connector, you'll be prompted to have Exchange Server automatically create a Routing Group Connector in the remote routing group. If you choose to do so, the connector that is created in the remote routing group will inherit the settings you have chosen for the local connector, with some exceptions.

First, on the General tab of the Routing Group Connector (Figure 13-1), if the remote routing group has more than one server, Exchange Server will select the These Servers Can Send Mail Over This Connector option and then select each SMTP virtual server for this configuration. If any of the virtual servers that have been created on the target servers are incompatible with message transfer over this connector, you'll need to either manually remove those servers from this list or configure the other connector manually.

Figure 13-1. Specifying servers that can send mail over this connector.

Second, on the Remote Bridgehead tab (Figure 13-2), Exchange Server will list all of the SMTP virtual servers as target servers. Again, if you have an SMTP virtual server that cannot be a target server, you'll need to either remove the server from the list or configure the connector manually.

Figure 13-2. Specifying target servers for this connector.

The Routing Group Connector uses a bridgehead server, which acts as the gateway through which messages flow into and out of the routing group. As with the Site Connector in Exchange Server 5.5, you can configure the Routing Group Connector to use multiple target bridgehead servers. Unlike the Site Connector, however, in which you assign a cost to each target server, a Routing Group Connector contacts the target servers in a sequential order that you specify. The obvious advantage of identifying multiple servers as bridgehead servers is that if one bridgehead server goes down, Exchange 2000 Server will choose another through which to transmit the message.

The Routing Group Connector uses SMTP as its transport protocol, giving it a higher tolerance than the Site Connector in Exchange Server 5.X for lower-bandwidth and higher-latency environments. The Site Connector uses TCP to initiate and maintain a connection to the target bridgehead server and then uses remote procedure calls (RPCs) to invoke the connector's functions. RPCs incur much overhead and require higher bandwidth and greater permanency to maintain their bindings. In contrast, although the Routing Group Connector passes SMTP commands through a TCP session, the commands don't make RPC calls to the target server. Instead, SMTP sends a series of discreet commands that can tolerate lower bandwidth and less permanency than RPCs can. For a more complete discussion of SMTP, please see Chapter 16.

When you upgrade an Exchange 5.5 bridgehead server that is configured with a Site Connector, you'll find that the connector is upgraded to a Routing Group Connector that communicates over RPC to Exchange 5.X servers yet uses SMTP to communicate with other Exchange 2000 servers.

The Routing Group Connector contains several features not available in the Site Connector in Exchange Server 5.5. First, you can create a schedule to define when messages will pass over the connector. In addition, you can schedule messages based on size (for instance, any message over 2 MB) so that you can send them when bandwidth usage is lower.

NOTE
Microsoft recommends having at least 64 Kbps of available bandwidth for a connection handled by a Routing Group Connector. Also, no encryption is currently available between the bridgehead servers.

REAL WORLD   Resolving Target Server IP Addresses for Bridgehead Servers

When a bridgehead server (BHS) that hosts a Routing Group Connector receives a message destined for a server in the other routing group, the BHS takes the following steps to resolve the IP address of the target BHS:

The BHS contacts DNS and attempts to resolve the IP address of the mail exchanger (MX) record of the target machine. If multiple MX records exist, it considers the preference values when deciding which BHS to resolve to. If no MX record exists, the BHS queries DNS for an address A record and attempts resolution. When using Microsoft Windows 2000 DNS, all Windows 2000-based servers automatically register A records in DNS. If no A record exists, the BHS attempts to resolve the IP address using the NetBIOS name resolution process.

NOTE
To learn more about the DNS and Windows 2000, refer to Microsoft Windows 2000 TCP/IP Protocols and Services Technical Reference (Microsoft Press, 2000) and Active Directory Services for Microsoft Windows 2000 Technical Reference (Microsoft Press, 2000).

Creating a Routing Group Connector

To create a new Routing Group Connector, right-click the Connectors container (it appears as a folder) located under the Routing Group container in the Exchange System snap-in, point to New, and then select Routing Group Connector. On the General tab, enter the name of the connector and then select the routing group to which you would like this connector to connect (Figure 13-3).

You can also select either Any Local Server Can Send Mail Over This Connector or These Servers Can Send Mail Over This Connector. The first option is the default and allows any server in the routing group to use the connector for sending messages destined for a server in the other routing group. The second option is a way to reserve the connector for certain virtual servers in the routing group. When you select this option, you'll be able to specify the virtual servers in the routing group that can use this connector.

TIP
Be sure to select a virtual server that will send mail to the destination routing group. For instance, assume that you have a group of external users who send their messages into the organization using Transport Layer Security (TLS) and that you've set up an SMTP virtual server to accept mail on a second IP address over port 25. This SMTP virtual server requires a certificate for authentication. Let's now assume that there are no such configurations for the local users on your LAN. If you were to choose this virtual server as the only server to send mail over the Routing Group Connector you are creating, messages sent by the local users would be rejected because the message would be routed back to the second IP address of the server and the SMTP server would be looking for TLS security and certificates. In this scenario, you want to be sure you don't select this virtual server for your Routing Group Connector.

At the bottom of the General tab, you can select Do Not Allow Public Folder Referrals. Selecting this check box means that if a client cannot access or find a public folder replica in the local routing group, the client will not be allowed to look for it in the public folder servers in the other routing group over this Routing Group Connector.

Figure 13-3. General tab of the Routing Group Connector's property sheet.

Remote Bridgehead Tab

On the Remote Bridgehead tab (refer back to Figure 13-2), you can specify one or more servers in the remote routing group with which this connector will attempt to establish a connection before sending messages. The servers are contacted in order, starting at the top of the list. Also, if the destination server has more than one SMTP virtual server configured, you'll need to select the one that will allow messages to be sent across the connector you are setting up.

Delivery Restrictions Tab

On the Delivery Restrictions tab (Figure 13-4), you can indicate who can use this connector, either by specifying that all messages are to be rejected except for those from a select list of users or by specifying that all messages are to be accepted except those from a select list of users. You'll find that you cannot enter Active Directory directory service distribution groups here. Instead, you can enter only mail-enabled users and contacts.

TIP
To select more than one user from Active Directory, highlight the first user in the Select Recipient list and then use the down or up arrow on your keyboard to select a contiguous list of users. To select a discontiguous list of users, hold down the Ctrl key and then use your mouse to highlight all the users you want to add to this list.

Figure 13-4. Delivery Restrictions tab of the Routing Group Connector's property sheet.

REAL WORLD   Giving Priority to Messages from Certain Users

When used in conjunction with the cost assigned to the connector itself, the Delivery Restrictions tab can be configured to give messages sent via the Routing Group Connector from a certain group of users a higher priority than messages sent from other users. For instance, suppose that your sales staff and pre-sales support staff are located in two different cities that also represent two different routing groups. Let's further assume that most of your orders come in over the telephone and that when members of your sales staff have a technical question about a product, they need to send that question via e-mail to the pre-sales support staff. In this scenario, you might want to set up two Routing Group Connectors. The first would be a connector with a cost of 100 that would accept messages from any user and forward them on as appropriate but would reject messages from members of the sales staff. The second connector would have a cost of 1, and it would reject all users except for the members of the sales staff, who would be listed on the Delivery Restrictions tab. This arrangement would cause the sales staff's messages to be sent to the other routing group faster than messages from other users.

Delivery Options Tab

The Delivery Options tab, shown in Figure 13-5, allows you to specify when messages can flow through the connector. This ability is especially helpful if you're using the connector over a slow or unreliable WAN link. By selecting the Use Different Delivery Times For Oversize Messages check box, you can hold larger messages until the times you set, presumably when the connector is experiencing little traffic.

Figure 13-5. Delivery Options tab for the Routing Group Connector's property sheet.

Content Restrictions Tab

On the Content Restrictions tab, shown in Figure 13-6, you can set the priorities, types, and sizes of messages that can pass over this Routing Group Connector. Under Allowed Types, selecting the System Messages option allows the transmission of all non-user-generated messages, including directory replication, public folder replication, network monitoring, and delivery and nondelivery report messages. In the Allowed Sizes area, you can restrict messages to those less than a specified size.

Figure 13-6. Content Restrictions tab for the Routing Group Connector's property sheet.



Microsoft Exchange 2000 Server Adminstrator's Companion
Microsoft Exchange 2000 Server Adminstrator's Companion
ISBN: N/A
EAN: N/A
Year: 1999
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net