Below is taken straight from Microsoft articles and best practices explaining the basic topologies and the clear picture of their implementations. The golden rule is always keep it simple, and don't make it complicated. The more any type of design gets complicated, you are looking into potential problems, and so if you don't need it don't try to deploy resource forest, stick to a Single Forest and take advantage of simple design, and lay down your active directory with more granular control over multiple OU structure. Exchange is such application integrated with AD as cast and stone. Most of the Exchange administrators deal with Active directory and other applications relaying mail capabilities. Therefore if you do not have a security reason going into Resource forest implementation stick with simple design and save head ache for yourself.
Single Forest
If your organization has a single Active Directory forest, you can implement Exchange in that forest. The single forest Exchange design is recommended because it offers the richest set of mail system features and has the most streamlined administrative model. Because all resources are contained in a single forest, a single global address list (GAL) contains all users across the entire forest. The following figure illustrates this scenario
The single forest option offers the following advantages:
Provides the richest set of mail system features
- Allows for a streamlined administrative model
- Leverages an existing Active Directory structure
- Uses existing domain controllers and global catalog servers
- Does not require provisioning or synchronization
The main disadvantage associated with this option is that administrators need to determine how to share or divide responsibilities for managing
Using a Dedicated Exchange Forest (Resource Forest)
There are some cases in which you may need to set up a separate Active Directory forest that is dedicated to running Exchange. For instance, you may have a Windows NT forest that you want to retain. Or, you may need to separate administration of Active Directory objects and Exchange objects; therefore, you may want to set up a separate Active Directory forest dedicated to running Exchange. Companies that require security (forest) boundaries between Active Directory administration and Exchange administration may choose this option.
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. For more information about deploying Exchange in a multiple forest environment, see Planning to Deploy Exchange in a Multiple Forest Environment.
The enabled user from the account forest is associated with a mailbox attached to a disabled user in the resource forest. This configuration allows users to access mailboxes that reside in different forests. In this scenario, you configure a trust between the resource forest and the account forest. You may also need to set up a provisioning process so that each time an administrator creates a user in Active Directory, a disabled user with a mailbox is created in Exchange
Using Multiple Forests with Exchange
Although a single-forest topology is recommended because it provides the richest set of messaging features, there are various reasons for implementing multiple forests. Some of these reasons include:
- You have multiple business units that require data and service isolation.
- You have multiple business units that have separate schema requirements.
- You are confronted with a merger, acquisition, or divestiture.
Whatever the case may be, the only way to establish strict boundaries between business units is to create a separate Active Directory forest for each business unit. If this is your Active Directory configuration, the preferred way to implement Exchange is to create an Exchange resource forest. For more information about this, see "Using a Dedicated Exchange Forest." For additional information on how mergers and acquisitions can impact your Active Directory topology, see "Active Directory Implications of Mergers and Acquisitions."
However, if the resource forest option is not feasible (for example, with mergers or acquisitions, or because multiple forests are already running their own instances of Exchange), you can implement Exchange across multiple forests, as illustrated in the following figure.
Exchange deployed in multiple forests, with synchronization between forests (classic multiple forest configuration)
http://technet.microsoft.com/en-us/library/aa998404.aspx
Oz Ozugurlu
No comments:
Post a Comment