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!
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.
Prior to Exchange 2000 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 "315408 XADM: How to Control Which Site Replication Services Owns a 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.
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.
For more information see: "291170 XADM: Exchange Server 5.5 Users Cannot See Exchange 2000 Mailboxes"
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.
NOTE: Microsoft does not support creation of an SRS on a cluster server. For more information see: "328875 HOW TO: Implement Exchange 2000 Server on a Windows 2000-Based Cluster"
Also, the SRS will not function properly on a front end server. For more information see: "313646 XADM: Services Are Disabled on Front-End Servers After an Exchange 2000"
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.
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.
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.
For more related info, I’d also suggest checking out the Graham McIntyre's "Pure Exchange 2000 Admin Groups and Group Membership" blog @ http://blogs.msdn.com/exchange/archive/2004/04/13/112453.aspx
Hope this was helpful! Questions? Comments?