0x2095 AD Error: Fix It Fast Without Rebuilding Domain

Cause #1: Stale Domain Controller Metadata

I've seen this exact error more times than I can count. A domain controller gets removed improperly – someone demotes it but skips the cleanup, or a VM snapshot gets rolled back. The old DC's metadata hangs around in Active Directory, and when replication tries to sync with that ghost DC, you get 0x00002095.

Last month a client had a DC that crashed and they restored it from backup without demoting first. Boom, error 2095 every time the other DC tried to replicate.

How to fix it

1. Open ADSI Edit (or use ntdsutil – I'll show both).
2. Connect to the Default naming context.
3. Go to CN=Servers,CN=<SiteName>,CN=Sites,CN=Configuration,DC=<yourdomain>.
4. Find the dead DC's computer object under its server node. If the server object is still there but the computer account is gone, right-click the server object and delete it.

But honestly, ntdsutil is cleaner. Run this from an elevated command prompt on a working DC:

ntdsutil
metadata cleanup
select operation target
list sites
select site 0
list servers in site
select server <number of dead DC>
quit
remove selected server
quit
quit

After that, run repadmin /syncall /AdeP to force replication and see if the error clears.

If you can't delete the server object because it's already gone, skip to cause #2 – DNS is probably your real problem.

Cause #2: Broken DNS Records

Active Directory is nothing without DNS. When a DC can't find its replication partner by name, it throws generic errors like 0x2095. The classic scenario: you changed IP addresses, or the DNS scavenging ran and deleted the DC's A record.

Check DNS first – it's faster than rebuilding anything.

The fix

1. On each DC, open DNS Manager.
2. Expand Forward Lookup Zones → _msdcs.<yourdomain>.
3. Look for CNAME records pointing to your DCs. Each DC should have a CNAME in _msdcs, and an A record in the main zone.
4. If any record is missing or wrong IP, create or fix it manually.

Also run this from each DC:

ipconfig /registerdns
net stop netlogon && net start netlogon

That re-registers all the SRV records. Then check with dcdiag /test:dns – if it reports failures on the DNS test, you're still broken.

One time – a smaller client – the firewall was blocking UDP 53 between the two DCs. DNS queries failed, and boom, 0x2095. So if DNS looks fine, check your firewall rules, especially if you have multiple sites.

Cause #3: Insufficient Permissions on the Directory Service

Less common but still real. If an application or a user tries to modify AD attributes and they don't have the right permissions, you get this generic error. I've seen it with third-party backup software that had a service account with delegated permissions, and the delegation got removed during a security cleanup.

You'll know it's this if the error happens when you try to create a user, change a password, or sync from an external system.

How to fix it

1. Check the event log on the domain controller – look for event ID 4662 or 4779 that mentions the object and the account that failed.
2. Open ADSI Edit, right-click the object, go to Security.
3. Make sure the account has Read and Write permissions on the specific attribute that's failing.
4. If it's a service account, compare with a working one – sometimes the fix is just adding the account to the Domain Admins group (not ideal, but it works for a quick test).

If it's replication-related, also check the KRBTGT password – if that's out of sync, you can get weird errors. But that's rare. The permissions thing is more common than people think.

Quick-Reference Summary

Start with the DNS check – it's the cheapest and fixes most cases. Then move to metadata cleanup if DNS is clean. Permissions are the last thing I check unless you have a specific culprit app.

If you're still stuck after these, run repadmin /showrepl and dcdiag /v – they'll point you to the exact failing replication partner. Good luck.