Event ID 2601: Exchange cannot contact a domain controller or global catalog

Fix it now

MSExchange ADAccess events in the 2000 range are Exchange reporting on its own view of Active Directory, and 2601 appears when it has no usable directory server to work with. Microsoft publishes no description for these event IDs, so read the event’s own text and then check the three things that actually decide it: site membership, DNS, and whether a global catalog serves that site.

nltest /dsgetsite
nltest /dsgetdc:contoso.com /GC /FORCE
ipconfig /all
Get-ExchangeServer | Format-List Name,Site

1. Read nltest /dsgetsite first. If the site is not the one you expect, the Exchange server’s subnet is missing from Active Directory Sites and Services and everything else follows from that.
2. Read the nltest /dsgetdc result. /GC restricts the answer to global catalogs and /FORCE makes it query DNS rather than the cache, so a failure here is real rather than stale.
3. Confirm the server’s DNS servers are internal domain controllers hosting the Active Directory zone. A public resolver anywhere in that list breaks locator queries intermittently.
4. In the Application log, find the most recent Event ID 2080 and read its own text: it lists the servers Exchange discovered and how each one answered.
5. After correcting site data or DNS, restart the Microsoft Exchange Active Directory Topology service and wait for a fresh 2080 before judging the result.

If you need Exchange bound to one named controller while you work, use Set-ADServerSettings -PreferredServer dc01.contoso.com. It is session-scoped and it undoes itself when you close the shell.

If Exchange finds its directory again and the services settle, stop here. If not, the next section covers what Exchange is actually looking for.

Why it happens

When the Active Directory Topology service starts, it works out which Active Directory site the server belongs to from its IP address and the subnet objects defined in Sites and Services. It then finds the domain controllers serving that site, tests them, and builds a list it is willing to use. It repeats that discovery on a timer, so directory changes are picked up without a restart – and so recovery after an outage is not instant.

The detail that catches people out is scope. Exchange uses controllers and global catalogs in its own site, and reaches beyond it only where site coverage or site links make another site’s controllers available. Ten domain controllers in the forest are no help at all if none of them serves the site Exchange sits in, and a site is decided by a subnet object that somebody has to have created.

One caveat before you go event-hunting. Microsoft publishes no description for event 2601, 2604, 2114, 4027 or 2080. That does not make them useless – each event’s own description field carries the process, the server and, in the case of 2080, the discovery result – but it does mean you should read the entry rather than look up the number. An article that tells you exactly what 2601 means is telling you something the vendor has not published.

What you can rely on is the shape of the dependency. Almost every Exchange service waits on the topology service, so a directory problem produces a batch of service failures rather than one, and fixing the directory fixes all of them at once. If you find yourself restarting six Exchange services in sequence, stop and go and look at DNS and Sites and Services instead.

Full reference

Reading the discovery event

Commands that answer the question

Ports Exchange needs to a domain controller

A firewall between Exchange and its domain controllers is a design that has to be maintained rather than set up once. The dynamic RPC range in particular is the one that gets missed, because the endpoint mapper answers on 135 and everything looks fine until an actual call is made.

Five event IDs, none of them published

Events 2601, 2604, 2114, 4027 and 2080 all appear in this investigation and Microsoft publishes a description for none of them. Read them for their content: which process wrote the entry, which server is named, and in the case of the discovery event, the table of servers and how each answered. Do not act on a number alone, and be sceptical of any source that assigns a confident meaning to one of them.

Restarting the Microsoft Exchange Active Directory Topology service forces a fresh discovery, which saves waiting for the timer. It also restarts the services that depend on it, so treat it as a change rather than a query.

Design decisions that stop this recurring

• Define every subnet in Sites and Services, including the ones nobody thinks matter. An undefined subnet is invisible until Exchange trips over it.
• Put at least two domain controllers in any site that holds an Exchange server, or arrange and test site coverage from a neighbouring site.
• Give Exchange servers internal DNS only, and check that after every network change rather than after every outage.
• Do not install Exchange on a domain controller. It complicates patching and recovery and turns two separate outages into one.
• Stagger domain controller reboots so that no site loses all of its controllers at once.

Every code this article covers

Confirm the fix worked

1. nltest /dsgetsite returns the site you expect for that server.
2. nltest /dsgetdc:<domain> /GC /FORCE returns a global catalog without an error.
3. Get-ExchangeServer | Format-List Name,Site agrees with nltest.
4. A fresh discovery event appears in the Application log listing the controllers you expect.
5. Test-ServiceHealth shows the Exchange services running, and a directory-dependent command such as Get-Mailbox -ResultSize 5 completes.

Questions people ask about this