Exchange 2000 Server and Exchange Server 2003 SRS


Topic Last Modified: 2006-04-07

By Jonathan Runyon

This article covers Site Replication Service (SRS), which is a component of Microsoft® Exchange Server 2003 and Exchange 2000 Server. There is confusion about what SRS does, how to troubleshoot it, and how to work with it without causing more problems. This article addresses many of those issues. For a better understanding of SRS, we recommend that you read the entire article.

SRS is a service that makes possible the exchange of directory information between the Exchange Server version 5.5 directory and the dissimilar Active Directory® directory service. In mixed-mode organizations, SRS is necessary because Exchange Server 5.5 directory information can only be replicated among servers running Exchange Server 5.5, and not with Microsoft Windows® domain controller servers.

Exchange Server 5.5 servers are able to replicate directory information with SRS, because SRS mimics an Exchange Server 5.5 directory service. Using a connection agreement, the Active Directory Connector (ADC) service then replicates the directory information between SRS and a domain controller.

SRS performs additional functions, such as exchanging recipient information for administrative groups without an SRS. SRS can act as an Exchange directory endpoint of an ADC recipient connection agreement. It also automatically detects and reacts to directory replication topology changes in the Exchange organization.

SRS is created automatically, and runs on the first server running Exchange Server 2003 or Exchange 2000 Server that joins an Exchange Server 5.5 site. Manual SRS creation on additional servers running Exchange Server 2003 or Exchange 2000 Server is also possible under certain circumstances.

There are several components that make up the working set of the SRS server.

Like other Exchange Server 2003 or Exchange 2000 Server services, the SRS service (Srsmain.exe) runs under the context of the local system account. All servers running Exchange Server 2003 or Exchange 2000 Server contain the binaries and registry information for SRS by default. However, the service is only enabled when SRS is created on the specific server.

SRS is similar to the Exchange Server 5.5 directory service, except that the Name Service Provider Interface (NSPI) is disabled to prevent Microsoft Outlook® clients from connecting to it and using the Exchange Server 5.5 directory for name resolution.

SRS uses remote procedure calls (RPCs) to communicate with previous versions of Exchange Server directory services within its administrative group (intrasite). SRS can also replicate directory information with Exchange Server 5.5 servers or SRS servers in other sites when used as a bridgehead for directory replication connectors (intersite).

Because ADC supports only the Lightweight Directory Access Protocol (LDAP), SRS must run an instance of this protocol. To prevent port conflicts when Exchange Server 2003 or Exchange 2000 Server is running on a domain controller, the LDAP interface for SRS uses port 379 instead of 389. Exchange Server 2003 SRS will adapt to match the LDAP port number of the Exchange Server 5.5 server used for initial synchronization during SRS creation, if the LDAP protocol setting for the site is set to anything other than 389. After SRS is installed, the SRS LDAP port is hard coded and cannot be changed. However, in Exchange Server 2003 SRS, the SRS port might be something other than port 379.

Although you can connect to SRS using the Exchange Server 5.5 administrative program, you are limited to viewing the properties of configuration objects only. You cannot view the properties of recipient objects in the SRS directory. Viewing the global address list (GAL) from SRS using the Exchange Server 5.5 administrative program does not show the true contents of the SRS directory, because this view of the GAL is read from Active Directory and not the SRS directory.

Using the LDP tool, you can connect to the LDAP port on an SRS server, bind with the service account of the Exchange Server 5.5 site, and browse the recipient objects in the SRS directory. The contents of the SRS recipient container can also be exported to a .csv file using the Exchange Server 5.5 administrative program. In those ways, you can see what objects were actually replicated into the SRS database, either by ADC or by directory replication from Exchange Server 5.5 servers.

SRS utilizes a transactional logging JET database similar to the Exchange Server 5.5 directory service database (Dir.edb) to store the directory information. The Srs.edb file, located in the exchsrvr\srsdata folder, is subject to the same treatment reserved for Dir.edb. The srsdata folder should be excluded from file-level antivirus scanners to prevent database corruption or log file quarantine. For disaster recovery purposes, the SRS database should be restored from online backups. On servers that have SRS running, there is a separate option to back up the SRS database in NTBackup.

The configuration connection agreement (config connection agreement) replicates the Exchange Server 5.5 site configuration data with the Exchange Server 2003 or Exchange 2000 Server configuration data in Active Directory. Config connection agreements allow servers running Exchange Server 2003 or Exchange 2000 Server to coexist with previous versions of Exchange.

Config connection agreements are automatically created by Setup when you install a server running Exchange Server 2003 or Exchange 2000 Server in an existing Exchange Server 5.5 organization. Setup analyzes the Exchange organization and builds the config connection agreement necessary to replicate configuration information between Exchange Server 5.5 and Active Directory.

The first config connection agreement uploads the configuration directory data from every Exchange Server 5.5 site to Active Directory. However, it downloads only the configuration directory data for the local site back to SRS.

When you install servers running Exchange Server 2003 or Exchange 2000 Server in other Exchange Server 5.5 sites, more config connection agreements are created, because the first server running Exchange Server 2003 or Exchange 2000 Server installed in a pure Exchange Server 5.5 site will get an SRS automatically. When this happens, the first config connection agreement stops uploading Active Directory configuration directory data for the sites that now have servers running Exchange Server 2003 or Exchange 2000 Server installed, and the configuration directory data is replicated by the config connection agreement for each site. The local SRS takes ownership of its site naming context.

Each SRS and config connection agreement is a matched set. The matching config connection agreement is deleted automatically when the owning SRS is decommissioned.

Also, consider the ADNAutoDRC directory replication connector that appears in Exchange Server 5.5 directory.

ADNAutoDRC appears as a directory replication connector, in the Directory Replication Connector container in the Exchange Server 5.5 directory of a mixed site. ADNAutoDRC represents the replication path of the config connection agreement, and lists any pure Exchange Server 2003 or Exchange 2000 Server site for which SRS is responsible as an inbound site. ADNAutoDRC does no replication. Its schedule is set to never. But Exchange Server 5.5 servers consider ADNAutoDRC as a directory replication connector, and list the pure Exchange Server 2003 or Exchange 2000 Server group as an inbound site. When the Knowledge Consistency Checker (KCC) runs on the Exchange Server 5.5 servers, KCC determines that SRS is the directory replication bridgehead for that connector, and requests updates from SRS for the site.

In a mixed-mode administrative group, SRS is responsible for replicating the configuration context of the administrative group to which it belongs. However, because pure Exchange Server 5.5 and pure Exchange Server 2003 or Exchange 2000 Server administrative groups have no SRS, SRS in a mixed-mode administrative group must take responsibility for replicating any pure administrative group's configuration naming context.

To prevent replication conflicts, only one SRS at a time can take responsibility for replicating an administrative group's configuration context. A component of SRS, named the Site Knowledge Consistency Checker (SKCC), arbitrates which SRS is responsible.

The Site Knowledge Consistency Checker (SKCC) is sometimes referred to as Super KCC.

Each SRS in the organization runs its own separate instance of SKCC. When SKCC on one SRS obtains ownership of a configuration naming context, SRS writes the distinguished name of the administrative group's configuration container onto the SRS config connection agreement. For administrative groups, the value is written to msExchServer1ExportContainer. For sites, the value is written to msExchServer2ExportContainer. Then, when SKCC runs on another SRS, SKCC reads the site or administrative group's configuration distinguished name from the owning SRS config connection agreement, and knows that the naming context has been claimed.

SKCC runs by default every three hours.

When an administrator introduces a new administrative group into the organization, it may be desirable to control which SRS in the organization takes responsibility for replicating the new configuration naming context. For example, to limit replication latency, SRS in a mixed-mode administrative group that is also a hub site for Exchange Server 5.5 directory replication is a better choice than SRS in a downstream spoke site.

In Exchange versions earlier than Exchange 2000 Server with Service Pack 2 (SP2), there was no way to control arbitration. The PreferredSRS logic, added in SP2, enables an administrator to specify the SRS to be responsible when creating new sites or administrative groups. For more information, see Microsoft Knowledge Base article 315408, "How to control which site replication service owns a site."

Note that the arbitration can be controlled only if the site's naming context is not yet owned by any SRS in the organization. If SRS has already claimed a site and is responsible for it, the PreferredSRS logic cannot be used to change the SRS that is responsible for that site.

Because a pure administrative group has no SRS, an SRS somewhere in the organization has to take the responsibility for replicating recipient information for that administrative group and making it available for Exchange Server 5.5. Otherwise, users on Exchange Server 5.5 servers would not be able to view that administrative group's users, contacts, or groups in the GAL. Also, if Exchange Server 5.5 Internet mail connectors are still in use to accept inbound mail, messages to these users would fail.

SRS has the ability to replicate not only its own naming context, but also the naming context for any pure administrative group for which it has previously won responsibility during arbitration. A two-way recipient connection agreement is needed to replicate the recipient data from Active Directory to the SRS database. SRS is then able to replicate the data to Exchange Server 5.5 servers through the directory replication process and make it appear as if the data had replicated directly from the pure administrative group's naming context.

For more information, see Microsoft Knowledge Base article 291170, "XADM: Exchange Server 5.5 Users Cannot See Exchange 2000 Mailboxes in the Global Address List."

Because SRS creation is handled automatically by Setup on an as needed basis, manual creation of an additional SRS is only required if an existing SRS has to be replaced. Creation of SRS is controlled from the Exchange System Manager program, running on the target server, which is the server that will be running SRS.

Microsoft does not support creation of SRS on a cluster server. For more information, see Microsoft Knowledge Base article 328875, "How to implement Exchange 2000 Server on a Windows 2000-based cluster."

Also, SRS will not function properly on a front-end server. For more information, see Microsoft Knowledge Base article 313646, "XADM: Services Are Disabled on Front-End Servers After an Exchange 2000 Server SP2 Upgrade."

The new (second) SRS synchronizes directories with the existing SRS during creation. After the new SRS is fully functional and only after all responsibilities have been moved to the new SRS, the original SRS can be deleted. If the SRS is an endpoint for Exchange Server 5.5 directory replication connector, or ADC recipient connection agreement, you will need to shift these endpoints to the new SRS.

When the original SRS is deleted, the new SRS will automatically have responsibility for its own local administrative group. But there is no guarantee that the new SRS will have responsibility for all the naming contexts of other administrative groups, which were previously the responsibility of the original SRS. You can only control this using the PreferredSRS method mentioned earlier.

There is no load balancing achieved by introducing a second SRS into an administrative group. Unless there are topology changes in the organization, specifically the addition of new administrative groups, or changes in Exchange Server 5.5 directory replication links, there will be no arbitration for which the second SRS can compete.

We strongly recommend that all Exchange Server 5.5 servers in the organization be decommissioned before removing the only SRS server in an administrative group. Changes to the replication topology caused when removing SRS will have significant impact to interoperability between administrative groups.

SRS can be safely deleted only if the following conditions are met:

  • Another SRS exists in the administrative group to take over responsibility for replicating the configuration naming context.


  • There are no Exchange Server 5.5 servers in the administrative group and SRS is not the endpoint of an Exchange Server 5.5 directory replication connector.

SRS can only be deleted using the Exchange System Manager running on the server running Exchange Server 2003 or Exchange 2000 Server running the SRS to be deleted. You can also accomplish this through a terminal session to the server running Exchange System Manager.

Consider the following troubleshooting information.

  • Exchange Server 5.5 Directory Replication

    Because SRS emulates an Exchange Server 5.5 directory service, many of the same troubleshooting methods can be employed. Increase diagnostic logging for MSExchangeSRS as you would MSExchangeDS when testing intersite or intrasite directory replication. Check the application event log for warnings and errors relating to directory replication and Knowledge Consistency Checker. Many articles written for Exchange Server 5.5 troubleshooting apply to SRS as well.

  • SRS Database

    You can use Exchange Server Database Utilities (Eseutil) to check the consistency of Srs.edb, or perform an offline defragmentation. But like an Exchange Server 5.5 directory service database, it should never be repaired. If the SRS database becomes corrupt, SRS will start, but in a semi-running state. While the SRS directory will not be functional in this condition, it is a requirement for the backup API to locate SRS during a restore.

    If no backup of the SRS database is available to restore, you may be able to create a new SRS on another server running Exchange Server 2003 or Exchange 2000 Server in the administrative group, as long as an Exchange Server 5.5 server is also available. When the new SRS is created, select the Exchange Server 5.5 server to initially synchronize directories.

  • ADC Connection Agreements

    Before testing any connection agreement that uses SRS as an endpoint, confirm that the information you expected to replicate is present on the origination endpoint, which is the directory from which add, change, or delete action was taken. Use ADSIEdit to check the Windows endpoint and make sure changes in Active Directory have replicated at least as far as that domain controller. Use the LDP tool connected to SRS to check for changes in Exchange Server 5.5 directories that have made it to SRS, or perform a directory export out of SRS into the .csv file.

    After you determine that the data you expect to replicate is present on the endpoint, use diagnostic logging for the ADC service to check for any warning or error events related to the connection agreement and the object to be replicated.

    The config connection agreement will only replicate configuration objects, and then only from the directory where the object were created. For example, changes to Exchange Server 5.5 servers and connectors will only replicate from SRS to Active Directory, and changes to servers running Exchange Server 2003 or Exchange 2000 Server and connectors will only replicate from Active Directory to SRS.