Fix 0X00002189: AD partition access error on remote server

30-Second Fix: DNS and Network Basics

The culprit here is almost always DNS. When a domain controller can’t resolve the remote server’s name or IP, it throws 0X00002189. Don’t bother with complex tools yet — start here.

1. Open Command Prompt as admin on the affected DC.
2. Run nslookup <remote-DC-FQDN>. Example: nslookup dc2.contoso.local. If it fails, your DNS records are broken.
3. Check the remote server’s IP: ping <remote-DC-IP>. No reply? Network firewall or routing issue.
4. Verify both DCs point to the same DNS server (usually another DC). Run ipconfig /all and check the DNS server list.
5. Flush DNS: ipconfig /flushdns and reregister: ipconfig /registerdns. Then restart Netlogon: net stop netlogon && net start netlogon.

If the error goes away, you’re done. If not, move on.

5-Minute Fix: Check Replication and AD Health

DNS is clean? Then replication between DCs is broken. This error pops up when one DC can’t pull the partition from another. Use these tools in order.

Run DCDIAG

dcdiag /test:replications /test:dns /v | more

Look for “failed test” under Replications or DNS. Common failures: “Access denied” or “The remote server is not available”. Fix those specific errors — usually a time sync issue or a stale metadata object.

Check Time Sync

w32tm /query /status

If the offset is more than 5 minutes, run w32tm /resync. Then restart the KDC service: net stop kdc && net start kdc. Kerberos hates clock drift.

Force Repadmin

repadmin /syncall /AdeP

This forces replication across all partitions. Watch for error codes like 8453 (access denied) or 1722 (RPC server unavailable). Those point to firewall ports (TCP 135, 389, 636, 3268, 3269, 445, 49152+).

Still stuck? Let’s go deeper.

15+ Minute Fix: Ntdsutil Repair and Metadata Cleanup

If DNS and replication look fine, the AD database itself might be corrupt or a lingering server object is blocking access. This fix requires downtime on the affected DC. Do it during maintenance.

Step 1: Identify the Problem Partition

Open Event Viewer → Windows Logs → Directory Service. Look for Event ID 1925 or 1988. They’ll name the partition — could be DomainDNSZones, ForestDNSZones, or the default domain partition (DC=contoso,DC=local).

Step 2: Run Ntdsutil Integrity Check

ntdsutil
activate instance ntds
files
integrity

This scans the database for corruption. If it finds errors, you’ll see “Database is corrupt”. Don’t panic — you can repair it.

Step 3: Compact the Database

ntdsutil
activate instance ntds
files
compact to c:\temp

This creates a fresh copy of the DB, fixing most corruption. Move the new file over the old one:

copy c:\temp\ntds.dit c:\windows\ntds\ntds.dit

Then reboot the DC.

Step 4: Remove Stale DC Metadata

If a remote DC was decommissioned badly, it leaves ghost references. Use ADSI Edit or ntdsutil:

ntdsutil
metadata cleanup
connections
connect to server <working-DC>
quit
select operation target
list domains
select domain 0
list sites
select site 0
list servers in site
select server <stale-server-ID>
quit
remove selected server

Replace placeholders with your actual server IDs from the list.

Step 5: Force Replication from a Working DC

repadmin /syncall /AdeP /e /j:10

The /e switch includes cross-site links. Give it a few minutes, then run dcdiag /test:replications again. If all tests pass, you’ve killed the bug.

Real-world trigger: I once saw 0X00002189 on a Server 2016 DC after someone accidentally deleted the SYSVOL share. The fix was restoring SYSVOL from a backup using ntdsutil authoritative restore. But that’s a last resort — try the steps above first.

Still Broken? Check These Edge Cases

• Firewall rules: Windows Firewall or third-party AV blocking RPC dynamic ports. Open TCP 49152-65535 between DCs.
• IPv6 disabled: If you turned off IPv6, AD replication breaks. Enable it via registry (set DisabledComponents to 0x20 only, not 0xFF).
• KB5004442 patch: Some Windows Updates hardened RPC, causing older DCs to fail. Apply the latest cumulative update on all DCs.

If nothing works, you’re looking at a full DSRM restore or promoting a new DC. But 90% of the time, one of the above fixes it. Skip the wild goose chases — start with DNS, then replication, then the database.