Designing Active Directory for Exchange Server 2003

Active Directory is a necessary and fundamental component of any Exchange Server 2003 implementation. That said, organizations of any size 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 Server 2003:

• Forest and Domain Design

• AD Site and Replication Topology Layout

• Domain Controller and Global Catalog Placement

• DNS Configuration

Forest and Domain Design

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

In many cases, an existing Active Directory forest and domain structure is already in place in organizations considering Exchange Server 2003 deployment. In these cases, Exchange can be installed on top of the existing AD environment, and no AD design decisions need to be made. Exchange Server 2003 can be installed on either a Windows 2000 or Windows Server 2003 Active Directory implementation.

In some cases, there may not be an existing AD infrastructure in place, and one needs to be deployed to support Exchange. In some specific cases, Exchange may be deployed as part of a separate forest by itself, as illustrated in Figure 5.1. This is often the case in an organization with multiple existing AD forests.

Figure 5.1. Multi-forest Exchange configuration.

In any case, AD should be designed with simplicity in mind. A single-forest, single-domain model, for example, will solve 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.

In some cases, a separate domain called a placeholder root domain can be established to increase overall forest security by segregating rights to the AD schema into a separate domain from the normal domain accounts. This model increases security, but also requires the deployment of more domain controllers for the additional domain.

NOTE

The addition of Exchange Server 2003 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 Identify Integration Server 2003. MMIS 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.

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, Exchange 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. Small organizations should subsequently configure their Active Directory implementation with a single AD Site. Midsize and larger organizations may require the creation of multiple Active Directory sites to mirror the WAN connectivity of the organization.

Domain Controller and Global Catalog Placement

In small or midsize organizations, there are 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.

The second option is to separate the Active Directory domain controller duties onto a separate physical server from Exchange Server 2003. This option is more expensive, but has the advantages associated with distributed computing. As the anticipated load on the server increases with the number of users using the system, this option becomes necessary.

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. See Chapter 7, "Domain Name System Impact on Exchange," for more information on third-party DNS scenarios.

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 into, such as cconet.internal . In general, the more security-conscious an organization, the more often the internal namespace will be chosen .

Active Directory Design Decisions for Small Organizations

Company123 did not have an existing Active Directory infrastructure in place, so design decisions regarding AD were necessary. Because its needs were not complex, however, the AD design decisions were not complex. Small organizations rarely need to spend a great deal of time worrying about Active Directory forests, trees, and domains. In reality, the vast majority of these small organizations use a single-forest, single-domain model for their Active Directory.

In Company123's case, the size of the company dictated a simple Active Directory design. Because it had no specific need for a complex forest design, it settled for a single-forest, single-domain AD design, as illustrated in Figure 5.2.

Figure 5.2. Single-forest, single-domain Active Directory design.

In Company123's case, 12 of the 15 employees are physically located in the San Francisco headquarters. An additional 3 employees are located in a London office, but it was determined that the number of employees in this location was too small to warrant the creation of a second AD Site. A single San Francisco site was created for AD.

When the decision about domain controller placement arose, Company123 chose the simple structure of having a single domain controller for the entire forest. This meant that there were no decisions to be made regarding Global Catalog placement either, because the first domain controller is, by default, a Global Catalog server. In addition, most small organizations opt to have their domain controller on the same hardware as their Exchange Server, which is the configuration chosen by Company123.

Company123 installed and configured DNS on the single server chosen as the domain controller and Exchange server for the organization. A single forward lookup zone for the AD domain was created ( company123.org ) and a reverse lookup zone was created for the subnet ( 10.0.0.0/24 ), as illustrated in Figure 5.3.

Figure 5.3. Forward lookup and reverse lookup zone configuration.

The DNS namespace chosen for the Active Directory domain was the same as the external DNS namespace registered to Company123 on the Internet: company123.org . This option was less secure, but because the security needs of Company123 were not great, the decision was made to assume the same namespace for convenience purposes and therefore not confuse the end-users.

Midsize Organization AD Design Decisions

OrganizationY already had an Active Directory domain infrastructure in place and wanted to integrate Exchange Server 2003 into the forest. The AD domain structure used a placeholder root structure, which isolated the schema master role and increased security for the organization, as illustrated in Figure 5.4.

Figure 5.4. Placeholder root Active Directory design structure.

OrganizationY had three major locations, so separate Active Directory sites had been configured for each location to optimize replication traffic. In advance of the Exchange Server 2003 project, the two largest sites ”Manchester and Los Angeles ”were allocated full Global Catalog servers. The St. Petersburg site was allocated domain controllers, but with the Universal Group Caching options enabled for the site. This ensured that the Exchange servers would have fast access to Global Catalog information from each site.

The primary user domain used an internally published DNS namespace named Ydomain.internal . DNS Zones were configured for both the placeholder root domain ( placeholder.internal ) and the user resource domain ( ydomain.internal ). The local copy of the zone was configured as AD-Integrated, and the other domain zone was configured as a stub zone, as illustrated in Figure 5.5. This enabled the highest level of security along with the most efficient levels of replication.

Figure 5.5. AD-integrated and stub zone configuration.

Large Organization AD Design Decisions

CompanyABC was faced with a complex Active Directory problem. Separate AD forests had already been deployed in two locations within the company, and it was determined to be too complex an undertaking to consolidate the AD forests into a single forest for Exchange.

CompanyABC was left with the decision to either deploy Exchange Server 2003 in two locations and synchronize the address lists between them using Microsoft Identify Integration Services (MIIS) 2003, or deploy a dedicated forest for Exchange. The second option was chosen, and CompanyABC designed a completely separate AD forest for Exchange, but with cross-forest transitive trusts established between the forests, as illustrated in Figure 5.6.

Figure 5.6. Multiple Active Directory forest with cross-forest trusts.

The AD Site structure was set up to follow existing WAN topology, with Active Directory sites for Minneapolis, San Francisco, Dallas, New York, Paris, Moscow, Tokyo, and Singapore. Each site contained Global Catalog domain controllers for fast Exchange access.

As evident in Figure 5.6, CompanyABC chose a single domain model with a DNS namespace of exchange.internal for the Exchange forest. All external forest accounts would be granted permissions to their mailboxes across the cross-forest trusts.