Designing Active Directory for Exchange Server 2007 & Determining Hardware and Software Components

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 1. This model is known as the Exchange Resource Forest model. This is often the case in an organization with multiple existing AD forests.

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

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.

Determining Hardware and Software Components

Justifying hardware and software purchases is often a difficult task for organizations of any size. It is, therefore, important to balance the need for performance and redundancy with the available funds in the budget, and, thus, deploy the optimal Exchange Server hardware and software configuration.

Unlike previous versions of Exchange, Exchange 2007 requires the use of 64-bit capable systems, so it is critical to order the appropriate equipment when deploying Exchange 2007 systems.

Designing Server Number and Placement

Exchange scales very well to a large number of mailboxes on a single machine, depending on the hardware chosen for the Exchange server. Subsequently, Exchange 2007 is optimal for organizations that want to limit the amount of servers that are deployed and supported in an environment.

Exchange 2000 Server previously had one major exception to this concept, however. If multiple sites required high-speed access to an Exchange server, multiple servers were necessary for deployment. Exchange 2007, on the other hand, expands upon the concept of site consolidation, introduced in Exchange Server 2003. This concept enables smaller sites to use the Exchange servers in the larger sites through the more efficient bandwidth usage present in Outlook 2007 and Outlook 2003 and other mobile technologies.

Providing for Server Redundancy and Optimization

The ability of the Exchange server to recover from hardware failures is more than just a “nice-to-have” feature. Many server models come with an array of redundancy features, such as multiple fans and power supplies and mirrored disk capabilities. These features incur additional costs, however, so it is wise to perform a cost-benefit analysis to determine what redundancy features are required. Midsize and larger organizations should seriously consider robust redundancy options, however, because the increased reliability and uptime is often well worth the up-front costs.

Exchange 2007 further expands the redundancy options with the concept of Cluster Continuous Replication (CCR), which allows for a series of servers to each contain an active copy of a user’s mailbox, allowing for immediate global cluster failover to any system.

One of the most critical but overlooked performance strategies for Exchange is the concept of separating the Exchange logs and database onto separate physical drive sets. Because Exchange logs are very write-intensive, and the database is read-intensive, having these components on the same disk set would degrade performance. Separating these components onto different disk sets, however, is the best way to get the most out of Exchange.

In addition to separating the Exchange database onto a striped RAID5/RAID10(0+1) set, the Simple Mail Transfer Protocol (SMTP) component used by Exchange can be optimized by moving it to the same partition as the database or onto a dedicated partition. By default, the SMTP component is installed on the system (OS) partition, but can be easily moved after an Exchange server has been set up.

Reviewing Server Memory and Processor Recommendations

Exchange Server is a resource-hungry application that, left to its own devices, will consume a good portion of any amount of processor or memory that is given to it. The amount of processors and random access memory (RAM) required should reflect the budgetary needs of the organization. In general, midsize and larger organizations should consider multiprocessor servers and greater amounts of RAM—8GB or 16GB or more. This helps increase the amount of mailboxes that can be homed to any particular server.

Outlining Server Operating System Considerations

The base operating system (OS) for Exchange, Windows Server 2003, comes in two versions, Enterprise and Standard. Some midsize and larger organizations could deploy the Enterprise Edition of the Windows Server 2003 product, namely for clustering support. If this functionality is not required, the Standard Edition of the OS is sufficient.

Designing Clustering and Advanced Redundancy Options

In larger organizations, the need to ensure a very high level of reliability is paramount. These organizations often require a level of uptime for their email that equates to “5 nines” of uptime, or 99.999% uptime per year. For this level of redundancy, a higher level of Exchange redundancy is required than the standard models. For these organizations, the clustering features built in to Windows Server 2003, Enterprise Edition and used by Exchange Server 2007, Enterprise Edition are ideal.