Windows Server  ·  medium  ·  Directory & core infrastructure

NTDS events 2087 and 2088 — DNS lookup failure caused replication to fail

2088 means replication succeeded by falling back to NetBIOS or a fully qualified name; 2087 means it failed outright. Both say DNS is broken — 2088 is the warning before 2087.

What you see

Directory Service log records 2087 or 2088 naming a partner DC. Replication may still be working, which is why 2088 is often ignored until it becomes 2087.

What is actually wrong

The partner's host record or its _msdcs CNAME is missing, stale, or the DC is querying a DNS server that does not host the zone.

Codes and articles

20872088Event 2087Event 2088

Start here — find out which fix applies

A script that runs the 1 inspection command from the write-up below and prints what each one returned. It reads the machine and changes nothing — every command that could write, delete, start or stop is excluded from it by construction. Run this first, then pick the fix its output points at.

Download the read-only diagnosticchanges nothing · safe to run before reading

No warranty. Use at your own risk - JbTecWiz accepts no liability. Read it before you run it, and have a backup.

The fix

Repair the DNS records the DCs use to find each other
Elevated PowerShell30 minuteslow riskreversible

Either event is present. Treat 2088 with the same urgency as 2087 — it is the same fault, currently masked by a fallback.

  1. Run the DNS test and read the failures rather than the summary.

    PowerShell
    dcdiag /test:dns /v /e
  2. On each DC, re-register its records.

    PowerShell
    ipconfig /registerdnsnltest /dsregdnsRestart-Service Netlogon
  3. Check for stale records belonging to decommissioned DCs and delete them.

    PowerShell
    Get-DnsServerResourceRecord -ZoneName '_msdcs.example.local' -RRType CName | Format-Table HostName, RecordData -AutoSize

    A CNAME pointing at a DC that no longer exists makes replication attempts hang and then fail, and dcdiag reports it as a lookup failure.

  4. Confirm scavenging is enabled so stale records do not accumulate again.

    PowerShell
    Get-DnsServerScavenging
  5. Force replication.

    PowerShell
    repadmin /syncall /AdeP
Confirm it workeddcdiag passes and neither event recurs.
PowerShell
dcdiag /test:dnsrepadmin /replsummary
If you need to undo itNone — this removes records that should not exist and recreates ones that should.
Download this fix as a PowerShell scriptasks before each step

No warranty. Use at your own risk - JbTecWiz accepts no liability. Read it before you run it, and have a backup.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.