DNS Event ID 4013 (DNS Server Waiting for AD DS Initial Sync): A Read-First DNS Client, Replication, and 4015 Triage

Helpdesk: "After Sunday's patch reboot, DC01 sat at 'Preparing network connections' for about twenty minutes. Now DNS Manager on it says the server could not be contacted, and the DNS Server log has Event 4013 every two minutes: 'The DNS server is waiting for Active Directory Domain Services (AD DS) to signal that the initial synchronization of the directory has been completed.' DC02 was patched and rebooted at the same time. A forum post says to set Repl Perform Initial Synchronizations to 0 and point DC01 at 127.0.0.1 only. Can we do that?"

Not that way. Event 4013 usually isn't a broken DNS server. A DNS server that hosts AD-integrated zones waits after boot until AD DS finishes its first inbound replication, and AD DS can't replicate until it can resolve its partners' names through DNS. When the DC points only at itself, when its partners are rebooting too, offline, or long gone, or when the network isn't up yet, the two wait on each other. Microsoft says it plainly: "DNS Event ID 4013 in the DNS event log indicates that DNS service startup was delayed. It's because inbound replication of Active Directory partitions hadn't occurred." It's just as plain about the registry shortcut: "This configuration change isn't recommended for use in production environments, or in any environment on an ongoing basis." Pointing a DC with partners at itself only is the other half of the forum advice, and Microsoft's 4013 article lists that exact setup among the conditions that make 4013 worse. Work through it as a chain: which DC, which events, since when → is it a boot-time wait that ends, or one that never ends? → what are the DNS Server and AD DS services actually doing? → which DNS servers does this DC ask, and do they answer? → can it resolve its replication partners? → is inbound replication happening, and from whom? → is it the only DC, a role holder, or a recovery case? → is it really 4015, 4000, or 4007? → change one link → prove a clean boot. Get-WinEvent, Get-Service, Get-DnsClientServerAddress, Resolve-DnsName, Test-NetConnection, repadmin /showrepl, repadmin /replsummary, Get-ADReplicationPartnerMetadata, Get-ADReplicationFailure, dcdiag /test:dns, and Get-ItemProperty are the sources for that chain. Set the registry value "to be safe" and you may bring up a DC that serves stale zones and acts on stale role data, and the next reboot of two DCs at once still hangs the same way.

If the partners show replication error 1722 once you can read them, Active Directory Replication Error 1722 covers the DNS, RPC, and firewall side. If member servers log Netlogon 5719 in the same boot window, Netlogon Event ID 5719 covers the client view of the same timing problem. This post covers "a domain controller that runs DNS with AD-integrated zones and logs DNS Server Event 4013 (the DNS server is waiting for AD DS initial synchronization), with or without 4015, 4000, or 4007, a slow 'Preparing network connections' boot, DNS Manager or Active Directory Users and Computers failing to connect, and you need a read-first path before you change the registry, point the DC at itself, or restart services in a loop."

TL;DR

• A short 4013 run after boot can be normal. Microsoft: "The delay won't occur if Active Directory has completed its initial synchronization during Windows startup." The event "will be logged every two minutes until AD DS has signaled that the initial synchronization has successfully completed", so count the events and read how long they lasted (Step 2).
• DNS waits for AD DS, and AD DS needs DNS to find its partners. Replication "is delayed until it can resolve the CNAME GUID of its source domain controller to an IP address on the DNS servers used by the destination domain controller for name resolution." (Steps 4 and 5).
• A DC with partners shouldn't point only at itself. Microsoft: "Domain controllers hosting AD-integrated DNS zones shouldn't point to a single domain controller and especially only to themselves as preferred DNS for name resolution." A forest with one DC is the exception (Steps 4 and 7).
• Stale or offline partners keep the wait going. Read repadmin /showrepl and remove the metadata of DCs that are really gone; don't wait on them (Step 6).
• The registry value is a temporary emergency tool. Repl Perform Initial Synchronizations set to 0 "should be used only in critical situations to resolve temporary and specific problems. The default setting should be restored after such problems are resolved." (Steps 7 and 9).
• 4015 is a different problem. It's "a critical error from the Active Directory" with an error code that picks the cause: RODC, permissions, or too many orphaned records (Step 8).

Where in the chain did it break?

Step 1: Capture the symptom (read-only)

Write these on the ticket first:

Then branch on what you see:

Step 2: Read the events and how long they lasted (read-only)

4013 is in the DNS Server log (Event Viewer: Applications and Services Logs > DNS Server), not the System log. Read it with its neighbors, and read the Directory Service log for the same window:

# Read-only: DNS Server events since the last boot, oldest first $boot = (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime Get-WinEvent -FilterHashtable @{ LogName = 'DNS Server' Id = 4000, 4007, 4011, 4013, 4015 StartTime = $boot } -ErrorAction SilentlyContinue | Sort-Object TimeCreated | Select-Object TimeCreated, Id, LevelDisplayName, Message # Read-only: first and last 4013 since boot, and how many $w = Get-WinEvent -FilterHashtable @{ LogName = 'DNS Server'; Id = 4013; StartTime = $boot } -ErrorAction SilentlyContinue if ($w) { $first = ($w | Sort-Object TimeCreated | Select-Object -First 1).TimeCreated $last = ($w | Sort-Object TimeCreated | Select-Object -Last 1).TimeCreated [pscustomobject]@{ Boot = $boot; Count = @($w).Count; First = $first; Last = $last; Minutes = [int]($last - $first).TotalMinutes } } # Read-only: DNS lookup failures for replication partners in the same window Get-WinEvent -FilterHashtable @{ LogName = 'Directory Service' ProviderName = 'Microsoft-Windows-ActiveDirectory_DomainService' Id = 2087, 2088 StartTime = $boot } -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, Message 

Read the result against Microsoft's text for each event:

Two details matter when you compare with forum posts. First, the waiting text is the one on Microsoft's event reference page (symbolic name DNS_EVENT_DS_OPEN_WAIT), and it ends: "This event will be logged every two minutes until AD DS has signaled that the initial synchronization has successfully completed." Microsoft's current troubleshooting article for 4013 shows the older "unable to open the Active Directory" wording instead. Both are 4013 from the DNS server; search for the event ID, not only the text. Second, the waiting text gives a direction of its own: "If events in the AD DS event log indicate that there is a problem with DNS name resolution, consider adding the IP address of another DNS server for this domain to the DNS server list in the Internet Protocol properties of this computer."

Microsoft's 4013 article lists event data values it can carry, and notes they "may not be logged":

Then read the timing (our reading):

Microsoft's own test explains why the wait can be that long: when the DNS Server service isn't available, "NTDS will need to send out 10 DNS queries to resolve the IP address", and with the default DNSQueryTimeouts "DNS client will wait 12 (1 + 1 + 2 + 4 + 4) seconds for the DNS server response." Multiply by the partitions (schema, configuration, domain, and the two DNS application partitions) and the minutes add up.

Step 3: What are the services doing? (read-only)

Read the services the chain depends on, and whether the DC is advertising yet. DNS Server, AD DS, Netlogon, and KDC are the ones that matter here:

# Read-only: the services behind DNS and AD DS on this DC Get-Service -Name DNS, NTDS, Netlogon, Kdc | Select-Object Name, DisplayName, Status, StartType # Read-only: which DC does DC locator return from here? (this DC itself once it advertises; our reading) nltest /dsgetdc:contoso.com 

Then try the consoles once, without restarting anything. Microsoft's example scenarios show what a DC stuck in this state looks like:

Restarting the DNS Server service while AD DS is still synchronizing doesn't shorten the wait (our reading): Microsoft's resolution for the event says "Ensure that AD DS is functioning properly, troubleshoot any problems, and then restart the DNS Server service." Fix the AD DS side first.

Step 4: Which DNS servers does this DC ask? (read-only)

This is the step that most often explains a long 4013. Read every adapter's DNS server list, in order:

# Read-only: DNS servers per adapter, in the order the DC uses them Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object { $_.ServerAddresses } | Select-Object InterfaceAlias, InterfaceIndex, ServerAddresses # Read-only: the same from ipconfig, with suffix and registration details ipconfig /all 

Read the list against Microsoft's guidance for DCs:

Microsoft's summary of what a DC's DNS servers must do is short: they should be servers that "Are available at Windows startup." and that "Host, forward, or delegate the _msdcs.<forest root domain> and primary DNS suffix zones for current and potential source domain controllers." Two client details from Microsoft's best-practice article explain why a good-looking list can still fail: the client uses the preferred server until it fails to respond, and "Only a failure to respond will cause the DNS client to switch Preferred DNS servers; receiving an authoritative but incorrect response does not cause the DNS client to try another server."

Then prove each listed server answers for the AD zones right now. Run this from the DC (or from another machine, against the same servers):

# Read-only: does each DNS server in the DC's list answer on port 53 and hold the zones? $servers = '10.0.0.11', '10.1.0.10', '127.0.0.1' foreach ($s in $servers) { $tcp = Test-NetConnection -ComputerName $s -Port 53 -WarningAction SilentlyContinue $soa = Resolve-DnsName -Name 'contoso.com' -Type SOA -Server $s -DnsOnly -ErrorAction SilentlyContinue $msd = Resolve-DnsName -Name '_msdcs.contoso.com' -Type SOA -Server $s -DnsOnly -ErrorAction SilentlyContinue [pscustomobject]@{ Server = $s; Tcp53 = $tcp.TcpTestSucceeded; DomainSOA = [bool]$soa; MsdcsSOA = [bool]$msd } } 

Step 5: Can this DC resolve its replication partners? (read-only)

AD DS finds a source DC by the GUID-based alias in _msdcs. Microsoft: "You should ensure that domain controllers can successfully resolve the guided CNAME records to host records of current and potential source domain controllers." Read the partner's CNAME from replication data, then resolve it from each server in this DC's list:

# Read-only: inbound partners with their fully qualified CNAME (look for the _msdcs name in the output) repadmin /showrepl DC01 /verbose # Read-only: resolve one partner's GUID CNAME and host record from a specific DNS server $guidName = 'dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com' Resolve-DnsName -Name $guidName -Type CNAME -Server 10.0.0.11 -DnsOnly Resolve-DnsName -Name 'DC02.contoso.com' -Type A -Server 10.0.0.11 -DnsOnly 

Microsoft documents /verbose as showing the "fully qualified CNAME, invocation ID, replication flags, and update sequence number (USN) values" for each source partner, which is the name you need. If AD DS isn't answering on this DC yet, run repadmin /showrepl against a healthy DC instead and read its view of this DC.

Then run Microsoft's DNS tests from the 2087 procedure, against this DC and against the partner:

# Read-only: basic DNS health (connectivity, services, client config, records, zone and SOA) dcdiag /test:dns /s:DC01 /DnsBasic /f:C:\Temp\dcdiag-dns-DC01.txt # Read-only: are the A, CNAME, and SRV records for DC location registered? dcdiag /test:dns /s:DC02 /DnsRecordRegistration 

Microsoft's description of the basic test covers what you'd otherwise check by hand: it confirms the DNS Client, Net Logon, KDC, and DNS Server services are running, that "DNS servers on all adapters are reachable", and that each DC's host record "is registered on at least one of the DNS servers that is configured on the client." /DnsRecordRegistration checks "the address (A), canonical name (CNAME) and well-known service (SRV) resource records". Note that /DnsDynamicUpdate is not read-only: Microsoft says it performs "registration of a test record (_dcdiag_test_record)", deleted automatically after the test.

Step 6: Is inbound replication happening, and from whom? (read-only)

Microsoft's cause statement is about partners: these DCs "try to inbound replicate all locally held directory partitions during Windows startup, as part of an initial synchronization or init sync." Read who they are and whether each one works:

# Read-only: inbound replication status for this DC, by partition and partner repadmin /showrepl DC01 # Read-only: only the failing partnerships, for every DC in the forest repadmin /showrepl * /errorsonly # Read-only: failures and largest deltas, summarized per source and destination repadmin /replsummary * /bysrc /bydest /sort:delta 

The PowerShell view gives the same data as objects, once AD DS on the DC you query is answering:

# Read-only: inbound partners of DC01, last success and last result Get-ADReplicationPartnerMetadata -Target DC01 -PartnerType Inbound | Select-Object Partner, Partition, LastReplicationAttempt, LastReplicationSuccess, LastReplicationResult # Read-only: current replication failures recorded for DC01 Get-ADReplicationFailure -Target DC01 | Select-Object Partner, FailureCount, FirstFailureTime, LastError # Read-only: every DC the domain knows about, with site and address Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address, IsGlobalCatalog, OperationMasterRoles 

Read the partners against Microsoft's list of conditions that keep initial sync from finishing:

Microsoft's guidance for the gone-for-good case is direct: "Remove references to stale domain controllers." and "Make offline or non-functioning domain controllers operational." Its 2087 article adds the check before cleanup: confirm the source DC is really down, with net view \\<SourceDomainControllerName> (which "displa...