SYSVol replication issue

I have two 2012 domain controllers that are having SYSVol replication issues and I have read though a lot of the articles on here as well as mass google searches and nothing seems to be helping. I currently have 11 GPO's and on dc01 the sysvol folder as them as well, but when I go to the seconf DC it has all of the old ones. And when I open the domain\sysvol folder it lists all of the old ones as well. What is the harm of manually deleting the ones that are no longer current or is there a way to get the replication to kick in. I am attaching screenshot's of both dc's, the domain SYSVOl as well as the GPO list.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Lionel MMSmall Business IT ConsultantCommented:
To me it sounds like there is a replication issue that should have errors in the vent logs to point you in the right direction as to why they DC are not staying in synch. I would recommend exporting and importing the GPOs instead trying to copy the folders from one DC to another
VB ITSSpecialist ConsultantCommented:
What steps have you done to try and troubleshoot the replication issues? Have you ran the dcdiag and repadmin tools to check for any issues?
From Picture you shown, it seems that actual GPO count is much less than actual folder count, I guess its orphaned GPO issue
Have you checked GPMC on both servers, is it showing same GPOs on both DCs?

A GPO typically becomes orphaned in one of two different ways:
1.If the GPO is deleted directly through Active Directory Users and Computers or ADSI edit.
2.If the GPO was deleted by someone that had permissions to do so in AD, but not in SYSVOL. In this case, the AD portion of the GPO would be deleted but the SYSVOL portion of the GPO would be left behind.

Run PowerShell script in below blog on PDC Master server to identify all orphaned GPOs and its respective folders and just delete those folders from Sysvol

I have used above script many times and its works just fine

U do require 2008 R2 DC server at least to run script

After you remove all orphaned GPO folders, force sysvol replication and check the difference between both servers
If still there is difference, probably sysvol is not replicating correctly
In that case do sysvol non authoritative restore on another DC (Non PDC)
To do sysvol non authoritative restore follow below article - If sysvol is running through FRS - if sysvol is running through DFSR
Check below article for correct sequence to non-authoritatively restore Sysvol-DFSR

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

Kelly-BradyAuthor Commented:
These are great suggestions and I will try this first thing Monday morning.
Kelly-BradyAuthor Commented:
This is what I have tried, in the following "primary" refers to the DC that holds the PDC Master and Secondary refers to the second one.

OK I have run the DCDiag and it is stating that there is issues with SYSVOl replication, I also ran the repadmin, the script mentioned by Mahesh. I ended up running that script on both DC's to see what the difference would be. The only;y thing I did not try was exporting out the GPO's from the primary and importing them into the secondary. Not sure if that would be the best option right now or would it do any harm to it to try?

I did check GPMC for both DC's and they both show the same GPO's within the GPMC

Attaching all files from the commands that were run.
Kelly-BradyAuthor Commented:
I even tried to to start the DC in DRSM and do a restore and rebuild of the SYSVol folder but when I logged in as the remote admin it would not let me delete the SYSVol Folder. So that is not going to work.
Do not restore any folder from backup
Because you don't know from when the issue started and which backup can fix it.
 From orphaned GPOs its looks like there are almost 33 folders in sysvol which are orphaned on secondary DC and six on primary DC
U can delete orphaned GPO folders from secondary, but it will not fix replication issue, it is some thing kind of Journal wrap issue.
In my opinion, demote secondary DC gracefully / forcefully if unable to demote correctly followed by Metadata cleanup and then again run orphaned GPO script on primary DC and find out orphaned GPOs
Then remove those orphaned GPO folders, reboot the server, if GPOs are populating correctly I GPMC and again check with script if it finds any thing.
If you don't find any new orphaned GPOs now, its good to go to build another ADC and check if every thing is working as expected
Do not use same name for new DC as earlier, it might create new issues
I hope Exchange server is not installed on DC being demoted.
Kelly-BradyAuthor Commented:
No there is no exchange server in the environment. So when I demote this what will happen to those machines that are using the demoted DC as there logon server? Is there a script or command line option to force them all to use the good DC?
Probably you could do this in off business hours to minimize impact.
Ensure that healthy DC is preferred DNS server on client workstations (probably you can do this via DHCP if exists or manual intervention is required), and do this activity within off business hours.
After demotion of server do not forget to remove all NS records, Host(A) records, PTR records, (same as folder) records, SRV records for demoted DC from healthy DC
This will ensure that client will logon to healthy server only even if you need more time to deploy another DC after demotion.
Kelly-BradyAuthor Commented:
Would it make sense to get another healty DC up and running before doing this, maybe migrate from server 2012 to server 2012R2?
U don't want to get into scenario (Risk) where only 1 DC left for time being
Ideally I would not prefer to introduce new DC in existing environment where both DCs are having problem.
Do not try to install 2012 R2 in 2012 AD, it will require additional configuration and increase complexities
However, you can try below.
U can introduce new ADC on new 2012 member server and do not forget to select healthy DC under additional options in dc promotion wizard so that new DC will be promoted with replica from healthy DC and then try to remove faulty DC followed by cleanup Sysvol mess from new and healthy DC as well with the help of script
Kelly-BradyAuthor Commented:
I will do as you suggested and I will not add a another DC to the environment. It probably is best not to muddy the waters with another DC until the faulty one is removed and we have a healthy environment.
for safer side take system state backup of primary DC before you demote secondary DC and keep it in safe place
Kelly-BradyAuthor Commented:
I will have to schedule this over the next few days, and I will let you know the outcome.
VB ITSSpecialist ConsultantCommented:
Sorry but demoting a DC and creating a new one to troubleshoot SYSVOL replication issues is a bit overkill in my eyes. There's also no point doing this if the replication issues are on your main DC, as any other DCs you introduce into your environment will most likely just experience the same issue.

Have you tried installing the Distributed File System management tools on your machine and running the diagnostic health and propagation tests and reports? This should give you a bit more insight as to why SYSVOL isn't replicating between your DCs.

If you don't have the tools installed, you can add it by going to the Add Roles and Features wizard through Server ManagerFeatures > expand Remote Server Administration ToolsRole Administration Tools > expand File Services Tools > tick DFS Management ToolsInstall.

Once you have installed it, open the DFS Management console and then click Create Diagnostic Report in the Actions pane on the far right. Follow the instructions in the wizard to create the health and propagation reports then return here with your findings.

Also have a look at the logs in the Applications and Services LogsDFS Replication area in Event Viewer for an warning/error messages and post them here.
Kelly-BradyAuthor Commented:
I ran through those and it helped resolve a few issues but it did not give me a place to go with the replication. Here are the files.
VB ITSSpecialist ConsultantCommented:
Anything in the DFS Replication logs? Make sure you check on both DCs.

Did you run the tests on both DCs as well?
Kelly-BradyAuthor Commented:
I am attaching the screen shots from the DFS Event viewer and those are the errors that I am trying to resolve. I also thought that the DFS test covered both the DC's, they were both listed on the "included servers" list
VB ITSSpecialist ConsultantCommented:
Have you tried following the steps in this article to try and force SYSVOL replication?
Kelly-BradyAuthor Commented:
Yes I did but I am more then willing to try again, the question would be do I go with the Authoritive or the non-authoritive  option?
Kelly-BradyAuthor Commented:
This is where I had to hunt around

3.Force Active Directory replication throughout the domain and validate its success on all DCs.
             Getting the right command to force it was not the easiest, and how do you validate it?

4.Start the DFSR service set as authoritative:
              Ok starting the service is easy but to start it as Authoritative?????
Kelly-BradyAuthor Commented:
The non authoritative restore worked the this time. Not sure why it did not the first time but right now I do not care. Tested the replication with a test txt file and it replicated within a second. I appreciate your help.
VB ITSSpecialist ConsultantCommented:
Glad to hear it's working now. Strange that the authoritative sync didn't work yet the non-authoritative sync did.

Whatever the case, the answers to your questions are as follows:
3.Force Active Directory replication throughout the domain and validate its success on all DCs.
             Getting the right command to force it was not the easiest, and how do you validate it?
To force replication, I always use the steps outlined in this article:
To verify replication you can use this command: repadmin /showrepl - make sure you run this command in an elevated Command Prompt (i.e. right click on Command Prompt > Run as administrator)
More information regarding verifying replication can be found here:
4.Start the DFSR service set as authoritative:
              Ok starting the service is easy but to start it as Authoritative?????
You only need to do this if you stopped DFSR service while performing the authoritative or non authoritative sync. Did you stop this service while performing the steps in the Microsoft KB? If not, you can safely skip this step.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.