2

I've inherited two horrible servers (don't ask), and it turns out that it uses FRS to replicate the sysvol between the PDC and the second DC. (I checked the registry key)

I tried using https://docs.microsoft.com/en-gb/windows/desktop/VSS/backing-up-and-restoring-an-frs-replicated-sysvol-folder which is very helpful and informative, however, after I tried the non-authoritative D2 restore my sysvol folder contents just got deleted and the share itself got removed as well if you can believe that. It did save the pre-existing files in it, however, after a 2nd D2 restore it even deleted those. (good thing I backed all of that up)

Why would this delete the share even, I can understand it deleting the contents of the folder as that's what it's supposed to do, but the share itself?

Both servers are 2008 R2, no idea if they were 2003 before.

Any thoughts?

Is it because I didn't perform "Step 2 Restore the backed-up data to the SYSVOL folder."? That step did not seem listed anywhere else online and didn't make much sense since data should just resync from the good sysvol on the other server, right?

1

This may not be quite an answer and I would comment but lack reputation. I just finished this process on a pair of Windows Server 2012 R2 domain controllers, also still using FRS to replicate SYSVOL. The result was successful and SYSVOL is replicating fine for me now (original issue was it had entered JRNL_WRAP_ERROR state for some reason I was unable to determine).

I believe you are supposed to specify an authoritative server in lieu of a non-authoritative server. That way, the authoritative server will tell other replica member(s) to receive its "authoritative" data set. If you set D2 on both, neither of them will assert that they have the proper files so I can imagine that the result would be what you described where there is no authoritative source, and so they wipe themselves out and put the contents in the pre-existing folder (that is also what my non-authoritative server did when set with D2). I believe D2 is really designed to receive a healthy data set from a D4 server.

I think that's it, you needed an authoritative source. As an aside, I practiced this in a test environment and even when using D4 on one server and D2 on another, SYSVOL was wiped clean on both servers (I think due to how domain controllers really lose their minds when restored from a full VM backup like I had done, but I'm not sure). What I did was to restore all my GPOs using Restore-Gpo -All -Path C:\Path\To\GPO\Backups in PowerShell and manually create the "scripts" folder in C:\Windows\SYSVOL\domain which was shared as NETLOGON automatically after a reboot. This fixed my replication issues and kept all my GPOs intact. Even GPO links were fine after restoring GPOs.

So, if you have a backup of your GPOs (which you can create using Backup-Gpo -All -Server localhost -Path C:\Path\To\Gpo\Backup)or even a backup of the server which you can spin up on an isolated network or hypervisor then you can use the GPO backups to restore them, and manually create the scripts folder. That brought me back to normal when practicing in test. Good luck if you're still struggling with this.

| improve this answer | |
  • Thank you very much for that, it's fallen off the radar in terms of importance now but I'll give it a go at some point when I have a moment. Thank you! – user757392 Jul 11 '19 at 14:47
  • Let us know how it goes. I'm curious, what did you end up doing to recover your sysvol? Did you start from scratch and recreate GPOs? – Dusty Vargas Jul 11 '19 at 14:49
  • absolutely nothing, just left it as it is as we're upgrading to server 2019 during the summer anyway... in the meantime we're manually copying policy files between DCs if we need to... – user757392 Jul 11 '19 at 14:52
  • Yikes. How is Group Policy faring in this state? Working? Are you manually copying GPO files between servers? – Dusty Vargas Jul 15 '19 at 17:24
  • Hi @dusty_vargas, yes, we are manually copying changes between DCs and sites. Only one month to go until the whole thing is ditched... – user757392 Jul 22 '19 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.