Fix ERROR_DS_CANT_FIND_DC_FOR_SRC_DOMAIN (0x00002159)
This error pops up during Active Directory migration or replication when the source domain's DC can't be found. It's usually a DNS or connectivity issue.
When does this error show up?
You're in the middle of an Active Directory migration—maybe running adprep /forestprep from a Windows Server 2019 box against an older 2008 R2 domain, or trying to add a new domain controller to an existing domain. Then boom: ERROR_DS_CANT_FIND_DC_FOR_SRC_DOMAIN (0x00002159). It also hits during cross-forest replication setup or when you're using tools like repadmin /syncall. I've seen it most often when the source domain is in a different site or forest, and DNS can't resolve the source DC's SRV records. Frustrating? Absolutely. But it's fixable.
What's really happening here?
The error means the machine you're on tried to locate a domain controller for the source domain (the one you're migrating from or replicating with) but couldn't find one. That's not a vague "something's wrong"—it's a specific DNS or network connectivity failure during domain location. The source domain's DCs aren't registering their SRV records properly, or your target machine can't reach those records. Sometimes it's a firewall blocking LDAP or Kerberos ports. Other times it's a stale DNS zone. The root cause is almost always one of these three: bad DNS forwarding, missing SRV records, or a firewall that's too strict.
Fix it—step by step
Step 1: Check DNS resolution for the source domain
On the machine that throws the error, open a command prompt as Admin and run:
nslookup -type=SRV _ldap._tcp.dc._msdcs.<SourceDomainFQDN>Replace <SourceDomainFQDN> with the actual domain name, like contoso.com. If you get a response with multiple DC IPs, DNS is working. If you get "Non-existent domain" or no SRV records, that's your problem. Skip down to Step 2. If you get a timeout, check network connectivity first—ping <SourceDomainFQDN> or Test-NetConnection <DC-IP> -Port 389.
If you do see records but the error persists, the issue might be that your machine's DNS server can't resolve across forests. You'll need conditional forwarding.
Step 2: Fix DNS forwarding or conditional forwarding
On your DNS server (the one the failing machine uses), open DNS Manager. Right-click Conditional Forwarders and choose New Conditional Forwarder. Enter the source domain's FQDN, then add the IP address of a DC in that source domain. Check the box "Store this conditional forwarder in Active Directory" and select "All DNS servers in this forest"—this makes it replicate. Apply and test with nslookup again.
I've seen this fail when admins only add one DC IP. Add at least two for redundancy. If you're in a different forest entirely, also check that the source domain's DNS allows recursion from your DNS server—otherwise you'll get a referral error.
Step 3: Verify firewall rules between domains
AD replication and location need ports 53 (DNS), 88 (Kerberos), 389 (LDAP), 445 (SMB), and 135 (RPC). Run a quick connectivity test from the failing machine to a source DC:
Test-NetConnection <SourceDC-IP> -Port 389If that fails, check Windows Firewall or any third-party firewall between them. In a cloud scenario (Azure to on-prem, for example), check NSG rules and route tables. I once lost two hours because of an unsaved NSG rule—don't skip this verification step.
Step 4: Force DC discovery using nltest
Sometimes the Domain Controller Locator service gets confused. Use nltest to force a fresh discovery:
nltest /dsgetdc:<SourceDomainFQDN>This writes detailed info to the output, including which DC it found and via which mechanism. If it says "Cannot find a DC", you'll see a specific reason—like "DNS lookup failure" or "No response from any DC". That's your clue to revisit Steps 1-3.
Step 5: Check AD replication status (if already in same forest)
If the source domain is in the same forest and you're still seeing this error, run:
repadmin /replsummaryLook for errors on any source DCs. If replication is broken, fix that first. Common issues: tombstone lifetime exceeded, or the KCC hasn't generated the right topology. Use repadmin /kcc to trigger a recalculation.
What if it still fails after all that?
Check two more things. First, verify that the source domain's Domain Naming Master role holder is online and reachable. You can find it with:
netdom query fsmoSecond, look at the event logs on the target machine—System and Directory Service logs often have additional error codes like 0x0000215B that point to a specific DC that's down. If all else fails, temporarily add a static host entry in the target machine's C:\Windows\System32\drivers\etc\hosts file mapping the source domain's name to a known DC IP. This is a band-aid, not a cure—use it only to get a migration step moving while you fix the DNS permanently.
Was this solution helpful?