Hone Active Directory for efficiency before deploying Exchange 2007

An efficient Active Directory topology is a must if you're planning to deploy Exchange 2007. Unlike its predecessors, the latest version of Exchange doesn't use Routing Groups to handle messaging traffic; rather, it works directly off of the existing AD infrastructure. Fortunately, achieving the level of AD efficiency you need has become far easier, thanks to the much-improved Knowledge Consistency Checker (KCC)

An efficient Active Directory topology is a must if you're planning to deploy Exchange 2007. Unlike its predecessors, the latest version of Exchange doesn't use Routing Groups to handle messaging traffic; rather, it works directly off of the existing AD infrastructure. Fortunately, achieving the level of AD efficiency you need has become far easier, thanks to the much-improved Knowledge Consistency Checker (KCC).

KCC first saw the light of day in February 2000, when Microsoft released Windows 2000 and offered admins the ability to connect remote sites together under one structure: Active Directory. To assist in that task, Microsoft added a behind-the-scenes algorithm to the structure: the Knowledge Consistency Checker.

KCC was promoted as an automatic site topology builder for monitoring physical connections between sites and subnets. Moreover, it was celebrated for forming logical connection links that included a replication schedule and site link costs -- that is, the costs to connect two sites based on connection speeds and bandwidth utilization.

This automatic manager of site replication for AD seemed too good to be true -- and it was, in fact. KCC was criticized for being a poor algorithm, and hence administrators ended up creating their own manual links and costs.

Some time later, according to administrative legend, a mathematical wiz took the algorithm apart, enhanced its capabilities, and gave it back to Microsoft. In fact, in 2004 InfoWorld's previous Enterprise Windows author Oliver Rist wrote, "For enterprises with an increasing number of branch offices or other remote locations, check out 2003's KCC (Knowledge Consistency Checker). Under Windows 2000, you were asking for trouble by attempting to connect more than 100 sites to a central server farm. KCC, however, has been reworked to handle well above 200 sites with no complaints whatsoever."

And so KCC now really is a valuable facet to your AD replication. If you haven't already done so, consider eliminating the aforementioned manual links and allowing the new and improved KCC to resume its responsibility over the AD site topology. Greg Shields, author of the book "Windows Server 2008: What's New, What's Changed" explains that "the KCC automatically applies link costs as part of what it does naturally. In all but the very largest of environments, you should never need to modify anything having to do with the KCC at all."

Using KCC to make your AD topology more efficient is a good start toward deploying Exchange 2007. However, prior to deploying even the first Exchange server, you should officially document your physical sites and subnets and note the current physical and logical links between these sites. Document the site link costs as well. Once you have things documented you want to look for ways to improve your overall infrastructure for superior AD replication topology.

One other enhancement you want to consider before deploying Exchange 2007 is the addition of Global Catalog servers in every site. These are Domain Controllers that retain a copy of every AD object. From an AD perspective, they assist in the logon process and in the search procedures for objects. From an Exchange perspective, they assist in the sending and receiving of mail. So, access to a GC is essential in your Exchange 2007 environment, and one per site is a best practice.

Jumping slightly to the future: You've enhanced your AD infrastructure and deployed your Exchange 2007 servers. Now you wish to make some changes to your messaging environment and perhaps even change those site link costs that KCC calculated.

Why would you want to change those costs? Well, suppose a message has to travel from Site A to Site D. There's no direct connection physically (or logically) but the message can go through Site B or Site C. The route choice is made by adding up the site link costs from A to B to D and the costs from A to C to D. The servers will choose whichever costs less.

There are times, however, when you may feel that you should manually intervene and select a more expensive route; for example, you may not be pleased overall by the speed of messaging based upon costs that are set on the AD side (and perhaps those costs are not functional because they were manually created, rather than making use of the KCC).

In some cases you may be an Exchange admin who doesn't have control over your AD environment. However, you still have the ability to alter the site link costs for your Exchange messaging. There are two ways to change these costs. If you change them within the Active Directory Sites and Services tool, it will be altered for both AD replication and Exchange replication traffic. If, however, you wish to make the change only for the Exchange side, you can open PowerShell and use the set-adsitelink cmdlet to create a new cost link for Exchange messaging only. You can read a full article on this here.

Now, even if you don't use Exchange (in any form, 5.5, 2000, 2003 or 2007) but you have an AD infrastructure in place, it behooves you to ensure greater efficiency, which still leads us back to the KCC, a free piece of Active Directory that may not be utilized in your environment.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies