Every version of Microsoft Exchange Server since Exchange 2000 Server has been dependent on Active Directory (AD). What many new Exchange administrators might not realize is that even though AD acts primarily as a repository for user and topology information, your AD design can make or break an Exchange organization's performance. It does little good to have high-performance Exchange servers if your domain controllers (DCs) can't keep pace with Exchange-related LDAP queries. Exchange Server 2007 has different requirements for AD design than Exchange Server 2003, so let's take a look at some of the things you need to consider before deploying Exchange 2007.

Domain Controllers
Exchange 2007 has specific requirements for your organization's DCs. The first requirement for DCs in Exchange 2007 environments is that the schema master and all the Global Catalog (GC) servers within the forest where Exchange 2007 will be installed must be running Windows Server 2003 SP1 or later. Because Windows Server 2003 SP2 is available, this requirement probably isn't a problem for most organizations, but it must be met.

The second requirement is that all domains within the forest must have a functional level of Windows 2000 native or higher. You can check a domain's functional level by opening the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in and right clicking the domain you want to check in the console tree. Select Raise Domain Functional Level from the shortcut menu, and you'll see a dialog box similar to the one below.

The domain shown in above is already running at the Windows Server 2003 functional level, which works fine because it's a higher functional level than the required Windows 2000. Had this domain been running at a lower functional level, the dialog box would include an option to raise the domain to a higher level. Raising the functional level of a domain is a one-way operation: Once the level has been raised, there's no going back.

The domain functional level affects which servers can act as DCs in the domain. For example, if the domain functional level is set to Windows 2003, then all DCs in the domain must be running Windows 2003 or Windows Server 2008 (formerly code-named Longhorn). You can't have DCs running Windows 2000 or Windows NT Server in a domain with a Windows 2003 functional level. Windows 2000 DCs can participate in domains with a functional level of Windows 2000 or higher.

The third requirement for DCs in Exchange 2007 organizations is that any site that will contain an Exchange server running the Mailbox, Hub Transport, or Client Access server role (or any combination of these roles) must contain at least one GC server. Although any DC can easily be designated to act as a GC server, Exchange 2007 has some important guidelines regarding GC server placement, which I'll discuss more in the next section.

One last recommendation regarding DCs is that, if possible, your DCs should be running a 64-bit Windows OS. Assuming that the server is equipped with a sufficient amount of memory, 64-bit versions of Windows will usually let DCs handle a heavier load.

I also want to mention that Exchange 2007 shouldn't be installed on a DC. People argue this point with me all the time. The rationale behind their arguments is usually that Small Business Server (SBS) is designed to let Exchange reside on a DC, so it must be OK for other Exchange deployments as well. But keep in mind that SBS is intended for organizations that have only a couple dozen users at most. Typically, these organizations lack the budget or the expertise to support full Exchange deployments. Because they don't have many users, their servers don't usually have to bear the heavy workloads commonly associated with DCs and Exchange servers in larger organizations.

If for some reason you must install Exchange 2007 on a DC, remember that the DC must be running a 64-bit version of Windows. Even though you can install Exchange on a DC, doing so is a bad decision. At best, running Exchange on a DC causes problems with memory constraints and long shutdown times. This type of configuration also raises some questions regarding security. Your Exchange server communicates with the outside world and is therefore an entry point for malware and possibly hacking. It would be foolish to place an AD database on a server that's such a common target for those with malicious intent.

If the server is also hosting the Client Access role, then the risks are even greater because you're letting the outside world access the server using a Web browser.

Global Catalog Servers
Microsoft has changed its recommendations for GC server placement quite a few times over the life of Windows 2003 and Exchange 2003. To the best of my knowledge, Microsoft's most recent recommendation for GC server placement in an Exchange 2003 environment was to use a 4 to 1 ratio of Exchange server cores to GC server cores. This doesn't mean there should be one GC server for every four Exchange servers (although I believe that was Microsoft's recommendation at one point). Instead, this ratio is based on the number of processor cores.

As an example, imagine you had four Exchange servers, each with one single-core processor. One GC server with a single-core processor could support these servers. Of course, having only one GC server is a bad idea because this server represents a single point of failure.

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.