[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1310
  • Last Modified:

NTDS Replication Error

Long story short, one of my two DC's crashed. I used metadata cleanup on the other DC to manually remove the crashed DC. After rebuilding the machine, I DCpromoed it back into the domain, and everything appears to be functioning correctly, except for the following that it popping up on one of the DCs (The one that didn't crash)

Event Type:      Error
Event Source:      NTDS Replication
Event Category:      DS RPC Client
Event ID:      1411
Date:            3/24/2007
Time:            10:17:45 PM
User:            NT AUTHORITY\ANONYMOUS LOGON
Computer:      WSCPDC
Description:
Active Directory failed to construct a mutual authentication service principal name (SPN) for the following domain controller.
 
Domain controller:
50266e59-dfa6-4d1f-882b-6e65c5482bee._msdcs.domain.com
 
The call was denied. Communication with this domain controller might be affected.
 
Additional Data
Error value:
8589 The DS cannot derive a service principal name (SPN) with which to mutually authenticate the target server because the corresponding server object in the local DS database has no serverReference attribute.

If I look at the GUID that the error is reporting, I'm pretty sure that this GUID is the old identifier for the DC that crashed. If I look in the _msdcd folder in DNS, there is no reference to this GUID anywhere. This is why despite the error, the directory seems to be working fine.

How can I clean this up?
0
jschweg
Asked:
jschweg
  • 3
1 Solution
 
Zenith63Commented:
You could use ADSIEdit to have a look at the lower level of the Active Directory database and do a search from there for the SID.  If the reference is in AD you'll find it.  However as you obviously guessed it looks more like the kind of error you'd see if the reference to the old SID was in DNS somewhere.  Did you go through the entire DNS tree looking for the record?
0
 
jschwegAuthor Commented:
I thought that I went though all the DNS records, but it was pretty late at that point. I will re-check them.
0
 
AnthonyP9618Commented:
Did you remove the connection information to the old DC from AD Sites and Services?  My guess is that it's trying to replicate and still shows the old connection information with which to replicate.

If you promoted the new DC with the same name, go ahead and delete that DC anyway.  Windows (moreover, the KCC) will rebuild those connections based upon what it needs.  In this case, I would probably force the KCC to kick off manually (Do this from your working DC):

repadmin /kcc <DCservernameyoujustremoved>
repadmin /showreps

I would run the /showreps command until you see the KCC rebuild the links.  Once that's complete, go back into AD Sites and Services and manually replicate your connections.  Any errors?
0
 
jschwegAuthor Commented:
To answer your questions...

During my removal process, I ran the metadata cleanup, removed all the DNS records, and removed the DC from Sites and Services. I DID rejoin the crashed DC back with the same name after rebuilding it.

Both DC's appear to be happy, if I run repadmin /showreps now, everything is successful on both. I'm only getting the error on of the DC's (the one that didn't crash), and so far it only pops up if I reboot the DC.

0
 
jschwegAuthor Commented:
Sorry for the huge delay, time got away with me. Thanks for the help.
0

Featured Post

NEW Veeam Agent for Microsoft Windows

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now