News Stay informed about the latest enterprise technology news and product updates.

Marry Exchange 2000 and Active Directory for maximum performance, part 1

Figuring out your Exchange 2000 design is an integral part of deploying Active Directory correctly. An Active Directory expert discusses design options in this SearchWindowsManageability exclusive two-parter.

Exchange 2000 and Active Directory can't be treated as separate islands in a system, according to AD expert Ratmir Timashev. While AD must be in place before Exchange 2000 can be deployed, Exchange's characteristics must be factored into the actual AD design.

In a recent SearchWindowsManageability interview, Timashev -- president and CEO of Aelita Software -- discussed the implications for single forest and multi-forest AD designs. In this SWM interview, Timashev explains the issues and challenges administrators might face with a multi forest AD design in Exchange 2000. In part two, he details setting up multi forest environments and the messaging systems within them.

SWM: Why is Exchange deployment an issue for AD design?

It's an issue because Exchange 2000 integrates with Active Directory. Exchange 2000 uses AD for all directory-related operations, such as information storage and look-ups, replication and synchronization, but even the end-user e-mail experience relies on AD. For example, e-mail relies on AD for information about users, and AD is used to populate the Global Catalog, which is used as the Exchange 2000 address book.

By design, an AD forest can support only one Exchange 2000 organization, and all users in an Exchange organization have access to the same public folders and calendar information. But users in other Exchange organizations do not automatically have access to the same address book, public folders and calendar information, just like users in different forest don't have access to the same resources.

SWM: What are some of the issues involved in setting up Exchange in a multi-forest AD design?

With a multi-forest AD design, in which each forest has a separate AD service, you have to decide whether each forest should have its own Exchange organization or whether each forest will share a single Exchange organization. Each option will affect collaboration level, replication and other options you have. So at a high level, the main issues are collaboration, replication, and synchronization of data. Together, these issues affect the designs that can be implemented when setting up Exchange.

SWM: What are the main AD/Exchange designs that are possible?

When deploying AD and Exchange, there are three main designs: single forest/single org, multi-forest/single org, and multi-forest/multi-org. Most companies select a single forest/single org (SF/SO) configuration during the early AD deployments. It is the simplest AD/Exchange structure. The whole AD consists of a single forest and that forest has a single Exchange 2000 organization installed in it as the messaging system.

The multiple forest/single org (MF/SO) model suggests that while user accounts are split into multiple AD forests, all mailboxes are located within an AD forest that supports a single Exchange 2000 organization. This configuration is similar to the traditional Windows NT/Exchange 5.5 model, when separate directories were used for the accounts and messaging system.

The multiple forest/multiple org (MF/MO) model suggests that the directory is split into separate AD forests, with each of the forests having its own Exchange organization.

If you are interested, we have a free white paper on our Web site that discusses this issue:

SWM: How does each design increase/decrease collaboration capabilities?

Native Microsoft tools support the single forest/single organization model. Having a single forest and Exchange 2000 organization means that all users have mailboxes within a single Exchange organization and access the same Public Folders, address book, and calendar information. In addition, all the replication tasks are handled by the native AD/Exchange mechanisms.

In a multiple forest/single organization model, all of the users access the same resources in the Exchange organization. But the AD data in each forest needs to be synched with the AD data in the forest that supports the Exchange organization (i.e., the "Exchange resource" forest). For example, if a user account is created in a forest, then there will also need to be a corresponding user account and mailbox in the "Exchange resource forest." Any changes made to a user?s properties, his group membership, etc. also need to be replicated. No native tools provide for this. Aelita's Enterprise Directory Manager can be customized to perform this task automatically whenever changes are made.

In a multiple forest/multiple organization model, the messaging system also gets split between separate Exchange organizations. Exchange 2000 offers limited collaboration capabilities between separate Exchange organizations. For example, users would have separate Public Folders and would not be able to schedule meetings and access public folders in different organizations. So if the messaging system is used for more than just e-mail, this limitation would be a problem.

SWM: How does each design increase/decrease administrative cost?

The single forest/single organization model offers the lowest administrative cost because it is the simplest design and because native Microsoft tools support this model. Having a single forest and Exchange 2000 organization also means that all the replication tasks are handled by the native AD/Exchange mechanisms.

Administrative costs increase as you split the directory into separate forests. In particular, you have to set up some means of addressing the replication and collaboration needs. But this is the only way that you will get the benefits and ROI of this design.


Continue on to part two.

Read SWM's first interview with Timashev, "Single forest vs. multi-forest Active Directory design"

Dig Deeper on Windows systems and network management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.