We are following Microsoft's Migrating SYSVOL to DFS Replication on our Server 2008 R2 servers so we can do move over to Server 2019. We started it on 8/12/2019 and let it run over the week to check for errors. I don't have a test environment to try this in so wanted to make sure it doesn't break anything.
We are currently in a succeeded Redirected state. Everything went smoothly up to this point. The SYSVOL_DFSR folder has been created on all 3 writeable domain controllers (no RODC's) and I have tested replication by placing a new file in that folder and watching it replicate over.
I have also ran Health Reports, Propagation tests and propagation reports. I ran a separate propagation test/report for each domain controller. They show zero errors and a 92.18% reduction in bandwidth for all 3. Propagation tests are also successful.
repadmin /replsummary shows there are 0 fails and 0 errors on replication.
AD Replication Status Tool shows no errors.
DCDIAG passes all the tests except for NCSecDesc, but I've already looked up those errors and it shows they are benign, I think because we aren't using any RODC's.
'FRSDiag` with all options selected shows these errors, everything else passes. I believe the FRS Log errors are simply that I didn't run FRSdiag as an administrator before.
Checking for errors/warnings in FRS Event Log ....
NtFrs 8/12/2019 1:05:32 PM Warning 13518 The File Replication Service did not grant the user "tladm" access to the API "Get Internal Information". Permissions for "Get Internal Information" can be changed by running regedit. Click on Start, Run, and type regedit. Expand HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Services, NtFrs, Parameters, Access Checks, and highlight "Get Internal Information". Click on the toolbar option Security and then Permissions... Access checks can be disabled for "Get Internal Information". Double click on "Access checks are [Enabled or Disabled]" and change the string to Disabled.
1. Are there any other replication tools I should be running to ensure that going to the eliminated state won't have any hiccups.
2. These are VMWare virtual domain controllers and use Veeam to backup only the primary domain controller w/ FSMO roles. Microsoft suggests using backing up the system state with wbadmin start systemstatebackup. I haven't used wbadmin in over a decade. Should we do this or just use the full, active backup from Veeam? Some best practices for this would be useful in the event we have to roll back. Would a VMWare Snapshot be an alternative?
