Lesson 1: Routing Group Planning | MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration

A routing group is a collection of Exchange 2000 servers that typically share a permanent, reliable, high-bandwidth network connection. In a particular routing group, all servers communicate directly with each other using SMTP. SMTP, in turn, can work efficiently over all types of network connections, including on-demand dial-up links with limited bandwidths and high latencies. This gives you tremendous flexibility when designing the routing topology of your organization.

This lesson covers important aspects of characteristic routing group topologies. The most important reason to engage in routing group planning is minimizing transmission costs by maximizing the efficiency of network communication.

At the end of this lesson, you will be able to:

Explain the purpose of routing groups.
Describe the advantages of typical routing group topologies.
Manage routing groups.

Estimated time to complete this lesson: 75 minutes

Multiple Routing Group Scenarios

The primary reason for multiple routing groups in an Exchange 2000 organization is control and optimization of the flow of messages between servers. Within a routing group, servers communicate directly and immediately with each other by means of SMTP virtual servers. Between routing groups, on the other hand, message transfer relies on messaging connectors. Connector parameters, such as connection times, determine how messages are transferred.

NOTE
All SMTP virtual servers of a particular Exchange 2000 server must belong to the same routing group.

Single Routing Group Scenario

Organizations operating a homogenous LAN-like network environment will find the deployment of a single routing group sufficient and advantageous. If necessary, servers can be managed in multiple administrative groups, even though they are members of a single routing group. By default, one routing group called First Routing Group exists, and all servers are added to it during their installation (see Figure 16.1).

click to view at full size

Figure 16.1 A single routing group environment with two administrative groups

In a single routing group environment, connectors are merely used to connect to foreign systems. To give an example, you can use the SMTP Connector to establish an access point to the Internet (see Figure 16.2). The server running the SMTP Connector is called a bridgehead server. All inbound and outbound messages must be transferred to the bridgehead server before they are delivered. With only one bridgehead, you only need to configure one Internet connection with access to external DNS servers. However, it is possible to configure multiple bridgehead servers in a routing group for fault tolerance and load balancing. The configuration of the SMTP Connector is covered in Lesson 2.

The following are some advantages of single routing group organizations:

Direct access to public folders. Routing groups define the boundaries of direct public folder access. Within a single routing group, all local public folders are available. You can read more about public folder access in Chapter 17, "Public Folder Management."
Easiest message routing administration. It is not necessary to manage the routing topology manually. Connectors installed on bridgehead servers in the routing group are available to all users in the routing group.

click to view at full size

Figure 16.2 A messaging bridgehead in a single routing group

Efficient routing of messages. Message delivery from server to server is direct and immediate without a need for intermediate bridgehead servers (single-hop routing).
SMTP-based message transfer. SMTP is the transport protocol used between Exchange 2000 servers for message transfer in the same routing group.

Reasons for Multiple Routing Groups

If an organization relies on wide area network (WAN) connections, it will be desirable to control network communication. WAN connections may generate transmission costs, may have low bandwidth, may not be permanently available, and may operate unreliably. Here, the implementation of routing groups has advantages. Through the configuration of messaging connectors, you can define dedicated bridgehead servers, which can act as concentrators for message traffic over WAN connections between routing groups (see Figure 16.3).

click to view at full size

Figure 16.3 Two routing groups separated by WAN

Multiple routing groups enable you to minimize the consumption of network bandwidth. For instance, you can block access to public folders that reside on servers in other routing groups, which is especially desirable over slow network links because it reduces the bandwidth consumed. As explained in Chapter 18, "Public Folder Replication," you can replicate public folder instances to your local routing group if you need to provide them to your users.

Messaging connectors between routing groups can also help minimize transmission costs. You may queue messages and transfer them in batches at specified connection times when transmission charges are minimal (for example, at night). Likewise, it is possible to define a size limit and configure a different connection schedule for oversized messages, which might otherwise delay the transfer of normal messages. Furthermore, data is compressed by an average ratio of 5:1 before it is sent across a connector, which also saves expensive network bandwidth.

NOTE
It is possible to place all servers in one administrative group for global administration but still maintain multiple routing groups for optimized message transfer.

The following are reasons for implementing multiple routing groups:

Access to public folder resources must be controlled.
Dedicated bridgehead servers with optimized hardware for message transfer are desired.
Geographical locations are a consideration.
Network traffic should be reduced.
Unstable network links affect message transfer performance.
WAN transmission generates costs and must be optimized.

Hierarchical Routing Group Arrangement

In a hierarchical arrangement of routing groups, a central group of hub servers controls the entire message transfer between subordinated groups, known as spokes (see Figure 16.4). Especially in large and very large environments, the hierarchical arrangement has proven very reliable, scalable, and resilient. Multiple hub servers share the workload and provide redundancy for well-defined message paths between all locations. This design approach prevents uncontrolled rerouting of messages, which was difficult to handle in earlier versions of Exchange Server.

click to view at full size

Figure 16.4 A hierarchical backbone architecture

Even though Exchange 2000 Server overcomes certain routing limitations of previous Exchange Server versions, you may avoid using a full-mesh topology. Deploy Exchange 2000 Server in the central location first. As soon as the hub servers are in place and operating reliably, the spoke locations can be deployed or upgraded. Later, you might experiment with Exchange 2000 Server's new and very powerful routing engine by configuring shortcut routes between spokes to speed up and simplify message delivery. Exchange 2000 Server's routing architecture is flexible and allows topology changes at any time.

NOTE
The new directory architecture and the implementation of the link state algorithm help to overcome many of the deployment issues found in earlier versions of Exchange Server. During the phase of coexistence, however, organize your routing architecture according to the requirements of Exchange Server 5.5.

Full-Mesh Routing Group Arrangement

The hierarchical routing group arrangement has several limitations. Message routing always involves an additional hop, or transfer of a message to a hub server. Hierarchical routing paths may not optimally reflect the physical network infrastructure. Finally, the hub routing group may not be local to the spokes and may require transmission of a large amount of e-mail messages over WAN connections.

By implementing shortcut routes between spokes, you can bypass the hub for more efficient message transfer. In this scenario, you gradually move your routing architecture toward a full-mesh arrangement in which all routing groups can communicate directly with each other, eliminating ping-pong message transfer between bridgehead servers. Based on link state information, Exchange 2000 Server is able to gain a complete overview of connector availability in the organization, which allows for optimal message routing. To give an example, if a central bridgehead server in Rio de Janeiro is shut down, servers in Oslo will be able to recognize this and avoid routing messages to it. You can read more about the propagation of link state information in Lesson 3.

Mixed Routing Group Arrangement

The full-mesh architecture overcomes intermediate hops in message transfer because all bridgeheads communicate directly with each other. However, limited scalability is one significant drawback of the full-mesh topology. Figure 16.5 leaves a confusing impression. As the number of bridgeheads increases, the connector configuration might get out of hand.

As always, an optimal routing architecture depends on a detailed analysis of the underlying network infrastructure. Large organizations might find a hierarchical arrangement of fully meshed subbackbones most fitting. Whereas the hierarchical structure corresponds to a global communication infrastructure, local subbackbones can handle the message transfer between geographically close locations directly and efficiently. Users will likely send the majority of their e-mail messages to close recipients.

click to view at full size

Figure 16.5 A full-mesh backbone architecture

Managing Routing Groups

The actual management of routing groups is not difficult and requires no special utilities. You can use Exchange System Manager to create routing groups, move servers between them, rename routing groups, or delete them. Moving servers between routing groups is as easy as a simple drag-and-drop operation (see Exercise 1). Connectors associated with a particular server, such as an X.400 Connector, are moved along with the server.

NOTE
The default First Routing Group is not displayed unless you explicitly enable it via the Display Routing Groups check box (in the General tab of the organization object (for example, Blue Sky Airlines [Exchange]). If you display administrative groups in addition, you will find this routing group under First Administrative Group. All administrators of the First Administrative Group are routing administrators by default.

Dedicated Routing Group Management

If you want to delegate routing group management tasks to a specific group of administrators, you can create a dedicated administrative group to hold all routing groups. Delegate Access permissions for this administrative group to the group of desired routing administrators. Servers from any administrative group can be members of the routing groups. As shown earlier in Figure 16.1, the routing group topology is independent of the administrative group arrangement. You can read more about administrative groups in Chapter 14, "Managing Server Configuration."

Exercise 1: Creating Multiple Routing Groups

In this exercise you will create an additional routing group in your test environment. By means of drag-and-drop, you will move an Exchange 2000 server into the newly created group using Exchange System Manager.

To view a multimedia demonstration that displays how to perform this procedure, run the EX1CH16*.AVI files from the \Exercise_Information\Chapter16 folder on the Supplemental Course Materials CD.

Prerequisites

If you have completed the exercises of Chapter 14 and configured BLUESKY-SRV1 as a dedicated public folder server, you will need to add a mailbox store to this server, similar to the steps outlined in Exercise 1 of Chapter 14. Name the new mailbox store Mailbox Store (BLUESKY-SRV1) and move the mailbox of Carl Titmouse to BLUESKY-SRV1. The Administrator mailbox should still reside on BLUESKY-SRV2.
Make sure that administrative and routing groups are displayed in Exchange System Manager—via the Display Routing Groups and Display Administrative Groups check boxes in the properties of the organization object (that is, Blue Sky Airlines [Exchange]).
Log on as Administrator to BLUESKY-SRV1 and BLUESKY-WKSTA.

To create an additional routing group and split Exchange 2000 servers

Verify that BLUESKY-SRV2 has been moved into the Members container of the Second Routing Group. Wait a few minutes for Active Directory replication to propagate the changes to BLUESKY-SRV2.
Right-click Routing Groups, point to New, and select the Routing Group command.
In the Properties dialog box, under Name, type Second Routing Group, and then click OK.
Expand First Routing Group and Second Routing Group, select the Members container under First Routing Group. Drag BLUESKY-SRV2 from this container over the Members container of the Second Routing Group, then let it drop there (see Figure 16.6).
Verify that BLUESKY-SRV2 has been moved into the Members container of the Second Routing Group.
On BLUESKY-WKSTA, launch Outlook 2000, and send a test message to Carl Titmouse. Notice the nondelivery report stating that the recipient could not be reached.

click to view at full size

Figure 16.6 Split server resources across multiple routing groups

Exercise Summary

The configuration of routing groups is a simple task. Existing servers can be moved between routing groups easily. However, as soon as servers are separated by means of routing groups, additional configuration is required to provide a message path. Without additional connectors, there can be no e-mail communication between users in different routing groups.

Without additional connectors, there can be no e-mail communication between users in different routing groups. Non-delivery reports (NDRs) are generated for all those messages that cannot reach their recipients. NDRs provide information about delivery problems, suggest possible options to resolve them, and indicate the servers that could not transfer the messages further, such as in the line <bluesky-srv2.bluesky-inc-10.com #5.0.0>.