Share via

Planning for Access to Active Directory

  • Article

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Microsoft Exchange Server 2010 stores all configuration and recipient information in the Active Directory directory service database. When a computer that is running Exchange 2010 requires information about recipients and information about the configuration of the Exchange organization, it must query Active Directory to access the information. Active Directory servers must be available for Exchange 2010 to function correctly.

This topic explains how Exchange 2010 stores and retrieves information in Active Directory so that you can plan access to Active Directory. This topic also discusses issues you should be aware of if you try to recover deleted Exchange 2010 Active Directory objects.

Exchange Information Stored in Active Directory

The Active Directory database stores information in three types of logical partitions that are described in the following sections:

  • The schema partition

  • The configuration partition

  • The domain partition

The Schema Partition

The schema partition stores two types of information: schema classes and schema attributes. Schema classes define all the types of objects that can be created and stored in Active Directory. Schema attributes define all the properties that can be used to describe the objects that are stored in Active Directory.

When you install the first Exchange 2010 server role in the forest or run the Active Directory preparation process, the Active Directory preparation process adds many classes and attributes to the Active Directory schema. The classes that are added to the schema are used to create Exchange-specific objects, such as agents and connectors. The attributes that are added to the schema are used to configure the Exchange-specific objects and the mail-enabled users and groups. These attributes include properties, such as Microsoft Office Outlook Web Access settings and Microsoft Exchange Unified Messaging (UM) settings. Every domain controller and global catalog server in the forest contains a complete replica of the schema partition.

For more information about schema modifications in Exchange 2010, see Exchange 2010 Active Directory Schema Changes.

The Configuration Partition

The configuration partition stores information about the forest-wide configuration. This configuration information includes the configuration of Active Directory sites, Exchange global settings, transport settings, mailbox policies, and UM dial plans. Each type of configuration information is stored in a container in the configuration partition. Exchange configuration information is stored in a subfolder under the configuration partition's Services container. The information that is stored in this container includes the following:

  • Address lists

  • Address and display templates

  • Administrative groups

  • Client access settings

  • Connections

  • Messaging records management, mobile, and UM mailbox policies

  • Global settings

  • E-mail address policies

  • System policies

  • Transport settings

Every domain controller and global catalog server in the forest contains a complete replica of the configuration partition.

The Domain Partition

The domain partition stores information in default containers and in organizational units that are created by the Active Directory administrator. These containers hold the domain-specific objects. This data includes Exchange system objects and information about the computers, users, and groups in that domain. When Exchange 2010 is installed, Exchange updates the objects in this partition to support Exchange functionality. This functionality affects how recipient information is stored and accessed.

Each domain controller contains a complete replica of the domain partition for the domain for which it is authoritative. Every global catalog server in the forest contains a subset of the information in every domain partition in the forest.

How Exchange 2010 Accesses Information in Active Directory

Exchange 2010 uses an Active Directory API to access information that is stored in Active Directory. The Active Directory Topology service runs on all Exchange 2010 server roles. This service reads information from all Active Directory partitions. The data that is retrieved is cached and is used by Exchange 2010 servers to discover the Active Directory site location of all Exchange services in the organization. For more information about topology and service discovery, see Planning to Use Active Directory Sites for Routing Mail.

Exchange 2010 is an Active Directory site-aware application that prefers to communicate with the directory servers that are located in the same site as the Exchange server to optimize network traffic. Each Exchange 2010 organizational server role must communicate with Active Directory to retrieve information about recipients and information about the other Exchange 2010 server roles. The data that each server role obtains is described in the following sections.

By default, whenever an Exchange 2010 server starts, it binds to a randomly selected domain controller and global catalog server in its own site. You can view the selected directory servers by viewing the properties of the Exchange 2010 server in the Exchange Management Console or by using the Get-ExchangeServer cmdlet in the Exchange Management Shell. You can also use the Set-ExchangeServer cmdlet to configure a static list of domain controllers to which an Exchange 2010 server should bind or a list of domain controllers that should be excluded.

Important

A Windows Server 2008 domain controller can be configured as a read-only directory server. This configuration is useful when you want to deploy a domain controller or global catalog server in a remote site for authentication and authorization purposes, but you don't want to allow administrators in that site to write changes to Active Directory. However, you can't deploy an Exchange 2010 server in any site that contains only read-only directory servers.

Hub Transport Server Role

The Hub Transport server role contacts Active Directory when it performs message categorization. The categorizer must query Active Directory to perform recipient lookup and routing resolution. The information that the categorizer retrieves during recipient lookup includes the location of the recipient's mailbox and any restrictions or permissions that may apply to the recipient. The categorizer must also query Active Directory to expand the membership of distribution lists and to perform the Lightweight Directory Access Protocol (LDAP) query processing that is required when mail is sent to a dynamic distribution list.

During routing resolution, the categorizer uses the topology information that is cached by the Active Directory Topology service to discover the routing path for a message. The Hub Transport server uses Active Directory site configuration information to determine the location of other servers and connectors in the topology.

When the Hub Transport server has resolved the location of the recipient's mailbox, it uses Active Directory site information to locate the mailbox store. If the mailbox store is in the same Active Directory site as the Hub Transport server, the Hub Transport server delivers the message directly to the user's mailbox. If the mailbox store is in a different Active Directory site than the Hub Transport server, the Hub Transport server delivers the message to a Hub Transport server in the remote Active Directory site.

The Hub Transport server stores all configuration information in Active Directory and accesses Active Directory to retrieve this information. The configuration information includes the details of any transport rules, journal rules, and connectors.

Client Access Server Role

The Client Access server role receives connections from the Internet for users who access their mailbox by using Outlook Web App, (POP3, IMAP4, or Microsoft Exchange ActiveSync). When a user connection is received, the Client Access server contacts Active Directory to authenticate the user and to determine the location of the user's mailbox server. If the user's mailbox is in the same Active Directory site as the Client Access server, the user is connected directly to their mailbox. If the user's mailbox is in a different Active Directory site than the Client Access server that received the initial connection, the connection is redirected to a Client Access server in the remote Active Directory site.

Unified Messaging Server Role

The Unified Messaging server role accesses Active Directory to retrieve global configuration information, such as dial plans, IP gateways, and hunt groups. When a message is received by the Unified Messaging server, it searches for Active Directory recipients to match the telephone number to a recipient address. When it has resolved this information, the Unified Messaging server can determine the location of the recipient's mailbox store and then submit the message to a Hub Transport server for routing to the mailbox.

Mailbox Server Role

The Mailbox server role stores configuration information about mailbox users and stores in Active Directory. Additionally, the configuration for agents, address lists, and policies is stored in Active Directory. The Mailbox server retrieves this information to enforce mailbox policies and global settings.

Edge Transport Server Role

The Edge Transport server role is deployed in the perimeter network and is not a domain member. The Edge Transport server doesn't have access to Active Directory and uses Active Directory Lightweight Directory Services (AD LDS, formerly known as Active Directory Application Mode or ADAM) to store schema and configuration information. You can create an Edge Subscription to subscribe the Edge Transport server to an Active Directory site. The Hub Transport servers in that Active Directory site use the Microsoft Exchange EdgeSync service to synchronize Active Directory data to AD LDS.

We recommend that you create an Edge Subscription for each Edge Transport server. This process will automatically provision the Send connectors that are required for end-to-end mail flow. You must create an Edge Subscription if you will be using the recipient lookup or safe list aggregation anti-spam features.

Recovery of Deleted Exchange Objects

Active Directory Recycle Bin helps minimize directory service downtime by enhancing your ability to preserve and recover accidentally deleted Active Directory objects without restoring Active Directory data from backups, restarting Active Directory Domain Services (AD DS), or rebooting domain controllers.

The most important thing to understand about recovering deleted Exchange-related Active Directory objects is that Exchange objects don't exist in isolation. For example, when you mail-enable a user, several different policies and links are calculated for the user based on your current Exchange configuration. Two problems that may arise when you restore a deleted Exchange configuration or recipient object are:

  • Collisions   Some Exchange attributes must be unique across a forest. For example, proxy (e-mail) addresses must not be the same for two different users. Active Directory doesn't enforce proxy address uniqueness—Exchange administrative tools check for uniqueness. Exchange e-mail address policies also automatically resolve possible conflicts in proxy address assignment based on deterministic rules. Therefore, it's possible to restore an Exchange user object and, as a result, create a collision with proxy addresses or other attributes that should be unique.

  • Misconfigurations   Exchange has automated rules that assign various policies or settings. If you delete a recipient, and then change the rules or policies, restoring an Exchange user object may result in a user being assigned to the wrong policy (or even to a policy that no longer exists).

The following guidelines will help you minimize problems or issues when you recover deleted Exchange -related objects:

  • If you deleted an Exchange configuration object using Exchange management tools, do not restore the object. Instead, re-create the object using the Exchange management tools (Exchange Management Console or Exchange Management Shell).

  • If you deleted an Exchange configuration object without using the Exchange management, recover them as soon as possible. The more administrative and configuration changes that have been made in the system since the deletion, the more likely it is that restoring the objects will result in misconfiguration.

  • If you recover deleted Exchange recipients (contacts, users, or distribution groups), monitor closely for collisions and errors relating to the recovered objects. If Exchange policies or other configuration relating to recipients may have been modified since the deletion, re-apply current policies to the restored recipients to ensure that they are configured correctly.

For more information about using Active Directory Recycle Bin, see Active Directory Recycle Bin Step-by-Step Guide.

 © 2010 Microsoft Corporation. All rights reserved.