Unable to achieve full replication

Question

Unable to achieve full replication

Diana Piloya 245

I have an on-premises DC and created a secondary DC on azure the communication is happening through site-to-site vpn. though when I check on replication, the DFSR service is running though i get error the RPC server is unavailable (1722) from both DCs, how do i resolve this?Then if you can share a documentation for an end-to-end process of creating secondary DC on azure. User's image

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

The error you're seeing typically indicates a network connectivity, name resolution, or RPC communication issue rather than a problem with the DFSR service itself. Since the DFSR service is running and you have already enabled the DFS-R firewall rule, the next step is to verify the underlying RPC connectivity that Active Directory replication depends on.

First, confirm that the Azure VM and the on-premises domain controller can resolve each other's fully qualified domain names (FQDNs). From each domain controller, run commands such as nslookup <PartnerDCName> and ping <PartnerDCName> (if ICMP is allowed). Also verify that the returned IP address is the correct private IP address across the site-to-site VPN. Incorrect DNS resolution is one of the most common causes of RPC 1722 errors.

Next, verify general network connectivity over the VPN. Test whether the required Active Directory ports are reachable between the domain controllers. In PowerShell, you can use commands such as Test-NetConnection <PartnerDC> -Port 135 for the RPC Endpoint Mapper and repeat the test for other required ports including TCP 445 (SMB), TCP/UDP 389 (LDAP), TCP 636 (LDAPS if used), TCP/UDP 53 (DNS), TCP/UDP 88 (Kerberos), TCP 464 (Kerberos password changes), TCP 3268 and 3269 (Global Catalog), and the dynamic RPC port range (TCP 49152-65535 on modern versions of Windows). If any of these ports are blocked by an Azure Network Security Group, Windows Firewall, or an on-premises firewall, replication will fail with RPC errors.

Although the DFS-R firewall rule is enabled, Active Directory replication relies on RPC, so ensure that the Windows Firewall rules for Active Directory Domain Services, Remote Service Management, Windows Management Instrumentation (WMI), File and Printer Sharing, and Remote Event Log Management are also enabled on both domain controllers. If custom firewall policies are in place, verify that the complete set of required Active Directory ports is allowed in both directions.

Check whether Azure Network Security Groups or Azure Firewall are restricting traffic. The Azure VM's subnet or network interface may have NSG rules that allow only selected ports. Ensure that traffic from the on-premises subnet to the Azure subnet (and vice versa) is permitted for all required Active Directory ports. Likewise, verify that the on-premises firewall allows the same traffic across the site-to-site VPN.

Verify that Active Directory replication itself is failing by running repadmin /replsummary and repadmin /showrepl on both domain controllers. These commands will identify which naming contexts are failing and often provide more detailed error information than the DFS Replication console. You can also run dcdiag /v, dcdiag /test:replications, and dcdiag /test:dns to identify DNS, replication, or service configuration issues.

Review the Event Viewer logs under Directory Service, DFS Replication, DNS Server, and System on both domain controllers. Events associated with RPC failures, DNS lookup failures, Kerberos authentication, or secure channel issues often point directly to the underlying cause.

If the VPN itself is functioning, verify that there are no overlapping IP address ranges between the on-premises network and the Azure virtual network. Overlapping address spaces can result in intermittent routing issues that manifest as RPC failures. Also confirm that the Azure virtual network is configured to use your domain controllers for DNS rather than Azure's default DNS service, as incorrect DNS configuration frequently prevents successful domain controller communication.

More at

https://learn.microsoft.com/en-us/training/modules/deploy-manage-azure-iaas-active-directory-domain-controllers-azure/

https://learn.microsoft.com/en-us/azure/architecture/example-scenario/identity/adds-extend-domain

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/virtual-dc/adds-on-azure-vm

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Diana Piloya 245 Reputation points

2026-07-13T04:30:36.2+00:00

I have carried out the steps you highlighted above ; the repadmin /replsummary command shows both DCs as the source and destination DSA with 0 fails. this command repadmin /showrepl shows a successful attempt. this command dcdiag /test:dns shows some tests are successful though at the end it returns broken delegated domain on all the visible DCs. Then when i run the netshare command on both DCs, the on-premises DC returns both sysvol and netlogon while the azure DC only returns sysvol. How can i resolve this?
Diana Piloya 245 Reputation points

2026-07-13T04:41:30.31+00:00

I have carried out the steps you highlighted above ; the repadmin /replsummary command shows both DCs as the source and destination DSA with 0 fails. this command repadmin /showrepl shows a successful attempt. this command dcdiag /test:dns shows some tests are successful though at the end it returns broken delegated domain on all the visible DCs. Then when i run the netshare command on both DCs, the on-premises DC returns both sysvol and netlogon while the azure DC only returns sysvol. The ipaddresses are not overlapping. So for the DNS configuration; the setup for custom DNS is on-premises DC ip while the virtual network on azure is in the snapshot. How can i resolve this?
Marcin Policht 108.6K Reputation points MVP Volunteer Moderator

2026-07-13T11:05:36.8+00:00

Change the DNS servers settings in the Azure VNet to use the Custom option - and point to the same DNS servers (IP addresses) you are using on-premises.

Note that Azure VMs must be restarted for the DNS servers configuration to take effect

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
Diana Piloya 245 Reputation points

2026-07-13T15:29:02.8066667+00:00

what of this custom DNS on the azure DC network interface. it is the on-premises DC. should i keep it that way or change it to the azure ip address.
Marcin Policht 108.6K Reputation points MVP Volunteer Moderator

2026-07-13T16:39:09.4933333+00:00

Use the on-premises DC IP address

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
Diana Piloya 245 Reputation points

2026-07-14T14:39:20.6+00:00

I have updated the DNS and restarted though, netlogon is not visible yet on the azure vm yet the service is running and this is the only

error in event viewer.