Active Directory Design Concepts for Exchange Server 2003

After all objectives, dependencies, and requirements have been mapped out, the process of designing the Exchange Server 2003 environment can begin. There are several key areas where decisions should be made:

• Active Directory design

• Exchange Server placement

• Global Catalog placement

• Client access methods

Understanding the Active Directory Forest

Because Exchange Server 2003 relies on the Windows Server 2003 Active Directory for its directory, it is subsequently important to include Active Directory in the design plans. In many situations, an Active Directory implementation, whether based on Windows 2000 or Windows Server 2003, already exists in the organization. In these cases, it is necessary only to plan for the inclusion of Exchange Server into the forest.

If an Active Directory structure is not already in place, a new AD forest must be established. Designing the Active Directory forest infrastructure can be complex, and can require nearly as much thought into design as the actual Exchange Server configuration itself. Subsequently, it is important to understand fully the concepts behind Active Directory before beginning an Exchange 2003 design.

In short, a single "instance" of Active Directory consists of a single Active Directory forest. A forest is composed of Active Directory trees, which are contiguous domain namespaces in the forest. Each tree is composed of one or more domains, as illustrated in Figure 4.1.

Figure 4.1. Multi-tree forest design.

Certain cases exist for using more than one Active Directory forest in an organization:

• Political Limitations Some organizations have specific political reasons that force the creation of multiple Active Directory forests. For example, if a merged corporate entity required separate divisions to maintain completely separate IT infrastructures , more than one forest would be necessary.

• Security Concerns Although the Active Directory domain serves as a de facto security boundary, the "ultimate" security boundary is effectively the forest. In other words, it is possible for user accounts in a domain in a forest to hack into domains within the same forest. Although these types of vulnerabilities are not common and are difficult to do, highly security-conscious organizations should implement separate AD forests.

• Application Functionality A single Active Directory forest shares a common directory schema, which is the underlying structure of the directory and must be unique across the entire forest. In some cases, separate branches of an organization require that certain applications, which need extensions to the schema, be installed. This might not be possible or might conflict with the schema requirements of other branches. These cases might require the creation of a separate forest.

• Exchange-Specific Functionality In certain circumstances, it might be necessary to install Exchange Server 2003 into a separate forest, to enable Exchange to reside in a separate schema and forest instance. An example of this type of setup would be an organization with two existing Active Directory forests that creates a third forest specifically for Exchange and uses cross-forest trusts to assign mailbox permissions.

The simplest designs often work the best. The same principle applies to Active Directory design. The designer should start with the assumption that a simple forest and domain structure will work for the environment. However, when factors such as those previously described create constraints, multiple forests can be established to satisfy the requirements of the constraints.

Understanding the Active Directory Domain Structure

After the Active Directory forest structure has been laid out, the domain structure can be contemplated. As with the forest structure, it is often wise to consider a single domain model for the Exchange 2003 directory. In fact, if deploying Exchange is the only consideration, this is often the best choice.

There is one major exception to the single domain model : the placeholder domain model. The placeholder domain model has an isolated domain serving as the root domain in the forest. The user domain, which contains all production user accounts, would be located in a separate domain in the forest, as illustrated in Figure 4.2.

Figure 4.2. The placeholder domain model.

The placeholder domain structure increases security in the forest by segregating high-level schema-access accounts into a completely separate domain from the regular user domain. Access to the placeholder domain can be audited and restricted to maintain tighter control on the critical schema. The downside to this model, however, is the fact that the additional domain requires a separate set of domain controllers, which increases the infrastructure costs of the environment. In general, this makes this domain model less desirable for smaller organizations, because the tradeoff between increased cost and less security is too great. Larger organizations can consider the increased security provided by this model, however.

Reviewing Active Directory Infrastructure Components

There are several key components of Active Directory that must be installed within an organization to ensure proper Exchange Server 2003 and Active Directory functionality. In smaller environments, many of these components can be installed on a single machine, but all need to be located within an environment to ensure server functionality.

The Domain Name Service (DNS) Impact on Exchange Server 2003 Design

In addition to being tightly integrated with Active Directory, Exchange Server 2003 is intrinsically linked with the Domain Name Server (DNS). DNS serves as the lookup agent for Exchange Server 2003, Active Directory, and most new Microsoft applications and services. DNS translates common names into computer-recognizable IP addresses. For example, the name www.cco.com translates into the IP address of 12.155.166.151 . Active Directory and Exchange Server 2003 require that at least one DNS server be made available so that name resolution properly occurs.

Given the dependency that both Exchange Server 2003 and Active Directory have on DNS, it is an extremely important design element. For an in-depth look at DNS and its role in Exchange Server 2003, see Chapter 7, "Domain Name System Impact on Exchange Server 2003."

DNS Namespace

Given Exchange Server 2003's dependency on DNS, a common DNS namespace must be chosen for the Active Directory structure to reside in. In multiple tree domain models, this could be composed of several DNS trees, but in small organization setups, this normally means choosing a single DNS namespace for the AD domain.

There is a great deal of confusion between the DNS namespace in which Active Directory resides, and the email DNS namespace in which mail is delivered. Although they are often the same, in many cases there are differences between the two namespaces. For example, CompanyABC's Active Directory structure is composed of a single domain named abc.internal , and the email domain to which mail is delivered is companyabc.com . The separate namespace, in this case, was created to reduce the security vulnerability of maintaining the same DNS namespace both internally and externally (published to the Internet).

For simplicity, CompanyABC could have chosen companyabc.com as its Active Directory namespace. This choice increases the simplicity of the environment by making the Active Directory login User Principal Name (UPN) and the email address the same. For example, the user Pete Handley is [e-mail] for login, and [e-mail] for email. This option is the choice for many organizations, because the need for user simplicity often trumps the higher security.

Global Catalog Caching and GC/DC Placement

Because all Exchange directory lookups use Active Directory, it is vital that the essential Active Directory Global Catalog information is made available to each Exchange server in the organization. For many small offices with a single site, this simply means that it is important to have a full Global Catalog server available in the main site.

Recall that the Global Catalog is an index of the Active Directory database that contains a partial copy of its contents. All objects within the AD tree are referenced within the Global Catalog, which enables users to search for objects located in other domains. Every attribute of each object is not replicated to the Global Catalogs, only those attributes that are commonly used in search operations, such as first name and last name. Exchange Server 2003 uses the Global Catalog for the email-based lookups of names, email addresses, and other mail- related attributes.

Windows Server 2003 domain controllers and sites enable the concept of Universal Group Membership Caching, which enables a standard (non Global Catalog) domain controller to cache the membership of commonly referenced universal groups in the organization. Because this is one of the most common types of objects that are looked up using the Global Catalog, the addition of this functionality enables the placement of domain controllers in remote sites without a local Global Catalog, as illustrated in Figure 4.3.

Figure 4.3. Global Catalog and domain controller placement.

Because full Global Catalog replication can consume more bandwidth than standard domain controller replication, it is important to design a site structure to reflect the available WAN link capacity. If a sufficient amount of capacity is available, a full Global Catalog server can be deployed. If, however, capacity is limited, universal group membership caching can be enabled to reduce the bandwidth load. The important factor to keep in mind is that any local Exchange server must have an available copy of Global Catalog information nearby so that performance can be optimized.

Multiple Forests Design Concepts Using Microsoft Identify Integration Server 2003 (MIIS2003)

Microsoft Identify Integration Server 2003 (MIIS2003) enables out-of-the-box replication of objects between two separate Active Directory forests. This concept becomes important for organizations with multiple Exchange implementations that want a common Global Address List for the company. Previous iterations of MIIS required an in-depth knowledge of scripting to be able to synchronize objects between two forests. MIIS 2003, on the other hand, includes built-in scripts that can establish replication between two Exchange Server 2003 AD forests, making integration between forests easier. For more information on using MIIS with Exchange Server 2003, see Chapter 6, "Integrating Exchange Server 2003 in a Non-Windows Environment."