Exchange Server's Use of Domain Controllers

If you’ve ever had to install and maintain Exchange Server (any version since Exchange 2000), you know that it is pretty picky about its domain controllers.

‘Way back when, in Exchange 5.5 and before, Exchange didn’t care about domain controllers. That was because Exchange had its own directory built right in and there was a copy of that directory on every Exchange server.

Starting with Exchange 2000, Exchange uses Active Directory instead. In order to use AD, Exchange has to communicate with a domain controller. And Exchange uses that domain controller for lots of things, some not so obvious.

For example:

• To find out a person’s email address
• To find out a contact’s email address
• To find out the email address of a public folder
• To find a distribution group
• To find out where someone’s email should be delivered
• To find out who can modify a distribution group
• To find out which mailbox server a user should be connected to
• To load all Exchange configuration information
• and many others

Since Exchange was originally designed with an on-board directory, it uses a great deal of directory information. In order to reduce the impact of Exchange queries and updates to Active Directory, Exchange maintains a series of caches to optimize the access to the Active Directory. There are three caches, named:

• DSAccess - caches information about user objects
• Mailbox info - cache information about mailboxes, including security
• Mailbox limits - cache information about mailbox limits and quotas

The DSAccess cache is, by default, only five minutes. The first Mailbox info cache has a default of two hours. The Mailbox limits cache, which is fed from the Mailbox info cache, is also two hours. The impact of this tiered cache is that, under the worst possible conditions, it can take up to four hours for a change that you make in Active Directory Users and Computers (Exchange 2000/2003) or the Exchange Management Console (Exchange 2007) to take effect. By that time, you may have been so frustrated that you rebooted your server! Of course, after you rebooted the change was in effect. Now you know better.

There are mechanisms for changing these cache values. For Exchange 2000 and 2003, refer to the Microsoft Knowledge Base article KB 327378. For Exchange 2007, see this TechNet article: https://technet.microsoft.com/en-us/library/bb684892.aspx.

While most of us probably use Exchange in a single-domain forest, Exchange is architected to work in large organizations that may have many domains contained within their Active Directory forest. This means that Exchange may potentially need to have information about users whose information is stored in domains other than the one you are stored in. This is why Exchange generally will use Global Catalog servers in preference to normal domain controllers. Global catalog servers store selected information about every object in an Active Directory forest. The Global catalog is also often referred to as the “partial attribute set” because the selected information is only a small subset of the total information available about each object. Include in the information is all of the information that Exchange requires about each object.

The primary case when Exchange doesn’t use a global catalog server is when Exchange is making changes to itself - that is, updating Exchange configuration information. Exchange configuration information is stored in a special piece of Active Directory known as the “configuration naming context”. This part of Active Directory exists upon, and is replicated to, all domain controllers, not just global catalog servers.

As a final note for today, Exchange examines the Active Directory environment every 15 minutes. Therefore, if a particular server goes offline and another comes back online within that time frame, it may take up to 15 minutes for Exchange to recognize and respond to that change.