Fix Error 0x00002103: Active Directory Database Replication

Quick Answer

Run ntdsutil and choose 'repair' on the database. But first, stop the NTDS service, check disk space, and make sure no backup is running. If the database is corrupted bad enough, you'll demote the DC.

What's Going On?

Error 0x00002103 shows up in the Directory Services log or as a replication status. The full message is ERROR_DS_DRA_DB_ERROR – 'The replication operation encountered a database error.' This happens when your local Active Directory database (NTDS.dit) has a structural problem. The database engine (Extensible Storage Engine, or ESENT) can't complete a transaction or read a page. That kills replication cold.

Real-world trigger: A power loss on the domain controller while it was writing a replication change. Or a disk that filled up 100% during a sync. I've also seen this after a failed Windows Update that interrupted the database service. Don't ignore it – left alone, the DC becomes a brick.

Fix Steps

These steps assume you're on a Windows Server 2012 R2 through 2022. Run everything as Domain Admin. Do them in order.

Open an elevated command prompt. Right-click Command Prompt, choose 'Run as administrator.' Confirm the UAC prompt.
Stop the Active Directory Domain Services service. Type:
```
net stop ntds
```
You'll see 'The Active Directory Domain Services service is stopping...' then 'stopped.' Wait for that message. If it fails, check if another process holds the database file – like a backup tool. Force it using taskkill /f /im lsass.exe? No, don't. That crashes the server. Instead, find the blocker:
```
tasklist /m ntdsa.dll
```
That shows processes using the AD library. Usually it's only lsass.exe. If you see something else (like wbadmin.exe), kill that process gracefully.
Check disk space on the drive holding NTDS.dit. That's usually C:\Windows\NTDS. Open File Explorer, right-click the drive, Properties. You need at least 20% free space for the repair. If you're tight, move some logs or expand the volume.
Run a database repair using ntdsutil. In the same command prompt:
```
ntdsutil

activate instance ntds

files

repair
```
After you type 'repair,' hit Enter. The tool scans the database and fixes corrupted pages. This can take 5-30 minutes depending on DB size. You'll see progress lines like 'Scanning extent X of Y' and then 'Repair completed.' If it tells you 'Operation completed successfully,' you're in good shape.
Run an integrity check. Still inside ntdsutil, at the 'file maintenance' prompt:
```
integrity
```
This checks the logical consistency of the database. Takes another 10-20 minutes. Expect to see 'Integrity check completed.' If it throws errors, the repair didn't fix everything – you'll need to demote.
Quit ntdsutil. Type quit twice to return to the command prompt.
Start the AD service.
```
net start ntds
```
You should see 'The Active Directory Domain Services service is starting...' then 'started.'
Test replication. Open an admin PowerShell or command prompt:
```
repadmin /replsum
```
Look for any entries showing 'fail' next to the repaired DC. If all green, you're done. If the error persists, move to alternative fixes.

Alternative Fixes If That Didn't Work

Sometimes the repair fails because corruption is too deep. Here's the backup plan:

Check for disk errors. Run chkdsk c: /f and reboot. Bad sectors on the drive can mimic database corruption. After the reboot, retry steps 2-4.
Restore from a recent system state backup on that DC. If you have a backup from within 60 days (the AD tombstone lifetime), restore the system state. Use Windows Server Backup or whatever tool you have. After restore, the database should be clean and replication should resume.
Demote and re-promote the DC. This is the nuclear option but it's reliable. Open Server Manager, remove the Active Directory Domain Services role. The server becomes a member server. Then re-add the role and promote it back. Make sure DNS is configured correctly on the other DCs before demotion – otherwise the other DCs lose a name server.

One more thing: Check if your antivirus is scanning the NTDS folder. I've seen real-time scanning lock NTDS.dit and cause this exact error. Add an exclusion for C:\Windows\NTDS in your AV policy.

Preventing This From Happening Again

Put NTDS.dit on a different volume than the OS. Use a dedicated drive for the database and logs. If the OS drive gets full, AD won't crash.
Set disk quotas or alerts. Configure a performance counter alert in Windows or use a monitoring tool that pages you when free space drops below 10% on the database drive.
Use a UPS on the DC. Unplanned shutdowns are the #1 cause of ESENT corruption. A battery backup gives you time to shut down cleanly.
Schedule a backup of system state weekly. That way you can do a quick restore instead of a full repair.
Run ntdsutil files integrity quarterly. It's a proactive check. If you catch small corruption early, repair is fast.

I've seen this error on a Server 2016 DC after a disk that was 99.9% full – the database couldn't write a single transaction. The repair took 12 minutes, and the DC was back in business. But the next week it happened again because nobody cleared the disk. So don't just fix it – fix the root cause.