AD Replication Troubleshooting steps (DNS)

 

Quick Checks:

-Check and confirm the network browsing is working and it has not changed your firewall to public

-Use Event Viewer to get more detail. It is the easiest quick resource but note the timeline of the errors many times you will see errors as the server is booting up and initializing. Ignore those and pay attention to the logs after full boot up completes. (i.e. don’t chase your tail)

-Most alerts are generic in their details/description. Make sure you are addressing ones that matter for your current AD forest and domain level. If it doubt escalate to someone that knows. You can melt down your domain by following bad online advice.

-Check DNS settings on the network interface and point your DC to another DC first then itself second. There are different views on this but I do so to avoid DNS isolation.

-Know your FSMO Role holders. If you don’t know what FSMO role holders are you should not be learning on production. Quickest way to check them is:

NETDOM /query FSMO

-if you need to transfer FSMO Roles see my FSMO posts.

Open a command Prompt as an admin

repadmin.exe /showreps

- this will show DCs listed in domain

repadmin.exe /replsummary

- This will give you a DC replication summary

On DCs run “dcdiag” for a quick searchable summary

- The following command will export a detailed diagnostics to the path specified

DCDIAG /e /v /c /f:C:\DCDiagReport.txt

-you can then review those for errors and more detail. This report takes a few minutes to run, longer with more DC’s and/or errors/retries.

 

The following is a recent real AD replication issue I troubleshot:

I was getting the 1722 RPC service error below on repadmin.exe /replsummary:



This is a generic error that can mean lots of communication issues.

In this case I confirmed that the RPC services were running and set to Automatic as expected

From the errors I saw in DCDiag I ran a quick command on DNS

DCDIAG /TEST:DNS

-be patient with this test it takes a few minutes

On one DC it reported no errors. On the other server it took longer but was filled with errors. One in particular caught my attention:



It caught my attention because 192.168.1.22 in this case is NOT a current DC or DNS server.

I then confirmed the troubled  servers network interface had the wrong DNS address.

That was causing it to query to nowhere and thus break replication.

With the change to a correct DNS server all errors were cleared and replication started working perfectly

Final Note to remember:

IT'S DNS! Even when it can't be DNS, IT'S DNS  

Comments

Post a Comment

Popular posts from this blog

Office 365 Deployment Tool Office Download fails “Could not Install”

Image
Problem: you run the setup.exe /download download.xml and fails immediately with “Couldn’t install” You make sure all the settings are correct (see other blogs) and find nothing wrong Solution: Change drives and run it as an administrator again. For example above i am in the F:\OfficeDeploy directory which is the same directory I have the download.xml directing the download to. If i Change to the c: and run the same command again it works The Office Data folder was created and updated as shown below:
Read more

FRS to DFSR Post Cleanup “File Replication NtFrs Stopped”

Image
After successfully migrating from FRS to DFSR you get the File Replication NtFrs service is Stopped error on the local servers AD DS Services list. In the Event logs you may see Event id 13575 13577. You can confirm your migration completed by opening a cmd prompt as administrator and typing in: dfsrmig /getmigrationstate After your migration to DFSR is completed and you have given your servers ample time to propagate this service is no longer required. Since it is set to “Automatic”, as shown below” it shows in logs as a false positive error. Edit the File Replication Service and change it to “Disabled”, as shown below: Once it is listed as “Disabled” it will no longer show in the Console as an “error” Note : it may take some time to clear from the active view
Read more

Domain Migration SubinACL /Migratetodomain How To:

Caution : DO NOT run this on Domain Controller C:\ and only run on roaming profiles folders, or my docs shares day of migration to avoid ownership change issues. Confirm Domain trust is in place and users and groups have been migrated Test ping of olddomain.org from new domain Test ping of newdomain.org from olddomain Add newdomain.org domain controller host records to olddomain.org including reverse DNS records Confirm the user running the app is a domain admin in BOTH domains Download SubinACL here: http://www.microsoft.com/en-us/download/details.aspx?id=23510 /Migratetodomain- command will add the permissions of the new user to the old files and folders for example if jimbob@olddomain.org was migrated to the new domain jimbob@newdomain.org and you run the command below any file or folder in that path that has jimbob@olddomain.org will add Jimbob@newdomain.org with the exact same permissions. This is a safer way to migrate by keeping the old and new permissions intact while a
Read more