Designing Active Directory for Exchange Server 2007

Active Directory (AD) is a necessary and fundamental component of any Exchange 2007 implementation. That said, organizations do not necessarily need to panic about setting up Active Directory in addition to Exchange, as long as a few straightforward design steps are followed. The following areas of Active Directory must be addressed to properly design and deploy Exchange 2007:

. Forest and domain design

. AD site and replication topology layout . Domain controller and global catalog placement . Domain name system (DNS) configuration

Understanding Forest and Domain Design

Because Exchange Server 2007 uses Active Directory for its underlying directory structure, it is necessary to link Exchange with a unique Active Directory forest.

In many cases, an existing Active Directory forest and domain structure is already in place in organizations considering Exchange 2007 deployment. In these cases, Exchange can be installed on top of the existing AD environment, and no additional AD design decisions need to be made. It is important to note that Exchange 2007 can only be installed in a Windows Server 2003 Active Directory forest; Windows 2000 Server forests are not supported.

In some cases, there might not be an existing AD infrastructure in place, and one needs to be deployed to support Exchange. In these scenarios, design decisions need to be made for the AD structure in which Exchange will be installed. In some specific cases, Exchange might be deployed as part of a separate forest by itself, as illustrated in Figure 4.1. This model is known as the Exchange Resource Forest model. This is often the case in an organization with multiple existing AD forests.

Cross-Forest Trust

Exchange Forest and Domain

Production Forest and Domains

In any case, AD should be designed with simplicity in mind. A single-forest, singledomain model, for example, solves the needs of many organizations. If Exchange itself is all that is required of AD, this type of deployment is the best practice to consider.

NOTE

The addition of Exchange 2007 into an Active Directory forest requires an extension of the AD forest’s Active Directory schema.

Considerations for this factor must be taken into account when deploying Exchange onto an existing AD forest.

Microsoft has gotten serious recently about support for Exchange Server across multiple forests. This was previously an onerous task to set up, but the ability to synchronize between separate Exchange organizations has been simplified through the use of

Microsoft Identity Integration Server (MIIS) 2003. MIIS now comes with a series of preconfigured scripts to replicate between Exchange forests, enabling organizations which, for one reason or another, cannot use a common forest to unite the email structure through object replication.

Outlining AD Site and Replication Topology Layout

Active Directory sites should mirror existing network topology. Where there are pools of highly connected AD domain controllers, for example, Active Directory sites should be created to optimize replication. Smaller organizations have the luxury of a simplified AD site design. In general, the number of sites is small—or, in most cases, composed of a single physical location. Midsize and larger organizations might require the creation of multiple Active Directory sites to mirror the wide area network (WAN) connectivity of the organization.

Exchange 2007 no longer uses a separate replication mechanism (routing groups) from Active Directory, and Exchange replication takes place within the context of Active Directory sites. This makes proper AD site topology creation a critical component of an Exchange deployment.

Reviewing Domain Controller and Global Catalog Placement Concepts

In small or midsize organizations, you have effectively two options regarding domain controller placement. The first option involves using the same physical server for domain controller and Exchange Server duties. This option is feasible for smaller organizations because its impact on the server is minimal. This type of deployment strategy is not feasible for enterprise organizations, however, and the domain controller functions should be separated onto dedicated systems.

Configuring DNS

Because AD and Exchange are completely dependent on DNS for lookups and overall functionality, configuring DNS is an important factor to consider. In the majority of cases, DNS is installed on the domain controller(s), which enables the creation of Active Directory-integrated DNS zones. AD-integrated zones enable DNS data to be stored in AD with multiple read/write copies of the zone available for redundancy purposes. Although using other non-Microsoft DNS for AD is supported, it is not recommended.

The main decision regarding DNS layout is the decision about the namespace to be used within the organization. The DNS namespace is the same as the AD domain information, and it is difficult to change later. The two options in this case are to configure DNS to use either a published, external namespace that is easy to understand, such as cco.com, or an internal, secure namespace that is difficult to hack in to, such as cconet.internal. In general, the more security-conscious an organization, the more often the internal namespace will be chosen.