Single forest. This is the simplest design and is normally most appropriate for small to medium deployments because it removes a great deal of complexity. All servers in the forest share the same schema and configuration, even if multiple domains are deployed, and difficulties are not usually encountered with security and permissions because all objects operate within a single security context.

Multi-forest. Sometimes referred to as cross-forest implementation, this deployment features two or more forests that operate independently from each other in terms of the accounts and applications that are deployed inside each forest. It is possible to synchronize user account information between forests so that users can access a common directory that includes everyone. Exchange can be deployed in one or more forests. A hybrid deployment, where some parts of Exchange are on-premises and some are located on a cloud platform, can be considered similar to a multiforest configuration.

When Exchange is deployed in multiple forests, the organizations have different names, SMTP addresses, configurations, and so on and a messaging flow between the organizations can be established by SMTP connections to complement the common directory. Multi-forest deployments usually occur as the result of company acquisitions. Less commonly, companies have deployed Exchange in multiple forests to satisfy particular requirements for specific parts of the company that were inconsistent with the needs of other parts. Exchange 2013 supports the ability to move mailboxes between organizations, so this is not an obstacle. It’s also possible to use the Exchange 2013 Exchange Administration Center (EAC) or Exchange Management Shell (EMS) to access multiple organizations at one time. However, the different security contexts created by multiple forests make management more difficult and complex than in a single forest.

Resource forest. In this scenario, user accounts and groups are deployed in a root forest, and applications such as Exchange are deployed in a special resource forest. Exchange mailboxes exist in the resource forest and use disabled user accounts that belong to the resource forest. Users who log on to the root forest gain access to their mailboxes in the resource forest through an association with the mailboxes.

Resource forests have some attraction because they allow a very clear separation of administrative responsibilities between Windows (the root domain) and applications, each of which is assigned its own resource domain. Resource domains are often used in a hosting environment in which the hosting provider creates a resource domain to host and manage Exchange. A one-way trust is usually used to connect the resource forest with the root forest because this allows the hosting provider to manage Exchange without having any control over Active Directory.

There are many variations on these three basic themes in production today. For example, a design composed of root and resource forests is often referred to as a hybrid forest if mail-enabled accounts exist in both forests. You then get into the discussion about whether to deploy one domain per forest, multiple domains per forest, or a mixture of both. Multiple domains are commonly used to isolate Exchange management and operations or to distribute administrative activity across business units or geographic regions. Cost is another factor to include in the planning debate. Additional domains normally imply the need to deploy extra servers as domain controllers. Extra servers increase the complexity of the environment that you have to manage, monitor, and operate, and they drive cost in terms of hardware (servers and storage), datacenter power and cooling, network bandwidth, and software licenses.