Fix ERROR_LOGON_SERVER_CONFLICT (0X00000238) in AD

Quick answer for advanced admins: Restart the Netlogon service on both domain controllers. Then verify secure channel trust using nltest /sc_query:<domain>. If that doesn't work, reset the secure channel with nltest /sc_reset:<domain>.

I know seeing ERROR_LOGON_SERVER_CONFLICT (0X00000238) during authentication or replication feels like your servers are fighting you. I've been there—two domain controllers suddenly refusing to talk, users getting locked out, and the event log flooding with NTDS or Netlogon errors. This error typically shows up when a domain controller can't establish a secure channel with another DC because of a trust secret mismatch, time skew, or replication lag. It's common in multi-DC environments after a restore, a password reset on the computer account, or a partial replication failure. Let's fix it.

Step-by-Step Fix for ERROR_LOGON_SERVER_CONFLICT (0X00000238)

1. Restart the Netlogon Service on Both DCs

This is the fastest sanity check. The Netlogon service maintains the secure channel. Rebooting is overkill—just restart the service:

net stop netlogon && net start netlogon

Do this on the DC that threw the error, then on the other DC. If the error persists, move to step 2.

2. Check the Secure Channel with nltest

On the problematic DC, run this to see if the secure channel to a specific DC is broken:

nltest /sc_query:yourdomain.com

If it returns ERROR_CANNOT_ACCESS_DOMAIN or 0x6DD, the channel is dead. Note the target DC name from the output—that's the machine with the conflict.

3. Reset the Secure Channel

Reset the channel from the broken DC to the other DC. On the broken DC, run:

nltest /sc_reset:yourdomain.com\otherDCname

I've used this dozens of times—it forces a re-authentication and resets the trust secret. You'll need Domain Admin credentials.

4. Verify Time Synchronization

Kerberos is picky about time. Check time on both DCs—they should be within 5 minutes of each other. Use:

w32tm /query /status

If one DC is using a different time source (like the PDC emulator is not syncing), fix it with:

w32tm /resync /nowait

Then restart Netlogon again.

5. Check Replication Status

Use repadmin to see if replication failed:

repadmin /showrepl

Look for last success timestamps older than 15 minutes. If you see failures, the error code often points to a trust conflict. Force replication:

repadmin /syncall /AdeP

Alternative Fixes If the Main Steps Don't Work

Reset the Computer Account from ADUC

If the secure channel keeps breaking, the computer account password may be corrupt. Open Active Directory Users and Computers, find the DC's computer object, right-click, and select Reset Account. Then rejoin the DC to the domain (yes, you'll need to reboot). I've only needed this once in six years, but it's a nuclear option that works.

Use dcdiag to Test Authentication

Run a full dcdiag test on the affected DC:

dcdiag /test:Netlogons /v

This tests secure channel authentication. If it fails, the error message will tell you which DC is causing the conflict. Follow that output to reset the specific connection.

Check DNS Records for Stale Entries

Sometimes a DC's DNS record points to an old IP. On the broken DC, check:

nslookup otherDCname

If the IP is wrong, delete the stale record from DNS Manager and run ipconfig /registerdns on the other DC.

Prevention Tips for ERROR_LOGON_SERVER_CONFLICT

Monitor Netlogon events: Set up alerts for Event ID 5722, 5783, and 5807 on all DCs. These are early warnings.
Use Group Policy to enforce Kerberos time tolerance: Set 'Maximum tolerance for computer clock synchronization' to 5 minutes in Computer Configuration > Administrative Templates > System > Kerberos.
Schedule regular dcdiag runs: Automate a daily dcdiag /q to catch trust issues before they become failures.
Never manually reset DC computer passwords: Use the proper reset via ADUC or nltest. I once saw an admin use netdom resetpwd and it broke the entire domain—don't do that.

This error is frustrating, but it's almost always fixable with the steps above. Start with Netlogon restart, then nltest, and work through replication. If you hit a wall, the ADUC account reset will give you a clean slate. Good luck.