Hello all,
I have inherited a Server 2012 Essentials environment at a customer's, and I am currently trying to migrate to Server 2019 Standard. From all I read it should be a normal procedure except for leaving the FSMO roles up to the last minute. I checked that sysvol
replication was on DFSR and then introduced the new DC. Regular AD replication is fine (repadmin reports all DCs up to date). However, sysvol was not being replicated and I went to check deeper.
SYSVOL looks complete, junction points are good, state of DFSRMIG is "eliminated" so DFSR should be used. Now the new DC is waiting for initial sync, and the old DC shows no errors, but it seems the sysvol folder is simply not a known replicated
folder on that system.
As sysvol is basically healthy, I did a backup of the files and tried the steps in this article:
https://support.microsoft.com/en-us/help/2218556/how-to-force-an-authoritative-and-non-authoritative-synchronization-fo
It goes well up to the point where I should see event 4602 in the DFSR event log of the authoritative DC after doing the dfrsdiag pollad. Checking with
wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state
on the old DC (of course after reverting the ADSI changes) I get "No instance(s) available". I found that this problem can occur when the DFSR database is corrupt after disk problems, but neither have I found any indication of this (there should
be a warning 2213 or such in the event logs, but there isn't) nor am I able to "ResumeReplication" on any of the GUIDs I found in the DFSR config (in System Volume Information). I tried the folder GUID, the replication group GUID as well as the volume
GUID, but each attempt only reports "no instances available".
Further checking the DFSR config files is seems as though the Replication group is known, I can also see it in the DFSR console. Running a health report there I get the message which basically says the same as "no instances available", namely that
the folder is not in a replicated state on the original DC.
Now I am faced with a decision to either try to repair the state of the original DC or (without being sure this is possible) force the new DC to just skip initial sync and let me seed the sysvol manually. So I have two questions and I really hope anyone
can help me out here.
1. Is there any obvious solution I am missing in my attempt to repair the DFSR on the old DC?
2. Can I force the new DC to skip initial sync by making it authoritative? Then just copy the sysvol contents where they belong? Has anyone tried this on a completely new DC? I am wondering about the implications here and how to go about sharing the SYSVOL
and NETLOGON as those are not shared right now, of course.
Thanks everyone in advance!
Claudia