Hello, this is David, principal Engineer at Dell.
And today, I'll be covering
performing an authoritative sync of SYSVOL
using the File Replication Service, or FRS.
As mentioned in the non-authoritative video,
FRS has been deprecated for a while now,
but it is still around, and it does still break.
In an authoritative sync,
you tell a domain controller to initialize FRS
using its copy of the SYSVOL data,
rather than copying it from another domain controller,
as in a non-authoritative sync.
We're back in our two DC domain here,
and as you can see, we're on DC2
And if we run "net share" in here,
we'll see that there's no "SYSVOL" or "NETLOGON" share
indicated in the output.
And this is common if a domain controller is promoted
after FRS has broken on another domain controller.
It will never replicate SYSVOL,
and therefore it won't create the shares.
If we look in the "Event Viewer" on this one,
we'll see an event saying "File Replication Service
is having trouble enabling replication
from DC1 to DC2 for the SYSVOL content."
And often when you see this error on a domain controller,
it means the real problem is on its replication partner,
in this case DC1.
So, let's take a look at DC1.
If we run "net share" here,
we see it does have a "NETLOGON" and "SYSVOL" share.
So, that part is working okay.
But if we check the "Event Viewer," we see this error here,
"The File Replication Service is in an error state."
Just like any other video,
this is an artificially created error.
The error message you get may be different,
although in this case, FRS really is broken.
I just manually broke it.
So you may see other events here indicating it's not working.
We go to Group Policy Management,
and we can see there are five GPOs in this domain.
And if we go into the SYSVOL folder
in File Explorer, we see we do have five GUID folders
corresponding to those GPOs.
As we did before, we could go through
and look at the properties of each GPO
and confirm that those GUIDs
match the GUIDs in their "Settings" tab.
But there's no need to do that this time.
Just trust me, they do match.
So, what we'll need to do here,
because the problem is on DC1,
and DC1 actually does have the GPOs,
we will need to perform an authoritative sync.
First, we'll need to stop the File Replication Service
before we make any changes.
It takes a few seconds to stop.
Next, we go into "Registry," and once again we're at
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\NtFrs\Parameters\Backup/Restore\Process at Startup."
And we're looking at that "BurFlags" DWORD value again.
If we modify this to perform an authoritative sync,
we'll set it to D4 hex instead of D2
for non-authoritative, and that corresponds to 212 decimal.
Once we do that, we start the File Replication Service.
Wait for it to start.
And if we go back and "Refresh" the "Registry,"
we'll see that "BurFlags" has gone back to zero,
which means it has done something.
Now, if we go to Event Viewer,
we can see that there are new events in the FRS event log.
So we will refresh, drag this down so you can see more,
and go back to our last error.
That was the event that was there before.
Just scroll through these one by one.
We can see the service is stopping, has stopped,
is starting, deprecated.
As I mentioned, we already knew that.
And then we'll see that same warning about
a write cache, which we can ignore.
And then we get to this one, "File Replication Service
is scanning the data in the system volume."
"Can't become a domain controller until that's complete."
It means we're getting there.
Next event successfully added the computer to the replica set.
Then successfully added connections to the replica set.
And since we only have two domain controllers,
inbound and outbound connections go to DC2, since this is DC1.
And finally, we see event "13516," which is our all-good event.
"File Replication Service is no longer preventing
the computer from becoming a domain controller."
Run "net share" again, and we see nothing's changed here.
It had a SYSVOL in "NETLOGON" share
to begin with, and it still does.
If we go into the "Policies" folder in File Explorer,
we see nothing has changed there either.
Those same five GUID folders are still there.
And that's as expected.
If we switch over to DC2,
we see now its FRS Event Log has some new events.
So, we go and "Refresh" that log.
And the "13508" event was our last warning.
"13509", I've never been sure why this is a warning
because this is actually a good event.
As you can see, it says
it's enabled replication after repeated retries.
That means something's working now that wasn't working before,
so I'm not sure why that's classified as a warning.
But then we have the "13516" info event here too saying
that FRS is no longer preventing it from being a DC.
If we run "net share" again,
now we see we have "SYSVOL" and "NETLOGON" shares.
And if we go into the "SYSVOL" folder in File Explorer
and refresh "Policies," we see we do now have
the same five GUIDs here that we had on DC1.
This means that the authoritative sync on DC1
enabled DC2 to replicate SYSVOL content as we intended.
You may find in some cases that you need to perform
a non-authoritative sync on your other domain controllers
after you perform an authoritative sync on one of them.
But we didn't have to do that this time.
Once again, I'm David, principal engineer at Dell.
Thank you for watching.