After applying the Windows Server 2016 Security baseline GPO to the domain controllers OU replication does not work (Access Dined error)

Hi,

Check your Windows Defender Firewall allows the following ports:

RPC (TCP 135)

Dynamic RPC range (TCP 49152–65535)

DFSR (TCP 5722)

Try turning off the firewall on one domain controller as a quick test. If replication starts working again, it means the GPO is blocking the communication. You can then adjust the GPO or create rules to allow these ports.

Also, review the settings “LDAP server signing requirements” and “Network access: Restrict clients allowed to make remote calls to SAM”, as these can also stop replication if set too high.

Once replication works again, you can reapply the baseline with small changes using the Security Compliance Toolkit. If one DC is in Azure, please make sure the same ports are open in your Azure network or VPN as well.

I hope this helps you get replication back on track! If you find this answer helpful, click “Accept Answer” so others can benefit from it as well 😊

Best regards,

VP

Hi Ashan Dissanayake,

Has your issue been solved? If it has, please accept the answer so that others can benefit too. If not, is there anything I can help you with? Please let me know.

Vivian

Ashan Dissanayake, the failure on port 5722 is not caused by the firewall being off — it’s because the DC name is resolving to the IPv6 loopback (::1) instead of the server’s real IP. That means your connectivity test is never leaving the local host. You need to correct DNS/hosts resolution so the DC resolves to its actual network address, then verify that the DFS Replication (DFSR) service is running and listening on TCP 5722.

Dear VP,

At present, we are experiencing issues with trust relationships on client computers, and Active Directory servers are failing to replicate with one another. Our environment consists of five domain controllers (DCs). The FSMO role was originally held by DC03, then transferred to DC04, and subsequently to DC01. We have since shut down DC03 and demoted DC05 few days back. DNS and DHCP services continue to function.

However, we are unable to add new devices to the domain or promote additional domain controllers. Our plan is to restore DC03 from a backup that is 25 days old. Please advise on the process and let us know if there are any recommended steps to help restore ADDS functionality.

Proposed steps:

1.       Take backups of all DCs.

2.       Isolate all domain controllers from the network.

3.       Restore DC03 using the 25-day-old backup.

4.       Remove DNS and AD Site configurations related to other DCs from DC03.

5.       Connect DC03 to the appropriate network and assign its previous IP address.

6.       Once restored, verify that Active Directory services are operational on DC03.

7.       Promote an additional domain controller and re-establish replication.

We appreciate your guidance on this recovery process.

Ashan Dissanayake,

In this case you should do Immediate troubleshooting now, don't restore anything yet

Take offline backups of all DCs (VM snapshots + system state) before any change.

Validate basic health and replication diagnostics from a working management host:

Run dcdiag /v and capture output for each DC.

  Run repadmin /replsummary and repadmin /showrepl on each DC.
  
     Collect Event Viewer logs: Directory Service, DFS Replication, System, DNS, Netlogon and FRS/DFSR event channels.
     
     Confirm time sync and name resolution:
     
        Verify all DCs have correct time and NTP source. Kerberos fails otherwise.
        
           Verify each DC resolves other DC hostnames to the correct IPv4 addresses (nslookup and ping). Ensure no DC resolves to ::1.
           
           Verify critical services are running on every DC:
           
              Services: NTDS (Active Directory Domain Services), Kdc, Netlogon, DNS, DFSR.
              
                 If DFSR is stopped, collect DFSR-related events (Event IDs 4000/4012/5002 etc.).
                 
                 Confirm network connectivity and ports (from one DC to another):
                 
                    Test RPC 135, LDAP 389, LDAPS 636, Kerberos 88, SMB 445, DFSR 5722, and dynamic RPC range 49152–65535.
                    
                       If Test‑NetConnection resolves to ::1, fix DNS so it resolves to the DC’s real IP.
                       
                       Check firewall/GPO effects:
                       
                          On a DC where firewall appears “enabled and cannot be disabled,” run gpresult /h gp.html and review applied settings.
                          
                             Temporarily move that DC out of the Domain Controllers OU by changing its OU membership or apply a different GPO to allow testing; do NOT permanently remove it yet.
                             

The recovery plan I suggest below is the steps to restore AD safely. Follow this order exactly to avoid making the situation worse.

Backups and isolation

Snapshot/backup all DCs and system state now.

  Do NOT restore DC03 from 25‑day backup yet. Restoring an old DC into an active, changed domain will likely cause USN rollback.
  
  Fix name resolution and connectivity
  
     Ensure each DC’s A records and SRV records in DNS are correct and point to real IPs (not loopback).
     
        If needed, temporarily add correct IP mappings in hosts file on the DCs for immediate testing (then remove once DNS fixed).
        
        Remove/relax the Domain Controllers GPO temporarily
        
           From a management workstation, create a blocking GPO that applies to Domain Controllers OU to allow inbound RPC (TCP 135), dynamic RPC ports, DFSR 5722, LDAP/Kerberos/SYSVOL ports, and disable any overly restrictive settings you added.
           
              Apply the temporary GPO and force gpupdate /force on DCs or reboot them if required. Confirm firewall allows the needed ports.
              
              Bring services up and verify replication
              
                 Start NTDS and DFSR services where stopped. Check Event Viewer for immediate errors.
                 
                    Run repadmin /syncall /A /e /P and repadmin /replsummary to see progress.
                    
                       If replication still fails, run repadmin /showconn to check connection objects and repadmin /showrepl to inspect error codes.
                       
                       Clean up stale metadata if necessary
                       
                          If some demoted or removed DCs remain in AD metadata, perform metadata cleanup (ntdsutil) only after confirming those DCs will not return. Lingering metadata will block replication.
                          
                          FSMO roles
                          
                             Do not move FSMO roles again while replication is broken. Only seize FSMO if the previous FSMO holder is permanently unrecoverable. Seizing when replication is inconsistent can worsen the problem. If necessary, seize to a healthy, stable DC after replication is re-established.
                             
                             If DFSR database is corrupt
                             
                                If DFSR shows backlog or database errors, consider non‑authoritative or authoritative DFSR restore procedures: stop DFSR, back up database, follow Microsoft guidance to reconstruct SYSVOL if needed.
                                
                                If you must restore DC03 from backup (last resort)
                                
                                   Only restore if you can guarantee all other DCs will be taken offline first to avoid USN rollback, or perform it in an isolated network, then perform metadata cleanup and authoritative restores carefully. Preferred sequence if you restore a DC from old backup: a. Disconnect all other DCs from the network. b. Restore DC03 and verify it is healthy. c. Promote a new DC from DC03 (if required), then carefully bring other DCs back one at a time and run repadmin to synchronize, performing metadata cleanup for any permanently removed DCs.
                                   
                                      Note: This is high risk and error prone; avoid if possible.
                                      

1. Promote a new DC (preferred over restoring old backup)
   • If replication and DNS are restored, create a fresh new DC (promote) in the environment.

Practical commands and checks (run from an admin machine)

• repadmin /replsummary
• repadmin /showrepl * /csv > showrepl.csv
• dcdiag /v > dcdiag.txt
• netstat -an | find "5722" (on DCs)
• sc query dfsr ; sc query ntds
• Get DNS SRV records: nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain

LAST RESORT: IF YOUR ARE UNSURE OR THE SITUATION BECOMES WORSE!!!

• Engage Microsoft Premier/Unified Support immediately. This is a time‑sensitive AD recovery scenario where incorrect restores or FSMO moves cause forest‑wide damage. Provide them the diagnostic outputs above.
• https://support.microsoft.com/en-us/contactus/ This is the central hub for all business product support. Once on the page, you will be guided through a few steps to get the specific contact details for your issue: Describe your problem: You can enter keywords like "legacy volume licensing activation." Select a product: Choose the relevant product, such as "Windows" or "Microsoft 365." Get support options: The website will then present you with the most up-to-date contact methods for your region, which often includes a direct phone number for commercial support. I think this kind of support would facilitate you more easily, as it is a live chat that provides you with simultaneous consultancy. If you find this information helpful to some extent, please accept the answer so that it could be spread further to those in need. Thank you and good luck :) Vivian