Ever since Exchange 2000 Server was released, Active Directory administrators and Exchange administrators have shared each other's pain.
Exchange admins had to give up the environment they had to themselves in Exchange 5.5, and move their users and mailboxes into the Active Directory world, relying on AD administrators for configuration decisions, permission granting and other functions.
As a result, AD admins were forced to learn at least something about Exchange because of the AD schema changes made by the messaging system and the mailbox administration attached to their user objects. However, Exchange still maintained its own routing, its own way of finding global catalogs (GCs) and domain controllers (DCs) and other operations.
As an AD administrator, you might be saying, "So what? I know there are schema changes and objects and attributes held in the Active Directory, because I've dealt with that for years now." With that in mind, let's take a look at how the implementation of Exchange 2007 will affect AD.
What Exchange Server 2007 means for AD
Microsoft's release of Exchange Server 2007 (called Exchange 12 during the beta) brought about the first significant architectural changes to Exchange since the move from version 5.5 to 2000 about six years ago. Thus far, the most press coverage has focused on the fact that Exchange 2007 is supported on (and only on) x64 platforms, making it a significant investment for most organizations.
However, there are also several other significant changes involved with Exchange 2007 that will affect Active Directory more than ever before. Note that the changes below are not listed in any particular order, such as priority, and there is very little data and experience at this point to draw from, so other issues are bound to pop up in the future. That said, here are some currently known issues:
Changes affecting message routing
While these all serve as significant additions ...
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
to Active Directory, the most impressive addition involves the change in message routing. In Exchange 2000 and 2003, Exchange used its own "routing groups" to control message routing. In Exchange 2007, routing groups are eliminated (except for backward compatibility for Exchange 2003). Instead, mail routing depends on AD Site Topology. In fact, the new Microsoft Exchange Active Directory Topology Service now runs to report the AD topology and topology changes to Exchange. Mail routing now depends on least cost path defined in AD Site Link attributes.
In addition, Exchange leverages Active Directory site affinity to associate role-based servers such as the Client Access server (CAS), Hub Transport server and mailbox server. A Microsoft Outlook client's ability to locate a mailbox efficiently depends on having those servers associated with the correct site, as well as having the client in the correct site.
This is significant because, at least in my experience, many AD administrators view site affinity as an option, not a necessity. Event 5778, which warns of clients or servers that are in a subnet not assigned to an AD site, is commonly found in many AD environments. Of course this does matter to Active Directory, as it means clients in such subnets are probably authenticating to DCs in remote sites when they could be using a DC in their local sites. It can also prevent clients from getting to local DFS servers; and now, as a result of Exchange 2007, it will affect mail routing, too.
Furthermore, it appears that Microsoft does not believe that AD administrators have efficient site link cost structures, or at least they are not willing to trust message routing to it. Exchange admins can set a site link attribute, called msExchCost, with a different site link cost -- other than what Active Directory uses for replication decisions. Thus, Exchange admins can build their own site link cost topology. Note that this Exchange version of site link cost is set on each individual site link. Therefore, you could have a mixture -- with some site links having only the AD cost set and some having both set. However, this could be very confusing when you try to troubleshoot messaging problems.
Microsoft Outlook relies heavily on the AutoDiscover service running on the Client Access Server, which uses Web services and a new DNS "A" record to allow the Outlook client to locate the proper mailbox server and other resources. This reinforces the old AD design principle that all operations ultimately depend on DNS. Thus, DNS misconfigurations not only affect AD operations, but will also potentially cause messaging failures.
It should be obvious at this point that the Active Directory must indeed be "rock solid." DNS must be properly configured, the AD site topology must be configured to reflect the features of the physical network, subnets must be mapped to AD sites, DCs must be capable of handling the additional demands of Exchange, replication must be working efficiently and administration delegation will have to be redesigned.
Now that the stage is set, subsequent articles in this space will provide some guidance on how you can make your AD rock-solid by assessing Active Directory health and complying with best practices.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Windows Server-File Systems.
