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 /showrepland 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 | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which DC, which events with their full text, when it booted, which other DCs rebooted with it, and what changed | "DNS is down on DC01" with no event text and no boot time |
| 2. Event read | You know whether 4013 stopped after a few minutes or is still being logged, and which neighbor events came with it | Every 4013 treated as an outage; or a 4013 that's been logged for hours treated as boot noise |
| 3. Services | DNS Server, AD DS, Netlogon, and KDC states are known, and you know whether the DC is advertising | DNS Server shows Starting or Running with no zones; DNS Manager can't connect |
| 4. DC DNS client | The DC's adapter lists DNS servers that are up at boot, host the AD zones, and answer | Only 127.0.0.1 or its own address on a DC with partners; an ISP resolver; a retired DC |
| 5. Partner names | The DC can resolve each source DC's GUID CNAME and host record from the servers it asks | NTDS 2087 or 2088; Resolve-DnsName fails for the _msdcs CNAME |
| 6. Inbound replication | Every partner in repadmin /showrepl is online and replicates inbound |
Partners that no longer exist; partners powered off; RPC errors such as 1722 |
| 7. Special cases | Single DC, role holder, isolated network, or forest recovery is recognized for what it is | Repl Perform Initial Synchronizations left at 0 from an old fix; a lone DC that waits on nothing |
| 8. 4015, 4000, 4007 | The event is identified by ID and error code, not lumped in with 4013 | 4015 with 0000051B, 00002095, or ADMIN_LIMIT_EXCEEDED treated as a boot wait |
| 9. Change | One link fixed, then replication and the DNS Server service checked | Registry, DNS list, and services all changed in one go |
| 10. Proof | A reboot in a window logs no lasting 4013, replication is clean, and every DNS server answers | It works until the next patch night, when two DCs reboot together again |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Which DC, and is it a DNS server with AD-integrated zones? | 4013 is logged by DNS servers that store zones in AD DS, so it only appears on DCs running the DNS Server role (Step 3) |
| The full event text and data | 4013's wording differs between Windows versions and Microsoft pages; 4015 carries an error code that decides the branch (Steps 2 and 8) |
| When the DC booted, and how long the 4013s lasted | A few events right after boot that then stop is a different case from 4013 every two minutes for an hour (Step 2) |
| Which other DCs rebooted at the same time | Microsoft's example is two DCs pointing at each other that both restart; each waits for the other's DNS (Step 4) |
| How many DCs, sites, and domains | A single DC, a branch DC behind a WAN link, and a hub DC with local partners need different DNS client settings (Steps 4 and 7) |
| Since when, and what changed | Patching, a power or cooling outage, a DC removed without demotion, a restore or recovery, a new IP address, DNS client changes on the DC, a registry fix someone applied once, an RODC added |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| A few 4013s right after boot, then they stop | Initial synchronization finished; the DNS Server service started; nothing to fix unless the boot was slow | Step 2 |
| 4013 every two minutes for an hour or more | AD DS hasn't finished inbound replication of its partitions; find out why | Steps 4 to 6 |
| Two DCs that point at each other rebooted together | Microsoft's example scenario: each waits on the other's DNS while its own DNS waits on AD DS | Steps 4 and 9 |
| A DC with partners that points only at itself | Microsoft lists this among the conditions that make 4013 worse | Step 4 |
| One DC in a site, alternate DNS across a WAN link that was down | Microsoft's single-DC-in-a-site scenario | Steps 4 and 6 |
repadmin /showrepl shows a partner that no longer exists |
AD DS keeps trying to replicate from it; remove its metadata | Step 6 |
| NTDS Event 2087 or 2088 in the Directory Service log | The DC can't resolve a partner's GUID CNAME; 2087 means replication from it failed | Step 5 |
| The only DC in the forest logs 4013 | There's no partner to replicate from; read its DNS client list and the registry value | Step 7 |
| Repl Perform Initial Synchronizations is 0 | Someone used the emergency bypass and never restored it | Steps 7 and 9 |
| 4015 "has encountered a critical error from the Active Directory" | A different event; the error code in the text picks the cause | Step 8 |
| 4000 or 4007, zones not loading, Access Denied in DNS Manager | Microsoft's 4000/4007 article ties this to the DC's secure channel | Step 8 |
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:
| Event | Log or source (as Microsoft shows it) | Microsoft's message (excerpt) | What it tells you (our reading) |
|---|---|---|---|
| 4013 | DNS Server | "The DNS server is waiting for Active Directory Domain Services (AD DS) to signal that the initial synchronization of the directory has been completed." | DNS is waiting on AD DS initial sync; the rest of this post |
| 4013 (older wording) | DNS | "The DNS server was unable to open the Active Directory. This DNS server is configured to use directory service information and can not operate without access to the directory." | The same event ID as Microsoft's 4013 troubleshooting article shows it |
| 4015 | DNS Server | "The DNS server has encountered a critical error from the Active Directory. Check that the Active Directory is functioning properly." | Not a boot wait; read the extended error (Step 8) |
| 4000 | DNS Server | "The DNS server was unable to open Active Directory. This DNS server is configured to obtain and use information from the directory for this zone and is unable to load the zone without it." | Zones not loading (Step 8) |
| 4007 | DNS Server | "The DNS server was unable to open zone" (then the zone and application directory partition) | One zone's partition can't be opened (Step 8) |
| 4011 | DNS | "The DNS server was unable to add or write an update of domain name" | An AD write failed; Microsoft's large-record article shows it alongside 4015 |
| 2087 | Directory Service | "Active Directory could not resolve the following DNS host name of the source domain controller to an IP address." | Replication from that source failed on DNS (Step 5) |
| 2088 | Directory Service | "Active Directory could not use DNS to resolve the IP address of the source domain controller listed below." | Replication worked through fallback, but DNS is still wrong (Step 5) |
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":
| Hex | Decimal | Symbolic name | Microsoft's text |
|---|---|---|---|
| 000025f5 | 9717 | DNS_ERROR_DS_UNAVAILABLE | The directory service is unavailable |
| 0000232d | 9005 | DNS_ERROR_RCODE_REFUSED | DNS operation refused. |
| 0000232a | 9002 | DNS_ERROR_RCODE_SERVER_FAILURE | DNS server failure. |
Then read the timing (our reading):
| Finding | What it means |
|---|---|
| A handful of 4013s, the last within a few minutes of boot, then DNS answering | Initial sync finished; note the boot length and move on unless it was the 15 to 25 minute hang |
| 4013s for 15 to 20 minutes, then they stop | Microsoft's described delay: "these domain controllers can experience a 15-20 minute startup delay." Read Steps 4 to 6 so the next boot is faster |
| 4013 still being logged now | AD DS hasn't finished; find the partner or the DNS path that's missing (Steps 4 to 6) |
| 4013 plus 2087 for a partner | That partner's name doesn't resolve from this DC (Step 5) |
| 4013 on the only DC | No partner exists; read Step 7 |
| 4015 or 4000/4007 without 4013 | Go to Step 8 |
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:
| What you see | Microsoft's text | What it means (our reading) |
|---|---|---|
| DNS Manager (DNSMGMT.MSC) won't connect | "The server <computername> could not be contacted. The error was: The server is unavailable. Would you like to add it anyway?" |
The DNS Server service isn't serving yet; it's waiting on AD DS |
| Active Directory Users and Computers (DSA.MSC) won't open | "Naming information could not be located" | The DC can't yet act as a DC for the console |
| A long boot | "This issue occurs after the Preparing network connections message is displayed, and before the Windows logon prompt (Ctrl+Alt+Del) is displayed." | The wait happened during startup; read Step 2's timing |
| DNS Server Running, zones present, 4013s stopped | (none) | Initial sync finished; the problem, if any, is how long it took |
| DNS Server Running, 4000/4007, Access Denied in DNS Manager | Microsoft's 4000/4007 symptoms | Step 8, not a boot wait |
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:
| What the list shows | Microsoft's guidance (quoted) or our reading |
|---|---|
| Only 127.0.0.1 or the DC's own address, on a DC with partners | "Configuring domain controllers to point to a single DNS server's IP address, including the 127.0.0.1 loopback address, represents a single point of failure. This setting is tolerable in a forest with only one domain controller, but not in forests with multiple domain controllers." |
| Two DCs that each list the other first and themselves second, both rebooted together | Microsoft's own example: "When both DC1 and DC2 reboot simultaneously, there will be a slow startup because of this mutual dependency." The fix is the reboot schedule and a third DNS server that's up, not removing the partner (Step 9) |
| A hub-site DC | "Hub-site domain controllers should point to DNS servers in the same site as them for preferred and alternate DNS server and then finally to itself as another alternate DNS server." |
| A branch-site DC | "Branch site domain controllers should configure the preferred DNS server IP address to point to a hub-site DNS server, the alternate DNS server IP address to point to an in-site DNS server or one in the closest available site, and finally to itself using the 127.0.0.1 loopback address or current static IP address." |
| An ISP or public resolver | "Don't configure the DNS client settings on the domain controllers to point to DNS servers of your Internet Service Provider (ISP)." Use forwarders instead (Windows DNS Server Not Resolving External Names covers that side) |
| A retired DC's address, or a server that doesn't host the zones | Microsoft lists DNS servers "that either don't exist, are currently offline, aren't accessible on the network, or that don't host the required zones and records that are needed to inbound-replicate Active Directory" among the 4013 conditions |
| The first and only DC in the domain | "If the server is the first and only domain controller that you install in the domain, and the server runs DNS, configure the DNS client settings to point to that first server's IP address." (Step 7) |
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 }
}
| Finding | What it means (our reading) |
|---|---|
| Every server in the list is a DC that rebooted with this one | Nothing could answer during the boot window; that's the 4013 loop |
| The only server that answers is 127.0.0.1 | This DC's own DNS, which is the one waiting on AD DS; it can't help AD DS find partners |
A server answers but has no _msdcs zone |
It can't resolve the GUID CNAMEs replication uses (Step 5) |
| Port 53 fails to one server | It's off, retired, or blocked; it's still costing timeouts on every boot |
| A partner in another site answers | Good, as long as the WAN link is up at boot; Microsoft's single-DC-in-a-site scenario is the case where it wasn't |
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.
| Finding | What it means (our reading unless noted) |
|---|---|
| CNAME missing on every server | The partner never registered it, or it was removed; Microsoft notes DNS scavenging "can be configured too aggressively, causing valid records to be prematurely purged from DNS zones." (DNS Scavenging Not Working covers how) |
| CNAME present on one server, missing on another | Replication or zone scope differs between them; the DC asks the one that doesn't have it |
| CNAME resolves, host record points to an old address | A stale A record; Microsoft: "Missing, duplicate, or stale CNAME and host records all contribute to this problem." |
| 2087 for a partner | Microsoft: "attempts to resolve the globally unique identifier (GUID) in the alias (CNAME) resource record, the fully qualified domain name (FQDN), and the NetBIOS name to the IP address of the source domain controller have all failed." |
| 2088 for a partner | Replication succeeded by FQDN or NetBIOS fallback; the CNAME is still broken, and every boot pays for the fallback |
| The partner is gone, but its CNAME is still asked for | It's still in this DC's replication data; Step 6 |
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:
| Finding | Microsoft's condition (quoted) | Next step (our reading) |
|---|---|---|
| A partner that was removed without demotion or rebuilt under the same name | "The local domain controller's copy of Active Directory contains references to stale domain controllers that no longer exist on the network." | Metadata cleanup for that DC (Step 9) |
| A partner that's powered off for now | "The local domain controller's copy of Active Directory contains references to other domain controllers who are currently turned off." | Bring it up, or wait it out with another partner available |
| Partners online but failing with an error | "So the local domain controller's copy of Active Directory contains references to other domain controllers that are online and accessible but can't be successfully replicated from." | Read the error; 1722 is covered in Active Directory Replication Error 1722 |
| Every partner fails, and the network adapter shows no connectivity | "The network adapter or network stack on the caller or target computer is either disabled or non-functional." | Fix the adapter or virtual switch first |
| The DC was started on a lab or recovery network | "The domain controller has been booted on an isolated network." | Expected; see Step 7's recovery note |
| One partner succeeds, others fail | Initial sync needs each partition from a partner; a success for one partition doesn't cover the others (our reading) | Read the failures per partition |
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 "displays the Netlogon and SYSVOL shares, indicating that the server is functioning as a domain controller.").
Step 7: Is it the only DC, a role holder, or a recovery case? (read-only)
Three situations look like 4013 trouble but need their own reading.
The only DC in the forest. Microsoft's best-practice article says the first and only DC that runs DNS should point at itself: "Do not list any other DNS servers until you have another domain controller hosting DNS in that domain." With no partner, there's nothing to replicate from, so a long 4013 on a lone DC usually means its copy of AD DS still lists a partner (our reading): a second DC that was removed without demotion, or a DC from a test you forgot. Run Step 6's Get-ADDomainController -Filter * and repadmin /showrepl on it; any partner listed there is one it's waiting on.
A role holder. Operations masters have their own initial-sync rule, and Microsoft's 4013 article keeps the two apart: "The initial sync requirements required for FSMO roles to become operational is different from the initial sync discussed in this article, where Active Directory must inbound replicate to start the DNS Server service immediately." The role rules, from Microsoft's FSMO article:
| Role | Microsoft's initial replication requirement |
|---|---|
| Schema master | "This FSMO role holder is only active when the role owner has inbound replicated the schema NC successfully since the Directory Service started." |
| Domain naming master | "This FSMO role holder is only active when the role owner has inbound replicated the configuration NC successfully since the Directory Service started." |
| RID master, infrastructure master | "This FSMO role holder is active only when the role owner has inbound replicated the domain NC successfully since the Directory Service started." |
| PDC emulator | "There is no inbound replication requirement." |
So a role holder that logs 4013 may also be refusing role operations, such as RID pool requests, for the same reason (our reading); fix the replication, not the roles.
The registry value. Read it on every DC you touch, because an old fix often left it behind:
# Read-only: is the initial synchronization bypass set? (absent means the default)
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'Repl Perform Initial Synchronizations' -ErrorAction SilentlyContinue |
Select-Object 'Repl Perform Initial Synchronizations'
Microsoft's 4013 article gives the bypass as the value Repl Perform Initial Synchronizations, type REG_DWORD, data 0, under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, and then says "The use of Repl Perform Initial Synchronizations should be used only in critical situations to resolve temporary and specific problems." The forest recovery guide is where it's meant to be used: for a restored DC that holds operations master roles, so AD DS isn't unavailable until it has replicated a writeable partition. That guide's restore instruction is "After the forest is recovered completely, you can reset the value of this entry to 1, which requires a domain controller that restarts and holds operations master roles to have successful AD DS inbound and outbound replication with its known replica partners before it advertises itself as domain controller and starts providing services to clients."
| Finding | What it means (our reading unless noted) |
|---|---|
| Value absent | The default; nothing to change |
| Value 1 | The default behavior, set explicitly (Microsoft's recovery guide resets it to 1) |
| Value 0 and no one knows why | A leftover bypass; plan to restore it (Step 9) after replication is proven |
| Value 0 during a documented forest recovery | Expected, until the forest is recovered |
| DC started on a lab, recovery, or isolated network | Microsoft lists "The domain controller has been booted on an isolated network." among the 4013 conditions; 4013 there is expected |
Step 8: Is it really 4015, 4000, or 4007? (read-only)
These come from the same DNS Server and AD DS relationship but aren't boot waits. Read the full text of the most recent ones:
# Read-only: the newest 4015, 4000, and 4007 with their full message, including the extended error
Get-WinEvent -FilterHashtable @{ LogName = 'DNS Server'; Id = 4015, 4000, 4007 } -MaxEvents 10 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message |
Format-List
Microsoft's 4015 text is "The DNS server has encountered a critical error from the Active Directory. Check that the Active Directory is functioning properly. The extended error debug information (which may be empty) is", followed by the error. Its 4015 article sorts the error into three cases:
| Extended error starts with | Microsoft's cause | Microsoft's check or fix |
|---|---|---|
| 00002095 (often with "problem 5012 (DIR_ERROR)"), logged every three minutes on an RODC | "A Read-Only Domain Controller (RODC) running DNS can't connect to a writable domain controller" | Run nltest /dsgetdc: with the domain and /WRITABLE /AVOIDSELF /TRY_NEXT_CLOSEST_SITE /DS_6; the DC it returns must be writeable, run DNS, and have correct records |
| 0000051B (with "nTSecurityDescriptor") | "The SYSTEM account isn't the owner of the DNS zone." or "The Users group for the domain doesn't have the correct members, including the Authenticated Users group." | Zone owner set to SYSTEM; the domain Users group contains Domain Users, Authenticated Users, and INTERACTIVE |
| ADMIN_LIMIT_EXCEEDED (problem 5008) | "The DNS Server service generates this error code if a multi-valued dnsRecord attribute of a dnsNode object in Active Directory contains too many values." | Remove the orphaned records of demoted DCs, by record data |
The read-only checks for each branch:
# Read-only (00002095, on the RODC): which writable DC does DC locator return?
nltest /dsgetdc:contoso.com /WRITABLE /AVOIDSELF /TRY_NEXT_CLOSEST_SITE /DS_6
# Read-only (0000051B): members of the domain's Users group
net localgroup users /domain
# Read-only (0000051B): owner of each AD-integrated zone object in the domain DNS partition
Get-ADObject -SearchBase 'CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com' -LDAPFilter '(objectClass=dnsZone)' -Properties nTSecurityDescriptor |
Select-Object Name, @{n='Owner';e={$_.nTSecurityDescriptor.Owner}}
# Read-only (ADMIN_LIMIT_EXCEEDED): record counts per name in the forest DNS partition, to a file
repadmin /showattr . "CN=MicrosoftDNS,DC=ForestDnsZones,DC=contoso,DC=com" /subtree /filter:"(objectclass=dnsnode)" /atts:"dnsRecord" /allvalues > C:\Temp\dns_ForestDnsZones.txt
Microsoft's own route to the zone in the 0000051B case is Field Engineering diagnostic logging and Directory Service Event 1644 at the time of the 4015, then ADSI Edit: "Right-click the zone object, and then select Properties > Security > Advanced." and "Make sure that Owner is set to SYSTEM." Field Engineering logging is a registry change; turn it off afterwards, as Microsoft's steps do. For the record-count case, Microsoft explains why the values pile up: "However, when you demote a DC that acts as a DNS server, Active Directory doesn't automatically clean up the related DNS objects and attributes." Its large-zone article puts the ceiling at "approximately 1,200 values that can be associated with a single object in Windows Server 2022 and earlier versions."
4000 and 4007 mean zones didn't load, and Microsoft's article for that pair names a different cause: "This issue happens when that particular DC/DNS server has lost its Secure channel with itself or PDC." It adds: "This issue can also happen in a single DC environment where that DC/DNS server holds all the FSMO roles and is pointing to itself as Primary DNS server." Microsoft's symptoms include that "You notice that the DNS Server service is up and running." while DNS Manager gives Access Denied, which is how you tell it from a 4013 wait (our reading). Microsoft's fix for that case is in Step 9.
Step 9: Change one link, then let initial sync finish (a change)
Fix only what Steps 2 to 8 showed, then read the result before changing anything else.
The DC's DNS server list (Step 4). For a hub-site DC with partners, point it at in-site partners first and itself last, as Microsoft describes. Use the addresses from your own design:
# A change: partner DNS servers first, this DC's own loopback last
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses '10.0.0.11', '10.0.0.12', '127.0.0.1'
# Re-read it, then clear the resolver cache and re-register, as Microsoft's article says to after any change
Get-DnsClientServerAddress -InterfaceAlias 'Ethernet' -AddressFamily IPv4
ipconfig /flushdns
ipconfig /registerdns
Microsoft's rule for that last step: "If you change any DNS client settings, you must clear the DNS resolver cache and register the DNS resource records." For a branch DC, the order is hub first, then in-site, then itself (Step 4's table). For a lone DC, its own address is correct; don't add a server that doesn't host its zones.
The reboot plan (Step 4). If the 4013 came from DCs that point at each other and rebooted together, the fix is the schedule as much as the list. Microsoft: "Stagger the reboots of DNS servers in your enterprise when possible." and, among its single points of failure, "Placing all DNS servers on guest virtual machines on the same physical host computer". Put DCs in different patch waves, and keep at least one DNS server that each DC lists up while the others restart.
A partner that's gone for good (Step 6). Confirm it's down, then clean up its metadata. Microsoft's simplest path: deleting the DC's computer account from the Domain Controllers OU in Active Directory Users and Computers, where "the cleanup of server metadata is performed automatically." Then remove the DNS records it left behind, by record data, the way Microsoft's 4015 article does:
# A change: preview, then remove one gone DC's NS record from a zone (Microsoft's form, with -WhatIf added)
Remove-DnsServerResourceRecord -ZoneName 'contoso.com' -RRType 'NS' -Name '@' -RecordData 'dc9.contoso.com' -WhatIf
Remove-DnsServerResourceRecord -ZoneName 'contoso.com' -RRType 'NS' -Name '@' -RecordData 'dc9.contoso.com'
A partner whose records are missing (Step 5). On that partner, re-register. Microsoft: "The Net Logon service on a domain controller registers the DNS resource records that are required for the domain controller to be located on the network. The DNS Client service registers the host (A) resource record that the alias (CNAME) record points to."
# A change, on the partner DC: re-register its locator records and its host record
Restart-Service -Name Netlogon
ipconfig /registerdns
Microsoft's next instruction is "Wait 15 minutes, and then review events in Event Viewer to ensure proper registration of the resource records." Then re-run Step 5's Resolve-DnsName from the DC that logged 4013.
Pull replication once names resolve. Then restart DNS only after AD DS has synchronized:
# A change: synchronize DC01 from all its partners, all partitions, across sites, DNs in messages
repadmin /syncall DC01 /A /e /d
# When repadmin /showrepl DC01 is clean, restart the DNS Server service
Restart-Service -Name DNS
A known bad boot (Steps 4 and 6). When you must boot a DC into a setup you know will stall (its partners are down for a planned outage, for example), Microsoft's documented path is to stop DNS from holding up the boot: "Set the DNS Server service startup value to manual.", then "Reboot, wait for the domain controller to advertise.", then "Restart the DNS Server service." It explains why that works: "If the service startup value for DNS Server service is set to manual, Active Directory doesn't wait for the DNS Server service to start."
# A change, before the planned boot: DNS Server service to manual
Set-Service -Name DNS -StartupType Manual
# After the boot, once nltest /dsgetdc returns this DC: start DNS, then put the startup type back
Start-Service -Name DNS
Set-Service -Name DNS -StartupType Automatic
The registry value (Step 7). If it's 0 from an old fix, restore the default once replication is proven, as Microsoft's recovery guide does:
# A change: restore initial synchronization (Microsoft's recovery guide resets the value to 1)
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'Repl Perform Initial Synchronizations' -Value 1
Set it to 0 only in the situation Microsoft describes, a critical and temporary one, with a written plan to restore it, and expect the next reboot to be the real test.
4015 with 0000051B (Step 8). Fix the zone owner in ADSI Edit as Microsoft describes, or restore the Users group membership with Microsoft's command, then wait for replication and restart the DNS Server service on all the DCs in the domain, as Microsoft's steps say:
net localgroup users "NT AUTHORITY\Authenticated Users" /add /domain
4000 and 4007 (Step 8). Microsoft's resolution starts with the DNS list ("configure the server experiencing the issue to point to other active DNS server in TCP/IP properties"), then: "Stop the KDC service on the DC experiencing the issue.", reset the DC's machine account password against the PDC with netdom resetpwd, and "Once the command executes, reboot the server." Microsoft's command, with your PDC and admin account in place of its placeholders:
netdom resetpwd /server:DC02.contoso.com /userd:CONTOSO\admin1 /passwordd:*
That's a secure-channel repair, not a fix for 4013 (our reading); use it only when Step 8 showed 4000 or 4007 with the zones not loading.
Step 10: Prove a clean boot (read-only, after a planned reboot)
Reboot the DC in a window, alone, with its partners up, and then run the reads again:
# Read-only: DNS Server events since this boot; Microsoft's verify step wants none from 4000 to 4019
$boot = (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime
Get-WinEvent -FilterHashtable @{ LogName = 'DNS Server'; Id = 4000..4019; StartTime = $boot } -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message
# Read-only: the events Microsoft's verify step expects to see
Get-WinEvent -FilterHashtable @{ LogName = 'DNS Server'; Id = 4523, 4524; StartTime = $boot } -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id
# Read-only: replication and DNS health after the boot
repadmin /showrepl DC01 /errorsonly
dcdiag /test:dns /s:DC01 /DnsBasic
# Read-only: every DNS server returns the DC locator records and the zones load here
foreach ($s in '10.0.0.10', '10.0.0.11', '10.0.0.12') {
Resolve-DnsName -Name '_ldap._tcp.dc._msdcs.contoso.com' -Type SRV -Server $s -DnsOnly -ErrorAction SilentlyContinue |
Select-Object @{n='Server';e={$s}}, Name, NameTarget, Port
}
Get-DnsServerZone -ComputerName DC01 | Select-Object ZoneName, ZoneType, IsDsIntegrated
Microsoft's verify step for the event is: "Ensure that Event IDs 4523 and 4524 are being logged and that no events in the range 4000 to 4019 appear in the Domain Name System (DNS) event log."
Pass criteria (our reading): no 4013 after the first few minutes of boot (none at all is better), and none in the 4000 to 4019 range after that; the boot no longer hangs at "Preparing network connections"; repadmin /showrepl shows every inbound partner succeeding; dcdiag /test:dns /DnsBasic passes for the DC; every DNS server returns the SRV records; DNS Manager opens and lists the AD-integrated zones; Repl Perform Initial Synchronizations is absent or 1; and the next patch night has DCs rebooting in separate waves.
Common false starts
| False start | Why it doesn't help (our reading unless noted) |
|---|---|
| Setting Repl Perform Initial Synchronizations to 0 and leaving it | Microsoft: "The default setting should be restored after such problems are resolved." Left at 0, the DC skips the check that keeps it from serving stale data |
| Pointing a DC with partners at 127.0.0.1 only | Microsoft names it a single point of failure, "tolerable in a forest with only one domain controller", and it's the setup where AD DS can't find partners while its own DNS waits |
| Adding a public resolver as a second DNS server | It can't answer for _msdcs or your domain; Microsoft says not to point DCs at ISP DNS servers |
| Restarting the DNS Server service in a loop | DNS waits on AD DS; until initial sync finishes or fails over, a restart starts the same wait |
| Rebooting the DC again "to be safe" | The same DNS list and the same partners give the same wait; fix Steps 4 to 6 first |
Running dcdiag /fix or /DnsDynamicUpdate as a first read |
Both change things (/DnsDynamicUpdate registers a test record); start with /DnsBasic and /DnsRecordRegistration
|
| Treating 4015 as a boot wait | 4015 carries an error code that names the cause: RODC, permissions, or record limits (Step 8) |
Running netdom resetpwd for every 4013 |
Microsoft's resetpwd steps are for 4000 and 4007 with a lost secure channel |
| Seizing roles because the role holder logs 4013 | Role holders wait for their own partition to replicate; seizing doesn't make DNS start, and the old holder still has the roles when it comes back |
| Deleting a partner's computer account because it's offline today | Metadata cleanup is for DCs that are gone for good; Microsoft's 2087 article checks the source DC first |
| Adding HOSTS file entries for partners | Microsoft notes static entries "become invalid over time", and queries for one DC "may be incorrectly resolved to another domain controller" |
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| A DC with partners points only at itself | In-site partners first and itself last (hub), or hub first, in-site next, itself last (branch) | 127.0.0.1 as the only entry, or a public resolver as the alternate |
| Two DCs point at each other and rebooted together | Separate patch waves, plus a DNS server each DC lists that stays up | Removing the partner from the list so each DC points only at itself |
| A partner that's gone for good | Metadata cleanup for that DC, then its leftover DNS records removed by record data | Waiting it out, or setting the registry bypass so the DC stops asking |
| A partner that's offline for now | Bring it back, or make sure another partner and DNS server are up at boot | Metadata cleanup for a DC that's coming back |
| Partner CNAME or A record missing | Re-register on the partner (Netlogon restart and ipconfig /registerdns), then resolve again |
HOSTS or LMHOSTS entries on the DC |
| Repl Perform Initial Synchronizations left at 0 | Restore it to the default after replication is proven | Leaving it at 0 because the boot is faster |
| A planned boot into a known bad setup | Microsoft's manual DNS startup, then back to Automatic once the DC advertises | The registry bypass for a one-time maintenance boot |
| 4015 with 0000051B | Zone owner back to SYSTEM, or the Users group membership restored | Granting broad rights on the DNS partitions to make the error stop |
| 4000/4007 with Access Denied | Microsoft's secure-channel reset, after pointing the DC at another DNS server |
netdom resetpwd as a fix for a plain 4013 wait |
FAQ
What does Event 4013 "The DNS server is waiting for Active Directory Domain Services (AD DS) to signal that the initial synchronization of the directory has been completed" mean?
The DNS Server service on a DC with AD-integrated zones is holding off until AD DS finishes its first inbound replication after boot, because "critical DNS data might not yet be replicated onto this domain controller." A few events right after boot that then stop are normal; events every two minutes for an hour mean replication isn't finishing (Steps 2 and 6).
Why does a domain controller take 15 to 20 minutes to boot with Event 4013?
AD DS needs DNS to find its replication partners, and DNS is waiting on AD DS. When the DC's DNS servers are itself or partners that are also rebooting, each lookup times out before falling back, for each partition. Microsoft's test puts it at "greater than 14 minutes" for five partitions and one source. Fix the DC's DNS server list and the reboot schedule (Steps 4 and 9).
Should I set Repl Perform Initial Synchronizations to 0 to fix Event 4013?
Not as a fix. Microsoft says it "isn't recommended for use in production environments, or in any environment on an ongoing basis" and should be used only in critical, temporary situations, with the default restored afterwards. Its forest recovery guide uses it for a restored role holder and then resets it to 1 (Steps 7 and 9).
Should a domain controller point to itself for DNS?
A lone DC should. A DC with partners shouldn't point only at itself: Microsoft says DCs "shouldn't point to a single domain controller and especially only to themselves as preferred DNS for name resolution." Put partners first and the DC itself last, following Microsoft's hub and branch guidance (Step 4).
What's the difference between DNS Event 4013 and 4015?
4013 is a wait: DNS hasn't started serving because AD DS initial synchronization hasn't finished. 4015 is an error: "The DNS server has encountered a critical error from the Active Directory." Its extended error code picks the cause: 00002095 (an RODC can't reach a writable DC), 0000051B (zone owner or Users group permissions), or ADMIN_LIMIT_EXCEEDED (too many orphaned records) (Step 8).
Related posts
- Active Directory Replication Error 1722 (when a partner in repadmin /showrepl fails with the RPC server unavailable)
- Netlogon Event ID 5719 (when member servers can't find a DC in the same boot window)
- DNS Scavenging Not Working (when a partner's CNAME or host record was aged out and deleted)
- Windows DNS Server Not Resolving External Names (when a DC lists a public resolver because the forwarders were wrong)
Free checklist
Setting the initial synchronization bypass, or pointing every DC at itself, before anyone read which partner and which name lookup was failing, is a change made everywhere at once. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=dns-event-4013-initial-sync
Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 and 10 are read-only checks: Get-WinEvent, Get-CimInstance, Get-Service, nltest /dsgetdc, Get-DnsClientServerAddress, ipconfig /all, Test-NetConnection, Resolve-DnsName, repadmin /showrepl, repadmin /replsummary, repadmin /showattr, dcdiag /test:dns /DnsBasic and /DnsRecordRegistration, Get-ADReplicationPartnerMetadata, Get-ADReplicationFailure, Get-ADDomainController, Get-ADObject, net localgroup users /domain, Get-ItemProperty, and Get-DnsServerZone. Changing a DC's DNS server list, re-registering records, cleaning up DC metadata, removing DNS records, forcing replication, restarting or changing the startup type of services, changing the Repl Perform Initial Synchronizations value, changing group membership or zone ownership, resetting a machine account password, and rebooting DCs are deliberate changes. Change one link at a time, prove it with a planned reboot, and check current Microsoft Learn for version-specific behavior.
Top comments (0)