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.

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.

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.

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:

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:

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 up—it 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 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 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.

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:

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:

You need to know which DCs and GCs your Exchange server is currently configured to use, and whether they have been manually assigned or auto-discovered.

The GUI method is straightforward if you are running at least Exchange 2000 SP2. Frankly, if you are still running SP1 or original Exchange 2000, you have bigger problems to worry about. Still, you can find at least a small bit of the information by looking at the field labeled Domain controller used by services on this server on the General tab of the server properties dialog in ESM.

It is normal to see multiple DC instances; at a minimum, you’re going to have three: one for the configuration DC, one for the DC role, and one for the GC role. The additional instances are used for redundancy and failover. DSAccess will allow only one configuration DC instance, to minimize update issues caused by replication latency in Active Directory’s multi-master architecture.

On a machine that is both a DC and Exchange server, you will only see three entries no matter how many other DCs you may have deployed; they will all be the local machine (see Recipe 2.9). This is because when you combine these roles, Exchange makes the optimization decision that you probably only have one DC (as when you’re running Small Business Server)—a reasonable decision in most cases.

Recipe 2.8 for more on installing Exchange on a DC, Recipe 3.2 for more on forcing Exchange to use specified DCs, Recipe 3.3 and Recipe 3.4 for more on verifying which DCs and GCs are in use, and Recipe 3.8 for troubleshooting the DSAccess discovery process; the Understanding and Troubleshooting Directory Access Microsoft white paper, Chapter 3 of the Exchange Server 2003 Technical Reference Guide, and MS KB 316300 (Event ID 2080 from MSExchangeDSAccess); MSDN documentation for the Exchange_DSAccessDC class

You need to override the DSAccess auto-discovery algorithm and configure your Exchange server to use specific domain controllers.

This is a straightforward continuation of the previous recipe. Note that if your Exchange server is also a DC, you will not be able to disable auto-discovery and you will not be able to add or remove instances by any method.

Adding manually-configured entries previous to Exchange 2000 SP2 is a bit different than SP2 and later. In Exchange 2000 and SP1, you cannot set the Configuration DC type via any method. Instead, Exchange examines the list of auto-discovered DCs and chooses the first one to be the configuration DC.

Recipe 3.1 for determining which DCs Exchange is using, MS KB 250570 (Directory Service Server Detection and DSAccess Usage), and the Understanding and Troubleshooting Directory Access Microsoft white paper

You want to know which DC ESM is using to retrieve and display information from Active Directory, or you want to control which DC it will use.

ESM displays information about the Exchange organization by reading information from the configuration partition in Active Directory. You may be surprised to learn that ESM doesn’t choose a DC using DSAccess, but rather on its own using ADSI serverless binding. Due to replication delays and possible problems, the information on one DC may not be entirely consistent with the information on another DC. Unfortunately, there is no way to determine which DC ESM is using from within the tool itself. This can be frustrating in situations where the information displayed by ESM does not match with what you expect and you want to know the DC name to start some troubleshooting.

The GUI method to determine the DC uses the Process Explorer tool from www.sysinternals.com. It is probably the simplest method to use. The only wrinkle we’ve found is if you start ESM after you’ve started Process Explorer, you don’t see the ESM icon associated with mmc.exe. This can cause some confusion if you have more than one mmc snap-in open.

The command-line method is a little cumbersome, but does the job. Before using this method, it is advisable to close all open MMC snap-ins and then start ESM to avoid confusion with tasklist.exe finding multiple MMC snap-ins.

The second GUI method shows how to specify the DC you want to use with ESM at startup. Not many people know about this because they tend to launch ESM directly from the Microsoft Exchange group in the programs list that is created when you install the Exchange System Management Tools. Sadly, it is not possible to connect to a different DC once ESM has started, as you can with ADUC. Hopefully, Microsoft will implement this feature in a future Service Pack.

How ESM discovers domain controllers (http://blogs.msdn.com/exchange/archive/2004/02/16/73915.aspx)

You need to remove all traces of Exchange from Active Directory.

It is sometimes necessary to remove all Exchange-related objects from AD (bearing in mind that you can’t back out of the changes Exchange forestprep operations make to the schema). This is typically done when you’re cleaning up a failed installation to try again, or when you’re rebuilding a test or lab system but don’t want to have to roll back to a previous backup. The Exchange installer will remove the binaries, but it purposefully doesn’t touch anything in AD. Removing Exchange manually from AD is a tricky job—Exchange hooks deeply into AD, and it is often very hard to remove Exchange’s tentacles. If you are unsure if the remove operation has removed all traces of Exchange, you can follow the instructions in MS KB 260378 to verify that Exchange has been fully removed. If you’re trying to remove the first Exchange 2000 or Exchange Server 2003 server in an administrative group, you should check the steps described in MS KB 822931; the procedure described in this recipe doesn’t clean up Exchange-specific objects and shouldn’t be used for that purpose.

MS KB 822931 (How to remove the first Exchange Server 2003 computer from the administrative group), MS KB 260378 (How to Manually Remove an Exchange 2000 Installation), MS KB 273478 (How to Completely Remove Exchange 2000 from Active Directory), MS KB 312878 (The Exchange 2000 Service Pack 2 Removeorg Option for Update.exe), and MS KB 830185 (The REMOVEORG option in Exchange Server 2003)

The forest functional level can only be changed to Windows 2003 after all NT4 and Windows 2000 domain controllers have been either removed or upgraded to Windows Server 2003; once you have removed all of those older machines, you can raise the domain functional level of each domain in the forest. After all domains’ functional levels have been raised, you’ll be able to raise the forest functional level. The forest functional mode in Windows 2003 enables several Windows 2003-specific AD features, such as the ability to deactivate or redefine classes and attributes within the schema and the ability to rename a domain.

The msDS-Behavior-Version attribute identifies the forest functional level within Windows Server 2003. A setting of 0 indicates a Windows 2000 forest functional level, 1 indicates Windows 2000 interim mode, and 2 indicates Windows Server 2003 mode. The status of your forest can also be viewed by using ADSI Edit (from the Windows 2000 and Windows 2003 Support Tools) and drilling down through the Configuration container to the CN=Partitions object, then right-clicking the object and selecting Properties from the drop-down listing. You can then find the msDS-Behavior-Version attribute in the Select a property to view area; once this attribute is selected, you can view the current value.

Chapter 2 of Active Directory Cookbook for Windows Server 2003 and Windows 2000 (with special thanks to Robbie Allen for allowing us to reuse much of his recipe), for changing the functional level of a forest, and MS KB 322692 (Raise the Domain Functional Level in Windows Server 2003)

You want to apply Exchange settings like the GC/DC profiles described in Recipe 3.0 to all the servers in your organization.

There are several ways to apply settings to Exchange servers. Depending on the kind of setting you’re changing, the value that Exchange uses may come from Active Directory, the IIS metabase, or the local machine’s registry. Exchange system policies (described in Recipe 4.5) allow you to set some policies on a per-administrative group basis, but if you have a setting that depends on registry keys, you’ll need to use the group policy object mechanism to get these changes applied to the servers en masse. If you want to create custom values for registry-based settings across Exchange servers, the simplest way to do so is to create a template (or ADM file) and attach it to a group policy object. For example, you can create a template that implements the Outlook Web Access 2003 timeout settings (described in MS KB 830827), then apply the template settings to the OU that contains all of your Exchange OWA servers. The template format is documented on MSDN.

Recipe 4.5 for using Exchange system policies, “Administrative Template File Format” definition on MSDN (http://msdn.microsoft.com/library/en-us/policy/policy/administrative_template_file_format.asp), Chapter 9 of the Active Directory Cookbook, and Chapter 6 of Learning Windows 2003 (O’Reilly)

You need to ensure that additions, deletions, and changes to mail-enabled objects are updated in the GAL in a timely fashion, even in domains with no Exchange servers or where large numbers of directory changes are common.

The RUS is the component of Exchange that watches over changes to the various mail-enabled objects, recipient policies, and address lists in the domain to make sure that all changes are visible in a timely fashion. By default, there is one Enterprise Configuration instance for the entire organization, as well as one for each domain in which an Exchange server has been installed. If there is no RUS instance corresponding to a domain (as would be the case in certain Exchange deployments) then no recipients can be created in that domain unless you stamp the attributes yourself.

Each instance is tied both to a specific DC and a specific Exchange server. There can only be one RUS per DC (with the sole exception of the Enterprise Configuration instance), but an Exchange server can host multiple RUS instances (each of which will take a small amount of processor and memory resources). In a mixed Exchange 2000/2003 organization, instances may be hosted on either version of Exchange.

Normally, Exchange will add RUS instances as needed. However, if you have a large AD domain that spans multiple sites and network latency is an issue, you might consider installing additional instances so that there is at least one per site. This ensures that updates, no matter where they are generated, are quickly reflected in the organization address lists. However, in some environments this introduces problems with duplication of proxy addresses; a better general approach is probably to reduce the replication latency between sites first, and if that doesn’t work, add more RUS instances.

Another case that requires the manual configuration of RUS instances are domains that will host mail-enabled objects, but do not have an Exchange server installed within them. A somewhat common example of this situation is the placeholder root domain configuration. In this instance, this also gives the benefit that Exchange servers can make use of GCs in the root domain in the event that none are available in the child domains.

In theory, the addition and removal of RUS instances is scriptable via ADSI; MSDN documents the MS-Exch-Address-List-Service-Container class in the AD schema. This class is the base of all RUS instance containers. In practice, there are a formidable number of properties that must be configured with the appropriate GUIDs for various servers and domain; these linkages are not documented and there are no methods provided in the various scripting interfaces to create or manage RUS instances themselves.

Since you can easily add RUS instances for your entire organization through the same node in ESM, and since these assignments should be relatively stable, stick to using ESM to manage your RUS instances.

Recipe 5.19 for working with recipient policies, MS KB 253838 (How the Recipient Update Service Applies System Policies), MS KB 288807 (Troubleshooting the Recipient Update Service), and MS KB 319065 (HOW TO: Work with the Recipient Update Service in Exchange 2000)

You notice that DSAccess is using a DC or GC that is out of site, or otherwise not optimal, and you want to know why.

We know from the description of the role of DSAccess earlier in this chapter that it is central to the smooth running of Exchange. Hence, when things go wrong it is useful to know what view of AD Exchange has. Setting diagnostics logging for DSAccess Topology lets us do this. DSAccess uses a wide range of criteria to determine which DCs and GCs are most suitable for it to use. Sometimes changes in the AD environment, either planned or unplanned, can impact the DCs and GCs selected by DSAccess. For example, if your AD team removes the only GC from a site, or if that GC is unavailable due to a problem, Exchange will start to use an out-of-site GC, which can severely degrade Exchange performance. Setting Diagnostics Logging for DSAccess Topology discovery will help you to identify the problem quickly.

MS KB 316300 (Event ID 2080 from MSExchangeDSAccess), Exchange 2003 Technical Reference Guide:

and the Understanding and Troubleshooting Directory Access white paper:

Exchange ForestPrep was run at the time that the AD forest was first implemented and you now need to know which account or group has been granted Exchange Full Administrator permissions.

Many larger organizations tend to run Exchange ForestPrep at the time the AD forest is implemented. They do this to avoid the replication impact caused by running ForestPrep in a fully populated, live AD infrastructure. This may precede the installation of the first Exchange Server 2003 Server by some time and it may not be well documented. At the time Exchange ForestPrep is run, the setup program prompts for an account (or group) name. This account or group is then given Exchange Full Administrator permissions. When you want to install the first Exchange server, you may need to check, and optionally change, the account or group has been assigned these permissions.

The reason Exchange Server 2003 ForestPrep stamps a GUID instead of an organization is quite sensible. It gives you more flexibility to change your mind about the name in the time between running ForestPrep and installing the first Exchange Server 2003 Server. The Exchange 2000 ForestPrep would assign an organization name as one of its tasks, making it necessary to run setup with the /removeorg option if you subsequently wanted to change the organization name.

MS KB 312371 (HOW TO: Prepare the Forest by Using ForestPrep in Exchange 2000 Server)