Event ID 4013: the DNS server is waiting for Active Directory to synchronise

Fix it now

Microsoft publishes 4013 as the DNS server being unable to open Active Directory, configured to use directory information, unable to operate without it, and waiting for the directory to start. It is not a DNS fault. Fix inbound replication and the zones load on their own.

repadmin /replsummary
repadmin /showrepl
ipconfig /all
w32tm /query /status

1. Read the last inbound attempt for every partner and every naming context. An access denial, an RPC failure and a name resolution failure lead in three different directions.
2. Check what the server itself resolves through. Microsoft’s guidance is that domain controllers hosting directory-integrated zones should not point exclusively at themselves: a hub-site DC should use another DC in the same site as preferred and alternate and then itself, and a branch-site DC should use a hub-site DNS server as preferred, an in-site server as alternate, and itself last.
3. If the companion is Event 4000 rather than only 4013, read the next section: Microsoft’s documented cause for that pair is a lost secure channel, and no amount of replication work will clear it.
4. If 4013 clears within a minute or two of every reboot and never otherwise, nothing is wrong. That is the wait working as designed.

Microsoft documents a registry value that lets the server start without waiting, and describes it as not recommended for production. It is a recovery measure, and you put it back afterwards.

If the zones load and stay loaded across a reboot, you are done. If not, the next section explains the deadlock this event is describing.

Why it happens

A directory-integrated zone is not a file. It is a set of objects held in a directory partition, and the DNS server reads them out of the directory at startup. A domain controller that has just booted is not immediately ready to serve those objects, so DNS waits rather than loading whatever happens to be in the local database. Microsoft’s published text for 4013 says exactly that: the server is configured to use directory service information, cannot operate without access to the directory, and will wait for the directory to start.

The reason this becomes a deadlock rather than a pause is the circular dependency Microsoft documents alongside the event. DNS waits for the directory to complete its initial replication; the directory needs DNS to resolve the domain controllers it wants to replicate from. When several domain controllers boot together, each waits for the others while DNS queries fail slowly rather than quickly, multiplied across every naming context. The status code in the event narrows it: Microsoft lists 9717 DNS_ERROR_DS_UNAVAILABLE, 9005 DNS_ERROR_RCODE_REFUSED and 9002 DNS_ERROR_RCODE_SERVER_FAILURE as the common ones.

The companions matter because two of them are not about waiting at all. Event 4000 is published as the DNS server being unable to open Active Directory for a zone it cannot load without, and Microsoft’s documented cause for it is that the domain controller has lost its secure channel with itself or with the primary domain controller emulator. Event 4015 is a critical error handed back by the directory, and Microsoft documents three quite different readings of it depending on the status embedded in the text.

Full reference

The events

Reading the status inside a 4015

The status codes that accompany 4013

Microsoft’s other documented resolutions

• Make sure DNS servers are available at Windows startup, and that they host, forward or delegate the _msdcs zone for the forest root and the primary DNS suffix zones.
• Enable scavenging appropriately, but not aggressively, so stale records do not accumulate and are not removed while still in use.
• Stagger domain controller reboots so that several are not unavailable simultaneously.
• Where a server keeps booting into a known-bad state, set the DNS Server service to manual, reboot, wait for the domain controller to advertise, and start DNS by hand.
• Avoid single points of failure – one DNS server, or every DNS server on one physical host.

Confirming that a partner can be resolved

Microsoft points at directory events 2087 and 2088 in the Directory Service log alongside this problem. They record a destination domain controller that could not resolve a source domain controller’s alias record to a host record, and had to fall back to another name resolution method. If you see them, the replication failure and the DNS failure have the same root, and repairing the alias records breaks the deadlock in both directions at once.

How long to wait before acting

A few minutes on a healthy server. If the DNS service has not loaded its zones by the time you have signed in and opened Event Viewer, treat it as a replication problem rather than a slow start. The failure mode to watch for is the estate-wide one: several domain controllers restarted together, each waiting for the others, each taking twelve seconds per failed query across several naming contexts. That resolves itself eventually on a healthy network and does not on a broken one, which is why the replication output matters more than the clock.

Every code this article covers

Confirm the fix worked

1. The directory-integrated zones are present and loaded on the affected server.
2. A record from one of those zones is answered authoritatively when queried against this server directly.
3. repadmin /replsummary shows no failures for this server in either direction.
4. Reboot once more and confirm 4013 either does not appear or clears within a minute or two.
5. The Repl Perform Initial Synchronizations value is back at its default if you changed it.

Questions people ask about this