Installing Exchange Server 2007 : Planning an Active Directory Infrastructure

The following section focuses on the AD infrastructure required to support an Exchange Server 2007 implementation. Many facets are involved when planning an AD infrastructure—for example, forest model, domain model, group policies, delegation of administration. For more information about designing an AD infrastructure, refer to Windows Server 2003 Unleashed, R2 Edition, by Sams Publishing (ISBN: 0-672-32898-4). These sections strictly focus on the AD components required for implementing Exchange Server 2007.

Impact Forests Have on an Exchange Server 2007 Design

An AD forest and an Exchange organization are tightly integrated as Exchange utilizes AD as its directory repository for mailboxes, mail-enabled objects, Exchange servers, and much more. There is a one-to-one relationship between AD and Exchange. An AD forest can only host a single Exchange organization and an Exchange organization can only span one AD forest.

It is recommended that a single AD forest should be utilized to minimize complexity and administration when designing and implementing a company’s Exchange implementation. However, there will be times when a single AD forest will not meet the company’s business, security, or political requirements.

If multiple AD forests are necessary to satisfy the company’s requirements, it must be decided on which forest the Exchange organization will be hosted. It is possible to have Exchange reside in a single forest, a dedicated resource forest, or in multiple forests.

The Role of a Domain in Exchange Server 2007

After the AD forest structure has been laid out, the domain structure can be contemplated. Unlike the forest structure, an Exchange Server 2007 organization can span multiple domains within the forest if needed. Therefore, a user mailbox, Exchange server, or other Exchange object can reside in any domain within the forest where Exchange Server 2007 has been deployed. A company can plan its domain model structure (single domain model or multiple domain model) based on their business and security requirements without a direct negative impact to the Exchange Server 2007 design.

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 1.

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 trade-off between increased cost and less security is too great. Larger organizations can consider the increased security provided by this model, however.

Understanding How DNS and AD Namespace Are Used in Exchange Server 2007

The first step in the actual design of the AD structure is the decision on a common domain name system (DNS) namespace that AD will occupy. AD revolves around, and is inseparable from, DNS, and this decision is one of the most important ones to make. The namespace chosen can be as straightforward as companyabc.com, for example, or it can be more complex. Multiple factors must be considered, however, before this decision can be made. Is it better to register an AD namespace on the Internet and potentially expose it to intruders, or is it better to choose an unregistered, internal namespace? Is it necessary to tie in multiple namespaces into the same forest? These and other questions must be answered before the design process can proceed.

Planning a Proper Sites and Services Architecture

As stated earlier, one of the major changes in Exchange Server 2007 is that it no longer has an independent routing topology for sending email throughout the Exchange organization. In pure Exchange Server 2007 mode, Exchange Server 2007 piggybacks off AD Sites and Services for routing email.

If Exchange Server 2007 will be installed into an existing Exchange 2000 or 2003 organization, the administrators must take coexistence into consideration. It is necessary to configure routing group connectors to ensure that the Exchange Server 2007 servers are communicating to legacy servers.

Therefore, Exchange administrators must fully understand best practices around designing a proper Sites and Services architecture to support Exchange Server 2007. The AD Sites and Services concepts are fairly similar to Exchange routing topology. From a high-level perspective, within AD it is necessary for administrators to create sites, allocate subnets to sites, and then create site links between sites for communication to occur. Similar to Exchange 2000 and 2003, it is possible to set up redundant links between sites and allocate costs to control communication priorities.

Active Directory Sites

The basic unit of AD replication is known as the site. Not to be confused with physical sites or Exchange Server 5.5 sites, the AD site is simply a group of highly connected domain controllers. Each site is established to more effectively replicate directory information across the network. In a nutshell, domain controllers within a single site will, by default, replicate more often than those that exist in other sites. The concept of the site constitutes the centerpiece of replication design in AD.

Associating Subnets with Sites

In most cases, a separate instance of a site in AD physically resides in a separate subnet for other sites. This idea stems from the fact that the site topology most often mimics, or should mimic, the physical network infrastructure of an environment.

In AD, sites are associated with their respective subnets to allow for the intelligent assignment of users to their respective domain controllers. For example, consider the design shown in Figure 2.

Figure 2. Sample Exchange and client site assignment.

In this example, Server-EX01 is a physical member of the 192.168.115.0/24 subnet. Server-EX02 and Client01 are both members of the 192.168.116.0/24 subnet. Based on the subnets, Server-EX01 will automatically be assigned to the domain controller Server01 in site01 and Server-EX02 and Client01 will be assigned to the domain controller in the second site, site02.

Using Site Links

By default, the creation of two sites in AD does not automatically create a connection linking the two sites. This type of functionality must be manually created, in the form of a site link.

A site link is essentially a type of connection that joins together two sites and allows for replication traffic to flow from one site to another. Multiple site links can be set up and should normally follow the wide area network (WAN) lines that your organization follows. Multiple site links also assure redundancy so that if one link goes down, replication traffic follows the second link.

Site link replication schedules can be modified to fit the existing requirements of your organization. If, for example, the WAN link is saturated during the day, a schedule can be established to replicate information at night. This functionality allows you to easily adjust site links to the needs of any WAN link.

Exchange Server 2007 and Site Membership

After the AD site topology has been created, including adding the appropriate subnets to sites and creating site links between sites, an administrator can now take Exchange Server placement into consideration.

Similar to AD domain controllers, Exchange 2007 will automatically be associated with a site in AD based on their IP address and subnet mask. As stated earlier, it is beneficial to have a domain controller residing in the site that the Exchange 2007 server will be in.

Establishing a Proper Global Catalog Placement Strategy

One item to review is the placement of global catalog servers within the AD site configuration. The importance of the global catalog server cannot be overstated. The global catalog is used for the address list that users see when they are addressing a message. If the global catalog server is not available, the recipient’s address will not resolve when users address a message, and the message will immediately be returned to the sender.

One well-equipped global catalog server can support several Exchange 2007 servers on the same local area network (LAN) segment. There should be at least one global catalog server in every AD site that contains an Exchange 2007 server. For large sites, two global catalogs are much better and provide redundancy in the event the first global catalog server is unavailable.

For optimization, plan on having a global catalog server close to the clients to provide efficient address list access. Making all domain controller servers global catalog servers is recommended for an organization that has a single AD domain model and a single site. Otherwise, for multidomain models, all domain controllers can be configured as global catalog servers except for the domain controllers hosting the Infrastructure Master FSMO role. A good AD site design helps make efficient use of bandwidth in this design. This design helps reduce some of the overhead with multiple global catalogs in every AD site.