June 23, 2017 at 9:52 am #167084
So I had a server blow up AD last night, it lost some registry keys that I was able to recreate then let it repair.
This server is now inconsistent in its FRS to DFRS migration state. The network was migrations years ago.Quote:dfsrmig /getglobalstate
Current DFSR global state: ‘Eliminated’
The following Domain Controllers are not in sync with Global state (‘Eliminated’):
Domain Controller (Local Migration State) – DC Type
****** (‘Preparing’) – Primary DC
Migration has not yet reached a consistent state on all Domain Controllers.
State information might be stale due to AD latency.
If I run the same on the second domain controller I get:Quote:C:Usersdolphinict>dfsrmig /getmigrationstate
Unable to create DFSR Migration log file. Error 1307
Unable to connect to the PDC emulator. Make sure that the
PDC is reachable and retry the command later.
I’m assuming this is going to cause problems – if one DC is using an ancient copy of FRS and the other the current DFRS then nothing good can come of it. I don’t want to roll back the migration and re-run it incase it over-writes the current DFRS with an old FRS. Anyone got easy steps to knock the out of sync DC back into the state it should be in?
The FRS service has been stopped since May 2014 and dcdiag is throwing errors about FRS information missing and indeed there is only SYSVOL_DFRS so effectively I just need to tell the server to use DFRS without going through the migration process…June 26, 2017 at 3:35 am #362672
An update on this one, this part of the issue is now resolved although there are other things that need cleaning up.. I’ve been poking through the registry comparing with another similarly configured server.
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDFSRParametersSysVolsMigratingSysVolsLocal State was set to 4 so I changed it to 3
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetlogonParameterSysvolReady was set to 0 so I changed it to 1
This got DFSR back up and running and replicating the SYSVOL folder
I then went into ADSIEdit and verified that the DFSR-LocalSettings and DFSR-GlobalSettings were as expected. They were so I went to Google and looked for anywhere else that may hide similar settings.
I was effectively most of the way through this document – https://technet.microsoft.com/en-us/library/dd639789(v=ws.10).aspx having figured out all of the registry stuff. It did point me to the attribute editor for DFSR-GlobalSettings and DFSR-LocalSettings and msDFSR-Flags.
DFSR-LocalSettings for the DC in question was set to 64 (Preparing) so I changed it to 48 (Eliminated).
This then made dfsrmig /getmigrationstate report all DCs in eliminated state and migration succeeded.
Sysvol was then shared out.
So now the only evidence of there being a problem is an Exchange error (This is an SBS server) saying:
“Unexpected error The local machine must be a Kerberos KDC (domain controller) and it is not. ID no: 80090339 Microsoft Exchange System Attendant occurred.”
You must be logged in to reply to this topic.