Routing Group Connector
In most environments, the Routing Group Connector is the best choice for connecting routing groups because it is fast, reliable, and easy to set up. The RGC uses the Simple Mail Transport Protocol (SMTP), which means that it can be used even when bandwidth is 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 (it usually is), you’ll need to create two connectors to form the logical, bidirectional link between the two routing groups.
Fortunately, System Manager offers to automatically configure the other end of a link for you when you create the first connector. If you take advantage of this, the connector that Exchange creates in the remote routing group inherits the settings you choose for the local connector, with two major exceptions.
The first exception is evident on the General tab of the Routing Group Connector property sheet (Figure 13-1). If the remote routing group has more than one server, Exchange Server selects the These Servers Can Send Mail Over This Connector option and then selects each SMTP virtual server for this configuration. If any of the virtual servers 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 manually configure the other connector.
Figure 13-1: Specifying servers that can send e-mail over this connector.
The second exception to inherited settings is evident on the Remote Bridgehead tab (Figure 13-2). Exchange Server lists all the SMTP virtual servers as target servers. Again, if you have an SMTP virtual server that should not 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.
| Note | If your Exchange organization includes Exchange 5.x servers and those servers reside in a separate Microsoft Windows NT 4 domain, you can have a Routing Group Connector connect as an account in the NT 4 domain. Remember that a Routing Group Connector looks like a site connector in the Exchange 5.x organization and that it functions in the same way. |
The Routing Group Connector uses a bridgehead server that acts as the gateway through which messages flow into and out of the routing group. The RGC offers a level of fault-tolerance by allowing multiple source and destination bridgehead servers. Bridgehead servers can be used in one of three ways:
-
No bridgehead server is designated and all servers in the routing group function as bridgehead servers for message transmission.
-
One bridgehead server is designated and all e-mail destined for other routing groups flows through that one server. This gives the administrator great control over messaging configuration.
-
Multiple bridgehead servers are used and all e-mail flows over one of these designated servers. This configuration offers the advantages of load balancing and fault-tolerance. If one bridgehead server is unavailable for message transport, another will be available.
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.
 |
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 several steps to resolve the IP address of the target BHS. The BHS contacts DNS and attempts to resolve the IP address of the host (A) record of the target machine. If multiple records exist, DNS considers the preference values when deciding which BHS to resolve to. When using Windows DNS, all Windows-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.
|
| More Info | To learn more about the DNS and Windows Server 2003, refer to Microsoft Windows Server 2003 Administrator’s Companion by Charlie Russel, Sharon Crawford, and Jason Gerend (Microsoft Press) and Active Directory for Microsoft Windows Server 2003 Technical Reference (Microsoft Press). |
Creating a Routing Group Connector
To create a new Routing Group Connector, right-click the Connectors container 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).
Figure 13-3: General tab of the Routing Group Connector’s property sheet.
You can also select either the Any Local Server Can Send Mail Over This Connector or the These Servers Can Send Mail Over This Connector option. 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 e-mail to the destination routing group. For example, 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 e-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 e-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 is a Do Not Allow Public Folder Referrals option. Selecting this option means that if a client cannot access or find a public folder replica in the local routing group, the client will not be referred servers in other routing groups over this Routing Group Connector.
Remote Bridgehead Tab
On the Remote Bridgehead tab (refer to Figure 13-2), you can specify one or more servers in the remote routing group to serve as target bridgehead servers. The connector will attempt to establish a connection with each target server before sending messages. The servers are contacted in order, starting with the server 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 groups here. Instead, you can enter only mail-enabled users and contacts.
Figure 13-4: Delivery Restrictions tab of the Routing Group Connector’s property sheet.
| 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. |
|
When used in conjunction with the cost assigned to the connector, the Delivery Restrictions tab can be configured to give a higher priority to messages sent via the Routing Group Connector from a certain group of users than it would to 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 when you’re using the connector over a slow or unreliable WAN link, or over a link for which you are charged different rates at different times of the day. 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. The Allowed Priorities section lets you select which priority messages are allowed over the connection. This is a great way to establish connectors dedicated, for example, to passing high priority messages. In the Allowed Types section, 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 (NDR) messages. In the Allowed Sizes area, you can restrict messages to those smaller than a specified size.
Figure 13-6: Content Restrictions tab for the Routing Group Connector’s property sheet.
|
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 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. For a more complete discussion of SMTP, please see Chapter 20, “Supporting Internet Protocols and SMTP.”
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 it uses SMTP to communicate with other Exchange 2003 servers.
The Routing Group Connector contains two features not available in the Site Connector in Exchange Server 5.5. First, you can create a schedule to define when messages pass over the connector. Second, 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.
|
EAN: 2147483647
Pages: 254