Active Directory Replication Errors

I have a multi-site, single domain environment with 16 DCs.  I have a hub site with 4 DCs.  I have 12 branch office environments, each with 1 DC.  All DCs are GCs and DNS servers.  All branch offices are setup identically, with a hub and spoke replication topology.  I recently discovered that users at one of my branch offices were not getting GPO updates.  A few days later, when trying to update my schema for an upcoming Exchange 2013 SP1 migration, I discovered that the replication to the troublesome site is somehow broken.  I've attached a dcdiag report.  Any ideas on where to start?  When forcing replication in the RSAT Sites and Services console, I received the "Target Principal Name is Incorrect" message.  I followed the procedures in this article (  I no longer have any errors that appear in the GUI, but replication is obviously still not happening, as my branch office server still has not updated the schema from my hub DCs.  Any ideas where to begin? 
Side Note:  I checked out the solution mentioned in this article, as my dcdiag reported the MachineAccount test failed with a similar value of not requiring a password.  I'm not convinced this is the culprit, however, as all of my other functioning DCs have the same value.
Who is Participating?
This is a document I wrote many years ago on repairing AD corruption.

Repairing Active Directory Corruption

When many people think of corruption, they tend to think of individual files being unreadable or invalid. As with just about any other type of file, the Active Directory files are prone to this type of corruption, as well as some other problems that I’ll talk about later. If you've ever worked with Exchange, you’re probably familiar with the ESEUTIL tool. The NTDS utility is, for the most part, a frontend to the ESEUTIL.

Prior to starting this process – I usually create a backup of the entire c:\windows\ntds\*.* directory, in the off chance you run into any problems.  I’ll create a directory structure of c:\temp\1\, c:\temp\2\, etc. then copy all the files from the NDTS directory into the c:\temp\n\ directory after each step is completed.


Before you can use the Integrity command, you must be in Active Directory Restore Mode, at the command prompt.
ntdsutil: files
file maintenance: integrity
Opening database [Current].
Executing Command: C:\WINDOWS\system32\esentutl.exe /g "C:\WINDOWS\NTDS\ntds.dit" /10240 /8 /v /x /o
Initiating INTEGRITY mode...
        Database: C:\WINDOWS\NTDS\ntds.dit
  Temp. Database: INTEG.EDB
got 16043 buffers
checking database header
checking database integrity
                    Scanning Status  ( % complete )
          0    10   20   30   40   50   60   70   80   90  100
                checking SystemRoot
                SystemRoot (OE)
                SystemRoot (AE)
        checking system table
.               Name
                rebuilding and comparing indexes
        checking table "datatable" (6)
                checking index "NC_Acc_Type_Sid" (8)
                checking index "INDEX_00090092" (7)
                rebuilding and comparing indexes
        checking table "sdproptable" (17)
                checking data
integrity check completed.
Operation completed successfully in 30.994 seconds.
Spawned Process Exit code 0x0(0)
If integrity was successful, it is recommended
you run semantic database analysis to insure
semantic database consistency as well.
file maintenance:

Open in new window


You might have noticed at the end of the Integrity operation, the utility suggested that I run semantic database analysis in order to insure integrity. While the Integrity operation tested the integrity of the files themselves, running a semantic database analysis checks the integrity of the contents of the Active Directory database by comparing the database’s contents to the log files.
When you run a semantic database analysis, there are several things that the process looks for. First, the process runs a reference count check. The utility counts all of the references in the link table and the data table and makes sure that the actual counts match the listed counts. The process also makes sure that every object in the Active Directory has a GUID, a distinguished name, and a non zero reference count. If an object was supposed to have been deleted, the process verifies that the object has a date and time stamp for the deletion, and that it doesn't have a distinguished name or a GUID.
The semantic database analysis looks for other things in the database as well. For example, the process checks objects for valid security descriptors and makes sure that the access control lists aren't empty.
As you can see, running the semantic database analysis is an important part of getting your Active Directory back up to par. As with the file integrity test, the Symantec database integrity check can take a while to run. When the process completes, any errors that occur are written to a log file called DSDIT.DMP.xx.
To run the semantic database analysis, you must be in Directory Service Restore Mode. Once again, open a command prompt window and enter the NTDSSUTIL command. When you do, you’ll see the NTDSUTIL prompt. Now, enter SEMANTIC DATABASE ANALYSIS command. When you do, you’ll see the prompt change to SYMANTIC CHECKER. Enter the command VERBOSE ON. This will allow you to see what’s going on. Finally, enter the GO command to start the process. You can see an abbreviated sample output below:
ntdsutil: semantic database analysis
semantic checker: verbose on
Verbose mode enabled.
semantic checker: go fixup
Fixup mode is turned off
Opening database [Current].....Done.
Getting record count...7397 records
Writing summary into log file dsdit.dmp.0
Records scanned:       7300
Processing records..Done.

Open in new window


Sometimes when an Active Directory isn't working correctly, it’s best to just start with a new database. As you may know, databases become fragmented and need to be defragmented, just like hard drives. Windows actually performs what’s known as an online Defragmentation every 12 hours as a part of the trash collection process. However, when Windows does an online database Defragmentation, it merely optimizes the database, it never reduces the databases size. However, you can do what’s known as an offline Defragmentation. An offline Defragmentation actually creates a brand new database and copies all of the Active Directory records to it. During the process, fragmentation and empty space are removed. The end result is a clean and compact database.

To defragment an Active Directory, boot the system into Directory Service Restore Mode. When Windows boots, open a command prompt window and enter the NTDSUTIL command. Now, find the location of the database files by entering the FILES and INFO commands that I showed you in Part 1. Once you know the location of your databases, enter the command COMPACT TO drive:directory. You’ll have to compact the database to a different location than where the current database exists at. You can see a sample of this process below:

ntdsutil: files
file maintenance: info
Drive Information:
        C:\ NTFS (Fixed Drive  ) free(5.4 Gb) total(7.8 Gb)
        F:\ NTFS (Fixed Drive  ) free(13.2 Mb) total(15.6 Mb)
        Q:\ NTFS (Network Drive) free(60.4 Gb) total(63.5 Gb)
DS Path Information:
        Database   : C:\WINDOWS\NTDS\ntds.dit - 26.1 Mb
        Backup dir : C:\WINDOWS\NTDS\dsadata.bak
        Working dir: C:\WINDOWS\NTDS
        Log dir    : C:\WINDOWS\NTDS - 50.0 Mb total
                        res2.log - 10.0 Mb
                        res1.log - 10.0 Mb
                        REPAIR.TXT - 0.0 Kb
                        edb00003.log - 10.0 Mb
                        edb00002.log - 10.0 Mb
                        edb.log - 10.0 Mb
file maintenance: compact to c:\temp\
Opening database [Current].
Using Temporary Path: c:\temp\
Executing Command: C:\Windows\system32\esentutl.exe /d "C:\WINDOWS\NTDS\ntds.dit" /8
 /o /l"C:\WINDOWS\NTDS" /s"C:\WINDOWS\NTDS" /t"c:temp\4\ntds.dit" /!10240 /p
Initiating DEFRAGMENTATION mode...
        Database: C:\WINDOWS\NTDS\ntds.dit
       Log files: C:\WINDOWS\NTDS
    System files: C:\WINDOWS\NTDS
  Temp. Database: c:\temp\ntds.dit
                Defragmentation Status  ( % complete )
          0    10   20   30   40   50   60   70   80   90  100
Spawned Process Exit code 0xfffff8f0

If compaction was successful you need to:
copy "c:\temp\ntds.dit" to "C:\WINDOWS\NTDS\ntds.dit"
and delete the old log files:
del C:\WINDOWS\NTDS\*.log
file maintenance: 

Open in new window

When the process completes, rename your original Active Directory database file, and move the newly created database file to the directory where the original file existed. Once you've booted Windows and confirmed that everything worked successfully, you can erase the renamed original database file.


If you still haven’t been able to repair your Active Directory, and restoring a backup isn't an option, there’s one last thing that you can try. You can attempt a binary level repair. This process works by deleting anything that it doesn't understand. When you run this process, you’ll almost always lose some amount of data. Therefore, don’t run this process unless you don’t have any other options left.

To repair the database, boot Windows into Directory Services Restore Mode. When Windows boots, open a command prompt window and enter the NTDSUTIL command. At the NTDSUTIL prompt, enter the FILES command, and you’ll see the FILE MAINTENANCE prompt. Now, enter the REPAIR command and start praying.
marrjAuthor Commented:
It looks to me that the ntds.dit database is corrupt.  I've researched the 8451 errors and always seem to get directed to this site. .
David Johnson, CD, MVPOwnerCommented:
What jumped out to me was the schema mismatch

If the issue persist, please try to run Repadmin /showobjmeta *
then perform Forced replication

Additional Reading
marrjAuthor Commented:
The problem persists.  I tried the schema replication with no success.  The error I get with any replication is "The target principal name is incorrect".

I'm fairly confident in saying that the schema mismatch is due to my recent extension for Exchange that I performed before I realized what the issue was with this DC.

I tried a graceful demotion of the DC with no success.  It is complaining about the target principal name being incorrect with any other DC, just as when I try to force replication.

I've tried clearing the KDC tickets and resetting the password several times now.

I guess I'm looking at trying a forceful demotion/re-promotion next.  I really need to keep the same hostname/IP combo on this server, so I will be performing the metadata cleanup.  Any words of wisdom regarding this process?  I've done many forceful demotions before, but I've never tried to reuse the hostname.  I've heard it's possible with a metadata cleanup.  I hope it really works.
marrjAuthor Commented:
Thanks, guys.  I ended up doing a dcpromo /forceremoval and cleaning up the metadata.  A normal dcpromo came up with the name mismatch error.

I was then able to re-promote the DC under the same name.  All is well.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.