XADM: Exchange Server-Related Considerations for Demoting a Global Catalog Server to a Domain Controller

When a global catalog server is demoted to a domain controller, it stops responding to Lightweight Directory Access Protocol (LDAP) connections on port 3268 and removes its SRV records from the Domain Name System (DNS). DSAccess realizes that the computer is no longer a global catalog server and removes it from the roles listing. However, the Name Server Provider Interface (NSPI) cannot be automatically disabled on the demoted server. This means that Microsoft Outlook clients continue to be referred to the demoted server by Exchange 2000, even though the server is no longer a global catalog server.

If the demoted global catalog server is not restarted after the directory database has cleaned itself of remote naming contexts, NSPI reports incomplete information (about the local domain, not the entire forest). Be aware that by restarting the demoted global catalog server, Outlook 2000-and-earlier clients will stop responding (hang). To resolve this issue, each client running Outlook 2000 (and earlier) must be restarted. Outlook 2002 automatically fails over to a different global catalog. To alleviate potential issues of global catalog server-to-domain controller demotion, follow these steps:

1. A week before the demotion is due to occur, hard-code the RFR interface to a defined group of global catalog servers. This is to ensure that the global catalog server to be demoted does not appear on the list of referral servers.
   
   See the following Knowledge Base article for more information about configuring the RFR Target Server registry value:
   282446  (http://support.microsoft.com/kb/282446/EN-US/ ) XCCC: DSProxy Configuration for Static Ports on Exchange Cluster
   NOTE: All Outlook 2002 and Outlook 2000 Service Release 2 (SR-2) clients query the Exchange 2000 Server computer for a new referral after restart of the client. The server computer refers the clients to one of the global catalogs on your defined list.
   
   
2. After a week has elapsed, demote the global catalog server during a quiet time (such as the evening). Immediately restart the demoted server to disable NSPI.
3. After the demoted server has been restarted, use the DSADIAG tool to verify that none (or none in a sample) of the Exchange 2000 Server computers are reporting the server as a global catalog. If the demoted server is still reported as a global catalog server, wait 15 minutes, and then run DSADIAG again. If the server continues to appear in the Working global catalog server list, verify that the global catalog server SRV records have been removed from the DNS server, run IPCONFIG /FLUSHDNS, and then run IPCONFIG /REGISTERDNS on each Exchange 2000 Server computer.

This procedure does not include a fail-safe mechanism for users running older versions of Outlook 2000 (or earlier versions of Outlook). Therefore, these clients need to be restarted after global catalog server demotion has taken place.

If you are running only Outlook 2002 clients, you do not need to hard-code the RFR list because of dynamic failover. Instead, just demote the global catalog server during a quiet time, and then immediately restart it.

For more information, see the following Knowledge Base article: