Published: Jan 07, 2009
When Microsoft created Exchange Server 2007, they introduced a number of architectural changes. Among these changes are the fact that Exchange Server 2007 no longer has an independent routing topology. Instead of using routing groups, Exchange Server 2007 uses the routing topology defined by that Active Directory. In situations in which Exchange Server 2007 has to coexist with Exchange Server 2003 or with Exchange 2000, Exchange 2007 will emulate a routing group and use a routing group connector to interact with the legacy Exchange servers. In pure Exchange 2007 environments though, routing groups are not used at all, so it makes sense to take a look at your Active Directory topology to make sure that messages can be routed efficiently.
In smaller, self-contained organizations, the routing topology isn’t really a concern. Organizations that span WAN links must design their Active Directory infrastructure in a way that uses low bandwidth WAN connections efficiently though. The most common way of doing this is to implement Active Directory sites.
Generally speaking, the Active Directory site structure should mimic your network topology. Each network segment should generally correspond to its own site, although this isn’t an absolute requirement, especially if the network segments are bridged by high speed links.
The primary requirement for implementing Active Directory sites is that each site must contain at least one domain controller. Computers on the network use the site information to locate a domain controller that’s close to them, rather than traversing a WAN link every time that they have to contact a domain controller. Furthermore, at least one domain controller on each site should be designated to act as a global catalog server.
It isn’t an absolute requirement, but I would also recommend placing a DNS server and an Exchange mailbox server in each site. Having a DNS server in the site reduces the number of name resolution requests flowing across the WAN link. Having an Exchange mailbox server in each site allows you to host the user’s mailboxes within the same site as where the user’s computer resides. This not only reduces the amount of traffic flowing across the WAN link, it also ensures that users can still access their mailboxes if a WAN link should fail.
This type of design can have the added benefit of allowing users to continue to send messages internally even when a WAN link failure occurs, but it is important to keep another one of Exchange 2007’s architectural changes in mind. Exchange 2007 is designed so that all messages, even those sent internally, flow through the transport pipeline. In fact, Microsoft requires you to place at least one hub transport server into every Active Directory site that contains a mailbox server. Of course you don’t have to have a dedicated hub transport server for each site, unless the volume of mail flow warrants it. In most organizations, it is perfectly acceptable to piggyback the hub transport server role onto the mailbox server.
In case you are wondering, the hub transport server accomplishes two different things in this type of deployment. First, as I already mentioned, it ensures that internal mail flow will continue to function, even if a WAN link between the sites were to fail. The other thing that the hub transport server does is to act as a messaging bridgehead server between Active Directory sites.
Active Directory sites are connected to each other by site links between domain controllers. The domain controller in each site that is hosting the site link acts as a bridgehead server. It is important to remember though, that an Active Directory bridgehead server’s job is to minimize the amount of Active Directory replication traffic that’s flowing across the WAN link.
It is important to keep in mind that Active Directory bridgeheads neither know about nor care about Exchange Server. Exchange Server uses the Active Directory site structure in its routing topology, but the message routing decisions are made by the hub transport servers, not by domain controllers.
In this article, I have discussed some of the architectural considerations related to large Exchange 2007 organizations. In the next article in this series, I will continue the discussion by showing you how to create Active Directory sites, and how to create links between those sites. To read more on this topic, please continue on to the next article in this series. Planning a Sites and Services Architecture for Exchange 2007 – Part 2.
For more Exchange 2007 articles, please see the Petri Exchange 2007 Knowledgebase master index.