If you have a single Exchange server within your organization, the time may come when you need to scale up to multiple servers. If your company expands its employee ranks or you join a larger company with more Exchange servers, you will need to know how managing multiple servers differs from managing a single server.
When you install an additional Exchange Server, that server automatically becomes a part of your existing Exchange organization. All of your organization's Exchange Servers can be managed through the Exchange System Manager console.
The Exchange System Manager console is divided into several containers, such as Global Settings, Recipients and System policies. The Global Settings, Recipients and System Policies pertain to the Exchange organization as a whole. Any modification that you make to settings within these containers will effect all of the Exchange Servers in your organization in some manner (even if indirectly).
By default, the servers themselves are listed in the Administrative Groups container under the default administrative group, in a sub container called Servers. The Servers container allows you to make modifications to various settings and perform maintenance at the server level. For example, you could mount or dismount an information store without effecting the entire Exchange organization, because the information store settings exist at the server level, not at the organization level. The Servers container lets you mount stores, select protocols, move mailboxes, view logons and set full text indexing on a server-by-server basis. You can also perform actions such as enabling logging or performing mailbox maintenance at the server level.
Group mechanisms
If you are making the jump to a multiple Exchange Server environment, you need to be familiar with two mechanisms: administrative groups and routing groups.
If your company only has a couple of Exchange Servers and everything is in one building, you will probably never touch these features. However, if you work for a large or geographically dispersed organization then these two mechanisms are your friend.
As you may recall, earlier I mentioned that the Servers container exists below the Administrative Groups container within the default administrative group. The purpose of an Administrative Group is to allow an administrator to delegate management over specific servers. For example, suppose that I had 10 servers in South Carolina and another 10 servers in Hawaii. As much as I might enjoy going there, it's a bit impractical for me to jump on a plane and fly to Maui every time maintenance is needed. Instead, I hire someone in Maui to manage those servers for me. While I want him to manage the servers in Maui, I don't want him to touch the servers in South Carolina. The problem is that all of the servers are a part of the same Exchange organization. This is where administrative groups come into play.
In a situation like this I would create a second administrative group and move all of the Hawaiian servers into it. I would then grant my person in Hawaii (and myself) administrative control over that Administrative group. My South Carolina servers still exist in the default administrative group.
Routing groups and replication traffic
In Exchange Server 2000 and 2003, routing groups take the place of Exchange sites. The Windows Active Directory already has an object type called sites, and Microsoft thought that it was too confusing to have an Exchange object that was also called "sites" so they changed the name to routing groups.
Routing groups are intended to help prevent Exchange Servers from clogging WAN links with excessive replication traffic. Exchange is designed so that every Exchange Server replicates with every other Exchange Server in the organization. This is fine unless you have a situation like what I described earlier where half of the servers are in South Carolina and the other half of the servers are in Hawaii. It doesn't really cause any problems if all of the servers in South Carolina try to replicate with each other or if all of the servers in Hawaii try to replicate with each other, but if every server in South Carolina tries to replicate with every server in Hawaii, then you have a ton of replication traffic flowing between the two offices.
This is where routing groups come into play. Routing groups let you separate the two different offices into two different groups. Exchange Servers within a routing group replicate with each other freely. Since the two groups must still replicate with each other, though, you designate one server within each group as a bridgehead server. You must then establish a routing group connector between the two routing groups.
To see how this works, let's go back to my earlier example. Suppose that you added a new Exchange Server to South Carolina. Being that both offices are part of the same Exchange organization, every server in both offices needs to know about the new addition. The new server directly notifies every server in the South Carolina office. When the designated bridgehead server in the South Carolina office receives the update, it sends the update to the bridgehead server in Hawaii. The bridgehead server in Hawaii is responsible for making the other servers in Hawaii aware of the addition.
Rather than the new server notifying every server in Hawaii directly, only one notification went across the routing group connector. This saves a substantial amount of bandwidth.
The one thing that you must remember is that although Exchange routing groups work very similarly to Active Directory sites, they are completely separate mechanisms. Routing groups are not confined by site boundaries. It usually makes sense to set up routing groups the same way that your sites are set up, but you don't have to.
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, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have a useful Exchange tip to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
