Fix AD Replication Error 0x000020FB: Inconsistent DIT Database

When You'll See This Error

You try to replicate between two domain controllers, and you get hit with error 0x000020FB. The exact message says "The replication operation encountered a database inconsistency." This usually shows up in the Directory Services event log with Event ID 1988 or 1655. I've seen this after a disk ran out of space mid-write, after a dirty shutdown, or when a virus scanner locked the ntds.dit file during a write operation.

What's Actually Going On

The Active Directory database (ntds.dit) stores all your objects - users, computers, groups, trusts. This database is actually a Jet Blue engine database, same engine used by Exchange. When it gets corrupted, replication can't read or write data consistently. The corruption could be in a single page (4KB block) or across multiple pages. The server might still boot and answer LDAP queries for a while, but replication will fail.

The Fix: Step by Step

Skip the temptation to demote and re-promote the server. That's the nuclear option. Start with these steps first - they work 90% of the time.

Step 1: Identify the Corrupted DC

1. Open Command Prompt as Administrator on the DC that reports the error.
2. Run this command to check replication status:
   

   repadmin /showrepl

   Look for "Last Failure Status" = 8456 (which is 0x000020FB). Note which source DC and naming context failed.
3. Now run a more detailed check on the database itself:
   

   ntdsutil
   database integrity

   After typing "database integrity", press Enter. It will check the entire ntds.dit file. This can take 5-30 minutes depending on DB size. Expect to see messages like "Checking database integrity..." and eventually a summary. If it says "integrity check complete with errors", your DB has corruption.

Expected outcome: You'll know exactly which DC has the bad database and whether the corruption is minor or major.

Step 2: Repair the Database (If Integrity Check Failed)

1. From the same ntdsutil prompt, run:
   

   ntdsutil
   files
   info

   This shows where ntds.dit lives. Default location: C:\Windows\NTDS\ntds.dit. Note the path.
2. Type quit twice to exit ntdsutil.
3. Now run a repair. This is the actual fix for 0x000020FB:
   

   ntdsutil
   semantic database analysis
   verbose on
   go fixup

   This command runs a semantic check and repair. It fixes reference counts, orphaned objects, and link table issues. The "go fixup" part does the actual repair.
4. After it finishes (usually 5-15 minutes), run the integrity check again:
   

   ntdsutil
   database integrity

   Now you should see "integrity check complete, no errors" at the end.
5. Exit ntdsutil by typing quit twice.

Expected outcome: The database should now pass integrity and semantic checks. Replication may resume automatically.

Step 3: Force Replication

1. On the same DC, run:
   

   repadmin /syncall /AdeP

   The /A flag includes all partitions. The /d flag waits for completion. The /e flag includes cross-site connections. The /P flag pushes changes instead of pulling.
2. Watch the output. You should see "SyncAll Completed" with no errors. If you still see 0x000020FB, go to Step 4.

Expected outcome: Replication should succeed now. Check event log for Event ID 1126 (successful replication).

Step 4: Restore from Backup (If Repair Doesn't Help)

1. If the database is too corrupted for repair, you need a backup. Boot into Directory Services Restore Mode (DSRM). To do that:
   
   • Restart the server.
   • Press F8 during boot.
   • Select "Directory Services Restore Mode".
2. Log in with the DSRM administrator account (not the domain admin).
3. Open Windows Backup or use wbadmin. Restore the system state from a backup taken before the corruption.
4. After restore, reboot normally. The DC will replicate from its partners.

Expected outcome: The ntds.dit file is replaced with a clean copy. Replication should work immediately after boot.

What to Check If It Still Fails

If you've done all this and error 0x000020FB comes back, you've got a deeper problem. Here's what I'd look at:

• Disk health: Run chkdsk C: /f on the drive hosting ntds.dit. Bad sectors can corrupt the database repeatedly.
• Antivirus exclusions: Make sure your AV is not scanning the NTDS folder. Add C:\Windows\NTDS to the exclusion list. I've seen McAfee and Symantec lock files mid-write, causing corruption.
• RAM issues: Run Windows Memory Diagnostic. Faulty RAM can silently corrupt data during writes.
• Last resort: Demote the DC using dcpromo /forceremoval, then promote it fresh. This clears the problem but costs you time and network traffic.

Most of the time, the repair in Step 2 fixes 0x000020FB. Don't jump to demotion unless you have to.