9.8 Connecting routing groups

---

Routing groups connect together through routing group Connectors (RGCs), X.400 connectors, or SMTP connectors. The RGC is very similar to the RPC-driven "Site" connector in Exchange 5.5, since it is the fastest and easiest connector to set up. As with the Site connector, you achieve convenience at the expense of giving up a certain amount of control over how messages are transmitted, such as the fact that the RGC cannot be configured to prevent messages of a certain size from being delivered. You can configure both of the other connector types to a much tighter degree. This fact is probably not important if you simply want to send messages between two routing groups located in a well-established and stable network, but it might be if you wanted to route mail between two routing groups over the public Internet.

The RGC uses SMTP to pass messages between servers, and an SMTP connector can also do this. There is not a conflict here, because the RGC takes care of internal communications within an Exchange organization, while the SMTP connector handles external communication. You should use the SMTP connector instead of the RGC when:

• You need to connect to Exchange 5.5 sites that use the IMS as their connection mechanism.

• You need to authenticate a remote bridgehead server before sending messages.

• You need to schedule message exchange with another server, perhaps to pick up messages across a link that is only available at particular times. Connecting to an ISP for message pickup is perhaps the best example of such a scenario.

• You want to use DNS MX records as the basis for routing messages instead of the Exchange configuration data held in the AD. In an organization that only has Exchange 2000/2003 servers, the Routing Engine never needs to use DNS to route messages, because all of the information about servers and routing groups is held in the AD, and the link state table contains all the data required about the lowest available cost path. Exchange uses DNS to translate server names to IP addresses, but ignores the MX records.

Some people will use SMTP or X.400 connectors to tie routing groups together, but the RGC is the most popular choice for connections today.

9.8.1 Creating a routing group connector

An RGC links one or more bridgehead servers in one routing group to one or more bridgehead servers in another. This is different from the Site connector in Exchange 5.5, which allows you to select either one server to serve as a bridgehead for a site or use any server in a site. The "any server in a site" option is often not desirable when you deal with very large sites and you want to control how messages flow within the network. You should configure multiple bridgehead servers whenever you want to achieve better resilience across a link or when the volume of messages requires that the load is balanced across multiple servers. Exchange automatically balances message load if you configure multiple bridgehead servers in a routing group.

The RGC is unidirectional, which means that you must configure the connectors on both sides before messages can flow between two routing groups. As with the Site connector in Exchange 5.5, when you set up an RGC on one server, you can have the RGC configured in the target routing group at the same time, providing you hold the appropriate administrative permissions for that routing group. The RGC is protocol independent. SMTP connects Exchange routing groups together, but in a mixed-mode environment, where an RGC links an Exchange routing group to an Exchange 5.5 site, RPCs flow across the connector. This is logical, because SMTP is an optional protocol on an Exchange 5.5 server, and RPC is the only protocol that you can absolutely guarantee to have available for interserver communications.

Creating a new RGC is very straightforward, and Figures 9.29 and 9.30 illustrate the two major screens you need to complete. Before starting, you need to know:

• The server to act as the local bridgehead

• The server to act as the bridgehead in the routing group you want to connect to. You can specify more than one bridgehead, if you want to spread the messaging load across multiple servers.

• The cost allocated to the connection

• The name of the connector, which can be up to 64 characters long

Figure 9.29: General properties of a routing group connector.

Figure 9.30: Remote bridgehead server for an RGC.

The default cost for connections is 1. Best practice suggests that you set a default cost of 10 for all major connectors and use steps of at least 10 for minor connectors. Because the concept of "major" and "minor" links varies greatly from company to company and depends on network connectivity and the way that routing groups are created, it is very difficult to offer hard and fast definitions. For most purposes, you can define a major connector as a link that you expect to handle heavy traffic. For instance, a connector that links a central routing group and a hub routing group in a hub and spoke network falls into this category. Minor connections are defined as links that carry less traffic. A connection that serves a downstream routing group (one that not connected directly into a hub routing group) falls into this category. If you look at the organization illustrated in Figure 9.25, the major connection is between London and New York and has a cost of 10. The links between the routing groups off the two hubs all have a cost of 20.

After Exchange creates the local RGC, Exchange prompts you to create the corresponding RGC in the target routing group. This is equivalent to the way that you create Site connectors for Exchange 5.5, where, if you have the necessary permissions in the Windows NT domain that hosts the remote site, you can create connectors in both sites in a single operation.

The Content Restrictions, Delivery Restrictions, and Delivery Options property pages allow you to exert additional control over messages that flow across the link. Content restrictions determine what priority of messages can be transmitted: High, Normal, or Low. Delivery restrictions allow administrators to create lists of users who are either permitted or barred from using the link. The combination of Content and Delivery restrictions is enough to create a scenario where a link is only able to handle high-priority messages from a select group of users. In most cases, administrators will not want to create such a restrictive environment, but many will be interested in the Delivery options.

Everyone wants the messages to go as quickly as possible, but sometimes people send messages that you really wish were left until after office hours. Most of the time, these messages are very large. Delivery options allow you to determine when the connector is available and set a different schedule for messages that exceed a certain size. Figure 9.31 shows that the connector is always available (the default) and that a separate schedule governs when messages over 2 MB (approximately 2,000 KB) can be transmitted. Given the size of many PowerPoint presentations sent by major corporations today, 2 MB may be too small a limit, but it serves to illustrate the point. Exchange keeps any messages that exceed the limit on the queue for the connector until the schedule allows their dispatch.

Figure 9.31: Delivery options for an RGC.

After creating a new connector, it is always a good idea to check that it works by sending a message with a delivery confirmation to a mailbox on a server in the target routing group. Of course, the nature of link state routing is such that Exchange will deliver the message by any possible route, so your test may work even if the connector does not if another route is available. You can use message tracking to verify the route that the test message takes, just to be sure.

Connectors are one way, so it is important to remember that any change you make to an RGC only applies in the routing group that the connector belongs to. If you impose a restriction on who can use the connector or the size of messages that can be processed and only make the change on one side of the link, it is quite possible to end up in a situation where users can send large messages from one side to the other, but not the other way around.

The best way to avoid potential problems is to ensure that you maintain the same configuration for the RGC from both sides of the link. After you have configured the RGC on both sides, you should be able to see both connectors in their respective routing groups (Figure 9.32).

Figure 9.32: Routing group connectors.

---