Exchange 2000 Server includes many new features and, therefore, many new acronyms. One frequently discussed acronym is SRS—the Site Replication Service. When I first heard about the SRS, I had a hard time positioning it with the Active Directory Connector (ADC). I thought that the SRS and the ADC were just two means for synchronizing directory information between the Exchange Server 5.5 Directory Service (DS) and Active Directory (AD). However, as I experimented with these components, I finally figured out their differences. Let me try to clear up any confusion that you might have, too.
Positioning the SRS and the ADC
The ADC is the service that lets you perform directory synchronization between the Exchange Server 5.5 DS and AD. The ADC uses connection agreements (CAs) to define individual configurations for replication.
The SRS is an Exchange 2000 service that allows integration with Exchange Server 5.5 sites. The SRS runs on an Exchange 2000 server but presents itself as an Exchange Server 5.5 DS to other Exchange Server 5.5 servers. You can use the SRS only if you're running Exchange 2000 in mixed mode. A mixed-mode Exchange 2000 organization includes Exchange Server 5.5, Exchange Server 5.0, and Exchange Server 4.0 legacy servers. The sidebar "SRS Components," page 2, describes the files that make up the SRS.
Using the SRS to provide a shadow Exchange Server 5.5 DS lets other Exchange Server 5.5 servers provide directory replication to a particular server in the same way that they always did, even if you've upgraded that particular server to Exchange 2000. I explain later why maintaining this kind of operation is beneficial to both the existing Exchange Server 5.5 servers and the new Exchange 2000 servers.
Exchange Server 5.5 allows intrasite replication and intersite replication between servers. Intrasite replication uses remote procedure calls (RPCs) to perform replication between servers in a site. Intersite replication is mail-based and takes place over a directory replication connector (DRC) between bridgehead servers in separate sites. The SRS supports both forms of Exchange Server 5.5 replication.
Although every Exchange 2000 installation includes the SRS components, you configure and enable the SRS only in certain circumstances:
- When you upgrade the first Exchange Server 5.5 server in an Exchange Server 5.5 site to Exchange 2000
- When you install the first Exchange 2000 server into an Exchange Server 5.5 site
- When you upgrade an Exchange Server 5.5 bridgehead server to Exchange 2000 (all bridgehead servers—even those that aren't the first server in the site—have an SRS enabled)
The SRS works with the ADC to make Exchange Server 5.5 DS-to-AD synchronization easier. Specifically, the SRS helps make the management of CAs simpler. Ultimately, your job becomes simpler, too.
The SRS in Intrasite Replication
Let's take a look at some example environments that involve the ADC and the SRS. Figure 1 shows an Exchange Server 5.5 site (i.e., a site that contains only Exchange Server 5.5 servers) with a CA homed against one of the servers, S4. The CA to the AD is well defined because it has a valid source of Exchange Server 5.5 directory information. The ADC obtains information from the Exchange Server 5.5 DS on server S4.
But what happens when you upgrade the server S4 from Exchange Server 5.5 to Exchange 2000? Upgrading compromises the integrity of the CA because S4 doesn't have an Exchange Server 5.5 DS (because Exchange 2000 uses AD), and the CA becomes unusable. Your only option is to rehome the Exchange Server 5.5 end of the CA to another server (e.g., server S5). This action would reestablish the integrity of the CA, but you would need to rehome this CA when you subsequently upgrade server S5 to Exchange 2000. This rehoming activity could repeat itself for some time unless you initially homed your CA against a server that you knew would be the last one in the site you migrate to Exchange 2000.
Having to devote this kind of administrative attention to your CAs and Exchange Server 5.5 servers isn't a matter of life or death, but life would be much simpler if you didn't need to worry about it. The SRS lets you retain CA integrity, as I explain in the next section.
Retaining CA integrity. Let's assume that server S4 is the first Exchange Server 5.5 server in the site you're upgrading to Exchange 2000. This assumption satisfies one of the rules for enabling the SRS: You're upgrading the first server in the site. When you perform the upgrade in this situation, the SRS (which is the Exchange Server 5.5 DS in disguise) becomes active. And because the SRS takes part in Exchange Server 5.5 directory replication just like any other Exchange Server 5.5 service, it has a valid view of the Exchange Server 5.5 directory in its SRS database. Figure 2 shows the SRS active on S4.
Because the SRS is active on server S4, you can retain the existing CA that is homed against S4. Because the SRS is there, you have a valid source of Exchange Server 5.5 directory information, so you don't need to manually rehome the CA. Having one server that you know can always provide a source of Exchange Server 5.5 directory information is a big plus.
When you home a CA against a regular Exchange Server 5.5 server, you must bind the Exchange Server 5.5 end of the CA against the Lightweight Directory Access Protocol (LDAP) of the Exchange Server 5.5 DS. The ADC uses LDAP to access the Exchange Server 5.5 DS. By default, the Exchange Server 5.5 LDAP listens on port 389, but you can enable LDAP on another port (e.g., if you're running an Exchange Server 5.5 server on a Windows 2000 domain controller). AD on a Win2K domain controller also listens on port 389, and as Win2K is starting up, it seizes control of port 389 before the Exchange Server 5.5 DS can get to it.
The SRS behaves similarly. The SRS runs only on a Win2K system, and this system might be a domain controller. A CA always wants to connect to a source of Exchange Server 5.5 directory information over LDAP. To avoid confusion, the Exchange engineering team designed the SRS so that it offers its LDAP service from port 379. Therefore, if you had previously homed your CA against an Exchange Server 5.5 DS on port 389, you must modify the CA so that it now points to port 379 to get to the SRS DS. "More Tips for Using the Active Directory Connector," Reader to Reader, April 2000, explains how to change the LDAP port.
This modification requires only that you use the CA management tool to redirect the CA to a different port after the upgrade to Exchange 2000. However, this modification is a small change to an existing CA, compared with rehoming the CA to an altogether different server.
Within an Exchange Server 5.5 site, an Exchange Server 5.5 server communicates with other Exchange Server 5.5 servers to keep the information in its DS consistent with the information in the other Exchange Server 5.5 servers' directories. This behavior is the essence of intrasite replication. The component responsible for controlling this process is the Knowledge Consistency Checker (KCC)—which is on every Exchange Server 5.5 server. The KCC maintains a table of all Exchange Server 5.5 servers that take part in the replication chain.
As you upgrade many Exchange Server 5.5 servers in the site to Exchange 2000, most servers won't have the SRS enabled. In these cases, the upgrade code removes the entry for each respective server from the KCC table. For example, for the systems you see in Figure 2 (presuming that they're not bridgehead servers), the code removes servers S1, S2, S3, and S5 from the Exchange Server 5.5 intrasite replication chain. (More precisely, the code removes the servers' directory service agent—DSA—object from the KCC table.) Removing the servers' DSA ensures that they no longer take part in Exchange Server 5.5 intrasite replication because they're no longer Exchange Server 5.5 servers. If the upgrade process didn't remove these DSA objects from the KCC table, you'd see many errors in the event log, signifying that Exchange Server 5.5 directory replication failed against the newly upgraded servers.
The SRS in Intersite Replication
When you upgrade an Exchange Server 5.5 directory replication bridgehead server to Exchange 2000, the bridgehead server must maintain a means for communicating site information to its Exchange Server 5.5 bridgehead replication partner. The SRS provides this means because it appears to the replication partner as an Exchange Server 5.5 DS to communicate with. Figure 3 shows the original situation: Two Exchange Server 5.5 directory replication bridgehead servers (S9 and S1) communicating across a DRC.
When you upgrade server S1 from Exchange Server 5.5 to Exchange 2000, as Figure 4 shows, the SRS becomes indispensable because once again, it reduces the administrative effort associated with upgrading servers. Because the pure Exchange Server 5.5 site (i.e., Site B) has no CA, all site and topology information for Site B must come from traditional Exchange Server 5.5 directory replication.
In the absence of an SRS service, you need to rehome Exchange Server 5.5 DRCs onto different servers as you upgrade bridgehead servers from Exchange Server 5.5. In this example, upgrading server S1 to Exchange 2000 without an SRS service would require rehoming the DRC to another server in the site (e.g., S2).
Components of the SRS even optimize CAs and DRCs. If a CA becomes available to Site B, Exchange can deliver directory information into that site two ways: across a DRC and through a CA. Exchange Server 5.5 directory replication is object-based, whereas replication through a CA is attribute-based. Therefore, using CAs to provide directory information is more efficient than using DRCs because attribute-based replication involves less data on the wire. If you use a CA, as Figure 5 shows, the SRS disables the DRC between the two Exchange Server 5.5 sites and uses ADC-based replication instead.
You can see that, with respect to intersite replication, the SRS is a useful tool. Without it, the management of DRCs would increase administrative overhead. The SRS proves its worth just for managing CAs within a site, but coupled with managing connections between Exchange Server 5.5 bridgehead servers, it's essential.
Behind a Bridgehead Server Upgrade
When you upgrade server S1 to Exchange 2000, the Setup program modifies the existing local dir.edb database (i.e., the traditional Exchange Server 5.5 DS), copies the new executables for the SRS service from the installation CD-ROM, and creates several objects in AD's configuration-naming context. (The configuration-naming context contains all Exchange 2000 configuration information.)
Specifically, an instance of an object of class ms-Exch-Site-Replication-Service within the Exchange tree in the AD configuration-naming context represents the SRS. Figure 6 shows an example of a default SRS object, Microsoft DSA, from ADSI Edit. ADSI Edit, part of the Microsoft Windows 2000 Resource Kit, is a useful tool for looking at objects, attributes, and their values in AD.
In this case (i.e., when S1 is the first Exchange 2000 server in the site), the Setup process also creates a Configuration Connection Agreement (ConfigCA) between AD and the new SRS service installed locally. The SRS takes on the ownership of the DRC to server S9. Because the SRS object in AD has a legacyExchangeDN attribute of /o=<OrgName>/ou=<Site>/cn=/cn=Servers/cn=S1/cn=Microsoft DSA and is a mail-enabled object, the SRS becomes the destination for replication messages from server S9. In fact, you can use any transport (e.g., X.400, RPCs) to send mail to the SRS object. Figure 7 shows the value of the mail attribute of the SRS. As you can see, this attribute has an SMTP address (i.e., [email protected]), which means that any other Exchange Server 5.5 DS can send directory information to it over an SMTP connector.
So, let's review. The SRS connects to bridgehead server S9 over a DRC and to AD through a ConfigCA. The ConfigCA is two-way, replicating configuration information for the Exchange Server 5.5 view of Site A from the SRS to AD and back-replicating information for administrative group A (the Exchange 2000 view of the site) from AD to the SRS. For an explanation of administrative and routing groups, see Tony Redmond's Windows 2000 Magazine article, "From Sites to Groups," June 2000.
Minimal Management
The Exchange System Manager Microsoft Management Console (MMC) snap-in doesn't let you control the SRS to any extent. You can navigate to the Tools menu, but when you right-click the SRS object, you don't see real management options. Basically, this service just runs without much management.
However, you must perform a little system management. I mentioned earlier that the srs.edb database is a direct descendant of the dir.edb database that was part of Exchange Server 5.5. To obtain a useful backup of an Exchange Server 5.5 server, you must back up the Directory Store and the Information Store (IS) databases. In Exchange 2000, the directory is AD, and presumably your day-to-day operational procedures facilitate backing up and restoring AD. In addition, on an SRS-enabled Exchange 2000 system, you must back up the SRS database, too. The Win2K Backup utility, which Figure 8 shows, includes the SRS, and your favorite third-party backup product will undoubtedly include it soon.
A Useful Tool
Life could go on without the SRS. Although it's a useful component of Exchange 2000, it's not essential either to Exchange 2000's operation or to coexistence with Exchange Server 5.5 servers. However, without the SRS, administering CAs and sequencing server upgrades from Exchange Server 5.5 to Exchange 2000 would be more complicated.
The SRS's functionality will improve in future releases of Exchange Server. In the current version, if you upgrade an Exchange Server 5.5 server to Exchange 2000, you need to manually adjust the LDAP port number on the CA to 379, the port on which the SRS provides LDAP access. However, the SRS could make this adjustment automatically. Similarly, a newly installed, first Exchange 2000 server in a Exchange Server 5.5 site could detect a CA homed to another Exchange Server 5.5 server in the site and then rehome that CA to the local SRS database. Automating these functions would reduce your administrative burden.
Today, a clustered Exchange 2000 system doesn't support the SRS, so the first server you install into a Exchange Server 5.5 site must be a single-node system. For organizations wanting to enjoy Exchange 2000's server-consolidation benefits, this requirement is an inconvenience. However, you can easily work around the problem by installing a small system into the site solely to act as a host for the SRS.
In its present form, the SRS supplements the ADC's functionality by always offering a source of Exchange Server 5.5 directory information. Any migration plans that you're drawing up now to move from Exchange Server 5.5 to Exchange 2000 will, in all likelihood, involve directory coexistence and ultimately the ADC. As you finalize your plans, keep one eye on the SRS and use it as your friend when you define the placement of CAs, thus avoiding the need to modify and rehome them in the future.
