I mentioned in the previous blog post what the main components of the SRS are. Now, let’s go into how this thing works and how to troubleshoot it if needed!
1. Controlling Arbitration
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, an SRS in a mixed mode administrative group that is also a hub site for Exchange 5.5 directory replication is a better choice than an SRS in a downstream spoke site.
Please note here that the arbitration can be controlled only if the site's naming context is not yet owned by any of the SRSes in the organization. In other words - if an SRS has already claimed a site and is responsible for it - the PreferredSRS logic can not be used to change the SRS that is responsible for that site.
2. Special Functions of the SRS
Since 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 5.5. Otherwise, users on Exchange 5.5 servers would not be able to view that administrative group's users, contacts or groups in the Global Address List. Also, if Exchange 5.5 internet mail connectors are still in use to accept inbound mail, messages to these users would fail.
The 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 2-way recipient connection agreement is needed to replicate the recipient data from Active Directory to the SRS database. The SRS is then able to replicate the data to Exchange 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.
Since SRS creation is handled automatically by setup on an as needed basis, manual creation of additional SRS's is only required in unusual circumstances. An SRS cannot be "moved" from one server to another. Instead the responsibilities of an SRS are taken over by another SRS. The changes to directory replication topology brought on by shifting this responsibility can have detrimental effects on a messaging organization. Microsoft does not recommend taking this action unless there is a compelling reason. Since careful analysis and planning are required, contact Microsoft for guidance.
Creation of an SRS is controlled from the Exchange System Manger program, running on the target server (the server that will be running the SRS). Ideally there is no load balancing achieved by introducing a redundant SRS into an administrative group. Unless there are directory topology changes in the organization, specifically the addition of new Administrative groups or changes in Exchange 5.5 directory replication links, there will be no arbitration for which the second SRS can compete, and therefore no directory replication responsibilities.
4. Deleting an SRS
NOTE: Microsoft strongly recommends that all Exchange 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 an SRS will have significant impact to interoperability between administrative groups.
An SRS can only be safely deleted 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 5.5 servers in the administrative group and the SRS is not the endpoint of an Exchange 5.5 directory replication connector.
An SRS can only be deleted using the Exchange System Manager (ESM) running on the Exchange 200x server running the SRS to be deleted. You can also accomplish this through a terminal session to the server running ESM.
5. Troubleshooting the SRS
Exchange 5.5 Directory Replication:
Since the SRS emulates a 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 5.5 troubleshooting apply to the SRS as well.
You can use eseutil.exe to check the consistency of srs.edb, or perform an offline defragmentation. But like a 5.5 Directory Service database, it should never be repaired. If the SRS database becomes corrupt the SRS service 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 the SRS service 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 Exchange 200x server in the administrative group as long as an Exchange 5.5 server is also available. When the new SRS is created, select the Exchange 5.5 server to initially synchronize directories. For more information see: "822453 How to Rebuild a Site Replication Service in Exchange Server 2003 When"
ADC Connection Agreements:
Before testing any connection agreement that uses the SRS as an endpoint, confirm the information you expected to replicate is present on the origination endpoint (the directory from which add, change or delete action was taken). Use ADSIEdit to check the Windows endpoint and make sure changes in AD have replicated at least as far as that Domain Controller. Use the LDP.exe utility connected to the SRS to check for changes in Exchange 5.5 directories has made it to the SRS, or perform a directory export out of the SRS into the .csv file.
Once you have determined 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 CA will only replicate configuration objects, and then only from the directory where the object were created. For example, changes to Exchange 5.5 servers and connectors will only replicate from the SRS to Active Directory, and changes to Exchange 200x servers and connectors will only replicate from Active Directory to the SRS.