Windows 7 / Getting Started

---

Active Directory for Exchange Server

To say that Exchange depends on the performance of Active Directory is something of an understatement. Exchange Server is very tightly tied to Active Directory (AD) and cannot function properly if AD is not configured properly. Exchange utilizes the Configuration Naming Context of AD for storing information about all Exchange servers, address lists, policies, and so forth - almost any piece of Exchange information that is not recipient related. Recipient information (contacts, users, distribution lists, etc.) is stored in the Domain Naming Context of AD. Every Exchange object has a corresponding entry in AD. Even a mailbox, which resides in the Exchange mailbox database, is tied to an AD user and has both a GUID (Globally Unique Identifier) and a legacyExchangeDN (basically an X.500 address). These attributes on the user object point from the AD to the mailbox within the Exchange database.

The Configuration Naming Context (ConfigNC) of Active Directory is a part of AD called a partition. This partition is replicated to every single domain controller (DC) that is contained within an AD forest. That is, every DC has a copy of the ConfigNC, so every DC has a copy of all information about Exchange Server and organization configuration. However, the Domain Naming Context (DomainNC) partition only resides on DCs that are within a specific domain. Therefore, full recipient information is not on every DC. Exchange identifies certain types of recipient information (such as email addresses) as needing to be more widely available by marking them as a member of the Partial Attribute Set (PAS). Attributes in the PAS are present on every global catalog server in the global catalog partition.

Since Exchange currently stores server and configuration information in the ConfigNC in a specific way, there may be only one Exchange organization installed per AD forest. Exchange will normally use any available DC to obtain information about server and organization configurations. However, that isn't possible for recipient information. To obtain recipient information, Exchange is heavily dependent on global catalog (GC) servers.

Since most of what Exchange does deals with recipients (receiving email for a recipient, sending email from a recipient, expanding a distribution list of recipients, checking out delegate permissions, etc.), most of Exchange Server's interaction with AD on a volume basis is via GCs. This leads to a requirement that every AD domain that contains an Exchange server must have at least one GC within the domain (and preferably a minimum of two for resiliency in the case of a GC failure).

In medium-sized and large organizations with an already established AD environment, the impact of Exchange Server to that environment can be surprisingly high. The AD requirements of Exchange can be so high that it is common for Exchange Server to have a parallel forest stood up just for its needs.

In small and most medium-sized environments, this is a nonissue. However, the Exchange administrator must be aware of the performance of the AD that is supporting Exchange and (if the Exchange administrator is not an AD administrator) when that performance becomes strained, ensure that the AD performance is improved.

Three key counters in Exchange Server 2010 need to be monitored in the MSExchange ADAccess Processes performance object. This object has an instance for each process in the Exchange application that accesses AD, as well as an <All Instances> instance. The interesting counters in the object are

• LDAP Read Time
• LDAP Write Time
• Number of Outstanding Requests

The read and write counters should average below 50 ms. The number of outstanding requests counter should average zero. Generally, tracking <All Instances> is the right place to start in determining a performance issue; then you need to investigate each instance to acquire more detailed data.

Another interesting counter for Active Directory is MSExchange ADAccess Domain Controllers\Local Site Flag. The value of this counter is one if the instance of the counter is a DC in the local site; otherwise the value is zero. A particular Exchange server will perform much better if all DCs are in the same site as the Exchange server. Among other attributes, local sites are assumed to be well connected.