Troubleshooter: Determining Which GC Server to Use for Directory Access

Exchange 2000's DSAccess component running on server A makes a DNS query to find a DC; if server A receives multiple SRV records from this query, DSAccess picks one at random. Let's call this server DC1.

Server A's DSAccess queries DC1 for a list of all DCs in site 1 and throws out any returned DCs that aren't also GCs. DSAccess then performs tests to see which GCs are up, what their network latency is, and whether they can function as GCs for Exchange.

DSAccess queries AD to find out which sites are connected to site 1. DSAccess determines these connections by reviewing the site links or site link bridges, which you specify in the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in.

DSAccess sorts the connected sites by link cost, listing the lowest-cost sites first. DSAccess then queries these sites to build a list of remote site GCs.

DSAccess uses the final list of DCs, sorted by cost, to choose three roles: the server it should use to get information from the Configuration naming context (NC), the DC it should use for authentication, and the GC it should use for directory queries.

The DSAccess component on server A will choose a GC outside site 1 only if it can't find a suitable GC in site 1. If you're trying to figure out why Exchange is ignoring a local GC and preferring a remote one, you can use the Dsadiag and Nltest utilities to investigate whether the local GCs are working properly. You can also increase the diagnostic logging level for the Topology category of the MSExchangeDSAccess object in Exchange System Manager (ESM) to Maximum, then look for event ID 2080 in the event log. This event will tell you exactly why Exchange is ignoring the local GCs.