In a native Exchange 2000 Server organization, message transfer relies entirely on SMTP, which works over any type of network connection, including slow and unreliable links. You do not need to configure anything extra for the servers to communicate with each other. An Exchange 2000 server that must deliver a message to a recipient on another server can simply retrieve the name of the recipient’s home server from Active Directory. It then queries the Domain Name System (DNS) for the Internet Protocol (IP) address of that server, obtains the IP address (the home server is a Windows 2000 server in the same Active Directory forest, so a resource record [RR] should exist in DNS), and uses it to establish a TCP/IP connection to the target host. The sending server can then transfer the message, and the recipient receives it just fine. Is there anything to configure?
This lesson addresses important issues related to the transfer of messages across an Exchange 2000 organization and explains how to design an efficient routing topology. You will read about the purpose of routing groups, their advantages, the best ways to connect them, and how to benefit from Exchange 2000 Server’s capability to recalculate routing paths dynamically based on link state information (LSI).
Without implementing a sophisticated routing topology, message transfer is always immediate and direct; that is, the sending station attempts to transfer the message in a straight line to the target host as soon as the user clicks Send. However, this does not necessarily imply that the transfer is accomplished in a resource-conscious manner. Figure 5.6 gives an example of this. A message was addressed to three recipients on different servers in New York. Theoretically, the Exchange 2000 server in San Francisco could have transferred this message just once to the other side and a server in New York could then have split the message into three instances. Instead, because the message transfer is direct, the server sends the same message three times, wasting a significant amount of precious bandwidth.
Figure 5.6 - Inefficient use of WAN connections
In Chapter 4, "Assessing the Current Messaging Infrastructure," you read that routing groups are server locations interconnected by a backbone and corresponding to network segments or local area networks (LANs). In other words, a routing group is an area of well-connected TCP/IP subnets, where network connectivity is highly reliable and fast so that servers can communicate directly with each other without wasting precious network resources. Getting back to Figure 5.6, the locations of San Francisco and New York are good candidates for routing groups because the servers in each location can talk to each other without affecting the WAN. Keep in mind that within a routing group, message transfer is always direct and accomplished via SMTP.
You can use the Exchange System snap-in to create routing groups, move servers between them, rename routing groups, or delete them. Moving servers between routing groups is a simple drag-and-drop operation. In a native mode organization, servers from any administrative group can be members of the same routing group. In mixed mode only, routing groups are bound to administrative groups for backward compatibility reasons.
Routing groups are not displayed unless you explicitly enable the Display Routing Groups check box in the General tab of the organization object. If you display administrative groups in addition, you will find the default routing group called First Routing Group under First Administrative Group\Routing Groups. To create an additional group, click the Routing Groups container, point to New, and then select Routing Group. Specify a name and then click OK. You may want to keep the naming of your groups similar to that of administrative groups. One Microsoft recommendation is to use abbreviated names, such as RG, and a four-character identifier for the geographic location (for example, RGSFCA), but you can use full names such as RG San Francisco California as well, which might be more intuitive. There is no technical reason for limiting the routing group names to six characters.
Communication does not take place between routing groups without explicit configuration of messaging connectors. A routing group connector (RGC) is basically a configuration object that provides Exchange 2000 Server with information about how to transfer messages across a routing group boundary. Important connector parameters are local and remote bridgehead servers, connection times, and a cost value.
Bridgehead servers act as concentrators for message traffic over WAN connections, and the concentrated traffic results in a better use of precious network resources (Figure 5.7). Furthermore, data is compressed by an average ratio of 5:1 before it is sent across a connector. If slow delivery times are acceptable, you can queue messages and transfer them in batches at specified connection times when the general workload is minimal, for example, at night. Be careful, however, when scheduling transmission times. Your users may be upset if the delivery in your environment takes as long as a full day. Perhaps it is more clever to define a size limit and configure a different connection schedule only for oversized messages, which might otherwise delay the transfer of normal or high- priority messages.
The following is a list of RGCs available in Exchange 2000 Server.
Figure 5.7 - Efficient use of WAN connections
Note
Exchange 2000 Server does not support dial-up connections directly. Instead, Routing Group, SMTP, and X.400 connectors make use of dial-up connections by means of the Windows 2000 Routing and Remote Access Service (RRAS). Hence, if you want to connect to a remote routing group over an on-demand dial-up connection, you need to install and configure your modem or Integrated Services Digital Network (ISDN) card on a Windows 2000 server that will act as a network router. On this server, enable RRAS via the Routing and Remote Access utility from the Administrative Tools program group. You can then configure the messaging connector as if it were making a LAN connection.
When you create multiple routing groups and link them together, you establish a system of message pathways across your organization. One or many routes may then lead to the same destination, as shown in Figure 5.8. Typically, Exchange 2000 Server should use the most efficient path for message transfer. In Figure 5.8, this is the RGC between San Francisco and New York. The additional route via Chicago, on the other hand, may stand by in case the pri-mary connection is temporarily unavailable. For the most efficient routing, use a mesh topology that connects each routing group to every other routing group. This method will limit unnecessary message forwarding.
Figure 5.8 - Multiple routes to the same destination and a rerouting problem
Exchange 2000 Server determines the best connector based on cost values and other criteria, such as connector states. You can assign your connectors a cost value ranging from 1 to 100. The path that has the lowest cost value is tried first. For instance, in Figure 5.8, the path between San Francisco and New York has a cost value of 1. The alternative route via Chicago has a cost value of 2 because the costs of all RGCs in the message path are added together. Hence, Exchange 2000 Server attempts delivery via the direct connection first.
Note
If the RGC between San Francisco and New York has unsuccessfully attempted to transfer a message to its remote bridgehead servers in New York three times, it is marked as unavailable. In this situation, Exchange 2000 Server may choose another possible path for message transfer if one exists. In Figure 5.8, this is the connection between San Francisco, Chicago, and New York, and the messages reach their recipients in spite of the connectivity problem.
Although it is generally desirable to use an alternate path if messages cannot reach their targets directly, message rerouting can impose a subtle problem. Let’s say that the RGC between Chicago and New York is likewise down—because it was the central WAN router in New York that broke down and not just the RGC between San Francisco and New York. The messages would then be rerouted to Chicago without any tangible benefit. In fact, Chicago may now reroute the messages further to Miami while New York is still unavailable, so Miami may forward them to Paris, and Paris may think Chicago is a good alternative. In short, blind message rerouting can lead to a situation where a large number of messages dance around the destination like Rumpelstiltskin around the fire.
Exchange 2000 Server overcomes this dilemma by using a powerful routing algorithm based on LSI. Basically, all servers communicate the state of their connectors (links) to each other, so each server in the organization knows the current state of all connections in the environment. When a connector has repeated delivery problems, Exchange 2000 Server marks it as unavailable and propagates the new state to all other servers so that they stop routing messages to the problematic RGC. Applied to Figure 5.8, this means that if San Francisco has problems transferring local messages to New York, and if Chicago, Miami, and Paris experience the same problems, all connectors to New York will be marked as down. When rerouting a message in San Francisco, no alternative path is open, and the message is not transferred to any other location. The message remains in San Francisco until at least one pathway to New York becomes available again.
Exchange 2000 Server relies on a procedure known as the link state algorithm (LSA) to propagate LSI to all servers (Figure 5.9). When a bridgehead discovers that a local connector is unavailable, it communicates the news to its local routing group master, which consolidates the information and propagates it to all other servers in the routing group. The bridgehead also communicates the news via RGCs to all connected routing groups, where a remote bridgehead receives the LSI and in turn communicates it to its local routing group master, which again propagates the news to all other servers in the routing group, as just explained. When the connector becomes available, updated LSI is propagated again.
Figure 5.9 - The propagation of link state information
Note
It is easy to design the routing group topology of an Exchange 2000 organization if you accomplish the work in three stages. You need to decide which servers belong to the same routing group, then determine appropriate RGCs to connect them, and then, with all this information in place, you also must determine the desired message routing topology.
There are three key issues to keep in mind when designing a routing group topology:
To determine an appropriate routing group topology for your Exchange 2000 organization, take the diagram of your Active Directory sites and simply rename it Routing Group Diagram. Sites define areas of well-connected TCP/IP subnets and so do routing groups; there is no difference. Another option is to take the network topology documentation created in Chapter 3, "Assessing the Current Network Environment," and draw a circle around every LAN that has a substantial number of users. Again, you will have appropriately identified your routing group boundaries. Servers with slow but resilient connections may be part of the same routing group, but it is better to keep them strictly separated to make best use of the available network bandwidth.
Why did Microsoft separate the Active Directory site and Exchange 2000 routing group topologies? Perhaps the most important reason was to prevent sudden and unexpected changes to the routing topology. If a network administrator moved an Exchange 2000 server to a different IP subnet, the server would then also change its routing group membership immediately. Yet, when you move a server between routing groups, you also move all connectors configured on this server. Thus, by moving the server—and without noticing the problem—the network administrator could actually break the routing topology. Separating the site from the routing group topology eliminates this risk. You now have to update the routing group topology manually. However, keep in mind that moving servers between sites or routing groups is not a concern when designing the routing group structure.
When determining routing group boundaries, consider the following requirements:
It is not required to standardize on a single RGC in your Exchange 2000 organization. For instance, you can connect routing Group A to Group B using an X.400 connector, and Group B to Group A through an SMTP connector, and the message transfer will work fine. RGCs are unidirectional, meaning you have to create and configure them separately in every routing group.
Wherever possible, use a Routing Group connector. This connector is easy to configure and allows you to specify multiple bridgeheads, which increases the fault tolerance. The SMTP connector, on the other hand, gives you more control over the message transfer. It is a good choice if you want to implement remote-triggered message delivery, where remote servers pull queued messages from a central hub. It is also the right choice if you want to connect to a remote routing group via a foreign SMTP-based messaging system, such as a UNIX Sendmail host on the Internet. The X.400 connector is a good choice only in environments with an X.400 backbone because it is the hardest to configure.
The challenge in designing a routing group topology is to determine how to connect the routing groups together for optimal message transfer. The worst possible choice is to create a huge connector chain, like A – B – C – D – E – F. Could it be any more indirect (and slower) to get a message from A to F?
A much better choice is to connect all routing groups directly with each other: A – B, A – C, A – D, A – E, A – F, B – A, B – C, B – D, and so forth. Unfortunately, this fully meshed model does not scale well to a large number of routing groups. Remember, you have to configure RGCs in each routing group separately, leaving you with the task of configuring 35 connectors for just 6 routing groups (A through F).
Perhaps a better architecture is the hub–spoke topology, where a central routing group assumes the role of a message switch. In the current example, this would require you to configure 10 RGCs, for instance A – B, A – C, A – D, A – E, A – F, B – A, C – A, D – A, E – A, and F – A, provided that A is the central routing group. The most significant advantage of the hub–spoke architecture is that you gain total control over the message transfer. All intergroup traffic must traverse through the central group. There is no chance for any dynamic rerouting because alternate paths between any two routing groups do not exist. The most significant disadvantage of this hierarchical routing topology is, however, that this architecture may not reflect the network infrastructure very well. For instance, routing Groups B and C may be closely located to each other, but all messages must travel through routing Group A, which may be far away. Further, if routing group A fails, all intergroup messaging will fail.
The smart routing capabilities of Exchange 2000 allow you to deploy your RGCs according to the WAN topology of your network and to optimally route messages through the physical links. Hence, if your messaging organization is too complex to establish RGCs between all routing groups, and if you do not need the total control over all message paths, create a hierarchical routing topology of fully meshed subbackbones in a global arrangement (Figure 5.10).
Figure 5.10 - A hierarchical routing topology with fully meshed subbackbones
Note
For simplicity, it is assumed that Adventure Works maintains four LANs (one in Canada, and the others in the United States, South Africa, and Australia) in a global network environment that is based on reliable VPNs over the Internet. The network connections are fast and dependable, and theoretically, Adventure Works can implement a very simple routing topology based on a single routing group. Yet, John Y. Chen is afraid that the direct server-to-server communication may overwhelm the VPN during peak hours. For this reason, Chen opted to implement a separate routing group for each geographical location. The WAN supports direct connectivity between the routing groups, so Adventure Works will deploy Routing Group connectors in a fully meshed topology, as shown in Figure 5.11.
In this activity, you will design a message routing topology for Consolidated Messenger and another company called Litware, Inc.
Figure 5.11 - The routing group topology of Adventure Works’ Exchange 2000 organization
Tip
According to the explanations from Lesson 1, Consolidated Messenger has implemented two administrative groups to manage the Video department’s Exchange 2000 resources separate from the remaining messaging organization. It is now your task to outline an appropriate routing topology. Keep in mind that all resources belong to the same metropolitan area network (MAN) in Portland, Oregon. For simplicity, the MAN environment can be considered a huge LAN.
Litware, Inc., is a company with 4500 employees in Washington, DC and Los Angeles. Figure 5.12 displays a high-level diagram of Litware’s WAN topology. For simplicity, it is assumed that Washington, DC and Los Angeles are LAN-like environments.
Figure 5.12 - A high-level diagram of Litware’s WAN topology
It is your task to recommend a routing group topology for efficient and reliable message transfer.
You do not need to configure anything extra for Exchange 2000 servers to communicate with each other, but you may want to place your servers in separate routing groups to make best use of available network resources. Routing groups are areas of well-connected TCP/IP subnets. Within a routing group, servers can communicate directly with each other without wasting precious network resources. Between routing groups, communication does not take place without explicit configuration of messaging connectors. Messaging connectors allow you to concentrate message traffic over slow or unreliable connections to make better use of network links with limited bandwidth.
Messaging connectors that you can use between routing groups are the Routing Group connector, the SMTP connector, and the X.400 connector. The Routing Group connector is the most powerful and the easiest to install. The SMTP connector provides slightly more control over the message transfer. The X.400 connector is the hardest to configure and should only be used in an environment where X.400 connectivity is needed.
You also need to determine how to connect the routing groups together for optimal message transfer. Generally, you have three choices. You can create RGCs between all routing groups, which leads to a fully meshed topology. However, fully meshed structures are not suitable for environments with many routing groups because the number of RGCs quickly gets out of hand. Large organizations may therefore prefer a hierarchical routing group arrangement, but this may not perfectly reflect the underlying network infrastructure. It also prevents Exchange 2000 Server from rerouting messages because alternate paths do not exist. A third, and perhaps the most flexible, structure is a topology of hierarchically arranged, fully meshed subbackbones. Here, individual regions are grouped together in a fully meshed topology, which are then handled as units and fully meshed in the global backbone.