Exchange 2000 and Exchange 2003 store user configuration data in Active Directory (AD). Prior to Exchange 2000, user configuration data was stored in a dedicated Exchange directory. Each server had its own directory that matched user accounts to mailboxes stored on the server. Exchange 5.5 does use replication, but it tends to focus more on servers than user data.
In Exchange 2000/2003, replication works differently. No longer does each server have its own directory. Instead, all user configuration data is collectively stored in Active Directory.
The basics of Active Directory
The core component of Active Directory is a domain controller. A domain controller is a server that performs authentication for the domain. When a user enters their login name and password, the domain controller decides whether or not the user should be granted access.
The domain controller can perform authentication functions because it contains a copy of the Active Directory database. User accounts are treated as objects within that database. Consequently, all user configuration data is treated as an attribute of the user object. For example,
A domain will typically have at least two domain controllers, and possibly many more. Each domain controller maintains its own copy of the Active Directory database. If a domain controller fails, another domain controller can still authenticate users that are logging in. If a domain controller has a hard disk failure, multiple domain controllers will also prevent a loss of user accounts (and other types of objects that Active Directory stores), because there is a copy saved on another server.
As you can see, it makes good sense to have multiple domain controllers. When changes are made to Active Directory, replication ensures that those changes are copied to the other domain controllers in your organization.
A password reset scenario
Like an e-mail address, a password is an attribute of a user object. When you reset a password, you basically modify the password attribute on the user's AD account object. The problem is that the change is only applied to a single domain controller.
That domain controller then replicates the changed information to the other domain controllers. So, within a matter of minutes, each domain controller is aware of the password reset.
The same principle holds true for any attribute that gets added or modified. For example, if you were to create an Exchange mailbox for a user, the link to the mailbox would be a stored attribute on the domain controller, which would then be replicated to your other domain controllers.
The multi-master domain controller model
Windows 2000 and Windows 2003 use what is known as a multi-master domain controller model. This means that, when objects are created or deleted or their attributes are modified, the changes can be written to any domain controller in your domain.
In NT 4.0, changes to domain objects had to be written to a special domain controller known as the primary domain controller (PDC). From there, the PDC would replicate the changes to backup domain controllers (BDCs). Only the PDC could write to the backup domain controllers.
Today, Windows Server doesn't natively use a PDC/BDC domain controller model. The multi-master domain controller model has for the most part replaced it. Even so, both Windows 2000 and Windows 2003 offer backward compatibility with NT domains. In such environments, one of the Windows 2000 or Windows 2003 servers acts as a PDC emulator.
During the replication process, two domain controllers replicate with each other at a time. These domain controllers are known as replication partners. You might expect the domain controller that received a change to replicate that change directly to all other domain controllers. But things often don't work that way.
Instead, Windows performs the replication in the most efficient manner possible. Domain controller A might replicate data directly to domain controllers B and C. Or domain controller A might replicate data to domain controller B, which then replicates the data to domain controller C. It just depends on which method Windows deems to be more efficient.
Windows has a built-in mechanism called the Knowledge Consistency Checker that runs on each domain controller. Its job is to establish a replication topology for the domain based on the placement of the domain controllers. Windows then uses this information to decide which domain controllers should be replication partners.
Mixed mode Exchange replication
At the beginning of this article, I mentioned that Exchange 2000 and Exchange 2003 store information in Active Directory, but that Exchange 5.5 uses a dedicated Exchange directory. Even so, it is possible for an Exchange organization to contain Exchange 5.5 and Exchange 2000/2003 servers.
Exchange allows you to create a connection agreement between Exchange 5.5 and Exchange 2000/2003 servers. This connection agreement basically insures that Exchange-related changes written to AD are also written to the Exchange directory, and vice versa.
Aside from this one aspect, replication works the same way in a mixed Exchange environment as it does in a pure Exchange 2000/2003 environment.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Please let others know how useful this tip is via the rating scale below. Do you have a useful Exchange Server or Microsoft Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.
This was first published in November 2005