NERR_LogonServerConflict 0X000008A2: Two DCs Fighting Over One Role

1. The most common cause: a demoted DC still holds the logon role

What's actually happening here is that you demoted a domain controller but the role it used to hold never got transferred. The NERR_LogonServerConflict error (0X000008A2) appears when a client or another DC tries to contact the centralized logon server and gets two different answers. The old DC's metadata is still in Active Directory, so when a DC locator request comes in, it returns two servers that both claim to be the logon server for that domain.

I've seen this most often after an in-place demotion where the wizard completed but the server's own NTDS Settings object was left behind. Usually because the demotion failed at the last step or someone force-removed the DC role without running dcpromo /forceremoval first.

The fix: identify and clean up the stale role holder

1. On any healthy DC, open an elevated PowerShell prompt and run:

Get-ADDomainController -Filter * | Select-Object Name, Domain, OperationMasterRoles

The output shows which DC holds the PDCEmulator and RIDMaster roles. If you see a server that no longer exists, that's your culprit.

Next, check replication metadata to confirm it's stale:

Get-ADObject -Identity "CN=NTDS Settings,CN=OldDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=yourdomain,DC=com" -Properties *

If that object exists and the server is gone, you need to remove it. The clean way is with ntdsutil:

ntdsutil.exe
metadata cleanup
remove selected server OldDC
quit

Then press q to exit. After that, force replication with repadmin /syncall /AdeP and test with nltest /dsgetdc:yourdomain.

The reason this works is that the DC locator uses DNS SRV records and the NTDS Settings objects to build its list. Once the stale object is gone, the locator only sees the real DCs.

2. Second common cause: two live DCs with the same NTDS Settings GUID

Less obvious but just as nasty: you cloned a VM without running sysprep and without using the proper DC cloning process. Both DCs end up with the same invocationID (which is derived from the NTDS Settings object GUID). Replication starts to fail, and then you get the conflict error because both servers respond as if they're the same domain controller.

How do you know it's this? You'll see errors in the Directory Service event log like NTDS Replication event 1388 or 1988, and your replication partners will show as having the same invocationID.

The fix: reset the invocation ID on the cloned DC

First, confirm which DC is the real one and which is the clone. The clone should be taken offline immediately. Then, on the clone (while it's isolated), run:

ntdsutil.exe
roles
connections
connect to server "ClonedDC.yourdomain.com"
quit
quit
reset invocation ID
quit

This gives the clone a new invocationID so it can replicate properly. But honestly, if you have a proper backup, it's faster to just rebuild the clone from scratch with a clean install. The reset trick is a bandage—it works, but you're carrying around a DC that had a near-fatal identity crisis.

What's actually happening here is that Active Directory replication relies on each DC having a unique invocationID to track changes. When two DCs share the same ID, they can't tell whose changes are whose, so the replication engine throws a fit and the logon service doesn't know which DC to trust.

3. Third cause: lingering DNS records pointing to an old DC

Sometimes the AD metadata is fine, but the DNS SRV records for _ldap._tcp.dc._msdcs.yourdomain.com still list a dead server. Clients doing a DC locator query get back an IP that either doesn't respond or responds with a different name. That mismatch triggers the logon server conflict error.

You'll spot this when nltest /dsgetdc:yourdomain returns a server that you know is gone, but Get-ADDomainController shows a clean list.

The fix: clean up stale DNS records

Open the DNS management console on the DNS server that holds the Active Directory-integrated zone. Navigate to:

Forward Lookup Zones → yourdomain.com → _msdcs → _dc → _tcp

Look for SRV records that point to the old DC's hostname. Delete them. Also check the _ldap and _kerberos folders.

But before you start deleting, make sure the old DC isn't still alive somewhere. Check for the host A record as well. If you're running DNS on the DCs, the scavenging process should handle this automatically, but only if you've enabled scavenging on the zone. If scavenging is off (default in many orgs), you're doing this by hand.

After you delete the records, run ipconfig /flushdns and nltest /dsgetdc:yourdomain again. The conflict should disappear.

The reason stale DNS causes this specific error is that the DC locator uses SRV records to find a DC that can authenticate the client. If the DNS returns a name that doesn't match a valid DC, the Netlogon service on the client tries to contact it, gets no response or a mismatch, and then throws the conflict error because it can't decide which is the real logon server.

Quick reference

Start with the first fix because it's the most common. If that doesn't clear it, move to the second. The DNS cleanup is usually the last piece you need after you've fixed the metadata issues.