Some computers are dropping out of the domain (Windows Server 2016 environment). What is the issue, and how can it be resolved?

The immediate fix is to restore the missing GUID-based DNS CNAME record for DRNYAD, verify that both domain controllers use internal AD DNS servers, and then synchronize replication before repairing any workstation secure channels.

The error matches AD DS Event 2087: the destination domain controller cannot resolve [GUID]._msdcs.amanabank.com, which is the DNS alias used to locate the source replication partner. Until corrected, users, computer passwords, Group Policy, and other directory data can become inconsistent between domain controllers.^1^

1. Confirm that DRNYAD is still a valid domain controller

From another domain-connected server or DC, run:

net view \\DRNYAD
ping DRNYAD
nslookup DRNYAD.amanabank.com
nslookup -type=CNAME [GUID]._msdcs.amanabank.com

net view should show the NETLOGON and SYSVOL shares. The CNAME query should resolve to DRNYAD’s current FQDN, and that FQDN should resolve to its current IP address.^1^

If DRNYAD has been permanently retired or rebuilt and this GUID refers to an old installation, do not manually recreate the old record. Remove the stale DC metadata instead; deleting DC metadata is destructive and applies only after confirming that the old DC cannot be restored.^2^

2. Correct the DNS client configuration

Run ipconfig /all on DRNYAD and on the destination DC logging the error.

Their configured DNS servers must be internal DNS servers that host, forward, or delegate both:

• _msdcs.amanabank.com
• The AD domain’s primary DNS zone

Do not configure a DC to query an ISP or public resolver directly for AD name resolution. Test the GUID CNAME against each DNS server listed on the destination DC, because one DNS server may have the record while another does not.^2^

nslookup -type=CNAME [GUID]._msdcs.amanabank.com <DNS-IP-1>
nslookup -type=CNAME [GUID]._msdcs.amanabank.com <DNS-IP-2>

Also inspect DNS Manager → Forward Lookup Zones → _msdcs.amanabank.com and confirm that the GUID CNAME points to DRNYAD’s current FQDN.

3. Re-register DRNYAD’s records

If DRNYAD is operational and the record is absent, open an elevated Command Prompt on DRNYAD and run:

net stop netlogon && net start netlogon
ipconfig /flushdns
ipconfig /registerdns
dcdiag /test:dns /v /s:DRNYAD
dcdiag /test:dns /DnsRecordRegistration /s:DRNYAD

Netlogon registers the DC locator records, including the GUID CNAME and SRV records; the DNS Client service registers the host A record. Review the dcdiag output and resolve every relevant DNS warning or failure.^3^

If registration still fails, check:

• Event Viewer → Windows Logs → System for Netlogon registration errors.
• Whether the AD-integrated zones allow dynamic updates.
• Whether _msdcs.amanabank.com exists in duplicate replication scopes.
• Whether DNS scavenging is removing valid records too aggressively.^2^

4. Validate and synchronize replication

After DNS queries succeed from every destination DC:

repadmin /replsum
repadmin /showrepl *
repadmin /syncall /AdeP
dcdiag /test:replications /v

Replication is healthy when repadmin no longer reports DNS lookup failures and the Directory Service log stops generating Event 2087. Microsoft recommends using repadmin and the Directory Service events to identify and validate replication failures.^4^

5. Repair only computers that still report a trust failure

Replication failure can leave computer-account passwords inconsistent, but it does not prove that every affected computer has a broken secure channel. After replication is healthy, test each computer that displays “The trust relationship between this workstation and the primary domain failed.”

Sign in with a local administrator account and run elevated PowerShell:

Test-ComputerSecureChannel

# Run only if the result is False:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

# If repair still fails:
$credential = Get-Credential
Reset-ComputerMachinePassword -Credential $credential
Restart-Computer -Force

A result of True means the secure channel is intact and the remaining issue should be investigated as DNS or network-related. Rejoining the domain should be a fallback, not the first action.^5^

References

1. Active Directory replication Event ID 2087: DNS lookup failure caused replication to fail
2. Active Directory Replication Error 8524: The DSA operation is unable to proceed because of a DNS lookup failure
3. Verify DNS Functionality to Support Directory Replication
4. Troubleshooting Active Directory Replication Problems
5. Join a computer to a domain (windows-server-2016)