Forum Discussion
nikitamobile855
Apr 14, 2022Brass Contributor
DFS replication issues
Hello everyone, We are running Windows Server 2016 as a Primary Domain Controller. We don't have DFS management tool installed however I'm getting 6002 errors in event viewer. Please advise on h...
- Apr 20, 2022
Thanks, Nikita. That helped a great deal and saved a lot of time.
I'll start at the end and work backwards.
You want to run these commands to clean up what is a very broken DFS-R configuration. I'll provide an in-depth explanation after the commands
Remove-ADObject -Identity "CN=45d9316b-1098-408e-a65d-8ce8449f0aaa,CN=DFSR-LocalSettings,CN=UZTASSRV01,OU=Domain Controllers,DC=sm,DC=local" -Recursive -Confirm:$false; Remove-ADObject -Identity "CN=a7297769-fdcd-4490-ae1c-c80808f44d36,CN=DFSR-LocalSettings,CN=UZTASSRV01,OU=Domain Controllers,DC=sm,DC=local" -Recursive -Confirm:$false; Remove-ADObject -Identity "CN=DFS,CN=DFSR-GlobalSettings,CN=System,DC=sm,DC=local" -Recursive -Confirm:$false; Remove-ADObject -Identity "CN=DFS_IT,CN=DFSR-GlobalSettings,CN=System,DC=sm,DC=local" -Recursive -Confirm:$false; Remove-ADObject -Identity "CN=UZTASSVR02,CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=sm,DC=local" -Recursive -Confirm:$false;
Overview
What the JSON output you provided showed is:
- There are no DFS namespaces configured;
- The DFS replication group definitions are badly broken in places;
- The "built-in" SYSVOL DFS-R definition is fine but contains an orphaned reference to a domain controller no longer in existence (UZTASSVR02);
- Three DFS replications groups are defined:
- DFS;
- DFS_IT;
- Domain System Volume.
Approach
There were two options I could have pursued:
- Add the missing "MemberReference" values onto the existing "msDFSR-Subscriber" objects; or
- Delete the DFS and DFS_IT DFS replication groups.
I have chosen option 2 since:
- There is no associated DFS namespace;
- The replication groups would only have a single member, which is pointless;
- It provides you with the cleanest outcome, since you can always create new DFS namespaces and replication groups if you decide to later on, and you won't have to worry about old, corrupt data lingering around.
Explanation of each command
Line Comment 1 Removes the orphaned subscription to the "DFS" replication group from UZTASSRV01. 2 Removes the orphaned subscription to the "DFS_IT" replication group from UZTASSRV01. 3 Removes the "DFS" replication group. 4 Removes the "DFS_IT" replication group. 5 Removes the orphaned UZTASSVR02 reference from the "Domain System Volume" replication group. Once you have removed these objects, it will take DFS-R a little while to recognise the changes.
If you want to hurry the process up, you can do any one of the following:
- Restart UZTASSRV01 (since it's the only remaining host); or
- Restart the the "DFSR" service on UZTASSRV01; or
- Run the following command on UZTASSRV01 (it may not be installed though, which is fine):
dfsdiag pollad
Anyhow, once you've either waited a bit or hurried things up, you should find the Event Viewer errors stop.
Cheers,
Lain
LainRobertson
Jun 11, 2022Silver Contributor
Okay, the command output is good. You can safely also remove those two leftover objects from the output, which will bring the FRS era completely to a close.
The main thing I didn't want to see - and we didn't, is any kind of direct or indirect reference to IOS-SEA-A1. So, life is good(-ish.)
From the Microsoft Docs article, assuming you're running the commands from IOS-SEA-A1 (while also ensuring things like ADSIEDIT are specifically pointing to IOS-SEA-A1), then for steps 2 and 6, use the following statement to push changes outward from IOS-SEA-A1 to the other domain controllers:
repadmin /syncall IOS-SEA-A1 DC=iosdomain,DC=local /d /e /P
The confirmational events are described in steps 4 and 8, but that doesn't help with your question on how long to wait.
The answer to that is: you don't have to wait since you're only dealing with a single domain controller. So long a you see the events listed from steps 4 and 8, you've done everything correctly.
Of course, it takes SYSVOL some time to repopulate and even then, if you find it fails again as you have before, then we might be at the point where you have to delete the DFS-R database off of IOS-SEA-A1.
While Microsoft does discourage this in favour of the process above, the process above also doesn't fix every kind of issue, meaning that's the direction we're heading.
Still, I'd do the above Docs process once more, being sure to note the events (maybe clear the DFS-R event log first to make things easier to digest and track) before looking to delete the database.
Rest assured, deleting the database isn't all "impending doom", either. Microsoft does note some issues that can arise but they're outweighed by getting DFS-R working again.
The directory the database resides in will throw an access denied if you try to access it, but as per the following article, it really is there (read under the Symptoms heading at the top.) But let's not get ahead of ourselves as maybe the Docs article above will help this time around.
DFSR databases crash on primary member - Windows Server | Microsoft Docs
Cheers,
Lain
Zalastar
Jun 11, 2022Copper Contributor
Ok its my under standing to go through the steps again but running the altered repadmin /syncall command you provided. And just to be clear. I am setting the flag to False on the affected DC which is Seattle , which makes in non authorative, and leaving the others set to True
Im not understanding how to do this
" You can safely also remove those two leftover objects from the output, which will bring the FRS era completely to a close."
Do you mean for me to find and delete them with ADSIEDIT or will following the above process and using that Repadmin command take care of this? i a not understanding where those references in the output came from
I am running everything on the Seattle controller at the moment. The PDC is the PS-I-AD1 DC but I understand for the most part that the work I am doing needs to be done on the affected DC, which is Seattle