Technical

Often, setting up a separate Active Directory forest that is dedicated to running Exchange is a better solution than integrating the Exchange application into your production Active Directory security forest.

The Exchange forest (also known as the resource forest) is dedicated to running Exchange and hosting mailboxes. User accounts are contained in one or more forests, referred to as the account forests, which are separate from the resource forest. Using this model, updates and changes to Exchange can be made without affecting the production user account forests.

See Example Image

How it works:

The user from the account forest (where logons occur) is associated with a mailbox attached to a disabled placeholder user in the resource forest. This allows users to access mailboxes that reside in the Exchange resource forest.

The resource forest model is nearly identical to what is provided by Office 365’s Exchange Online, only with more control and easier configuration and setup.  There are 3 ways a user would access the mailbox in the resource forest:

• Without a Windows Trust:  Users would be prompted for credentials by Outlook and other clients.  There is not a built-in Single-Sign-On feature without a Trust.
• With a Windows Trust Using ‘Linked Mailboxes’:  Users are not prompted for credentials and the mailbox account in the resource forest is marked with the SID of the logon user in the account forest.
• With a Windows Trust Using ‘SID Future’:  Users are not prompted for credentials and the SID of the resource forest account is copied to the user in the account forest as an additional SID.

Note that setting up a Resource Forest does NOT mean that the same level of complexity must be created with regards to Active Directory Domain Controllers and AD Sites.  In this scenario, AD plays a supporting role to Exchange and its primary purpose is to provide the address book (by way of the Global Catalog).  As such, one (or more likely two, for redundancy) Domain Controller is all that is required, even if there is a need for many Exchange servers.  This means that the setup and deployment of a resource forest is quick and not as costly as may have initially been imagined.  The DCs in this Resource Forest are not processing logons, logon scripts, and the myriad of other actions and services that a DC normally provides.

A few key Benefits:

• A dedicated security boundary between Active Directory and Exchange administration.
• Features of new platform are realized immediately compared to a ‘mixed-mode’ setup where some key features are always disabled during the while 2 versions run concurrently.
• You can move to new versions of Exchange, like Exchange 2010, 2013, 2016, without polluting, corrupting, or disrupting your existing production Exchange implementation
• Eliminates risk to your existing Exchange implementation
  • There are important risks to consider by adding a newer version of exchange to an existing one such as:
  • …the newer version will try to take control of many actions, like inbound mail flow, transport rules, and other system level operational tasks.
  • …the newer version may enforce attributes on users that are incompatible, but which the current deployment does not
  • …the newer version cannot be fully tested and made “production-ready” without interfering with the current environment
  • …once the AD Schema is extended to support the new version, there is no ability to reverse the changes
  • …Public Folder databases/mailboxes may not sync to newer versions.  For example, there is NO REPLICATION between Exchange 2013 PFs and older versions of exchange.  If the PF deployment is very large, users may be without PF data for days or weeks after the mailbox migration.
• If a need arises during setup or testing of the Resource Forest to re-architect the environment, such can be done with no impact to the current environment.
• If you merge with another entity it’s simply a matter of creating a trust with the new accounts forest and not having to disrupt the exchange organization
• If you divest part of your business entity’s its much simpler to break off the Exchange resources without giving away sensitive security objects that would be part of the User Domains.
• Schema modifications needed for Exchange are isolated to just the Exchange forest and do not need to be implement in the Accounts forest
• Less stress on Global Catalogs and directory replication in the user accounts forest as all this traffic can remain in the Exchange resource forest
• Patches and updates that are not Exchange related, do not have to be installed in the Exchange forest.  This adds a level of stability that is unavailable in a mixed AD/Exchange forest.
• AD container and OU structure can be designed with Exchange Administration in mind and does not have to follow complex architecture of a user forest You can manage users and groups in a way the makes sense for Exchange and not be dependent on how users in the account forest are managed – imagine having a container structure where Executive and Large mailboxes were separated from contractors and simple “mail-consumers”.
• Distribution lists are not co-mingled with security groups because of separate forests.  DLs in the Exchange forest can be guaranteed to only provide access to exchange resources.

A few “reported” detractors to the Resource Forest (but not really)

• More admin work
  • This is one of the first proposed “negatives” of a Resource Forest.  However, it’s a bit of a fallacy.  While it is true, at a technical level, that 2 object have to be created and configured when a new user is hired, there is plenty of ability to script such actions into a single atomic event.  Powershell, available since Exchange 2007 makes such work trivial now.
  • Compared to the many advantages and the infrequency (in most organizations…but not all) of new hires/terminations, the Resource Forest should still be considered.
• Password Sync
  • This is reported from time to time, but really only by those that don’t truly understand the model.  There are 2 options listed above to provide single-sign-on, which inherently means that passwords do not need to sync.

Prerequisites

• Two Active Directory forests:
  • One forest contains the user accounts for your organization. In this procedure, this forest is called the accounts forest.
  • One forest does not contain user accounts and does not yet have Exchange installed. In this procedure, this forest is called the Exchange Forest or Resource Forest. You will use the procedure to install Exchange in this forest.
• You have correctly configured Domain Name System (DNS) for name resolution across forests in your organization. To check that you have DNS configured correctly, ping each forest from the other forest or forests in your organization. 
  

For more detailed information on deploying an Exchange resource forest see the following:

Exchange 2010 resource forest

Exchange 2007 resource forest

Exchange 2003 resource forest