Fix AD Replication Error 0x000020FB: Database Inconsistency

This error means Active Directory's database has internal corruption. You'll see it during replication between domain controllers. Here's how to fix it

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

Open Command Prompt as Administrator on the DC that reports the error.
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.
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)

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.
Type quit twice to exit ntdsutil.
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.
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.
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

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.
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)

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".
Log in with the DSRM administrator account (not the domain admin).
Open Windows Backup or use wbadmin. Restore the system state from a backup taken before the corruption.
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.