AD/SYSVOL Sync Issues

Hey you Experts!

I need your expertise. Let me first explain our setup, followed by what I've tried to remedy the issue. I apologize for the length, I've tried to include only the most relevant info right off the bat. We have 3 DCs (2 virtual, 1 physical). They are set for redundancy, we are doing a mix of virtual/physical simply to have a hybrid environment for fault protection. We had Windows Server 2008 loaded up on all of them, we started having replication issued, the physical box failed, and was replaced with 2012 R2. We have planned on moving the other two boxes to 2012 R2 (either 1 virtual, or continue with 2 virtual) but have not done so yet. The replacement kept the same IP/host name but a proper DCPROMO was done. We are a small/medium sized school district if that helps in any way (down time from users in the summer for big projects/cost/etc).

We are using FRS rather than DFS. We have Windows Firewall enabled for our DCs. I can't think of any other helpful info at the moment, so I will now pose my issue followed by what I've tried.

Here are some symptoms: Our GPO environment is faulting. On the GPC side, a change will be made, but the GPT side (SYSVOL) sometimes will not show the same change. For example, I delete GPO_Test from GPC, but GPT still has the stagnant entry. Another symptom is GPOs (when running a gpresult) with a test user/machine, with log-on/log-off in between, will either show that it was Approved/Denied or just not even processed at all, completely MIA. Ok, so here's what I've been looking at, and what I've tried..

*ACL/Security permissions issues.

*AD/SYSVOL (GPC/GPT) sync issues.

*File Replication issues.

For security, I checked group membership/ACL permissions/etc and everything looks fine. I checked security filtering on the GPO to make sure it's applied against the right users, it's fine. Of course, I made sure the GPO is being applied to the right OU and the user is in that OU (link established), and it's good.

For sync issues, I checked the DS/Computer versions and so forth and it all shows as the same versions/revisions. I ran gpotool.exe and it came back with the versions/etc. I did run a PowerShell script for orphaned GPOs, and found some. I checked to make sure they were truly orphans and did a clean up, re-ran the script and now show no orphans.

For replication issues, there are events in Event Viewer that there are replication issues (even before the physical DC swap), but nothing extremely specific or overall very helpful. I've run dcdiag on all three boxes and it says FRS is fine. I've checked on all three boxes to make sure FRS as a service is started and running.

I can't think of anything else relevant to put into this discussion. At this point, ANYTHING will help. Thanks!
LVL 1
-Garren-Asked:
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.

Guy LidbetterCommented:
Hi Garren,

Have you considered running DNSLint to diagnose any replication issues between you DC's?
An explanation of the tool and how to use it is below.

https://support.microsoft.com/en-us/kb/321045/

I also assume you have run a Repadmin and all reps are looking good?

Regards

Guy
0
BembiCEOCommented:
Just some thoughts...
So, the client errors do not really wonder, as they can take one time the one DC another time the other one. But you said, that replication issues happened before, so I would first follow the path to repair them.

Maybe this error list helps a bit to analyse the errors.
https://msdn.microsoft.com/en-us/library/bb727056.aspx

I also assume, you demoted the old physical box before you replaced it, right.

According to your GPOs, make sure that the DCs doesn't catch GPOs for other servers, I would strictly separate the Domain Controller policy from all others, so keep an eye on the global default domain policy.
And rather to filter them possibly better to try to separate them via OUs. Filters (esp. WMI filters) makes GPOs slow.

Have you checked the FSMO roles? Are they all present on a life system?

One fast solution maybe to choose the best DC (most complete) and to demote all others. Make sure they are completely away from the AD of the remaining DC. Then promote them again what should put all DCs into a clean state. The disadvantage of this is, that you may loose some settings, which stopped replicating if changes are made on different DCs.

Another way maybe to dig more into the deepness and try to find the items, which maybe responsible  for replication issues. Check if all AD changes replicate between the servers. If you can reduce the replication issues only to GPOs, you may filter them on the clients, which are sometimes not applied or you can compare them. Delete these GPOs, make sure they are away on all servers and then recreate them. The GPOs are also written (with their UID) into the AD, so there you may see, which GPOs are present and which not. Compare these settings possibly by connection to the AD using different servers. A good tool for this may be ADExplorer from sysinternals tools suite.
0

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
arnoldCommented:
your first step should be to identify which system is reflected in the AD as having the master roles.

Your issue is likely the result of the physical (whose name/ip you kept) and likely was the primary master on various roles.

Role transfer should have been done through seizure using ntdsutil making one of the VMs as the primary on the various RID,SChema, etc.
Then when you rebuild the physical, you can do with it as you see fit.

If the above is correct, you would need to rebuild the physical yet again because you would need  to use one of the VMs to seize the roles which means the newly rebuilt system can not be put online without OS reinstall. Make sure to backup the system state on one of the Vms just in case.
Not sure whether demoting the physical and possibly disjoining from the AD domain, seizing the roles/cleaning the metadata of any reference to the old name. Then making sure your VMs are not having replication issues.
Add the physical back as a new member server, and then dcpromo it as another DC.


Do both the VMs have the fileserver serivces for windows 2003 installed?
Does each Vm have the syslog/netlogon shares?
0
-Garren-Author Commented:
A good starting point, there is some deeply rooted corruption I've noted over the last couple weeks from running various AD tools from Technet and others. I'll close this ticket as there is a very long process I'm going to have to go through.
0
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.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.