DC replication - target principal name is incorrect??

[Mike Leone]

I came in this morning to a whole lot of weird errors. Users not able to access shares until I left the domain and rejoined (the sharing hosts, not the end users). I have other hosts I can't RDP to.

I checked my DCs, and see this:

C:\Windows\system32>repadmin /replsummary
Replication Summary Start Time: 2026-03-16 11:47:55

Beginning data collection for replication summary, this may take awhile:
  .......


Source DSA          largest delta    fails/total %%   error
 DC1ADS020                 52m:35s    0 /  10    0
 DC1WRK016                 52m:48s    0 /  10    0
 DC2ADS023                 55m:00s    0 /  10    0
 DC2WRK017         03d.12h:37m:13s    6 /  10   60  (2148074274) The target principal name is incorrect.


Destination DSA     largest delta    fails/total %%   error
 DC1ADS020                 54m:41s    0 /  10    0
 DC1WRK016         03d.12h:37m:13s    6 /  10   60  (2148074274) The target principal name is incorrect.
 DC2ADS023                 54m:49s    0 /  10    0
 DC2WRK017                 55m:00s    0 /  10    0

I never saw a "Target principal name is incorrect". Certainly not for a DC. 

I saw that on that sharing host, and I fixed that by leaving and re-joining the domain. Don't really wanna do that with a DC.

Now, 3 days ago I did see issues with DC2WRK017. The DNS settings on that DC pointerd to itself first, then DC1WRK016 (the DC in the other physical site). So I reveresed them. And everything seemed to be OK.

Ideas? 

--

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

[Wright, John M]

Not sure but you might try this:  Troubleshoot AD replication error -2146893022 - Windows Server | Microsoft Learn

 

Short version, stop KDC service, disable it, restart the DC, try replication test again, set kdc to auto again, restart the service.

 

--

John Wright

IT Support Specialist

1800 Old Bluegrass Avenue, Louisville, KY 40215

502.708.9953

Please submit IT requests to Hazelwoo...@bluegrass.org

24 Hour Helpline 1.800.928.8000

  

CONFIDENTIALITY NOTICE: This message contains confidential information and is intended only for the individual(s) addressed in the message. If you are not the named addressee, you should not disseminate, distribute, or copy this e-mail. If you are not the intended recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mike Leone
Sent: Monday, March 16, 2026 11:56 AM
To: NTSysAdmin <ntsys...@googlegroups.com>
Subject: [ntsysadmin] DC replication - target principal name is incorrect??

 

EXTERNAL EMAIL - This email was sent by a person from outside your organization. Exercise caution when clicking links, opening attachments or taking further action, before validating its authenticity.

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BgeTSsK2zYrrPQUCQ2-rMTmi8cLzSDb-OiOx-RCnm_ebQ%40mail.gmail.com.

[Henry Awad]

Domain controller replication failure with "The target principal name is incorrect" usually indicates a Kerberos authentication failure due to mismatched passwords between the source DC and the Key Distribution Center (KDC), or incorrect Service Principal Names (SPNs). Resolve it by resetting secure channels using netdom resetpwd.

Immediate Troubleshooting Steps

1. Reset Secure Channel: On the failing DC, run this command to reset its password against the PDC Emulator:
   netdom resetpwd /server:PDCEmulatorName /userd:Domain\Admin /passwordd:*
2. Restart KDC Service: Restart the Kerberos Key Distribution Center service on the DC, or reboot the server.
3. Purge Tickets: Clear cached Kerberos tickets by running klist -li 0x3e7 purge.
4. Verify DNS/SPN: Ensure DNS records (_msdcs) are correct and check for duplicate SPNs.

Henry Awad

Principal Engineer

Technology Services

The Catholic University of America

[Michael Leone]

UPDATE:

So we're following MS KB:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/replication-error-2146893022

We've disabled the KDC on 1 DC (there are only 2), and rebooted it.
But it's taking forever to come back to a login prompt. So we haven't
yet done the second step, about forcing replication.

In fact, other hosts who are rebooting are also now not coming back to
a login prompt ...

What a nightmare ...

On Mon, Mar 16, 2026 at 11:56 AM Mike Leone <tur...@mike-leone.com> wrote:
>

[Michael Leone]

On Mon, Mar 16, 2026 at 12:22 PM 'Henry Awad' via ntsysadmin
<ntsys...@googlegroups.com> wrote:
>
> Domain controller replication failure with "The target principal name is incorrect" usually indicates a Kerberos authentication failure due to mismatched passwords between the source DC and the Key Distribution Center (KDC), or incorrect Service Principal Names (SPNs). Resolve it by resetting secure channels using netdom resetpwd.
> Immediate Troubleshooting Steps
>
> Reset Secure Channel: On the failing DC, run this command to reset its password against the PDC Emulator:
> netdom resetpwd /server:PDCEmulatorName /userd:Domain\Admin /passwordd:*
> Restart KDC Service: Restart the Kerberos Key Distribution Center service on the DC, or reboot the server.
> Purge Tickets: Clear cached Kerberos tickets by running klist -li 0x3e7 purge.
> Verify DNS/SPN: Ensure DNS records (_msdcs) are correct and check for duplicate SPNs.

Yeah, that was the one I wanted to try. But my co-worker suggested the other KB
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/replication-error-2146893022

That's not working, as the DC nor any other domain member that was
rebooted is coming back to a login prompt.

Oh, MAN ....

[Mike Leone]

MORE:

So I only have 2 DCs. IPs of 7.94 and 7.95 (that's just the last 2 octets, obviously(. All the FSMO rules were on 7.94 (we thought), so we disabled KDC on 7.95 and reviews 

Turns out, somehow, the rules were NOT on 7.94, they're on 7.95 ... Which still isn't back to a login prompt after about 30 min. 

I've suggested paying MS, well see what happens ....

     

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CA%2BZrOWwFs%3DWAJw3a4TsjKATPVYpaKSV12L6q_AAv7Otz%3DCeLyQ%40mail.gmail.com.

[Michael Leone]

C:\Windows\System32>repadmin /replsummary
Replication Summary Start Time: 2026-03-16 12:27:20

Repadmin can't connect to a "home server", because of the following error.  Try specifying a different
home server with /homeserver:[dns name]
Error: An LDAP lookup operation failed with the following error:

    LDAP Error 82(0x52): Local Error
    Server Win32 Error 0(0x0):
    Extended Information:

Source DSA          largest delta    fails/total %%   error

Destination DSA     largest delta    fails/total %%   error

OY. This is from the other DC ...

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BhS6AFsrpEmg6zMwkQHRp5DM9XF6aoSMPaPb876xgN1aQ%40mail.gmail.com.

[Wright, John M]

If it's still not at logon prompt, can it be reached any other way (WinRM, psexec, etc.)? Those methods might not work if this is a secure channel issue but it might be worth trying to see if you can re-enable/restart the kdc service.

--
John Wright
IT Support Specialist

1800 Old Bluegrass Avenue, Louisville, KY 40215
502.708.9953
Please submit IT requests to Hazelwoo...@bluegrass.org
24 Hour Helpline 1.800.928.8000
  

CONFIDENTIALITY NOTICE: This message contains confidential information and is intended only for the individual(s) addressed in the message. If you are not the named addressee, you should not disseminate, distribute, or copy this e-mail. If you are not the intended recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited.

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CA%2BZrOWy9CQD8Us2WzJxxRZgssM2BMzYYkXw6qZ-vef8jw6tgFg%40mail.gmail.com.

[Michael Leone]

On Mon, Mar 16, 2026 at 1:04 PM Wright, John M <John....@newvista.org> wrote:

If it's still not at logon prompt, can it be reached any other way (WinRM, psexec, etc.)?  Those methods might not work if this is a secure channel issue but it might be worth trying to see if you can re-enable/restart the kdc service.

No. PSEXEC VMD did not work.

P:\utils\SysInternals>psexec \\cmd dc2wrk017

PsExec v2.43 - Execute processes remotely
Copyright (C) 2001-2023 Mark Russinovich
Sysinternals - www.sysinternals.com

Couldn't access cmd:
The network path was not found.

Make sure that the default admin$ share is enabled on cmd.

 

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/SN7PR12MB671495D15DDC0391C703AD659140A%40SN7PR12MB6714.namprd12.prod.outlook.com.

[Philip Elder]

Do you have a backup of the FSMO Role holder?

 

With two DCs this one is fairly easy to fix.

 

Start Restore DC0.

Shut down DC1 just as restore is complete.

Log on to DC0.

Verify FSMO Roles

# Check FSMO

Get-ADForest | FT SchemaMaster,DomainNamingMaster

Get-ADDomain | FT PDCEmulator,RIDMaster,InfrastructureMaster

 

If they show anything but DC0 SEIZE THEM:

# Seize FSMO Roles

$DestinationDC = “DC0”

Move-ADDirectoryServerOperationMasterRole -Identity $DestinationDC -OperationMasterRole 0,1,2,3,4 -Force -confirm:$False

Get-ADForest  | Format-Table SchemaMaster,DomainNamingMaster

Get-ADDomain  | Format-Table PDCEmulator,RIDMaster,InfrastructureMaster

 

Verify in the ADDS event logs that everything is happy.

 

Make sure SYSVOL and NETLOGON are presented via UNC.

 

TEST:

\\DC0\ ?

\\Domain.Com\ ?

 

Do you see SYSVOL and NETLOGON?

 

YES?

Perform Metadata Clean-up and remove ALL other DCs found

 

Mount OS install and boot to it for DC1.

Re-install Windows

Re-install ADDS Roles

DCPromo IN

 

Make sure your PDCe is set to time authority and the newly promo’d DC is second to it.

W32Tm.

 

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

MPECS Inc.

E-mail: Phili...@MPECSInc.Ca

Phone: +1 (780) 458-2028

Web: www.MPECSInc.Com

Blog: Blog.MPECSInc.Com  

Twitter: Twitter.com/MPECSInc

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CA%2BZrOWxiJfiknx8N0%2BwNCAcdzh6t6DMRz68hkU7V5vUHQOd8gA%40mail.gmail.com.

[Michael Leone]

Resolved (?)

C:\Windows\System32>repadmin /replsummary /homeserver:dc1wrk016.wrk.ads.pha.phila.gov
Replication Summary Start Time: 2026-03-16 14:45:25

Beginning data collection for replication summary, this may take awhile:
  .......


Source DSA          largest delta    fails/total %%   error

 DC1ADS020                 50m:07s    0 /  10    0
 DC1WRK016                 50m:48s    0 /  10    0
 DC2ADS023                 50m:26s    0 /  10    0
 DC2WRK017                 52m:19s    0 /  10    0

Destination DSA     largest delta    fails/total %%   error

 DC1ADS020                 51m:41s    0 /  10    0
 DC1WRK016                 50m:04s    0 /  10    0
 DC2ADS023                 52m:19s    0 /  10    0
 DC2WRK017                 50m:23s    0 /  10    0

The problem DC was DC2WRK017. That was the one that was hanging, when we set the KDC to DISABLED and rebooted, as the KB said.

My co-worker fixed it like this: (I admit, I didn't think it would work)

It's a VM, so he disconnected the NIC in the hypervisor (Nutanix AHV)

Rebooted the DC into Safe Mode (I didn't even know you *could* reboot a DC into Safe Mode!)

Re-enabled the KDC service

Re-enabled the NIC in the hypervisor

Rebooted

Went to lunch for an hour, and when we came back, it had fully replicated ...

WHY? Don't ask me, I have trouble spelling AD some days ...

But it *looks* like all my errors went away (for today ..)

Tomorrow I will try rebooting the other DC (DC1WRK016), that one had never given us issues today.

So I am ... good? ... for now ...

C:\Windows\System32>netdom query fsmo
Schema master               DC1ADS020.ads.pha.phila.gov
Domain naming master        DC1ADS020.ads.pha.phila.gov
PDC                         DC1WRK016.wrk.ads.pha.phila.gov
RID pool manager            DC1WRK016.wrk.ads.pha.phila.gov
Infrastructure master       DC1WRK016.wrk.ads.pha.phila.gov
The command completed successfully.

That is all correct, we have a parent domain above us, hence the different schema and domain naming master names,

Thanks everybody. I didn't even want to think about trying Philip's restore sequence ... goodness knows how bad that might have happened,

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/e3a0603553274a0eac7fe924c0c176c1%40MPECSInc.Ca.

[Henry Awad]

I have used Philip's restore process a few times in the past. As long as all your domain controllers are also global catalog, then you can seize FSMO roles from the main holder and restore them on any of the GCs. Metadata cleanup is not very complicated but you have to be thorough in the cleanup process before rebuilding the failed DC and promoting it back to a DC.

Hopefully your problem is solved for good.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CA%2BZrOWx-pfmKTJCzh6bUiyJyjLnd0vB6V4COQbgygEJ1H_bC5g%40mail.gmail.com.

[Philip Elder]

Directory Services Restore Mode = DC Safe Mode.

 

Make sure the DSRM password is a known commodity which it seems to be in this case.

 

Would I have done that?

 

Probably not.

 

I’d rather start with a now known good FSMO Role holder, best practice is to _always_ have them all on one DC, after seizing and verifying they are there and the SYSVOL and NETLOGON shows up as they should.

 

BURFLAGS is really easy too in a DFS-R situation. All DCs in the domain are available in ADSIEdit.

 

Oh, and _check your _msdcs stub zone NS records_ to make sure they are current!!!

 

DNS à Domain.Com à _msdcs

 

It’s the little grey guy. If it ain’t grey you’re AD ain’t healthy.

 

If it is grey but NS records are out of date you’re AD ain’t healthy.

 

It’s always the little things that make the big guys puke.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CA%2BZrOWx-pfmKTJCzh6bUiyJyjLnd0vB6V4COQbgygEJ1H_bC5g%40mail.gmail.com.

[Mike Leone]

On Mon, Mar 16, 2026 at 3:29 PM Philip Elder <Phili...@mpecsinc.ca> wrote:

Directory Services Restore Mode = DC Safe Mode.

 

Make sure the DSRM password is a known commodity which it seems to be in this case.

 

Would I have done that?

 

Probably not.

 

I’d rather start with a now known good FSMO Role holder, best practice is to _always_ have them all on one DC, after seizing and verifying they are there and the SYSVOL and NETLOGON shows up as they should.

They are.

C:\Windows\System32>netdom query fsmo
Schema master               DC1ADS020.ads.pha.phila.gov
Domain naming master        DC1ADS020.ads.pha.phila.gov
PDC                         DC1WRK016.wrk.ads.pha.phila.gov
RID pool manager            DC1WRK016.wrk.ads.pha.phila.gov
Infrastructure master       DC1WRK016.wrk.ads.pha.phila.gov
The command completed successfully.

 

 

BURFLAGS is really easy too in a DFS-R situation. All DCs in the domain are available in ADSIEdit.

 

Oh, and _check your _msdcs stub zone NS records_ to make sure they are current!!!

They are. I only see the DCs I expect to see.

 

 

DNS à Domain.Com à _msdcs

 

It’s the little grey guy. If it ain’t grey you’re AD ain’t healthy.

 

If it is grey but NS records are out of date you’re AD ain’t healthy.

 

It’s always the little things that make the big guys puke.

Ain't it the truth ...

All this started last Friday (the 13th ...), when we had network connectivity issues between our 2 sites. (when you can't ping by IP address, [and you could before] you have connectivity issues. If you can't ping by DNS name, you *may* just have stale DNS records). That was eventually resolved by my networjk team, but while I was troubleshooting, I saw that this problem DC has reversed DNS (it pointed to itself as primary, and the other site as secondary). I made it point to the other site as primary, and itself as secondary, and rebooted it. 

My connectivity issues *seemed* to disappear at the same time (but changing a DNS server setting would have no impact at all on a ping failing, but I digress ...). I think that was probably coincidence, but what do I know ....

Then today we saw all those other problems ....

[Philip Elder]

I see two different DCs holding FSMO Roles?

 

 

They should all be on the PDCe.

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

MPECS Inc.

E-mail: Phili...@MPECSInc.Ca

Phone: +1 (780) 458-2028

Web: www.MPECSInc.Com

Blog: Blog.MPECSInc.Com  

Twitter: Twitter.com/MPECSInc

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

 

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mike Leone
Sent: Monday, March 16, 2026 14:17
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] DC replication - target principal name is incorrect??

 

 

 

On Mon, Mar 16, 2026 at 3:29 PM Philip Elder <Phili...@mpecsinc.ca> wrote:

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BhPEGsVTGiY19%2BSNqSDr78jPj2%2BbpLog7BnrsvYUkH_eg%40mail.gmail.com.

[Mike Leone]

No, we use a root/ sub-domain structure. The first 2 DCs are in the root domain.

     

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/750e1ecc08af44e384ace8a834713cb4%40MPECSInc.Ca.

[Michael Leone]

RESOLVED (?)

C:\Windows\System32>repadmin /replsummary /homeserver:dc1wrk016.wrk.ads.pha.phila.gov

Replication Summary Start Time: 2026-03-16 14:40:53

Beginning data collection for replication summary, this may take awhile:
  .......


Source DSA          largest delta    fails/total %%   error

 DC1ADS020                 45m:35s    0 /  10    0
 DC1WRK016                 46m:16s    0 /  10    0
 DC2ADS023                 45m:54s    0 /  10    0
 DC2WRK017                 47m:47s    0 /  10    0

Destination DSA     largest delta    fails/total %%   error

 DC1ADS020                 47m:09s    0 /  10    0
 DC1WRK016                 45m:31s    0 /  10    0
 DC2ADS023                 47m:46s    0 /  10    0
 DC2WRK017                 45m:50s    0 /  10    0

On Mon, Mar 16, 2026 at 12:22 PM 'Henry Awad' via ntsysadmin <ntsys...@googlegroups.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAGaCHK764sR8K18xUwv-i4pYY85cCeXMFsTB2yOkRknbLqS5ig%40mail.gmail.com.