Exchange 2000 Interforest Synchronization

If you want to establish interorganizational replication between multiple Exchange Server 5.5 organizations or between Exchange 2000 Server and Exchange Server 5.5, you have several options. I discussed those options in "Exchange Server 5.5 Interorganizational Solutions," August 2000. However, establishing interorg or interforest replication between two Exchange 2000 organizations is more difficult.

I present an overview of how to build an interforest replication solution for connecting two or more Exchange 2000 organizations. You can find more information in the "Exchange 2000 Deployment Guide" in the Microsoft Exchange 2000 Server Resource Kit (in press).

When I talk about Exchange 2000, I use the terms interforest and interorg interchangeably because you can have only one Exchange organization for each Active Directory (AD) forest. Exchange 2000 differs from Exchange Server 5.5 in two important respects. First, Exchange 2000 doesn't have a separate directory such as Exchange Server 5.5's Directory Service (DS); Exchange 2000 is fully dependent on AD. Second, AD doesn't have built-in functionality that allows replication or synchronization of directory objects between separate forests. Because only one Exchange 2000 organization can exist in an AD forest, you need an interforest synchronization solution if your company has more than one forest (namespace).

Only one Exchange 2000 organization can exist per forest largely because of the AD schema. The AD schema defines the universe of objects that can reside in the directory. For each object class, the schema defines which attributes an instance of the class must have, which additional attributes it can have, and which object class can be a parent of the current object class. The AD schema must be the same on all Windows 2000 domain controller servers in the entire forest to provide a consistent set of attributes for all users. Because anyone with Schema Admin rights can extend the schema to include a new attribute and greatly affect the replication between servers, only trusted administrators should have Schema Admin rights.

To replicate directory entries between forests, you need a utility that can handle different schemas. The utility must use Lightweight Directory Access Protocol (LDAP) or Active Directory Service Interfaces (ADSI) to replicate entries between different forests. Microsoft Metadirectory Services (MMS) is a utility specifically designed to handle interforest synchronization requirements.

Metadirectory Solutions
A metadirectory solution differs from other replication or synchronization solutions because it maintains an independent join of objects from one or more directories. An independent join forms a link between objects in different directories without affecting objects when objects are renamed or moved. In this discussion, the joined objects reside in ADs that are separate forests.

Information about people, applications, and resources is scattered throughout most IT enterprises. Although organizations are storing an increasing amount of this identity data in LDAP standard-based directory services, they still store most of it in databases and other specialized forms. Companies confront many types of identity management challenges, such as

• Global Address List (GAL) applications—GAL applications typically attempt to synchronize mailbox information between different email directories within a company
• Human resources (HR) solutions—HR applications quickly propagate information about newly hired employees to all systems that require identity data and retract the information when employees leave
• E-commerce applications—E-commerce applications must synchronize information such as digital certificates for suppliers and extranet users with e-commerce directories that exist outside corporate IT firewalls

With each additional application and platform that you deploy, the number of places in which you must manage identity data increases. Therefore, enterprises must manage identity information in many different locations, even though each instance contains related and duplicate information.

Conceptually, the simplest solution is to have one enterprise directory that holds all information about users, machines, networks, and applications in the company. For many reasons, including political boundaries, most companies can't achieve this goal quickly, if ever. An alternative is a solution that links different directory services and applications and provides a consistent way to store, access, and manage identity data. If identity data must continue to exist in many places, solutions need to provide

• Connectivity to enable solutions to share identity information between many directory services, databases, and applications
• Brokering functionality to distribute changes made in one directory or application to other affected identity repositories in the enterprise
• Integrity mechanisms to ensure that related data remains consistent throughout the enterprise, maintains owner information, and adheres to integrity rules

Because identity management is complex, no one solution can perform all the necessary tasks. Instead, you might need to deploy several solutions, including

• Multidirectory access technologies that provide one programming interface to multiple directory services and database technologies
• Synchronization connectors that simplify management by keeping pairs of directory services synchronized automatically
• Directory consolidation strategies that enable companies, over time, to reduce the total number of directories that they need to manage
• Metadirectory technology that provides companies with advanced connectivity, brokering, and data-integrity management capabilities

You can benefit from a metadirectory in many ways. By integrating a company's identity repositories and joining identities shared among them, you enable departments to share information. This capability is valuable, for example, when one organization needs to share identities with another organization, when you need to create a mail-enabled user of one organization as a contact in another organization, and when you want to represent one organization's groups in another.

Microsoft Metadirectory Services
MMS 2.2 represents the Microsoft metadirectory solution. MMS uses management agents to connect to connected directories. Using an integrated discovery and integration process called the join, MMS creates connector object entries in the management agent's connector space and joins them to a single entry in the metaverse. The metaverse is that portion of the directory that presents the integrated view of joined objects from multiple connected directories. MMS can join the metaverse entry to multiple connected directory entries through these connector objects—each held in its respective management agent's connector space. When joined, attributes can flow between connected directories and the metadirectory. MMS supports bidirectional attribute flow, based on a set of rules that you configure. Figure 1 depicts the MMS structure.

The AD Management Agent
AD uses LDAP as its directory access protocol. Although MMS supports a generic LDAP management agent for use with Novell Directory Services (NDS), Netscape, Exchange Server 5.5, and other connected directories, the generic LDAP management agent isn't optimized for use with AD. The generic LDAP management agent must read the entire directory content to infer changes that have occurred in an LDAP-based directory. This approach is inefficient and not always practical in large directory environments, especially when you use administrative limits. Administrative limits restrict the number of entries that a search returns. Setting these administrative limits requires the LDAP management agent to automatically execute many smaller queries as part of a procedure to read the entire content of the directory.

Microsoft has included the AD management agent, a management agent that is fully integrated with and optimized for AD, as part of MMS 2.2. The AD management agent uses the Microsoft LDAP directory synchronization control to obtain directory updates from AD and uses LDAP to flow attributes and create objects in AD. This control lets the AD management agent request the changes that have occurred in AD without reading the entire content of the directory. This new mechanism allows near realtime synchronization with AD because you can use the mechanism to schedule synchronization updates as often as every minute. The AD management agent interfaces directly with the synchronization engine and automatically detects schema changes that occur in AD. The architecture of the AD management agent lets it automatically adapt to schema changes without requiring an adaptation of the management agent. In addition, the AD management agent is more efficient because it doesn't use an intermediate import and export file, as the other file-based management agents do.

You can use the MMS 2.2 AD management agent to directly mirror the contents of a Win2K forest in the MMS metaverse. When you use the AD management agent to mirror multiple trees of a forest or multiple forests, best practice is to create a virtual metaverse root for each forest with the dc=com namespace as the parent for each tree or forest. This practice lets the management agent fully replicate each tree or forest to MMS, preserving the tree's or forest's namespace while still allowing for replication between trees or forests through MMS. For more information about how to create a namespace when you're dealing with multiple trees or forests, see the MMS documentation on the MMS 2.2 CD-ROM.

Using MMS
If you need to limit transitive trust and schema proliferation (e.g., in case of mergers, acquisitions, or joint ventures), you need to use multiple Win2K forests. You can use the AD management agent to create a single namespace for these separate forests by integrating information from various business applications into AD. You then use the AD management agent to integrate and synchronize objects and attributes between multiple forests.

Multiple-forest environments are complex. In multiple-forest configurations, the AD doesn't support as many features as it supports in single-forest deployments (e.g., shared schema, security principals). However, you can reference another forest's security principals on ACLs as long as you've established trust. Although establishing trust might present problems in many interforest scenarios, it can be a useful solution to interorg collaboration problems. In the MMS 2.2 release of the AD management agent, Microsoft supports two multiple-forest scenarios—centrally managed AD forests and peer forests

Centrally managed forests. Most interforest AD scenarios are centrally managed; that is, a company integrates and manages multiple AD forests from one extended entity (i.e., one company). In a centrally managed forest, the company needs to

• Manage identities (users and contacts) across forests, including creating and deleting user accounts when employees join or leave the company
• Synchronize email address book attributes between the messaging systems of each forest (Exchange 2000, in this case)
• Manage nonsecurity-enabled distribution groups across forests
• Synchronize interforest locator information, such as site and subnet directory entries to support printer identification and searching

In a centrally managed forest, the AD management agent and MMS manage user, contact, organizational unit (OU), group, and public folder objects in AD. For example, the metadirectory manages entries originating from a central HR system. When HR adds an employee, business rules determine which forest to create the new account in. Then, the AD management agent adds a user object to the appropriate domain and a corresponding contact to a domain of the other forest.

You can propagate only a subset of objects in a forest to the other forest; you don't need to propagate all the objects in the forest. To create the subset, you explicit identify individual containers of interest and specific types of objects to propagate from one forest to the other.

MMS maps objects in one forest to the other as follows:

• Users of the source forest become contacts or disabled users in the target forest.
• Contacts in the source forest become contacts in the target forest.
• Security and distribution groups of a forest become universal distribution groups in the target forest.
• OUs of the source forest become OUs in the target forest.
• Domain controllers of the source forest become OUs in the target forest.

Some organizations might also need to support site, subnet, and location information and object synchronization between forests to support interforest resource locator services (e.g., the printer locator service). Performing this synchronization significantly reduces the time required to deploy Win2K across multiple forests in an enterprise. When site, subnet, and location information is available, users can locate the closest printer when they're using the Add Printer wizard. This information lets users locate printers in a uniform and consistent manner regardless of which forest or physical location they use to log on to Win2K.

Peer forests. In other situations, you need to integrate several forests that are peers (e.g., in the merger of two companies). Unlike the previous scenario, in this situation you manage each forest individually instead of from a central, external source. From the Exchange 2000 perspective, if you add users and groups in one organization, you need to project them and synchronize their attributes with the other organizations.

The peer forest requirements are essentially identical to the requirements of centrally managed forests, except that peer forests have a many-to-many relationship instead of the central forest's one-to-many relationship. To configure peer forests, you must enter a few parameters with minimal customization of the MMS AD management agent. Simply create a management agent for each forest and identify which object types to project, where to project these objects, and how often to perform the synchronization.

Setting Up MMS with Peer Forests
Let's look at an example in which you integrate two peer Win2K forests as a result of a company merger. In this situation, you must synchronize two or more Exchange 2000 organizations (forests) to support messaging between users in the two forests.

To create an interorg replication solution with MMS 2.2, you need to configure one AD management agent for each forest. You must configure this management agent in reflector mode, a management agent mode that forces all Win2K users to be automatically projected to the metaverse. Reflector mode differs from an association-mode management agent, which can join new objects only to existing metaverse objects that another management agent created. You set the management agent mode in the management agent configuration Properties dialog box. For information about how to configure the AD management agent, see the MMS documentation.

For this peer forest scenario, MMS must meet the following requirements:

• MMS must perform directory synchronization between the forests.
• Contact entries that MMS creates in either Exchange organization must mirror the corresponding native entry attribute for attribute.
• Ownership of all Exchange entry attributes must remain with the native Win2K forest.

You can install MMS on a server in either the target forest or the source forest. In this example, the namespace configured during the MMS install is dc=mergedcompany,dc=com, where mergedcompany represents the name the new company took after the merger. Then, the MMS creates one AD management agent for each forest and configures each management agent to communicate with the other forest.

The management agent for each forest brings all mailboxes and lists into the metaverse. It also extracts the other forest's entries from the metaverse and imports them into the local forest as contacts. When you configure this management agent to point to a specific AD forest, this management agent automatically picks a server to perform all read and write operations against. If the chosen server fails, the AD management agent automatically uses the GetNearestDC AD API call to find another server in the domain to communicate with the forest.

By default, all pertinent Exchange attributes are populated to the corresponding user objects in the metaverse. Using the management agent's attribute-flow user interface, you can customize additional attributes that you want to populate in the metaverse. The default configuration populates metaverse entry attributes to the contacts and groups of the target forest.

You must then create resource objects (i.e., pointers to a location in the forest) for each AD forest in which you want to create contacts and groups. This resource object dictates in which AD forest, AD domain, and AD container MMS populates and synchronizes these objects. You can decide also whether to create a flat list of users and groups or to pass on the hierarchical structure from the metaverse of the source forest. Usually, you set configurations to a flat namespace to create all the contacts and groups in one OU in the target forest. An exception to this practice is if you need to represent a hierarchical structure of OUs as they are in the source forest.

Next, you assign these resources to subtrees in the metaverse or use MMS's scripting capabilities to assign them to specific entries. Assigning resources to subtrees is simpler because you need only select a subtree in the metaverse (which represents an AD forest/Exchange organization) and assign it a resource. This action creates all objects of interest (e.g., contacts, groups, sites, subnets) in this forest and synchronizes their attributes in the container of the target forest that the resource specifies.

Setting up a resource for each forest and assigning it to a subtree of the metaverse representing the forests causes MMS to create these objects in the target forest. When MMS has created an object in the forest, attribute flow takes over and ensures that the attributes are synchronized.

Using MMS's scripting capabilities to assign resources to specific entries is a more powerful option because you can script specific behavior based on attributes of an object. For example, you might want to synchronize objects of only one forest to others based on the need to have a particular attribute present or have an attribute be a particular value. For instance, you might want to synchronize only full-time employees of the legal department with a partner's Exchange 2000 organization. The MMS documentation explains how to take advantage of these features.

To automate directory synchronization between two Win2K forests, the management agents must operate in "delta operation" mode; that is, the management agents must apply to the forest only changes they detect have been made since the last run. Applying only the latest changes reduces the amount of time needed to keep the forests updated. You can use either the MMS scheduling component for the management agents or the Win2K scheduling component.

An Interforest Solution
None of the current Microsoft interorg solutions for synchronizing mailbox information between Exchange Server 5.5 organizations work with Exchange 2000 because Exchange 2000 uses AD. The interorg tools that work with Exchange Server 5.5 depend on a Directory API (DAPI) interface to the directory or work only with the Exchange Server 5.5 DS. Win2K and Exchange 2000 include the Active Directory Connector (ADC), which uses LDAP to synchronize between Exchange Server 5.5 and AD, but the ADC currently doesn't support interforest synchronization.

Although not really a directory synchronization utility, MMS can combine the mailbox-enabled users and groups native to each Exchange 2000 organization into one directory (the MMS metaverse) while keeping track of which organization owns each directory entry. MMS can update any of the connected forests with entries external to the local Win2K forest namespace so that those users show up in the Exchange 2000 GAL. Through attribute flow, administrators have granular control over which attributes flow between the forests to support the business needs of each organization. MMS also provides more advanced tools that let you create complex business rules to support activities such as account provisioning or integration with HR directories. In the near future, Microsoft will add an interforest synchronization wizard to help you configure MMS. For more information about implementing MMS, check out the Web site at http://www.microsoft.com/windows2000/guide/server/ features/mms.asp or send inquiries to [email protected].