Why should I use the ADC Tools to create my Connection Agreements?

[The_Exchange_Team]

The Active Directory Connector is a utility that is used to replicate recipient and configuration data between the Exchange Directory and Active Directory.  It was first shipped with Windows 2000, then later shipped with Exchange 2000 Server and again with Exchange Server 2003.  It has proven to be a valuable asset in countless migrations, and it has caused customers more pain than just about any other Microsoft component.  Since I troubleshoot a majority of these cases, I am often asked by customers why I always recommend using the Connection Agreement Wizard from the ADC Tools to automatically create Connection Agreements rather than creating them manually.  The answer is simple - improper configuration due to human error.
 
Here are some of the more common mistakes that are made when customers manually create Connection Agreements.
 
One-Way Connection Agreement
 
Microsoft does not support the use of Connection Agreements that replicate in only one direction in mixed sites (sites containing an instance of the Site Replication Service).  Although customers will often configure one-way Connection Agreements in mixed sites, the ADC Tools will only allow this configuration for pure Exchange 5.5 sites.

Improperly Set Schedule
 
After the release of Exchange Server 2003 SP1, customers who moved mailboxes between sites began to experience problems with mail routing and distribution list membership.  While the progress of the cross-site mailbox move can be monitored using either the Active Directory Users and Computers or Exchange System Manager management consoles, the cleanup process occurs in the background over time. 
 
If the replication schedule for an ADC recipient connection agreement or a directory replication connector is set improperly, this cleanup process will be delayed - resulting in mail routing issues and distribution list membership problems.  If the replication interval for a Recipient CA or a directory replication connector is either set to None or Selected Times (with greater than four hours between cycles), these problems will arise.  Connection Agreements created by the ADC Tools are set to replicate Always.
 
841659 Issues to know about during site consolidation to an Exchange Server

Invalid/Improper Scope
 
Defining a proper replication scope is the most challenging aspect of creating an ADC connection agreement manually.  Most customers try to strictly control replication by using multiple connection agreements scoped to replicate only recipients or distribution lists from only certain recipient containers.  Although many customers have controlled replication successfully using manually configured connection agreements, many more have felt the pain caused by a replication scope that did not work as expected.
 
While controlling replication by manually adding each recipient container or organizational unit may prevent the creation of those containers in the target directory, if you delete any container defined in the properties of the connection agreement the ADC will exception and fail to replicate updates:
 
Event Type:       Error
Event Source:    MSADC
Event Category: Replication
Event ID:           8142
Description:
The service threw an unexpected exception. 
 
Event Type:       Error
Event Source:    MSADC
Event Category: Replication
Event ID:           8124
Description:
Processing of the Connection Agreement 'Recipient CA' has been stopped due to an invalid configuration. Check the event log for more information.
 
When the ADC replicates from Exchange 5.5 to Active Directory, a set of object-matching rules are used to search the entire Active Directory domain for the SID of the account associated with the Exchange 5.5 mailbox.  If the SID is found, the ADC links the account to the mailbox using an LDAP attribute called ADC-Global-Names - regardless of the organizational unit where it resides.  However, the ADC is limited to replicating the contents of only those organizational units specified under the From Windows tab of the recipient connection agreement to the Exchange 5.5 directory. 
 
With this in mind, a tightly scoped recipient connection agreement can fail to replicate updates back to Exchange 5.5 if the user account associated with an Exchange 5.5 mailbox does not exist in one of the export containers defined under the From Windows tab of the connection agreement.  This configuration produces inconsistent replication results.
 
To remedy both of these issues, the ADC Tools was designed to replicate from the parent Site container under the From Exchange tab and the parent domain container under the From Windows tab.  When the ADC is configured to replicate a parent container, it will also replicate mail objects in child containers.  The only disadvantage to this configuration is that the container structure contained in either the Exchange Directory or Active Directory may be duplicated in the target directory beneath the container defined as the Default Destination container in the properties of the Recipient Connection Agreement.  If necessary, objects created by the ADC within the Default Destination container in Active Directory may be moved to another Organizational Unit, as long as the ADC is configured to replicate the contents of that Organizational Unit or its parent container back to the Exchange 5.5 Directory.
 
867627 Description of the changes to ADC Tools in Exchange Server 2003 Service Pack 1
 
In addition to these two common scoping issues, one of the most frequent questions I have been asked by customers is how to manually create a recipient connection agreement for a pure Exchange 2000 or Exchange 2003 administrative group.  Prior to the development of the ADC Tools, a great deal of background knowledge on ADC replication behavior was required to successfully accomplish this task.  I finally wrote a Microsoft Knowledge Base article that documents this procedure in detail.
 
888032 Exchange Server 5.5 users cannot see recipients from a pure Exchange
 
The problem with manually creating recipient connection agreements for pure Exchange 2000 or Exchange 2003 administrative groups is that duplicate objects can be created in rare circumstances.  If a Site Replication Service acts as the replication endpoint for more than one Site's manually configured recipient connection agreement, duplicate objects may be created in the SRS whenever a new mailbox is created, if both connection agreements replicate at the same time. 
 
Connection agreements created by the ADC Tools are not susceptible to this behavior, as a custom LDAP search filter is used to replicate objects.  This insures that only one CA will replicate the mailbox to the target Site Replication Service.  This search filter is contained within the msExchServer1SearchFilter attribute, as shown:
 
msExchServer1SearchFilter: (&(|(objectclass=user)(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=Organization/ou=Site/cn=*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE)));
 
You may notice that after using the ADC Tools to create a recipient connection agreement, you are unable to modify the replication scope.  For example, you may want the connection agreement to replicate only mailboxes and not contacts or distribution lists.  If you try to deselect these options under the From Windows tab, you will find that it is grayed out.  This is by design (See this post for more info).
 
To exclude objects from replication using a connection agreement that is created by the ADC Tools, use ADSIEdit to remove the desired objectclass from the search filter.  For example, to replicate only contacts, remove (objectclass=user) and (objectclass=group).  Be sure to include the preceding and trailing parentheses, otherwise the search filter will be invalid.  Utilize caution, as this can produce unexpected results if not done correctly.
 
Deletions to LDF/CSV Files
 
One common mistake that a lot of administrators will make when deploying the Active Directory Connector with manually configured recipient CAs is enabling the option for keeping deletions by writing them to LDF or CSV files.  Although this is normally set with the intention of protecting the Exchange 5.5 mailboxes from being accidentally deleted, these two options can cause subtle problems within your environment.  
 
One of the primary purposes of the ADC is to provide Global Address List (GAL) synchronization for Exchange 5.5 and Exchange 2000 or Exchange 2003 users.  If deletions are written to LDF or CSV files, over time the GAL will become out of synch.  Imagine that you hire a team of consultants on a three month contract and provide them with access to email.  At the end of the contract, you delete their mailboxes and user accounts using Active Directory Users and Computers.  A few weeks later, you notice that their mailboxes still appear in the GAL in the Exchange 5.5 Directory.  This is because the option to write deletions to CSV file was selected in the properties of the recipient connection agreement, and you forgot to import the deletions into the Exchange Directory.
 
Another problem that can be c aused by these options occurs after mailboxes have been moved from one site to another.  Part of the cleanup process for cross-site mailbox moves involves the removal of the stub directory object in the source site.  This functionality is provided during the move mailbox process, as the original proxy addresses are stripped off the object, and two new X500 addresses are added to the stub object.  X500:ADCDoNotReplicate tells the ADC not to include this object in any further replication attempts, and X500:ADCDeleteWhenUnlinked tells the ADC to remove the object once all the distribution list membership is corrected via directory replication. 
 
If you see that stub directory objects in the source site are still lingering around for a few days after the mailboxes are moved cross-site, check the email addresses on one or more of the objects.  If X500:ADCDoNotReplicate is present but X500:ADCDeleteWhenUnlinked is missing, then you have a recipient connection agreement configured to write deletions to LDF/CSV files.  You will need to import the CSV file to complete the cleanup process.
 
Circumstances that Require a Manually Configured Connection Agreement
 
As wonderful as Connection Agreement Wizard is, there are certain circumstances that require human intervention involving the manual creation of a recipient connection agreement. 
 
The ADC Tools may also allow the creation of Connection Agreements that do not have writeable access to Active Directory.  If you run the Connection Agreement Wizard, you will be prompted to enter the service account information for each Exchange site.  You will also be prompted to enter the administrator account information for each domain that contains Exchange mailboxes.  This account should be a member of the Domain Admins group, and it should have at a minimum the "Exchange View Only Administrator" role delegated to it at the organizational level.  Additionally, if you have distribution lists with hidden membership in the Exchange 5.5 Directory, this account should also be a member of the Exchange Domain Servers or Account Operators group.  If the account you specify in the Connection Agreement Wizard does not meet these requirements, replication may fail with the following event:
 
Event Type:       Error
Event Source:    MSADC
Event Category: LDAP Operations
Event ID:           8270
Description:
LDAP returned the error [32] Insufficient Rights when importing the transaction
dn: cn=TestUserA,cn=Recipients,CN=Users,DC=domain,DC=com
changetype: Add
legacyexchangedn:/o= Organization/ou=Site/cn=Recipients/cn=TestUserA
mailnickname:TestUserA
mail:TestUserA@Site.Organization.com
...
-
  (Connection Agreement 'Users: domain.com - Site\Organization' #1436)
 
Additionally, the ADC Tools will not create Connection Agreements with custom object-matching rules.  By default, the Active Directory Connector will use the SID (security identifier) of the Primary Windows NT Account of an Exchange 5.5 mailbox to search for associated accounts in the target Active Directory domain.  Some customers may choose to "anchor" their matches based on a direct attribute, like sAMAccountName (ldap-display-name of User Logon Name attribute (Pre-Windows 2000)), or on the value of an attribute with a prefixed string, like [SMTP:] mail (ldap-display-name of the Primary SMTP Address).  Since the ADC Tools Connection Agreement Wizard uses the default matching rules, it will not be able to determine how the matching rules the customer has chosen would perform.

- Dave Howe

[#2]

Hi, Thanks for a great article. I have one question regarding the schedule. When moving mailboxes intra-site between an Exchange 5.5 server and a Exchange 2003 server we always stop the ADC service. If we then move a larger amount of mailboxes that will then result in the ADC not running for more than four hours. Will that generate problems for us when doing cross-site mailbox moves? Or will it just work fine i we start the ADC service when we are done and then manually run "replicate now"?

Thanks
Martin

[#3]

Martin -

You should definitely continue to stop the ADC when you're doing moves WITHIN the site. Cross-site mailbox moves require the ADC, and in these moves there's no need to stop the ADC.

That said, you CAN stop the ADC -- and if you're combining moves within the site and across sites, you should stop the ADC during the process to ensure the moves within the site are not affected. The mailboxes moved cross-site will simply not complete their cleanup until the ADC is reenabled and the cleanup cycle completes. See my blog post for more on the steps in this process: http://blogs.technet.com/evand/archive/2004/09/05/225918.aspx

[#4]

Thanks alot!

Martin

[#5]

best prices for xenical on http://www.bestrxpills.com