Active Directory Integration Tuning


Topic Last Modified: 2005-06-28

All Exchange servers and users should have fast access to a global catalog server. The proximity of the global catalog server to both the Exchange server and to the client computer directly affects the performance of the client. At least one global catalog server must be installed in each domain that contains Exchange servers; to achieve optimal performance in larger organizations, additional global catalog servers are required.

Per site, there should be a 4:1 ratio of Exchange processors to global catalog server processors, assuming that the processors are of similar models and speeds. However, increased global catalog server usage, large Active Directory implementations, increased application usage, or large distribution lists can necessitate more global catalog servers. Exchange 2003 can utilize global catalog servers that have up to eight processors installed.

Planning the number of global catalog servers required for your Exchange Server 2003 installation can be time-consuming. You should implement one global catalog processor for every four Exchange Server 2003 processors and then fine-tune as necessary. With this rule, it is assumed that the processors are of the same class and speed. For example:

  • A single-processor global catalog server can handle the load of a single 4-processor Exchange 2003 server.

  • Two single-processor global catalog servers can handle the load of a single 8-processor Exchange 2003 server.

  • Four 4-processor global catalog servers can handle the load of eight 8-processor Exchange 2003 servers.

Exchange Server 2003 can use global catalog servers that have up to 8 processors installed. However, you must take into account the 75 percent scaling factor between 4 and 8 processors for Active Directory servers. Therefore, an 8-processor global catalog should be considered as a 7-processor server when performing global catalog to Exchange ratio calculations.

If you have a high concentration of Exchange 2003 servers, you must dedicate a set of global catalog servers for Exchange. Create a dedicated Active Directory site that contains both the Exchange 2003 servers and any dedicated global catalog servers. There are several positive effects here:

  • Traffic from systems other than Exchange Server 2003 is distributed to other Active Directory servers in the organization.

  • Performance analysis and management of Active Directory is easier.

  • The Exchange administrator has better control over the Active Directory servers that are dedicated for Exchange.

Applications other than Exchange can make heavy use of the primary domain controller (PDC) emulator computer. If Exchange Server 2003 also tries to use the PDC emulator computer for its requests, the performance of the PDC emulator and Exchange can decrease. By default, DSAccess picks up the PDC emulator computer for request together with other servers in the local Active Directory site. However, you can add the MinUserDC value the registry to change this behavior.

For detailed instructions, see How to Set the MinUserDC Registry Value.

The Active Directory process uses the Extensible Storage Engine (ESE) for its database. By default, the ESE cache size is 512 MB. However, if you use Windows 2000 Advanced Server or Windows Server 2003 (any edition) for your global catalog servers, and you have more than 1 GB of physical RAM installed, you should set the /3GB switch in the Boot.ini file of these servers. This action automatically increases the ESE cache to 1024 MB. In most circumstances, having a larger cache reduces the number of disk reads by 20-40 percent and dramatically reduces LDAP response times.

On systems that have 1 GB or more of physical memory, it is recommended that you use the /3GB startup switch in the Boot.ini file. This helps reduce the amount of memory fragmentation in the virtual address space of the Active Directory process.

The /3GB switch should only be used on Active Directory servers with 1 GB or more of memory that are running any of the following operating systems:

  • Microsoft Windows Server 2003 Standard Edition

  • Microsoft Windows Server 2003 Enterprise Edition

  • Microsoft Windows Server 2003 Datacenter Edition

  • Microsoft Windows 2000 Advanced Server

  • Microsoft Windows 2000 Datacenter Server

The /3GB switch should not be used on Windows 2000 Server because it is unsupported and can cause application or operating system crashes. Furthermore, the /3GB switch is only supported on the above operating systems when 1 GB or more of physical memory is installed.

For detailed instructions about how to set this switch in the boot.ini file, see How to Set the /3GB Startup Switch in Windows.

For the best scalability and administrative flexibility, Exchange Server 2003 should be installed on a Windows member server instead of a domain controller or global catalog server. The latter scenario is supported, but you should be aware of the consequences:

Threads in the Lsass.exe process run at a higher priority than Exchange threads. An increase in the Lsass.exe process can adversely affect Exchange processing time.

If the Exchange server also acts as a domain controller, the server spends resources on other non-Exchange requests, such as user authentication and directory lookups for other applications. This additional activity affects performance on the Exchange 2003 server.

Although DSAccess detects all domain controllers and global catalog servers in the local Active Directory site, it does not use them. All directory requests are sent to the local directory service. Load-balancing and fail-over do not occur in this scenario.

To manage Exchange Server 2003 services, the administrator must be defined as a local administrator. If Exchange Server 2003 is running on a domain controller, the Exchange administrator must belong to the Administrators group in the domain. Membership implicitly gives the Exchange administrator additional access to other computers in the domain.

If you are running Exchange Server as a part of Microsoft Windows Small Business Server 2003, you can install Exchange Server on a domain controller. However, if you are not running Exchange Server as part of Windows Small Business Server, it is recommended that you avoid running Exchange Server on a domain controller.

If you are running Exchange Server on a domain controller without Small Business Server, be aware of the following issues:

  • Exchange Server and Active Directory are both resource-intensive applications. There are performance implications to be considered when both are running on the same computer.

  • If Exchange Server is running on a domain controller, you must also make that domain controller a global catalog server.

  • Several Exchange Server directory components, such as Directory Service Access (DSAccess), Directory Service Proxy (DSProxy) and the Message Categorizer will not fail over to any other domain controller or global catalog server.

  • You should not take advantage of the /3GB startup switch in Windows because it could cause Exchange Server to consume all memory, thus starving Active Directory.

  • System shutdown will take considerably longer if the Exchange Server services are not stopped before shutting down or rebooting the server.

  • This configuration is less secure because Exchange administrators will have local administrative access to Active Directory, enabling them to elevate their own privileges. In addition, any security vulnerability found in either Exchange Server or Active Directory exposes the other to compromise.

  • If you are running Exchange Server 2003 on a domain controller, using the domain controller promotion tool (DCPromo) to change the computer role is not supported, and is known to break components such as Outlook Mobile Access.

  • Running Exchange Server 2003 on a clustered node that is also an Active Directory domain controller is not supported and should never be done. This means that if you are running Exchange 2000 Server on a node in a cluster that is also a domain controller, you must demote the server to a member server prior to upgrading from Exchange 2000 Server to Exchange Server 2003.

If there are many Exchange 2003 servers in a Windows Active Directory site that contains Windows 2000-based directory servers, a very large LDAP load can be put on the Active Directory servers. By default, an Active Directory server is configured to support a maximum of 20 active LDAP queries. If this limit is reached, Active Directory returns the LDAP_ADMIN_LIMIT_EXCEEDED error and stops processing any more LDAP queries. A setting of 20 is generally sufficient for most Active Directory servers, but it is necessary to increase this value when you are running Exchange Server 2003 on eight-processor servers, or if the LDAP_ADMIN_LIMIT_EXCEEDED error message is logged.

The maximum LDAP queries can be configured through the MaxActiveQueries attribute. This setting can be adjusted using the Ntdsutil.exe tool. Increasing this setting uses more memory in the Lsass.exe process on the Active Directory server. Therefore, do not increase this value any higher than is necessary.

For detailed instructions about how to increase the maximum number of active LDAP queries, see How to Set the MaxActiveQueries Attribute.

MaxActiveQueries only applies to directory servers running Windows 2000 Server. MaxActiveQueries cannot be set on directory servers running Windows Server 2003.

By default, DSAccess component in Exchange caches objects. The cache is broken into two sections: one section for user objects (that is, domain naming context), and the other section for configuration data such as store and routing objects. User objects are cached for 5 minutes, and configuration data is cached for 15 minutes.

In Exchange 2000 Server, each cache pool was 25 MB. For better performance, the default settings have changed. By default, the configuration data cache in Exchange Server 2003 is 5 MB and the user object is 140 MB.

In very large topologies that contain more than 100 administrative or routing groups, increased performance can be achieved by manually tuning the DSAccess cache sections.

For detailed instructions about how to tune the DSAccess configuration cache, see How to Configure the DSAccess Configuration Cache.

For detailed instructions about how to tune the DSAccess user cache, see How to Configure the DSAccess User Cache.