RFR target server has been manually over-ridden
[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at http://go.microsoft.com/fwlink/?linkid=34707.]
Topic Last Modified: 2005-11-18
The Microsoft® Exchange Server Analyzer Tool reads the following registry entry on the Exchange server to determine if the Directory Services Proxy Referral (DSProxy referral) service has been manually overridden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSA\Parameters\RFR Target Server
If the Exchange Server Analyzer finds RFR Target Server to be present and configured, a non-default configuration message is displayed.
The first time a Microsoft Outlook® 2000 Service Release 2 (SR-2) or later client connects to an Exchange 2000 Server or Exchange Server 2003 computer, it looks for the directory service on the home Exchange server. Outlook initially goes through the DSProxy process for the very first session. After the client contacts the DSProxy service, a DSProxy referral is passed back to the client informing it that all future directory requests should go to the global catalog server. Outlook sets the DSProxy referral information in the MAPI profile in the registry.
The DSProxy referral mechanism reduces load on the Exchange server and reduces the latency for address book searches. If an explicit server name is entered into the profile, Outlook must restart if that global catalog server fails. If this occurs, the Exchange server sends Outlook a new referral.
In some situations, it is preferable to hard code the RFR Target Server entry to specify the servers that should be used for MAPI client referral service. For example, one week prior to demoting a global catalog server to a member server, you should hard code the RFR Target Server entry to a defined group of global catalog servers. This ensures that the global catalog server being demoted is no longer referenced in the MAPI profiles on the Outlook clients. For more information about this specific use of the RFR Target Server registry entry, see the Microsoft Knowledge Base article 305065, "XADM: Exchange Server-Related Considerations for Demoting a Global Catalog Server to a Domain Controller" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=305065).
This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore the registry if a problem occurs. For information about how to restore the registry, view the "Restore the Registry" Help topic in Regedit.exe or Regedt32.exe.
To use the RFR Target Server registry value
Open a registry editor, such as Regedit.exe or Regedt32.exe.
Navigate to: HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters
Create a new REG_MULTISZ value called RFR Target Server.
Configure the RFR Target Server value with the fully qualified domain name for the server (or servers) you want to specify.
Close the registry editor, and then restart the Microsoft Exchange System Attendant service for the change to take effect.
To disable a static setting for the RFR server, remove the fully qualified domain name entry for the server you want removed. If there is only one RFR target server entered, delete the RFR Target Server registry value.
Before you edit the registry, and for information about how to edit the registry, see the Microsoft Knowledge Base article 256986, "Description of the Microsoft Windows Registry" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256986).
For more information about how Outlook 2000 SR-2 and newer clients interact with the Active Directory® directory service, see the following Microsoft Knowledge Base articles:
302914, "XCCC: How Outlook 2000 Accesses Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=302914)
256976, "XCLN: How MAPI Clients Access Active Directory" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=256976)