Understanding Core Exchange Server 2013 Design Plans (part 2) - Understanding AD Design Concepts for Exchange Server 2013 - Understanding the AD DS Forest

2. Understanding AD Design Concepts for Exchange Server 2013

After all objectives, dependencies, and requirements have been mapped out, the process of designing the Exchange Server 2013 environment can begin. Decisions should be made in the following key areas:

• AD DS design

• Exchange server placement

• Global catalog placement

• Client access methods

2.1 Understanding the AD DS Forest

Because Exchange Server 2013 relies on the Windows Server 2008 AD DS for its directory, it is therefore important to include AD DS in the design plans. In many situations and AD implementations, whether based on Windows Server 2003, Windows Server 2008, or Windows Server 2012, AD DS already exists in the organization. In these cases, it is necessary only to plan for the inclusion of Exchange Server into the existing forest.

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

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

Figure 2.1. Multitree AD DS forest design.

Certain cases exist for using more than one AD DS forest in an organization:

• Political limitations—Some organizations have specific political reasons that force the creation of multiple AD DS forests. For example, if a merged corporate entity requires separate divisions to maintain completely separate information technology (IT) infrastructures, more than one forest is necessary.

• Security concerns—Although the AD DS 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 if they know what they are doing. Although these types of vulnerabilities are not common and are difficult to do, highly security-conscious organizations should implement separate AD DS forests or organizational units with delegated rights.

• Application functionality—A single AD DS 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, though this particular scenario is particularly discouraged.

• Exchange-specific functionality (resource forest)—In certain circumstances, it might be necessary to install Exchange Server 2013 into a separate forest to enable Exchange Server to reside in a separate schema and forest instance. An example of this type of setup is an organization with two existing AD DS forests that creates a third forest specifically for Exchange Server, called a resource forest, and uses cross-forest trusts to assign mailbox permissions.

The simplest designs often work the best. The same principle applies to AD DS 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.