Share via

2nd DC freshly created cant be contacted and does not autnenticate users

Salam ELIAS 302 Reputation points
2026-04-08T10:59:31.4333333+00:00

I have a primary DC (win 2k19) managing a network and decided to add a 2nd DC in case of any failure for the PDC. The 2nd DC is also win 2k19, setup went OK and it seems that replication was OK as well, time is synced between both. Windows firewall on DC2 is disabled.

When I shut down the PDC and tried to check that secondary DC will act and respond, it did not work, doing nslookup from client, it does not work.

When I fire Azure Users and Computers, I see that everything was transfered from DC1 to DC2

When Issuing the following command when DC1 is up and running 

 .\nltest /dclist:salam.net

I get

Get list of DCs in domain 'salam.net' from '\SALAMMAIN.salam.net'. SALAMMAIN.salam.net [PDC] [DS] Site: Default-First-Site-Name DC2.salam.net [DS] Site: Default-First-Site-Name The command completed successfully

Running

ping salam.net

on both machines DCs gives same result, it responds with the DC2 IPv4.

DNS roles installed on both DCs

I have set the IP address of DC1 and 127.0.0.1 for Preferred DNS on DC1.

I have set the IP address of DC1 and 127.0.0.1 for Preferred DNS on DC2

issuing nslookup salamn.net

I get

Server: dc1.salam.net Address: 192.168.1.13 *** dc1.salam.net can't find salamn.net: Non-existent domain

I really dont understand the 3rd statement when it has already found dc1 and its IP

When I run 

repadmin /syncall /AdeP on both DCs, I get 
	SyncAll terminated with no errors.

but running on DC2 (the new DC)

dcdiag /test:replications

I get

DsReplicaGetInfo() failed with status 8453 (0x2105) Replication access was denied.

As I said, when I disconnect Dc1 from network no authentication happens with DC2 and need to bring back DC1 in the network

Windows for business | Windows Server | Directory services | Active Directory
0 comments

6 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Salam ELIAS 302 Reputation points
    2026-06-04T09:25:44.9+00:00

    Also while I was doing required tests, I came across an error when running

    Get-ADDomain -Server myPDC

    I get

    Get-ADDomain : A call to SSPI failed, see inner exception.
At line:1 char:1
+ Get-ADDomain -Server myserver
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [Get-ADDomain], AuthenticationException
    + FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.Security.Authentication.AuthenticationException,Microsoft.ActiveDirectory.Management.Commands.GetADDomain

    Was this answer helpful?

    0 comments
  2. Salam ELIAS 302 Reputation points
    2026-06-04T09:22:31.8833333+00:00

    Hi, when I check

    _ldap._tcp.pdc._msdcs.mydomain

    DC2 is not present but it is present in ldap._tcp.dc._msdcs.mydomain as follows

    === _ldap._tcp.dc._msdcs.mydomain ===
_ldap._tcp.dc._msdcs.mydomain           SRV    600   Answer     dc2.mydomain                  0        100    389
_ldap._tcp.dc._msdcs.mydomain           SRV    600   Answer     SALAMMAIN.mydomain            0        100    389
_ldap._tcp.dc._msdcs.mydomain           SRV    600   Answer     salammain.mydomain            0        100    389
Name       : dc2.mydomain
QueryType  : A
TTL        : 1200
Section    : Additional
IP4Address : ......130
Name       : SALAMMAIN.mydomain
QueryType  : A
TTL        : 3600
Section    : Additional
IP4Address : ........13
Name       : salammain.mydomain
QueryType  : A
TTL        : 3600
Section    : Additional
IP4Address : .......13

    .

    From a win 10 machine when I run

    nltest /dsgetdc:mydomain /force /kdc

    I get only DC1 but DC2 does not show

    Was this answer helpful?

    0 comments
  3. Kate Pham (WICLOUD CORPORATION) 745 Reputation points Microsoft External Staff Moderator
    2026-04-22T02:36:11.82+00:00

    Hi @Salam ELIAS

    Your scenario involves adding a second Windows Server 2019 domain controller (DC2) to your domain for redundancy, but when the primary DC (DC1) is offline, authentication and DNS resolution fail, and you see replication errors (status 8453: Replication access was denied) on DC2.

    Please help refer to bellow instructions to address the issue:

    1. Replication Access Denied (Error 8453)

    This error indicates that DC2 does not have the necessary permissions or its computer account is not properly configured as a domain controller. Common causes and solutions include:

    • Check userAccountControl attribute: The computer account for DC2 must have the SERVER_TRUST_ACCOUNT and TRUSTED_FOR_DELEGATION flags. If these are missing, DC2 cannot replicate.
      • Run DCDIAG /TEST:MachineAccount on DC2 and check for errors.
      • The typical value for a DC is 0x82000. If you see a value like 0x288, it means DC2 is not recognized as a DC account.
    • Assign Replication Rights: Ensure that the following security groups have the correct rights on the directory partition:
      • NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
      • <YourDomain>\Domain Controllers
      • <YourDomain>\Enterprise Read-Only Domain Controllers
      • Missing rights like "Replicating Directory Changes" or "Replicating Directory Changes All" will cause replication to fail.
    • Kerberos Issues: If the machine account is not present or mismatched, or if there are Kerberos errors, verify that the domain partition of the KDC is in sync with the rest of the enterprise.
      • Use repadmin /syncall to attempt synchronization.
      • Use netdom resetpwd to reset the machine account password if needed.

    Fyi: Active Directory replication error 8453 - Windows Server | Microsoft Learn

     

    2. DNS Configuration

    Your DNS setup is critical for AD functionality. Both DCs should be able to resolve each other and themselves. Here’s what you should check:

    • Preferred DNS Settings:
      • On DC1: Preferred DNS should be itself (127.0.0.1 or its own IP).
      • On DC2: Preferred DNS should be itself (127.0.0.1 or its own IP), and Alternate DNS should be DC1’s IP.
    • Avoid Pointing Both to DC1:
      • If DC2 points to DC1 as preferred DNS, and DC1 is offline, DC2 cannot resolve names, causing failures.
    • Check DNS Records:
      • Ensure that both DCs have registered their SRV and A records in the DNS zone.
      • Use nslookup to verify that both DCs can resolve each other’s names and the domain name.
    • Replication of DNS Zones:
      • Make sure the DNS zone is AD-integrated and replicates to all DCs in the domain.
      • If the DNS server becomes an "island" (unable to replicate records), follow the guidance to point all DCs to a common DNS server until replication is confirmed, then reconfigure as needed.

    Fyi: DNS Server becomes an island - Windows Server | Microsoft Learn

     

    3. General Replication Troubleshooting

    • Check Event Logs: Review the Directory Service event log for errors and follow any recommended steps.
    • Use Repadmin and DCDIAG:
      • repadmin /showrepl to check replication status.
      • dcdiag /test:replications to diagnose replication issues.
    • Firewall and Network:
      • Ensure that required ports (especially RPC 135) are open between DCs.
      • Even if Windows Firewall is disabled, check for other network appliances or software firewalls.
    • Authentication and Authorization:
      • "Access denied" errors often mean missing permissions or misconfigured accounts.

     

    4. Steps to Resolve

    1. Correct DNS Settings:
      • On DC2, set Preferred DNS to 127.0.0.1 (or its own IP), Alternate DNS to DC1’s IP.
    2. Verify and Fix Machine Account:
      • Use DCDIAG /TEST:MachineAccount and correct any issues with the computer account for DC2.
      • If needed, reset the machine account password using netdom resetpwd.
    3. Assign Replication Rights:
      • Ensure the correct security groups have the necessary replication rights on the directory partition.
    4. Force Replication:
      • Use repadmin /syncall after fixing the above issues.
    5. Check DNS Records:
      • Use nslookup to verify that both DCs can resolve each other and the domain.
      • Ensure all necessary DNS records are present and replicated.
    6. Test Failover:
      • After making these changes, shut down DC1 and verify that DC2 can authenticate users and resolve DNS queries.

    For more detailed troubleshooting steps and explanations, please refer to the following documents: 

    Active Directory replication error 8453 - Windows Server | Microsoft Learn

    Guidance for troubleshooting Active Directory replication - Windows Server | Microsoft Learn

    DNS Server becomes an island - Windows Server | Microsoft Learn

    If the problem persists after these steps, you may need to review the specific permissions and attributes on DC2’s computer account and ensure that all replication and DNS configurations are correct.

    Would appreciate it if you find my response helpful and "Accept the Answer" 😊

     

    Thanks and Regards,

    Kate.

    Was this answer helpful?

  4. Harry Phan 21,095 Reputation points Independent Advisor
    2026-04-08T13:45:10.3266667+00:00

    Hi Salam,

    The issue is with DNS configuration and replication permissions. Right now, both DCs are pointing to DC1 as their preferred DNS, which means when DC1 is offline, DC2 cannot resolve queries properly. On each DC, set the preferred DNS to its own loopback (127.0.0.1) and the alternate DNS to the other DC’s IP. For example, DC1 should use 127.0.0.1 as preferred and DC2’s IP as alternate, while DC2 should use 127.0.0.1 as preferred and DC1’s IP as alternate. This ensures each DC can resolve names independently when the other is down.

    The replication error 8453 indicates that the DC2 machine account does not have sufficient replication permissions. Verify that DC2 is a member of the “Domain Controllers” OU and that the NTDS settings object exists under Sites and Services. Also check that the “Authenticated Users” group has “Replicating Directory Changes” permission on the domain root in Active Directory. Run dcdiag /test:replications /v again after confirming.

    Finally, make sure clients are configured to use both DCs as DNS servers, not just DC1. If clients only point to DC1, they will fail when it is offline. Once DNS is corrected and replication permissions fixed, DC2 will be able to authenticate and serve as a proper backup when DC1 is unavailable. Best Regards.

    Was this answer helpful?

  5. AI answer

    2026-04-08T11:00:18.02+00:00

    The second domain controller is online but not being used because of DNS and replication registration issues. Focus on DNS client configuration, DC locator records (_msdcs), and replication permissions.

    1. Fix DNS client settings on both DCs

    On each DC, the preferred DNS server must be another working DC, not itself, until all locator records are correctly registered and replicated.

    Use the pattern from the “DNS island” guidance:

    • Choose one DC (for example, DC1) as the primary DNS for the forest root.
    • Configure DNS on DCs as follows:
      • DC1: Preferred DNS = DC1 (its own IP). Alternate DNS = DC2 (optional, but must not point to itself as alternate).
      • DC2: Preferred DNS = DC1 (DC1’s IP). Alternate DNS = DC2 (its own IP) or another DC, but never only itself.

    This avoids the “DNS island” situation where a DC points only to itself and is missing other DCs’ locator records.

    1. Verify _msdcs CNAME and SRV records

    The error DsReplicaGetInfo() failed with status 8453 (Replication access was denied) and the fact that clients cannot use DC2 when DC1 is down strongly suggest missing or incomplete DC locator records in DNS.

    On DC2:

    1. Run ipconfig /all and confirm the DNS Servers list shows DC1’s IP first.
    2. Use nslookup to query the CNAME for DC2’s NTDS Settings object GUID on the DNS servers DC2 points to, as described in the replication troubleshooting: 
         nslookup -type=cname <DC2-NTDS-GUID>._msdcs.<forest-root> <DC1-DNS-IP>
   nslookup -type=cname <DC2-NTDS-GUID>._msdcs.<forest-root> <DC2-DNS-IP>
    3. If the CNAME is missing on either DNS server, restart Netlogon on DC2 to force registration: 
         net stop netlogon & net start netlogon
    4. Ensure that the _msdcs.<forest-root> zone exists only once (no duplicate zones in different replication scopes) and that SRV records such as _ldap._tcp.pdc._msdcs.<domain> and other LDAP SRV records for all DCs are present. If SRV records are missing, restarting Netlogon on the DCs will repopulate them; then ensure AD replication is healthy so changes replicate across DNS servers.
    5. Confirm DNS and DC reachability from clients

    On a domain member client:

    1. Check firewall/ports between client and both DCs: UDP 53 (DNS) and UDP/TCP 389 (LDAP) must be open.
    2. Run: 
         nltest /dsgetdc:<domain> /force /kdc
      This should list both DC1 and DC2 as available DCs.
    3. Run: 
         nslookup <DC2-FQDN>
   nslookup <domain-FQDN>
      If nslookup fails to resolve DC2 or the domain when DC1 is offline, DNS on DC2 is not serving all required records; re-check the _msdcs zone and SRV/CNAME registration as above.
    4. Address replication access denied (8453)

    The 8453 error on dcdiag /test:replications from DC2 indicates that DC2 cannot authenticate properly to replicate from DC1. Once DNS is corrected and the CNAME/SRV records are properly registered and replicated, rerun:

    repadmin /syncall /AdeP

    If 8453 persists, verify that DC2’s computer account and NTDS Settings object are correct and that there are no duplicate NTDS objects for DC2. Ensure that DC2 is using valid domain credentials (its machine account) and that there are no network/firewall blocks on LDAP/Kerberos between DC1 and DC2.

    1. Test failover again

    After fixing DNS and replication:

    1. With both DCs online, confirm:
      • nltest /dclist:<domain> shows both DCs.
      • dcdiag /test:replications passes on both DCs.
    2. Gracefully shut down DC1.
    3. On a client, run: 
         nltest /dsgetdc:<domain> /force /kdc
      It should now select DC2.
    4. Test logons and access to shared resources.

    If authentication still fails when DC1 is down, check for:

    • Clients still pointing only to DC1 for DNS (they must list DC2 as DNS as well).
    • Negative caching or clients repeatedly selecting a DC that is shutting down. To avoid this, stop Netlogon (and KDC) on a DC before shutting it down so clients are forced to choose another DC.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.