As an Exchange organization increases in size, excessive replication traffic can become a problem. This is especially true in situations where slow WAN links exist with multiple Exchange servers on each side. To help reduce the amount of replication traffic flowing across slow WAN links, Exchange 5.0 introduced the ability to define multiple sites.
The idea was that if 10 Exchange servers exist at a remote site, there's no need to replicate the same information 10 different times. Instead, the information can be sent once to a bridgehead server at the remote site. That bridgehead server can then distribute the replication data to the rest of the servers at the remote site.
This technique is still in use today; but when Microsoft released Exchange 2000, it changed the name for them (bridgehead servers) from Sites to Routing Groups to avoid confusion with an Active Directory feature called 'sites.'
Sites and Routing Groups work great as long as you're using an all Exchange 5.5 or all Exchange 2000/2003 server environment. If you start updating an Exchange 5.5 organization to a newer version of Exchange, it's common for directory replication between sites to fail.
This failure occurs because the Request For Response (RFR) Service is disabled by default in Exchange 2000 and Exchange 2003. In Exchange 2000/2003 environments, this isn't a problem because the servers simply e-mail replication updates to the remote site; there is no need for the RFR Service. But if you start mixing Exchange 2000/2003 with Exchange 5.5 servers in a multi-site environment, things get a bit more complicated.
Suppose an organization has a local site running all Exchange 5.5 servers with one remote site running all Exchange 2000/2003 servers.
For the local site to replicate directory information to the remote site, the process would start out much the same as it would in an Exchange 2000/2003 environment. The Exchange 5.5 bridgehead server would place the directory information being replicated into an e-mail message, and then send it to the remote site.
The remote site would use the Site Replication Service (SRS) (yes, Exchange 2000/2003 still have the Site Replication Service) to contact the DSProxy service, which in turn contacts the Global Catalog.
Once communications with the Global Catalog server have been established, the DSProxy service sends a referral back to the SRS. This referral allows the SRS to begin communicating directly with the Global Catalog server.
That's how the process is supposed to work.
The problem is that the Request For Response Service is disabled by default. This means that Exchange is unable to request a referral from the Global Catalog server. Since the Exchange server can't request a referral, it will never receive a referral; and without a referral, it is unable to establish direct communications between the Site Replication Service and the Global Catalog server.
Ultimately, this means failure of directory replication between the sites.
Fortunately, there is a way to fix this problem. You have to make a registry modification that will allow the Request for Referral service to run on your Exchange 2000/2003 servers.
Note: Keep in mind though that making a mistake when editing the registry can destroy Windows and/or applications, including Exchange. I recommend making a full system backup prior to making modifications.
- Use the REGEDIT command to open the Registry Editor.
- Navigate through the registry tree to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters.
- Double click on a registry key named No RFR Service.
- You will see the Edit DWORD Value dialog box appear. Change the base type from Hexadecimal to Decimal, the Value Data to 0, and click OK.
- Close the Registry Editor and reboot the server to finish.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.
Do you have comments on this tip? Let us know.