Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

How to control which site replication service owns a site


View products that this article applies to.

This article was previously published under Q315408

↑ Back to the top


Summary

In a mixed mode Microsoft Exchange Server 5.5 and Exchange 2000 Server or Exchange Server 2003 organization, every administrative group must have the administrative group's configuration naming context replicated between the Exchange Server 5.5 computer and Active Directory. Active Directory Connector (ADC), configuration Connection Agreements, and the Site Replication Service (SRS) process this replication. Each SRS has a configuration Connection Agreement that corresponds with this SRS. This configuration Connection Agreement is configured to use that SRS as the bridgehead to replicate Active Directory data between the Exchange Server 5.5 and Exchange 2000 Server or Exchange Server 2003 computer.

For mixed administrative groups that contain both Exchange Server 5.5 and Exchange 2000 or Exchange 2003 computers, an SRS in the local administrative group is responsible for replicating the configuration naming context. However, because pure Exchange Server 5.5 and pure Exchange 2000 or Exchange 2003 administrative groups do not have an SRS, an SRS in a different mixed mode administrative group must be responsible for replicating that site's configuration naming context.

Prior to Microsoft Exchange 2000 Server Service Pack 2 (SP2), a component of the SRS named the site Knowledge Consistency Checker arbitrates which SRS is responsible for replicating the configuration naming context for pure Exchange Server 5.5 administrative groups, mixed administrative groups, and pure Exchange 2000 or Exchange 2003 administrative groups. This procedure is performed by using an algorithm that compares a hash of the name of the administrative group and the name of each configuration Connection Agreement. The administrator cannot control which SRS obtains ownership of the naming context.

Each SRS in the organization runs its own separate instance of the site Knowledge Consistency Checker. When the site Knowledge Consistency Checker on one SRS obtains ownership of a naming context, the SRS writes the distinguished name of the site or administrative group's configuration container onto the SRS's configuration Connection Agreement. Then, when the site Knowledge Consistency Checker runs on other SRSs, the site Knowledge Consistency Checker reads the site or administrative group's configuration distinguished name from the first SRS's configuration Connection Agreement, and know that the naming context has been claimed. If the naming context is a pure Exchange Server 5.5 site, the distinguished name is added to msExchServer2ExportContainers. If the naming context is a pure Exchange 2000 or Exchange 2003 administrative group, the naming context is added to msExchServer1ExportContainers. If the naming context is a mixed administrative group, then the naming context is added to both msExchServer1ExportContainers and msExchServer2ExportContainers, because two-way replication is required for mixed administrative groups.

The msExchServer1ExportContainers attribute and the msExchServer2ExportContainers attribute are on each respective configuration Connection Agreement object under Active Directory Connections. To view the values of these attributes by using ADSI Edit, follow these steps:
  1. Expand the following container:
    Configuration Container\CN=Services\CN=Microsoft Exchange\CN=Active Directory Connections
  2. In the right pane, locate CN=ConfigCA_sitename_servername.
Which SRS owns the administrative group after arbitration cannot be controlled, and therefore it is possible that an Exchange Server 5.5 site could be arbitrated to an SRS that is not the closest SRS in the directory replication topology. This would increase replication latency for configuration changes in that site. In addition, if an administrator creates a new administrative group by using Exchange System Manager or a new site by using Microsoft Exchange Server 5.5 Administrator program, it is not possible to choose which SRS should be responsible for replicating that administrative group.

By controlling which SRS owns replication of non-local administrative groups, they can be consolidated onto a single SRS for consistency, or for Exchange Server 5.5 sites, and then can be configured to use a specific SRS to reduce replication latency. Latency can be reduced by choosing an SRS that is in a site that must cross the fewest number of directory replication connectors to reach the Exchange Server 5.5 site.

↑ Back to the top


More information

The PreferredSRS setting, added in Exchange 2000 SP2, enables an administrator to specify a specific SRS to be responsible when creating new sites or administrative groups. Any unclaimed naming contexts are reallocated to an SRS at the next site Knowledge Consistency Checker arbitration, which is determined as follows:
  1. To the administrative group's PreferredSRS, if set.
  2. Through typical arbitration, if PreferredSRS is not set.
Notes
  • A naming context is only re-arbitrated if the naming context is not currently owned by any SRS, or if multiple configuration Connection Agreements claim ownership. Setting PreferredSRS on an existing administrative group does not automatically move that administrative group to the new SRS, because the naming context is already owned by another SRS and, therefore it does not go through the arbitration process. In addition, all SRS servers must run Exchange 2000 SP2 or later for PreferredSRS to function properly.
  • If an administrative group is already owned by an SRS, attempts to remove that SRS or re-arbitrate the administrative group to a different SRS are not supported. An SRS that owns pure administrative groups should not be removed until you are ready to remove all SRSs in the organization. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    272314� Preparing a mixed mode organization for conversion to native mode
After Exchange 2000 SP2 is applied to all Exchange 2000 SRS servers, the site Knowledge Consistency Checker reads the Administrative note box on the administrative group's object in Active Directory for mixed and pure Exchange 2000 or Exchange 2003 administrative groups, and the Exchange Server 5.5 configuration object for pure Exchange Server 5.5 sites.

Type the PreferredSRS in the Administrative note in the following format:
PreferredSRS SRSName
where SRSName is the server name of the SRS that should be responsible. Multiple SRSs can be specified as:
PreferredSRS SRS1 PreferredSRS SRS2
The site Knowledge Consistency Checker reads the Administrative note from the Exchange 2000 or Exchange 2003 administrative group and Exchange Server 5.5 configuration containers and uses that list throughout arbitration. If none of the names in the list exists as an SRS, the list is discarded and typical arbitration occurs. Mixed sites are only arbitrated to servers within that site even though servers outside of that site may be in the list.

To set PreferredSRS when you create a new Exchange 2000 or Exchange 2003 administrative group, perform the following steps:
  1. Use Exchange System Manager to create a new administrative group.
  2. Set PreferredSRS SRSName on the Details tab (as described earlier), and then click OK in the administrative group's Properties.
  3. After the site Knowledge Consistency Checker runs, verify that the administrative group has been arbitrated to the correct SRS. To do so, perform the following steps:
    1. Open ADC Microsoft Management Console (MMC), click to expand the ADC server, and then double-click the configuration Connection Agreement that you want to view.
    2. Click the From Windows tab, and then view the Windows Organizational Units to verify if the administrative groups display.

      Note Because you cannot edit the dialog, there is no scroll bar available. If you cannot view the administrative group, then the alternate method is to verify the value of msExchServer1ExportContainers on the configuration Connection Agreement object in Active Directory by using a tool such as ADSI Edit or LDP.

↑ Back to the top


Keywords: KB315408, kbinfo

↑ Back to the top

Article Info
Article ID : 315408
Revision : 11
Created on : 10/25/2007
Published on : 10/25/2007
Exists online : False
Views : 321