Exchange Server 2007 and Exchange Server 2003

The primary recommendation for Exchange 2003 is that you should have one global catalog processor core for every four Exchange server processor cores. That is, a 1:4 ratio.

Important:
The 1:4 ratio relates to processor cores, not to servers or processors. A dual core processor counts as "2" in a ratio calculation.

For Exchange 2007, we recommend that you deploy one 32-bit global catalog CPU core for every four Exchange 2007 mailbox server CPU cores.  Other server roles can influence the number of global catalog cores that are required. However, the Mailbox servers that are deployed influence the deployment of the other roles. Therefore, you can safely base the number of global catalog cores on Mailbox server cores.

The Exchange 2003 recommendations are based on domain controllers that are running a 32-bit version Windows Server 2003 2003. However, when you upgrade the domain controllers to 64-bit version of Windows Server 2003, efficiency can double. Instead of a 1:4 ratio, there can be a 1:8 ratio between global catalog processor cores and Exchange server cores. To achieve an 8:1 ratio, there must be enough RAM installed on the 64-bit server to cache the whole Active Directory database in memory. To determine the size of the Active Directory database, look on a global catalog server for the NTDS.DIT file. By default, this file is installed in the following folder:

%WINDIR%\NTDS

Regardless of how much RAM you install on a 32-bit computer, it is unlikely that the whole database can be cached if it is larger than 1.5 GB to 1.7 GB. This is because of memory addressing limitations in the 32-bit platform. Because 64-bit Windows-based computers have a massively larger address space compared to 32-bit computers, very large Active Directory databases can be completely cached in RAM. This provides a significant speed boost in responding to queries, together with a significant reduction in expensive disk I/O.

Caution:

If your Active Directory database is 2 GB, be careful about using the /3GB switch to obtain extra 32-bit address space for cache. Theoretically, you can increase the cache by doing this. However, you would likely only see approximately 2.5-2.7 GB consistently in cache, and that would come at the price of system stability. Using the /3GB switch on domain controllers is discouraged because this can starve the computer of critical kernel resources. Typically, this condition occurs after several days or weeks of operation, or after a peak in client demand.  and the server becomes unstable or unresponsive.

When you upgrade to 64-bit domain controllers, make sure that you install enough RAM to easily cache the whole Active Directory database.

Important:
If you do not install enough RAM in a 64-bit domain controller, your performance will more closely resemble that of a 32-bit domain controller.

The ratio recommendations that are described in this topic are guidelines. They are not guaranteed quantities. Your environment may have unusual loads or configurations that can affect performance.

These ratio recommendations assume that both the domain controllers and the Exchange Mailbox servers run on approximately equivalent hardware. Using 32-bit domain controllers together with 64-bit Exchange Mailbox servers may affect performance of the standard 1:4 recommendation. A 64-bit computer is likely to have more advanced processors and improvements in other components that can affect performance, such as buses, memory, and more. If you use an older computer for a domain controller, you may have to lower the ratio. Standard benchmarks, such as the SPEC benchmarks (www.spec.org), can provide a more realistic measurement for comparing older computers to newer computers.

Regardless of your global catalog processor platform, you should expect some increase in network traffic between global catalogs and Exchange 2007 servers. This increase in network traffic may be large if you take full advantage of all the new features and roles that are available in Exchange 2007. These include antivirus and anti-spam programs, legal compliance features, Unified Messaging, and so on.

For example, when all these features are heavily used at Microsoft, the network traffic between Active Directory and Exchange almost doubles. Although this is a significant increase, it does not have a large practical effect. Historically, network bandwidth has not been a common bottleneck between Exchange and Active Directory . However, you should check your current usage and make sure that you have enough network bandwidth between Exchange servers and domain controllers as you deploy additional Exchange 2007 features.

The Performance Tools that are included in the "Toolbox" section of the Exchange Management Console application in Exchange 2007 can be very useful to report actual performance and to find bottlenecks. For more specific recommendations, including lists of performance counters to monitor, see the following white papers and blog posts.

White papers

• Active Directory Performance for 64-bi t Versions of Windows Server 2003
  
  
• Best Practice Active D irectory Design for Exchange 2000 (still highly applicable to Exchange 2007)
  
  
• Planning a Microsof t Exchan g e Server 2003 M e ssaging System (downloadable article; a good resource that mostly applies to Exchange 2007)
  
  

Exchange Team Blog Web site

• Measuring AD Per f ormance
  
  
• Update 2: E xchange 2007 Processor and M e mory Recommendations
  
  
• Microsoft Windows Kern e l M e mory Management and Microsoft Exchange Server
  
  

In Exchange 2003 environments, message routing and Active Directory site topology are independent of one another. The main reason to dedicate an Active Directory site to Exchange is to prevent Exchange and other services and applications from dominating the domain controllers.

We can define a "demanding application" as an application that does the following:

• Continuously generates many LDAP queries
  
  
• Requires ANR (Ambiguous Name Resolution) to resolve a good percentage of those queries
  
  
• Makes frequent authentication requests against domain controllers
  
  

In Exchange 2007, message routing maps directly to Active Directory site topology. Therefore, your Active Directory site topology should make sense for message routing, not only for domain controller load balancing. Do not create an Exchange-dedicated Active Directory site unless this also improves routing.

Fortunately, the extra performance that is available with 64-bit global catalog servers makes it easier for demanding applications to coexist in the same site as Exchange 2007. This performance level also reduces the need to use dedicated sites for Exchange. Exchange 2007 effectively load balances its requests across the domain controllers that are available to it. This includes thinking about how busy the domain controllers are with other work. It is unlikely that Exchange 2007 will dominate a domain controller. However, Exchange is a demanding application. It will present steady, relatively high load across all the global catalog servers that are available on the site.

If you have many demanding applications that are running on a site, you must consider both their average loads and their peak loads, and also the possibility that all those applications may access a single domain controller at the same time. When calculating your site requirements, consider the following guidelines:

• If you use 32-bit domain controllers, you can support up to 10,000 Exchange 2007 users on the same site together with demanding applications. 
  
  
• If you use 64-bit directory servers, you can support up to 20,000 Exchange 2007 users in the same site together with demanding applications.
  
  

If you are above the peak limits that are described in this section, you should consider how to dedicate directory resources to Exchange. For example, you can try to reserve domain controllers for Exchange use by being clever with DNS. By appropriately configuring SRV record priorities and weights, you can frequently obtain almost the same effect as you would obtain by using a dedicated site. For more information about how to make this configuration, see the "Isolate Client Authentication Traffic from Exchange Facing Domain Controllers" section of the downloadable topic, Microsoft IT Showcase: C reating a n Active Directory Site for Exchange Server.[]

You can define a static set of domain controllers for use by a particular Exchange server by using the set-ExchangeSe r v e r cmdlet. This definition lets you keep Exchange from using domain controllers that are dedicated to other applications. Although this is better than creating a dedicated site, it is not optimal from the perspective of ongoing management. This is because you have to remember which GCs belong to whom, and then manually tune and maintain lists instead of letting Exchange automatically optimize the load balancing.

If you cannot prevent another application from overwhelming the domain controllers that are needed by Exchange, consider your options for restricting or isolating that application instead of protecting Exchange in a dedicated site. If you have more than five Active Directory sites in your environment, avoid putting Exchange 2007 into a dedicated site.

In an environment that is more complex than five sites, it is unlikely that you can design a dedicated site topology that works well for routing. If you try to do this, you must force the Exchange 2007 routing topology into the shape that you want, regardless of the Active Directory site topology. Also, you will have to continue to manage and maintain a message routing topology and an Active Directory site topology that do not mesh.

Exchange and Active Directory are deeply entwined. Exchange 2007 takes advantage of this synergy to simplify and focus message routing, and make it easier to troubleshoot. You can use this relationship to your favor. If your Exchange routing needs are at odds with your AD site topology, you should consider redesigning both topologies.