The SRS is a service that makes possible the exchange of directory information between Exchange Server 5.5 Directory and the dissimilar Windows Active Directory. In mixed mode organizations, the SRS is necessary because Exchange 5.5 directory information can only be replicated between Exchange 5.5 servers - and not with Windows Domain Controller servers.
Exchange 5.5 servers are able to replicate directory information with an SRS because it mimics an Exchange 5.5 directory service. Using a connection agreement the Active Directory Connector (ADC) service then replicates the directory information between the SRS and a Domain Controller.
The SRS performs additional functions, such as exchanging recipient information for administrative groups without an SRS. The 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.
The SRS is created automatically, and runs on, the first Exchange 200x server joining into an Exchange 5.5 site. Manual SRS creation on additional Exchange 200x servers is also possible under certain circumstances.
There are several components that make up the working set of the SRS server.
Like other Exchange 200x services, the SRS service (SRSMAIN.exe) runs under the context of the local system account. All Exchange 200x servers contain the binaries and registry information for the SRS service by default. However the service is only enabled when the SRS is created on the specific server.
The SRS service is similar to the Exchange 5.5 Directory Service, except that the Named Service Provider Interface (NSPI) is disabled to prevent Outlook clients from connecting to it and using the Exchange 5.5 directory for name resolution.
The SRS uses Remote Procedure Calls (RPCs) to communicate with previous versions of Exchange Server directory services within its administrative group (intrasite). The SRS can also replicate directory information with Exchange 5.5 servers or SRS servers in other sites when used as a bridgehead for directory replication connectors (intersite).
Because the ADC supports only the Lightweight Directory Access Protocol (LDAP), the SRS must run an instance of this protocol. To prevent port conflicts when Exchange 200x is running on a domain controller, the LDAP interface for SRS uses port 379 instead of 389. An Exchange 2003 SRS will adapt to match the LDAP port number of the Exchange 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. In other words - while once the SRS is installed, the SRS LDAP port is "hardcoded" and can not be changed but in Exchange 2003 SRS, the SRS port might be something other than port 379.
While you can connect to the SRS service using the 5.5 admin 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 the SRS using the Exchange 5.5 admin program does not show the true contents of the SRS directory, as this view of the GAL is read straight from Active Directory and not the SRS directory.
Using the LDP utility, you can connect to the LDAP port on an SRS server, bind with the service account of the Exchange 5.5 site and browse the recipient objects in the SRS directory. The contents of the SRS recipient container can also be exported to CSV file using the Exchange 5.5 admin program. In those ways, you can see what objects were actually replicated into the SRS database, either by the ADC or by the Dir Rep from 5.5 servers.
The SRS utilizes a transactional logging jet database similar to the 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 anti-virus 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 the SRS running, there will be a separate option to backup the SRS database in NTBackup.
3. Configuration Connection Agreement (Config CA)
The Configuration Connection Agreement (config CA) replicates the Exchange 5.5 site configuration data with the Exchange 200x configuration data in Active Directory. Config CA's allow Exchange 200x servers to coexist with previous versions of Exchange.
Config CA's are automatically created by Setup when you install an Exchange 200x server in an existing Exchange 5.5 organization. Setup analyzes the Exchange organization and builds the config CA necessary to replicate configuration information between Exchange 5.5 and Active Directory.
The first config CA uploads the configuration directory data from every Exchange 5.5 site to Active Directory; however, it downloads only the configuration directory data for the local site back to the SRS.
As you install Exchange 200x servers in other Exchange 5.5 sites, more Config CAs are created, as the first Exchange 200x server installed in a "pure" Exchange 5.5 site will get an SRS automatically. As this happens, the first config CA stops uploading AD configuration directory data for the sites that now have Exchange 200x servers installed, and the configuration directory data is replicated by the Config CA for each site. In other words - the "local" SRS takes ownership of it's site's naming context.
Each SRS and config CA is a matched set. The matching config CA is deleted automatically when the owning SRS is decommissioned.
Here, we should also mention the ADNAutoDRC "Directory Replication connector" that can be seen in Exchange 5.5.
The ADNAutoDRC appears as a directory replication connector, in that container in the Exchange 5.5 directory of a mixed site. The ADNAutoDRC represents the replication path of the Config CA, and lists any pure Exchange 200X site for which the SRS is responsible as an inbound site. The ADNAutoDRC does no replication itself (its schedule is set to never), but Exchange 5.5 servers think the ADNAutoDRC is a directory replication connector and see that the pure Exchange 200X group is listed as an inbound site. When KCC runs on the Exchange 5.5 servers, they determine the SRS is the directory replication bridgehead for that connector, and request updates from the SRS for the site.
4. Site Knowledge Consistency Checker (SKCC)
(Note: SKCC is sometimes also referred to as "Super KCC")
In a mixed mode administrative group, the SRS is responsible for replicating the configuration context of the administrative group to which it belongs. However, because pure Exchange 5.5 and pure Exchange 200x administrative groups have no SRS, an 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 of replicating an administrative group's configuration context. A component of the SRS, named the Site Knowledge Consistency Checker (SKCC), arbitrates which SRS is responsible.
Each SRS in the organization runs its own separate instance of the SKCC. When the SKCC on one SRS obtains ownership of a configuration naming context, the SRS writes the distinguished name of the administrative group's configuration container onto the SRS's Config CA (for administrative groups, the value is written to msExchServer1ExportContainer, for sites the value is written to msExchServer2ExportContainer). Then, when the SKCC runs on other SRSs, the SKCC reads the site or administrative group's configuration distinguished name from the owning SRS's config CA, and knows that the naming context has been claimed.
The SKCC runs by default every 3 hours.
Hope this was helpful information. There will be another post about the SRS that will talk about specific things SRS does, how to control them and how to troubleshoot some of the problems that come up.