Active Directory Connector Connection Agreement Requirements for Mixed Administrative Groups

Running Exchange 2000 Server or Exchange Server 2003 in mixed mode allows coexistence with earlier versions of Microsoft Exchange Server. This article is intended to document the Active Directory Connector (ADC) configuration requirements for organizations that have Exchange 2003 servers, Exchange 2000 servers, and Exchange Server 5.5 or earlier computers. For the purposes of this document, the term "mixed site" refers to an administrative group that has at least one Exchange 2000 or Exchange 2003 server installed that is running a Site Replication Service (SRS). This administrative group may also have additional Exchange servers.

Every Mixed Site Must Have a Two-Way Connection Agreement

To allow proper replication between Active Directory and the Exchange Server 5.5 directory, every mixed site in the organization must have a two-way Connection Agreement configured. The server specified under Exchange Server information on the Connections tab of the Connection Agreement properties must be either an Exchange Server 5.5 computer or an SRS server in the mixed site. Note that the SRS server is hard-coded to use port 379 for Lightweight Directory Access Protocol (LDAP) traffic, so if you choose to use an SRS server as the Exchange endpoint, you must change the port number on the Connection Agreement to 379.

Two One-Way Connection Agreements Instead of One Two-Way Connection Agreement Is Not Supported

Using two one-way Connection Agreements that have overlapping import and export containers to achieve two-way replication is not supported. For example, suppose you have a "From Exchange to Windows" Connection Agreement set up that is replicating the Site\Recipients container to a default import container of Domain\Users. You cannot set up another one-way "From Windows to Exchange" Connection Agreement that has Domain\Users as an export container. To achieve the two-way replication required for mixed sites, you must use a two-way Connection Agreement.

There are several reasons for this requirement:

• The logic of the one-way Connection Agreement was not designed to support two-way replication. A one-way Connection Agreement assumes that the source object is authoritative, and the target object is not, while a two-way Connection Agreement treats the objects in both directories as possible sources.
• One-way connection agreements do not support timestamp checking. Timestamp checking is the process that a two-way Connection Agreement uses to ensure that if matching objects are modified in both directories between replication cycles, the latest change will apply.
• Two-way Connection Agreements support back-replication suppression, where it checks the objectVersion and replicatedObjectVersion attributes of the objects in both directories before replication. This ensures that if the ADC was the last process to modify an object, the ADC does not replicate that change back to the original directory. You cannot guarantee this with two one-way Connection Agreements, and this can cause replication loops, where both the Exchange and Windows objects are continually modified.

Note If you change an existing one-way recipient connection agreement to a two-way connection agreement, after Active Directory Connector (ADC) replication, you may receive an access denied error message and you can no longer log on to the Microsoft Exchange Server 5.5 mailbox. If you view the permissions of the mailbox in the Exchange Server 5.5 Exchange Server Administrator program (after you view the rights for roles on the Permissions tab), the mailbox owner right is not listed among the permissions for that account.

For additional information about how to resolve this behavior, click the article number below to view the article in the Microsoft Knowledge Base:

In an environment where the security group or the distribution list that was created in Active Directory is replicated to Exchange Server 5.5, if you add the new user whose site (Site 2) is different from the site (Site 1) where the security group or the distribution list is replicated to, that new user is not replicated to the Exchange Server 5.5 side. This issue occurs when you configure the Connection Agreement to use the From Windows to Exchange setting.

This issue is caused by the following Active Directory Connector (ADC) behavior. When ADC determines whether the objects in Exchange Server 5.5 and in Active Directory are the same or not, ADC reads both the ADC-Global-Names attribute on the Exchange Server 5.5 side and the msExchADCGlobalNames attribute on the Active Directory side. These values are added and replicated by ADC. If changes are added to an object, the objects whose values match each other in the directory are updated.

In the case of two-way Connection Agreements, if the user who is permitted to create the mailbox in Active Directory is replicated, that user's distinguished name and objectGUID are stored in the ADC-Global-Names attribute and the msExchADCGlobalNames attribute. If you add the user to the Exchange Server 5.5 distribution list where replication is performed by ADC, Exchange Server 5.5 reads the ADC-Global-Names attribute of the member mailbox that is going to be added and tries to identify the mailbox by using the distinguished name or the objectGUID that is stored in the ADC-Global-Names attribute. However, if you add the user in Site 2 to the security group or the distribution list that is configured to be replicated to Site 1 in Active Directory, the ADC-Global-Names attribute of Site 2 is not replicated to Site 1. You can see this symptom when you view the security group or the distribution list from Site 1 in Exchange Server 5.5.

For these reasons, Exchange Server 5.5 in Site 1 cannot read the distinguished name and the objectGUID of the mailbox that is being added to the distribution list. Because of this behavior, Exchange Server 5.5 cannot determine the mailbox that was added to the group. As a result, the user in Site 2 is not added to the security group or the distribution list.