Subscribe to Windows IT Pro

 

Get Newsletters

  • Get the Latest News
  • Product Updates
  • Helpful Tricks
  • Productivity Tips

Subscribe Now!

August 30, 2007 12:00 AM

Designing Active Directory for Exchange Server 2007

Follow these guidelines for best Exchange performance
Windows IT Pro
InstantDoc ID #96536
Rating: (1)

Executive Summary:
Microsoft Exchange Server 2007 has specific requirements for Active Directory (AD) that differ from Microsoft Exchange Server 2003. Your Exchange 2007 deployment needs to have one Global Catalog (GC) server core for every eight Exchange 2007 cores. Placing Exchange 2007 in a dedicated site could negatively affect mail flow, particularly in organizations with five or more AD sites.

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 Figure 1, shows.

The domain shown in Figure 1 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.

Related Content:

ARTICLE TOOLS

Comments
  • Edwin
    4 years ago
    Apr 03, 2008

    Good source

You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

White Papers

Get your Windows 7 deployment off to the right start by implementing PC lockdown. A locked-down environment is easier and cheaper to support since users are less likely to make unnecessary changes to the core system configuration - read more here!

Essential Guides

Is your iSCSI "lossy"? The reality is that most off-the-shelf Ethernet hardware deployed for iSCSI can lose packets, resulting in slow performance or application downtime. Learn how to assess your current iSCSI infrastructure and engineer an advanced iSCSI SAN infrastructure.

Web Seminars

What's the best way to keep your network safe from malware? In this web seminar, security expert Greg Shields suggests an alternative method to the traditional blacklisting approach that is common with anti-virus and anti-malware solutions.

eLearning Series

We bring the experts direct to you to share their real-world perspective and expertise. During each event, three sessions stream in real time, so you can learn, ask questions, and get solutions.
Upcoming event: Getting the Most with Exchange 2010 with Paul Robichaux

Subscribe to Windows IT Pro!

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.