Introduction

Exchange 2000 and Exchange Server 2003 are completely dependent on a functioning Active Directory infrastructure. Exchange 5.5 used its own independent directory that contained mailbox objects that were separate from their corresponding Windows NT domain accounts. Exchange permissions were completely separate from Windows NT permissions, and Exchange had its own authentication and authorization mechanisms for controlling access to Exchange data. In Exchange 2000 and Exchange Server 2003, all authorization and authentication is built on Active Directory. Almost every aspect of Exchange's normal operation depends on Active Directory in some way:

• When a user attempts to log on to a mailbox (whether through MAPI, HTTP, IMAP, or POP), her credentials are passed to an Active Directory domain controller for validation.

• Each server's routing engine retrieves an initial copy of the routing link state table from the forest configuration container, making initial convergence of the routing table much faster.

• When mail arrives at a server, the categorizer component of the Exchange transport core looks up the recipient addresses in Active Directory to decide if the recipient has a mailbox on that server or if it must be routed to another server in the organization.

• A wide variety of properties and controls for various operations (including automatic conversion of distribution groups to security groups, the location of the SMTP queue directories, and Exchange system policies) are stored as properties on the Exchange organization object and its children.

A complete discussion of Active Directory architecture and design issues is far outside the scope of this book (try O'Reilly's Active Directory, Second Edition if you're looking for more background). However, a little background on how Exchange communicates with, and depends on, Active Directory will help make the recipes in this chapter clearer.

Domains, Forests, and Trees

If you're familiar with Exchange 5.5, you may find the variety of Active Directory components, structures, and roles a little overwhelming. Exchange 2000 and Exchange Server 2003 are tightly integrated with Active Directory, but once you understand a few fairly simple concepts you'll probably find yourself more comfortable with that integration.

The first thing to know is that Active Directory data can be partitioned. You're already familiar with the concepts of domains, which are conceptually similar in Windows NT and Active Directory. Each Active Directory domain has a DNS name in addition to the more familiar NetBIOS name.

Active Directory allows the collection of multiple domains into structures known as forests and trees. A tree is a set of domains with a contiguous namespace and a common parent domain: for example, the oreilly.com tree can contain the windows.oreilly.com and macosx.oreilly.com domains. A forest, as you'd expect, is a collection of trees. The forest namespace doesn't have to be contiguous. Windows automatically creates transitive, bidirectional trust between all domains in a forest.

Forests, trees, and domains can be represented as naming contexts, or NCs. In addition, there's a special NC known as the configuration NC that lives at the forest level. The point behind these contexts is to allow applications (and the operating system) to store data at the appropriate level. For example, domain-level objects like computer accounts live in the domain NC.

Where Exchange Stores Configuration Data

Exchange depends on stored data in Active Directory. Most obviously, Windows uses the user objects held in the domain NCs within the forest to authenticate access requests, including those coming from Exchange. However, most of the data specific to Exchange's configuration and security is actually held in the configuration NC. When you install Exchange 2000 or Exchange Server 2003 for the first time in a virgin forest, or when you enable the Active Directory Connector to link an existing Exchange 5.5 organization to your forest, an object for the Exchange organization is created in the configuration NC. This object is immediately beneath the Exchange object in the configuration NC (cn=Microsoft Exchange, cn=Services, cn=configuration, dc=<yourDomain>), and it has the name you gave your Exchange organization during initial setup. Beneath the Exchange organization object, there are separate containers for address lists, administrative groups, connectors, recipient policies, system policies, and Exchange settings that should apply to all Exchange servers in the domain. These containers are used to store configuration settings that apply to all servers in the organization.

If you expand the administrative groups object, you'll find individual objects for the administrative groups themselves; in each administrative group is the cn=servers object, which has one child object for each server. These server objects store most server-specific settings. Keeping these settings in Active Directory instead of in the local registry or metabase means that ESM can easily find and display settings for any server from any computer in the forest. Many components, such as the routing engine, get settings primarily from Active Directory. Some Exchange components (notably the SMTP and HTTP protocol virtual servers) get their settings from the metabase, which is essentially an IIS-specific cross between Active Directory and the Windows registry. A special Exchange service called ds2mb is responsible for reading settings from Active Directory and stamping them into the metabase on each machine. A few (notably the information store and system attendant) get settings from all three locations; this is especially true for machine-specific settings like the diagnostic logging level.

DC Versus GC

It's easy to confuse the roles of the domain controller (DC) and the global catalog (GC) in an Exchange network: their acronyms are confusingly similar, and so (at first glance) are their functions. A DC for a particular domain is an authoritative source of information about objects that belong to that domain. Every domain object is represented in the domain NC; for each object contained within the domain, the domain NC stores a complete copy of all of its attributes. These attributes are writable (subject to permissions imposed by the system or the object owner). Every DC in a domain has the same information, assuming that AD replication is working properly, so it doesn't matter which specific DC an application talks to, as long as it can reach one.

The GC is an additional role enabled on a DC. In addition to maintaining a complete writable replica of its own domain NC, it maintains a partial read-only replica of objects from every other domain NC in the AD forest. The "partial" in that sentence indicates that, for objects that are present in the GC, not all attributes of that object are available. That means that the GC can answer lots of interesting queries (for example, "what server contains the mailbox for the user account paulr?") for any domain in the forest, not just the domain it happens to belong to. This makes it ideal for use with Exchange, since Exchange 2000 and 2003 are explicitly designed to run properly when users, servers, and recipients are spread across multiple domains in a forest.

The Role of DSAccess

Exchange uses a special-purpose service DLL called DSAccess to talk to Active Directory. Among other things, DSAccess is responsible for building a list of available DCs and GCs, deciding what roles those servers can play, and balancing query traffic between available servers in a particular role. For our purposes, it's enough to think of DSAccess as the intermediary between Exchange components that don't talk directly to the directory (such as the categorizer and System Attendant) and Active Directory.

Exchange actually divides directory servers into three separate roles:

• The GC role represents servers that can be used to access user account and property information across all domains in the forest. DSAccess communicates with these servers using LDAP on TCP port 3268 (the default; SSL-protected LDAP sessions will use port 636, and you can change either of these ports if necessary). DSAccess will query a DC to get the list of available GCs, then load-balances future queries against the list of available GCs. This list can contain up to 10 GCs from the local site, or up to 200 GCs from other sites.

• The DC role represents servers that can be used to answer queries where DSAccess knows what domain contains the requested object. DSAccess communicates with these servers using LDAP on TCP port 389 (the default standard LDAP port). DCs are dynamically detected every 15 minutes. As with the GC role, DSAccess maintains a list of up to 10 DCs, whether or not they're in the local site.

• The configuration role represents the DC used to retrieve information from, and write information to, the forest configuration naming context. Remember that Exchange uses the configuration NC to store information about the Exchange organization, and the routing and administrative groups defined therein, because this container spans all domains in the forest. Unlike the other roles, DSAccess will only use one server at a time for configuration requeststhat prevents issues arising from two different servers that may contain different Exchange configuration data until replication converges. Every eight hours, DSAccess retests the chosen configuration server to ensure that it's still suitable. If the selected server fails this test, or if it becomes unavailable before the eight-hour period expires, DSAccess will choose another DC from the DC list.

Obviously, a single DC can fulfill all three of these roles; it's equally possible for all three roles to be handled by separate DCs. The interesting part comes about when you consider how DSAccess decides which servers to use for these roles. The basic process is fairly simple:

1. When the System Attendant starts, it opens an LDAP connection to a randomly chosen DC in the domain that contains the machine where the SA is running. Microsoft calls this initial DC the bootstrap server .

2. When DSAccess starts, if you've configured specific GCs or DCs (as described in Recipe 3.2), DSAccess will use those. If not, it will query the bootstrap server to find out what Active Directory site the Exchange server is in and what secondary sites are connected via site link or site link bridge objects; it uses this information to give preference to local GCs and DCs in the availability lists for those roles.

3. DSAccess uses the DC connection to the bootstrap server to determine if any of the DCs in the local site are also GCs. If there aren't any local site GCs, DSAccess will use any available GC in the forest. In this situation, there won't be any load balancing; DSAccess assumes that using multiple GCs in a remote site might flood a slow inter-site link.

4. The configuration role is set to the first local DC found by DSAccess. If you force DSAccess to use statically set servers for the DC role, DSAccess use the first designated server.

If individual DC or GC servers go down, they're marked as down and rechecked every five minutes. If all of the DCs for a particular role fail, and you're not statically assigning roles, DSAccess will repeat the process described above to redetect available DCs for the role. If you are using static assignments and all assigned DCs for a role fail, Exchange will basically be useless until those DCs come back upit won't attempt to dynamically detect DCs since you told it not to. Redetection also happens when the Exchange server's Kerberos ticket expires (by default, it's good for ten hours), when DCs or GCs are added or removed in the local site or domain, or when the System Attendant process is restarted. This process is significantly simpler when you install Exchange on a DC, since DSAccess will always attempt to use the local service unless it's unavailable.

The Role of DSProxy

The DSProxy component has one simple job: it provides a way for Outlook clients using MAPI (or, more precisely, the Name Services Provider Interface, NSPI) to get address book information. In the original Outlook and Exchange design, every Exchange server had its own directory; with Exchange 2000 and Exchange Server 2003, that's no longer true, because directory services are provided by Active Directory. MAPI provides a referral mechanism that allows an Exchange server to tell the client where the directory server really is; DSProxy's first job is to generate those referrals for clients that can use them. In this case, that means Outlook 2000 Service Release 2 (SR2) and later, which understands the referral mechanism. Once these clients receive a referral, they're smart enough to communicate directly with the Active Directory services on the referred server. Earlier versions of Outlook don't do this, which leads to the second reason for DSProxy's existence: it accepts NSPI requests and proxies them to Active Directory, emulating the MAPI address book provider provided by Exchange 5.5.

The Role of the Recipient Update Service

The recipient update service, or RUS, is responsible for applying addresses to addressable objects. This sounds simple, and for the most part it is. Every mail-enabled object has to have at least one proxy address associated with it, and the RUS generates that address and applies it to the object according to whatever recipient policies apply to that object class (and the specific object). Besides the proxy address, the RUS also updates a variety of other attributes, including the home mailbox database for mailbox-enabled objects, the object display name, and the Exchange 5.5-style distinguished name (DN) of objects that live in mixed-mode environments. There will normally be two separate RUS instances in an Exchange organization: the enterprise RUS is responsible for stamping attributes on system objects, and the domain RUS applies attributes to objects in an Active Directory domain. If you install Exchange in another domain within your forest, you'll notice that a RUS for that domain is automatically created; however, if your Exchange servers are in different domains than your user and group objects (as when you have a resource forest design), you can create multiple instances of the RUS (see Recipe 3.7) to give you more control over RUS behavior in individual domains.

The RUS has another important function. You can create security or distribution groups that have hidden membership, but Exchange can't expand these groups to send mail to the group members! When it encounters such a group object, the RUS adds some nonstandard access control entries to the group object to allow Exchange to expand the group without allowing other users to do the same thing.

Where to Learn More

For Exchange 2000, Microsoft has an excellent white paper, Understanding and Troubleshooting Directory Access, that discusses the algorithm Exchange uses to locate the best domain controllers; this white paper is available for download at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=c976433f-f979-4745-b7a6-9d8446ef6409&amp;DisplayLang=en.

Almost all of the mechanisms it describes are identical in Exchange Server 2003, so this paper's a good reference for either version. The process of topology selection for Exchange Server 2003 is different in some respects; the best guide to it is Chapter 3 of the Exchange Server 2003 Technical Reference Guide:

http://www.microsoft.com/technet/prodtechnol/Exchange/guides/E2k3TechRef/3d005e5c-c5c6-4bcc-b72f-1ad6069bc917.mspx