Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2008-03-17

As a business grows in size, its infrastructure typically grows along with it. Such growth often brings with it added complexity and new security challenges. Of the four defined organization models for Microsoft Exchange Server 2007, the large Exchange organization is the largest organization model that can be deployed in a single Active Directory directory service forest environment. The distinguishing characteristics of the large Exchange organization include:

An Exchange organization with all of the listed characteristics is considered a large Exchange organization.

Single and Multiple Active Directory Domains

The single domain topology includes all scenarios where a single Active Directory domain is deployed for all user and computer objects. In a single domain model, a common domain name suffix is in use by all computer objects, and the domain name suffix matches the domain namespace used by Active Directory.

Large Exchange organizations often include multiple Active Directory domains. Within Active Directory forests, there is considerable variability on the organization of domains. Generally, domain models that are based upon geographic boundaries rather than business unit boundaries tend to have more longevity and flexibility because geographic boundaries change less frequently than business units. Although not a requirement of a multiple-domain environment, we recommend that geographically based domains be deployed where possible.

The most prominent multiple-domain model is the parent/child domain relationship. In this model, the root or parent domain is deployed primarily to provide a namespace for the forest. An equally important function is to prevent the proliferation of domains and expansion of the forest. Adding domains to a forest requires administrative access to the root domain, and typically very few personnel have administrative access to the root domain. After the parent domain is installed, one or more child domains may be added. A child domain refers to a domain that is subordinate to the parent domain. A child domain is typically where user accounts, file servers, and application servers are installed. In a normal Active Directory topology, the domain namespace is contiguous and reflects the hierarchy of the domains deployed. For example, if a root domain is named fabrikam.com, child domain names could include us.fabrikam.com, eu.fabrikam.com, and asia.fabrikam.com.

Beyond first-level child domains, additional layers of hierarchy may also be deployed. These layers are generally referred to as grandchild domains. To simplify Exchange environments, we recommend not using grandchild domains to host Exchange, and that you restrict your Exchange server membership to child domains. This approach does not mean that grandchild domains cannot be used to host mailbox-enabled users. All domains in a forest have transitive trusts between them, and as long as the Domain Name System (DNS) is working correctly for all domains in the forest, this configuration of users and servers should function normally.

Note:
The use of grandchild domains may require some additional configuration of DNS suffix search order on each host in the forest to work correctly.

The simplest implementation of multiple parent/child domain relationships is when all domains are deployed at a single location. This topology is uncommon, and it often includes a segregation of administration responsibilities between the domains. A more common deployment scenario of multiple parent/child domain relationships is when the domains are deployed along SDL boundaries.

Dedicated Active Directory Sites

Supporting high concentrations of Exchange servers and clients out of a single SDL can create a significant demand for directory services. Beyond Exchange, the addition of other applications that require directory services, client authentication, or directory replication can cause a significant degradation in the health and performance of Exchange. To alleviate directory service congestion, the creation of a dedicated Active Directory site to host Exchange servers using dedicated domain controllers and global catalog servers is a current best practice. By segmenting an SDL into multiple Active Directory sites, it becomes possible to separate the directory traffic generated by Exchange servers and Microsoft Outlook clients from other directory service traffic.

Note:
At this time, Exchange 2007 is undergoing performance and scalability testing and tuning, including testing the performance characteristics of systems with 64-bit directory servers. After this testing is complete, a review of this best practice will occur and supplemental information will be provided.

In the case of a location which hosts a dedicated Exchange Active Directory site, it is acceptable for foreign domain controllers to be located in the same Active Directory site that is used for general client authentication rather than the dedicated Exchange Active Directory site, provided that there is a direct IP site link between the two Active Directory sites and the segregation of mailbox ownership is maintained across the SDLs.

Examples of Large Exchange Organizations

A large Exchange organization comes in many varieties. However, large Exchange organizations typically have common attributes. For example, there is an increase in the number of physical locations supported by Exchange, even though Exchange is not deployed to all locations. In addition, many large Exchange organizations have multiple points of egress to the Internet, often using multiple Internet service providers (ISPs) while maintaining a single messaging and client protocol namespace.

  • Figure 1 illustrates one example of a large Exchange organization.


Large Exchange Organization Topology

Planning Considerations for Large Exchange Organizations

  • During the planning phase of your deployment, and before you deploy any Exchange 2007 servers in a large Exchange organization, we recommend that you consider the following points:

  • When a multiple-domain model is deployed, domain controller placement should be such that all domains used as security principals on Exchange objects should have excellent connectivity to locations that host many Exchange resources. This is especially important in Exchange server consolidation scenarios.

  • When an organization reaches sufficient size to require a dedicated Active Directory site for Exchange, it is quite common for this configuration to be replicated across major data center locations. This introduces additional replication links that must be accounted for in topology discovery, as well as Active Directory sites which do not have any Exchange presence.

  • When domain boundaries are based upon business unit boundaries rather than geographic boundaries, it can be common for the distribution of domains and SDLs to overlap significantly. When this occurs, a single Exchange server or group of Exchange servers will end up hosting resources from multiple domains out of a common SDL. This sharing of infrastructure increases the need for directory resources and additional domain controllers for each of the affected domains due to the additional authentication requirements for each domain, for management of distribution lists from the Outlook client, and for client referrals to a global catalog server. A proportionate number of global catalog servers from the appropriate domain must be available for use by clients because the Exchange server will send global catalog server referrals to a client that includes a global catalog server from the domain in which the mailbox account is hosted. In the case of a dedicated Exchange Active Directory site, this means domain controllers from each domain that the Exchange servers host resources for must be included in the Exchange Active Directory site.

  • When deploying a large Exchange organization, providing high availability deployment options becomes an important consideration. In Exchange 2007, there are multiple solutions that can be used to provide high availability for each server role. For more information about high availability strategies and features for Exchange 2007, see High Availability.

Transitioning a Large Exchange Organization

If you are transitioning from an existing Exchange Server 2003 or Exchange 2000 Server organization to an Exchange 2007 organization, be aware that you cannot perform an in-place upgrade of your servers. You must add one or more Exchange 2007 servers to your existing organization, move mailboxes and other data to Exchange 2007, and then remove the Exchange 2003 or Exchange 2000 server from the organization.

For more information about deploying and transitioning to a large Exchange 2007 organization, see Deploying a Large Exchange Organization.



Figure 1   Large Exchange organization