The target principal name is incorrect:

Active Directory Domain Controller

Replication Issue
On: Feb 14Author: Neil BryanCategories: Microsoft 8 Comments
During an Active Directory domain controller upgrade from Windows 2003 to Windows 2012
R2 I observed replication issues on the Domain Controller which also owned the PDC emulator
role.
A problem logging onto the domain controller is what initially triggered the investigation into
potential issues. It is always a good idea to ensure replication and event logs are healthy before
performing Active Directory changes and upgrades for situations like this.

Identifying the Error

repadmin /replsummary showed the following error:
Source DSA largest delta fails/total %% error
DC-01 15m:05s 0 / 10 0
DC-02 41m:15s 0 / 10 0
DC-03 06d.05h:43m:01s 4 / 10 40 (2148074274) The target principal name is
incorrect.

You can see DC-01 and DC-02 are fine but DC-03 has replication errors and shows the error
message"The target principal name is incorrect."
Resetting the domain controllers computer account using the following steps resolved the
replication issues.

Fixing the Issue

Step 1
Identify the DC which owns the PDC role:
netdom query fsmo

Step 2
On the domain controller, disable the Kerberos Key Distribution Center service (KDC).
Click Start, point to Programs, click Administrative Tools, and then click
Services.
Double-click KDC, set the startup type to Disabled, and then restart the
computer.

(Restarting is required or else you will get an error on the next step)

Step 3
Login to the DC again and run the following command to reset the computer account.
netdom resetpwd /server:server_name /userd:domain_name\administrator
/passwordd:administrator_password

(This can not be done in Active Directory Users and Computers for Domain Controllers.)

Step 4

Set the KDC service to "Automatic" again and restart the server again.

Step 5
Run the following commands to ensure there are no replication issues.
repadmin /syncall
repadmin /replsummary

A clean replication summary looks like this:

Source DSA largest delta fails/total %% error
DC-01 13m:10s 0 / 10 0
DC-02 15m:05s 0 / 10 0
DC-03 15m:05s 0 / 10 0

The target principal name is incorrect

Error during manual AD replication
During a manually initiated Active Directory replication at a customer, I repeatedly got the
following error message
The target principal name is incorrect. It was always the same domain controller in use for the
replication.
The reason for the message was, that a VPN connection between the headquarters and a branch
office was disconnected for several weeks. This is why a secure channel between the domain
controller between the branch and the headquarters did not exist any longer.
Rebuilding the secure channels fixed the error:

Troubleshooting The target principal name is incorrect

Solving the problem on the domain controller step-by-step:
1. Deactivate the service Key Distribution Center
2. Restart Domain Controller
3. Start a command-box as administrator and enter the following command:
netdom resetpwd /Server:dc-mit-pdc-Emulator-Rolle
/userd:Domain\Administrator /passwordd:password

4. Restart Domain Controller

5. Reset the service Key Distribution Center to automatic start and start
Source: Microsoft

The target principal name is incorrect | DC

Stops Replicating Pt. 3
This article is the final installment of our three part series. We will be continuing from our
previous article: [WARNING] Failed to query SPN registration on DC | Domain Controller
Stops Replicating Pt. 2. Our previous efforts have brought us even closer to resolving the
replication issues on our Los Angeles Domain Controller, however more work awaits us in this
AD Replication saga.
We will now continue and troubleshoot the error: The target principal name is incorrect which
is detected when running netdom /query fsmo
Issue: The target principal name is incorrect

Resolution
issue command: netdom reset DOMAINCONTROLLERNAME (in my case STAR)
Open a run-as administrator command prompt and enter the following command:
netdom reset DOMAINCONTROLLERNAME
Crashed on Audit Fail resolution for condition: CrashOnAuditFail=2
(http://support.microsoft.com/kb/2002013)
AD Replication fails when HKLMSystemCurrentControlSetControlLSACrashOnAuditFail = has
a value of 2,
A CrashOnAduitFail value of 2 is triggered when the Audit: Shut down system immediately if
unable to log security audits setting in Group Policy has been enabled AND the local security
event log becomes full.
Active Directory domain controllers are especially prone to maximum capacity security logs
when auditing has been enabled AND the size of the security event log has been constrained by
the Do not overwrite events (clear log manually) or Overwrite as needed options in Event
Viewer or group policy equivalents.
User Action if HKLMSystemCCSControlLSACrashOnAuditFail = 2:
Clear the security event log (save to alternate location as required)
Re-evalaute any size constraints on the security event log, including policy based settings.
Recreate CrashOnAuditFail (REG_DWORD) = 1
Reboot
On seeing a CrashOnAuditFail value of 0 or 1, some CSS engineers have resolved access is
denied errors by again clearing the security event log, deleting the CrashOnAuditFail registry
value and rebooting the destination DC.
Followed Excessive Time Skew Steps from same article:

C:>DCDIAG /TEST:CheckSecurityError
AND
C:>W32TM /MONITOR
Ensure Trust computer for delegation is enabled:
(based on the steps in green from: http://social.technet.microsoft.com/Forums/enUS/winserverDS/thread/e9c162cb-1e26-43e0-80df-73c491c22aac/)
Ensure the Trust computer for delegation check box is selected on the General tab of the domain
controller Properties dialog box in Active Directory Users and Computers.
Confirm that the userAccountControl attribute is set to 532480:
Using Adsiedit or Ldp (both included in the Windows 2000 Support Tools), confirm that the
userAccountControl attribute is set to 532480. To check this, perform the following steps
Type adsiedit.msc from Start, and then click Run.
Expand the Domain NC container.
Expand the object below, i.e. DC=Contoso, DC=COM
Expand OU=Domain Controllers
Right-click CN=<domain_controller>, and select Properties
Under Select a property to view, select userAccountControl and verify the value is 532480
Note:
Check this value for each failing DC account on the local copy of AD for every partner DC. For
example if DC-A and DC-B are failing replication, check the above on DC-As copy of AD and
DC-Bs copy of AD.
Reset Password and Refresh Kerberos Tickets:
1. Stop the Key Distribution Center (KDC) service on Server all Domain controller expect PDC
role holder server. To do so, open
a Command Prompt, type net stop KDC, and press Enter.
2. Load Kerbtray.exe on problem DC in you case it is STAR. You can do so by clicking Start,
clicking Run, and
then typing c:program filesresource kitkerbtray.exe and pressing Enter.You should see a little
green ticket icon in your system tray in the lower right corner of your desktop.
3. Purge the ticket cache on STAR, right-click the green ticket icon in your system tray, and then
click Purge Tickets. You should receive a confirmation that your ticket cache was purged. Click
OK.
4. Reset the Server domain controller account password on Server (the PDC
emulator).
To do so, open a command prompt and type: netdom /resetpwd /server:server2
/userd:domain.comadministrator /passwordd:password, and then press Enter.
5. Synchronize the domain. To do so, open a command prompt, type repadmin
/syncall, and then press Enter.
6. Start the KDC service on STAR and all other DC. To do so, open a command prompt, typenet
start KDC, and press Enter. This completes the process.
Alright! at this point the issue was finally resolved, what a quest. Through the process I refined
an excellent procedure for fixing this type of issue in the future.

[WARNING] Failed to query SPN

registration on DC | Domain Controller
Stops Replicating Pt. 2
This article is our second part of our three part series, continuing where we left off in our last
article: Domain Controller no longer replicating Pt. 1 Replication has been explicitly
disabled. Our previous steps have brought us closer to resolving the replication issues on
our Los Angeles Domain Controller, however issues still remain.
Now I will walk you through tackling:
DCDIAG / NETDIAG shows Time Service is stopped and Netlogon service is paused
[WARNING] Failed to query SPN registration on DC
Issue: We discovered a stopped Time service and a paused Netlogon service on the troubled
Los Angeles DC:

Starting test: Services

w32time Service is stopped on [STAR]
NETLOGON Service is paused on [STAR]
Resolution: Using services.msc, I took the Netlogon service off of pause and started the Time
Service.
Issue: [WARNING] Failed to query SPN registration on DC
After further investigation in DNS, I found that the PTR record is wrong for the Los Angeles
Domain Controller:

I also found the new DC has same IP as old DC and old DC never removed from Name Servers:

Verified Access this computer from the network rights, per MS

Article http://support.microsoft.com/kb/2002013 by running:
DCDAIG /TEST:CheckSecurityError

Now onto our third installment in this series: The target principal name is incorrect | DC Stops
Replicating Pt. 3
Domain Controller no longer replicating Pt. 1 Replication has been explicitly
disabled

Issue: Domain Controller in Los Angeles site hasnt replicated for over a
month
The first step is to run DCDIAG from the command prompt (right click run as administrator).
Amongst other errors DCDIAG reveals that Inbound and Outbound Replication is Disabled:

Testing server: LosAngeles\STAR

Starting test: Replications
[Replications Check,STAR] Inbound replication is disabled.
To correct, run repadmin /options STAR -DISABLE_INBOUND_REPL
[Replications Check,STAR] Outbound replication is disabled.
To correct, run repadmin /options STAR -DISABLE_OUTBOUND_REPL
. STAR failed test Replications
Replication explicitly disabled DCDIAG error:

[Replications Check,MOON] A recent replication attempt failed:

From STAR to MOON
Naming Context: CN=Schema,CN=Configuration,DC=contoso,DC=com
The replication generated an error (8456):
The source server is currently rejecting replication requests.
The failure occurred at 2012-11-28 12:49:37.
The last success occurred at 2012-10-10 02:49:53.
4748 failures have occurred since the last success.
Replication has been explicitly disabled through the server options.
Resolution: Enable inbound and outbound replication
(per Microsoft: http://technet.microsoft.com/en-us/library/cc783692(v=ws.10).aspx)
1. Open a Command Prompt.

2. Type the following command, and then press ENTER (where SERVERNAME is
the computer name of the Domain Controller):
repadmin /options SERVERNAME -DISABLE_INBOUND_REPL
3. Verify the new replication option, the following message should appear:
Current DC options: DISABLE_INBOUND_REPL
New DC Options: <none>
4. Type the following command, and then press ENTER:
repadmin /options SERVERNAME -DISABLE_OUTBOUND_REPL
5. Verify the new replication option, the following message should appear:
Current DC options: DISABLE_OUTBOUND_REPL
New DC Options: <none>

Here is an example, notice Current DC Options shows the conditions that were in effect at the
time that you ran the command. New DC Options shows the effect of the command, see how the
Disable Replication Option is not set:

repadmin /options STAR -DISABLE_INBOUND_REPL

Current DC Options: IS_GC DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
New DC Options: IS_GC DISABLE_OUTBOUND_REPL
repadmin /options STAR -DISABLE_OUTBOUND_REPL
Current DC Options: IS_GC DISABLE_OUTBOUND_REPL
New DC Options: IS_GC
The output shows that DISABLE_OUTBOUND_REPL and DISABLE_INBOUND_REPL
have been cleared and only IS_GC remains, indicating this DC is a global catalog server.
In conclusion, the Replication has been explicitly disabled through the server options
error has now been resolved. However in my case, replication was still not working because
there were additional issues. Continued in part two in this series: Domain Controller Stops
Replicating Pt. 2 [WARNING] Failed to query SPN registration on DC
Error Message "Target Principal Name is Incorrect" When Manually Replicating Data
Between Domain Controllers

Email
Print

Notice
This article applies to Windows 2000. Support for Windows 2000 ends on July 13,
2010. The Windows 2000 End-of-Support Solution Center is a starting point for
planning your migration strategy from Windows 2000. For more information see the
Microsoft Support Lifecycle Policy.

Symptoms
When you use the Active Directory Sites and Services snap-in to manually replicate
data between Windows 2000 domain controllers, you may receive one of the
following error messages:
The Target Principal Name is incorrect
-orAccess is denied
In addition, the following event ID messages may be logged in the system log:
Event Source: Netlogon
Event Category: None Event ID: 3210
User: N/A Event Description:
Failed to authenticate with \\DOMAINDC, a Windows NT domain controller fordomain
DOMAIN.
-andEvent Source: Netlogon
Event ID: 5722
Event Category: None User: N/A Event Description:
The session setup from the computer 1 failed to authenticate. The name of the
account referenced in the security database is 2. The following error occurred: n3
Resolution
To resolve this issue, first determine which domain controller is the current primary
domain controller (PDC) Emulator operations master role holder. To do this, use
either of the following methods:
Install the Netdom.exe utility from Windows 2000 Support Tools, and then run
the following command:
netdom query fsmo
Start the Active Directory Users and Computers snap-in, right-click the
domain, and then click Operations Masters. Click the PDC tab; the current role
holder is displayed in the Operations Master window. On this tab, you can
change the operations master role to the current computer in the second
window (if this computer is not the current holder).
Use the Ntdsutil.exe utility (that is included in Windows 2000), and the
Resource Kit command-line utility. However, these interfaces are
recommended for more advanced users.
For additional information, click the article number below to view the article in the
Microsoft Knowledge Base:
234790 How to Find FSMO Role Holders

On domain controllers that are experiencing this issue, disable the Kerberos Key
Distribution Center service (KDC). To do so:

1. Click Start, point to Programs, click Administrative Tools, and then click
Services.
2. Double-click KDC, set the startup type to Disabled, and then restart the
computer.
After the computer restarts, use the Netdom utility to reset the secure channels
between these domain controllers and the PDC Emulator operations master role
holder. To do so, run the following command from the domain controllers other than
the PDC Emulator operations master role holder:
netdom resetpwd /server:server_name /userd:domain_name\administrator
/passwordd:administrator_password
Where server_name is the name of the server that is the PDC Emulator operations
master role holder.
For additional information, click the article number below to view the article in the
Microsoft Knowledge Base:
260575 How to Use Netdom.exe to Reset Machine Account Passwords
After you reset the secure channel, restart the domain controllers. Even if you
attempt to reset the secure channel using the Netdom utility, and the command
does not complete successfully, proceed with the restart process.
If only the PDC Emulator operations master role holder is running, the KDC forces
the other domain controllers to resynchronize with this computer, instead of issuing
themselves a new Kerberos ticket.
After the computers have finished restarting, start the Services program, restart the
KDC service, and then attempt replication again.