Tip

Understanding Exchange Server routing groups

Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could

    Requires Free Membership to View

win a prize. 


Introduction

Exchange Server routing groups have one job: to keep your network bandwidth links from being overrun by replication traffic. In this article, I explain how Exchange routing groups work, issues to watch out for when using them, and routing group topology options that are available to you.

How routing groups work

 

If you have routing groups implemented, you can have one routing group at the corporate office and a separate routing group at a remote office. The routing groups would be joined by a routing group connector.

That connector would designate one server in each routing group as a bridgehead server. (Exchange traffic flowing between routing groups can only be sent between bridgehead servers.)

Let's say that an Exchange server in your main office has been updated, and that update needs to be replicated to 10 servers at a remote office. With routing groups set up, rather than sending 10 copies of the update across the WAN link, the server could send the update to the local bridgehead server. The local bridgehead would then send the update to the remote bridgehead server. The remote bridgehead server would distribute the update to the machines at the remote office.

So, instead of having to send 10 different copies of the update across the wire, the update only has to be transmitted once. This saves a tremendous amount of bandwidth.

Routing group caveats

Before you start dividing your own organization into routing groups, there are a couple of issues you need to be aware of:

 

  1. Routing groups are only useful if you have multiple servers in each routing group. Exchange won't stop you from creating a single-server routing group, but there is really no point in doing so unless you plan on adding additional servers in the near future. If you have a single Exchange server in a remote location, Exchange replication traffic will be sent across the WAN link once, regardless of whether a separate routing group has been defined or not.

     

  2. You should also be aware of the issue of single point of failure. For example, if a remote office is connected to the main office through a routing group connector, and one of the bridgehead servers fails, the remote office will be completely cut off from the rest of the organization.

    To avoid this problem, you can take advantage of various routing group topologies. The situation I just described -- in which there is one connection between the main office and the remote office -- is referred to as a star topology.

Routing group topology options

As I talk about topologies, remember that I am referring to routing group topologies, not physical network topologies. Routing groups and routing group connectors function completely independently of the topology of the underlying network (as long as some sort of connectivity exists).

 

  • Star topology: The idea behind a star topology is that the main office connects to each of the remote offices, but none of the remote offices connect to each other. In a star topology, if a bridgehead server in one of the remote offices fails, that office will be cut off from the rest of the organization. If the bridgehead at the main office fails, then all routing groups will be cut off from each other.

     

  • Ring topology: In a ring topology, every routing group is connected to two other routing groups. That way, if a routing group connector fails, there is still an alternate path available and none of the routing groups become isolated.

    Of course, to make a ring topology really effective, you need to define two bridgehead servers per routing group -- one for each connector. That way, the failure of a single bridgehead server does not cause an entire routing group to be cut off from the rest of the organization.

    If you prefer not to have replication traffic flow through two bridgeheads in each routing group, you can simply assign one of the bridgeheads a high cost value. This assures that the bridgehead will not be used unless the primary bridgehead malfunctions.

     

  • Mesh topology: In a full mesh topology, every routing group is connected to every other routing group. Again, each routing group should have at least two bridgehead servers to eliminate single point of failure.

Conclusion

Implementing routing groups can dramatically reduce the amount of Exchange replication traffic flowing across your WAN links. But, if you decide to implement them, make sure you design your routing group topology in a way that avoids single point of failure.

About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.

 


Do you have comments on this tip? Let us know.


Related information from SearchExchange.com:

 

This was first published in August 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.