Designing Active Directory for Exchange Server 2007

To expand on this concept, suppose you had four Exchange servers, each with two single-core processors. Collectively, the servers would have eight processor cores, so you would need two GC server cores to support them. This could be one server with two single-core processors or one dual-core processor, or it could be two separate servers.

Microsoft has adopted the same basic technique for determining the number of GC servers needed to support Exchange 2007, but the ratio has changed to one GC server core for every eight Exchange 2007 cores. Of course, this is just a guideline. In the real world, the actual number of cores you'll need might vary because some cores are faster than others and because you want to avoid having a single point of failure.

There are two important criteria that your GC servers must meet in order for this 8 to 1 ratio to be valid. First, your GC servers must be running a 64-bit Windows OS. As I'm sure you probably know, 64-bit OSs can address a much larger amount of memory than 32-bit OSs. This is important because of the second requirement for an 8 to 1 core ratio: The server must have enough physical memory installed that it can cache the entire AD database in RAM. You can find the size of your AD database by navigating through your GC server's hard disk to the \windows\ntds folder and looking for the Ntds.dit file. If your GC servers don't meet these criteria, you're better off using the 4 to 1 ratio that was used with Exchange 2003.

AD Site Topology
One of the more significant features of Exchange 2007 with regard to AD is that routing groups no longer exist. Exchange 2003 lets you route messages by creating routing groups on an as-needed basis. In contrast, Exchange 2007 is designed to let Mailbox servers connect directly to Hub Transport servers, which can connect to any other Hub Transport server. If a Hub Transport server is down in a site, the Mailbox server will use AD site topology as an alternative to routing groups to find the next closest Hub Transport server.

With Exchange 2003, it's a common practice to place Exchange servers and some DCs or GC servers into a dedicated site. This method prevents demanding applications from flooding GC servers or DCs with excessive requests and thereby reducing Exchange's performance. By placing these resources into a dedicated site alongside the Exchange servers, you can effectively isolate Exchange from other demanding applications—and prevent Exchange from consuming resources required by your other applications—with only minimal effect on mail flow. Remember that Exchange 2003 uses its own internal routing groups to control mail flow and that these routing groups work independently of AD sites.

You could place Exchange 2007 into a dedicated site, but doing so could negatively affect mail flow, particularly in organizations with five or more AD sites. In complex organizations, it's almost impossible to get mail flow to perform optimally when Exchange is in a dedicated site without creating a management headache in the process. For more information about message routing in Exchange 2007, see "Exchange 2007 Transforms Message Routing," March 2007, InstantDoc ID 94859.

DNS Requirements
Just as Exchange 2007 depends on AD, AD depends on a properly configured DNS server. In previous versions of Exchange, configuring DNS entries was a fairly straightforward task. In Exchange 2007, things work a bit differently than what you might be used to.

As you probably know, each Exchange 2007 server can be assigned one or more of five available roles: Mailbox, Client Access, Hub Transport, Edge Transport, and Unified Messaging (UM). Servers running the Mailbox, Client Access, Hub Transport, or UM roles must be domain members and must therefore have their IP addresses registered with the organization's internal DNS server.

The Client Access server is essentially just a Microsoft IIS server that hosts Microsoft Outlook Web Access (OWA). As such, users need to be able to access the Client Access server from outside the organization. Theoretically, administrators could register the Client Access server's IP address with an external DNS server, but doing so would be a security risk. More often, the address that's registered with an external DNS server is the firewall's external IP address. The firewall can then be configured to use port forwarding to send HTTP traffic to the Client Access server, which can then service OWA clients without exposing the server to the outside world.

The most significant new feature of Exchange 2007 from a DNS standpoint is the creation of the Edge Transport role, a special Exchange server designed to sit at the edge of your network and receive messages from the outside world. The organization's mail exchanger (MX) record would typically contain the IP address of the Edge Transport server. When messages arrive at the Edge Transport server, it performs various levels of message hygiene, then forwards the messages to the Hub Transport server. Because the Edge Transport server sits at the network perimeter, it's running a hardened Exchange implementation and isn't even a member of a domain.

Plan Ahead for Performance
Exchange 2007 brings with it new features, new architecture, and new management methods—and along with all that, new headaches for Exchange administrators. You can help alleviate some of your headaches, at least, by designing your AD with Exchange 2007 in mind. A carefully implemented AD is one way to ensure good performance of your servers. Check out the sidebar, "AD Considerations for Exchange 2007," for a checklist of things to remember in your design.