Domain has bad or corrupt sysvol, missing IPv6 DNS in gc, no GUID in registry for NTFRS

Two DCs in the domain, both have sysvol corruption that I can't seem to fix.  

For starters, sysvol in both had only the domain pointer, no polices or scripts subfolders.  I wanted to repair them by changing the registry settings to do a non-authoritative restore in HKLM\system\current control set\serives\ntfrs\parameters\backup/restore\process at startup and change BurFlags to D2.  

Imagine my surprise to see that the only thing in Ntfrs was Parameters and it was essentially empty.  So I used a reference DC from another domain to rebuild it.  But then I got stumped.  I don't know where to find the GUID value fr the replica sets subfolders.

Undaunted, I figured restarting File Replication Service (Ntfrs).  Much to my amazement, it was set to disabled on both DCs.  So I changed to automatic, thinking I had solved the problem.  Even more to my amazement, ntfrs will not start on either DC. I get an error 1053 service did not respond in a timely fashion. I bumped up the timeout value from 60000 to 100000 and still the same result.

Of course dcdiag craps out all over the place.  In particular, there are lots of SChannel errors, and the event logs are full of them, too.  I wasn't paying that much attention to them but could they be a conspirator in this?  Dcdiag just failed with systemlog test with a bunch of SChannel errors trying to reach the remote endpoint, and then failed again waiting for file replication service.  All other tests passed.

I mentioned in the title that any IPv6 AAAA records were absent in _msdcs zone for gc and pdc.  I also checked to see that all FSMO roles were on one server (the original one in the domain), and they were.  Just doesn't feel like a DNS issue though.

Now my questions I hope you can help me answer:

1. why won't ntfrs start on either DC?  If it were to, that would hopefully rebuild the registry.  Nothing in the event
2.  why the Schannel errors, or more precisely, how do I fix them?  Related to the other issues?
3.  what in particular is keeping replication from working?  FIrst server seems to have a correct sysvol, but not the second.  If I create private and scripts folders, NETLOGON wipes them out.

One last detail.  When I open DFS Manager and run a health report, the second DC (bad sysvol) shows as an error that the local path does not match the newly configured local path and a warning that the DC is awaiting initial replication of sysvol.  Let's just say its been a long, long time before this came to my attention.
Who is Participating?
MaheshConnect With a Mentor ArchitectCommented:
Are you saying that Sysvol is OK on PDC server? are you able to see event ID 4604 or 4602 ?
In that case Sysvol is working correctly on PDC...

If yes, now you should try non-authoritative restore on another server..
That should work

Also what about of Policies folder and its contents?
and where C:\users came in picture?

Also event id 5012 indicates that you might be having some AD replication /name resolution issue
Check AD replication and name resolution is working correctly
repadmin /syncall
check below article
have you upgraded your ad from windows 2003 or 2008?

If not, you are running DFSR sysvol and not ntfrs sysvol

what happens if you run below command from command prompt

Net Share

Is it showing sysvol and netlogon as shared folders?

You need to do DFSR sysvol authoritative restore 1st and then do non-authoritative restore

Refer below article for DFSR sysvol restoration

Also ensure that each domain controller point to itself own IP as 1st dns entry and other domain controller as secondary dns in network card properties and restart the netlogon service on domain controllers so that all missing DNS records will get recreated
have you upgraded your ad from windows 2003 or 2008?
If not, you are running DFSR sysvol and not ntfrs sysvol
This is very important. (Not trying to steal credit here, just reinforcing.) If this domain was created using domain controllers running 2008 or newer, the File Replication Service (FRS) most likely isn't being used at all. Instead, Sysvol is being replicated by using Distributed File System Replication, so don't worry about getting FRS to start.

DFSR has its own event log, so that would be a decent place to look for errors.

For starters, sysvol in both had only the domain pointer, no polices or scripts subfolders.
Does that mean that the Policies and Scripts folders are completely missing from the Sysvol\domain folder? If so, the authoritative/nonauthoritative restore procedure suggested by Mahesh above won't help, because there's nothing to restore. If one of the DCs does contain those folders in its Sysvol hierarchy, though (and those folders actually contain data), use that DC as the authoritative source and follow the steps in the link.
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

lmheimendingerAuthor Commented:
On the PDC, SYSVOL is now correct, and Mahesh's solution moved the ball significantly forward. SYSVOL seems to have replicated successfully.  Now replication on c:\users is failing because:

On the replicated server, I am getting 4114 event id that c:\windows\sysvol\domain has been disabled.
                                                                4304 "preventing from replicating a file due to consistent sharing violations

On the PDC replicating server, I am 5012 event id that "partner did not recognize the connection or replication group"
lmheimendingerAuthor Commented:
Yup, those events are showing up.  Polices folder seems replicated.

c:\users and c:\company are in the DFRS replication.  Essentials (Windows 2012 R2) is installed as a role and I think this is an offshoot of that.
Now non-authoritative DFSR Sysvol restore on ADC server should work, try that
Also ensure that AD replication and name resolution is working correctly
run dcdiag /v on both servers to check for any potential issues
lmheimendingerAuthor Commented:
close enough to fix replication thanks
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.

All Courses

From novice to tech pro — start learning today.