Become a Columnist Microsoft Exchange Site Microsoft Support SiteMSDN Exchange Site

       How did you like this article? Please vote and let us know.          

Subscribe to OutlookExchange
Anderson Patricio
Ann Mc Donough
Bob Spurzem
Brian Veal
Catherine Creary
Cherry Beado
Colin Janssen
Collins Timothy Mutesaria
Drew Nicholson
Fred Volking
Glen Scales
Goran Husman
Guy Thomas
Henrik Walther
Jason Sherry
Jayme Bowers
John Young
Joyce Tang
Justin Braun
Konstantin Zheludev
Kristina Waters
Kuang Zhang
Mahmoud Magdy
Martin Tuip
Michael Dong
Michele Deo
Mitch Tulloch
Nicolas Blank
Pavel Nagaev
Ragnar Harper
Ricardo Silva
Richard Wakeman
Russ Iuliano
Santhosh Hanumanthappa
Shannal L. Thomas
Steve Bryant
Steve Craig
Todd Walker
Tracey J. Rosenblath

 

 
 

Examining the Routing Group Master

by Catherine Creary

Exchange Server 2000 introduces Routing Groups...a.k.a. Sites in Exchange 5.5.....for grouping servers to define how mail is to be transferred.  But what exactly, is the routing group master and what are its responsibilities?

The routing group master is generally the first Exchange Server installed in a Routing Group.  One routing group master is allowed per routing group.  It maintains the link state information for the group and propagates this information to other routing groups.  Seems pretty simple, but is it?

The link state table, known as the GWART in Exchange 5.5, stores the names and status of all the connectors in an Exchange 2000 organization.  Each server must have an accurate copy of this table in order to determine the possible routes messages can take to reach their destination.

The routing group master ensures that this link state information is propagated to the appropriate locations within the routing group and beyond.  The rules are quite simple:

a)  TCP Port 691: used by the routing group master to send changes to the link state table within the routing group
b)  TCP Port 25: used by the routing group bridgehead server to send changes across connectors beyond the routing group

For example, if a SMTP connector fails from routing group A to routing group B, Exchange 2000 notifies the routing group master that the link state is DOWN within five minutes of its failure.  The routing group master's responsibility is to propagate this information to all servers within the current routing group (using Port 691).  Once any or all bridgehead servers in the routing group are notified and have updated their link state tables, they will begin the process of notifying the bridgehead servers in other routing groups via their associated connectors (using Port 25).  This is typically done by issuing a X-LINK2STATE command over the routing group or SMTP connectors.  The routing group master continues to check the link status every 60 seconds until it is UP.  It will then notify the other servers of the connector's new state.

 "What," you may ask, "happens if the routing group master and the bridgehead server are the same server?"

In this case, link state tables will continue to exist without new changes until an administrator has designated a new routing group master.  Unfortunately, a new master is not automatically assigned. One can accomplish this through the Exchange System Manager, by right-clicking on any other server in the group and selecting Set as Master from the pop-up menu.    It is important to note that you cannot uninstall the current routing group master without receiving the following error:

This server is the Routing Master for the Routing Group "{name}", which contains other servers. You cannot uninstall this server until you either select a new Routing Master for this Routing Group, or remove all other servers from this Routing Group.

If you choose to bring the current routing group master back online it will attempt to obtain and reconstruct the link state information by contacting the other servers in the current routing group, and will then propagate this information once more.

 

 

 


Disclaimer: Your use of the information contained in these pages is at your sole risk. All information on these pages is provided "as is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Pro Exchange. OutlookExchange.Com and Pro Exchange shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

© Copyright Pro Exchange, Inc., 2006