Forum Discussion

nikitamobile855's avatar
nikitamobile855
Brass Contributor
Apr 14, 2022

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 how to investigate further. Object CN could not be found from ADSI edit

 

 

 

  • LainRobertson's avatar
    LainRobertson
    Apr 20, 2022

    nikitamobile855 

     

    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:

     

    1. There are no DFS namespaces configured;
    2. The DFS replication group definitions are badly broken in places;
    3. The "built-in" SYSVOL DFS-R definition is fine but contains an orphaned reference to a domain controller no longer in existence (UZTASSVR02);
    4. Three DFS replications groups are defined:
      1. DFS;
      2. DFS_IT;
      3. Domain System Volume.

     

    Approach

    There were two options I could have pursued:

     

    1. Add the missing "MemberReference" values onto the existing "msDFSR-Subscriber" objects; or
    2. Delete the DFS and DFS_IT DFS replication groups.

     

    I have chosen option 2 since:

     

    1. There is no associated DFS namespace;
    2. The replication groups would only have a single member, which is pointless;
    3. 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

    LineComment
    1Removes the orphaned subscription to the "DFS" replication group from UZTASSRV01.
    2Removes the orphaned subscription to the "DFS_IT" replication group from UZTASSRV01.
    3Removes the "DFS" replication group.
    4Removes the "DFS_IT" replication group.
    5Removes 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:

     

    1. Restart UZTASSRV01 (since it's the only remaining host); or
    2. Restart the the "DFSR" service on UZTASSRV01; or
    3. 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's avatar
    LainRobertson
    Silver Contributor

    nikitamobile855 

     

    This isn't related to SYSVOL at all but another DFS-R replica that the domain controller once was/possibly still should be a member of.

     

    If it was removed, then it clearly wasn't successfully and cleanly removed, hence the attribute issue flagged as event 6002.

     

    If the domain controller is still meant to be a member of that replica (which ironically is simply named "DFS") then you want to put the distinguishedName of the domain controller computer object (what you're looking at in ADSI Edit: "CN=UZTASSRV01,OU=Domain Controllers,..." etc) into the "msDFSR-ComputerReference" on the object from the Event Viewer error (I'm not typing out GUIDs - it's the "CN=Topology" X.500 path).

     

    If the domain controller is no longer mean to be a member of the replica then you want to remove the object listed in the Event Log error from AD.

     

    Cheers,

    Lain

  • SYSVOL replication is done using DFSRS, not sure if that GUID is part of that. Do you have multiple Domain Controllers or just one? You can always install the DFS Management tools for more investigation

    • nikitamobile855's avatar
      nikitamobile855
      Brass Contributor
      Previously we had 2 but later second one was demoted and completely excluded from the network. All FSMO roles were moved to current DC. I wonder how it can be an error with DFS replication if DFS role is even not installed on current server?
      • Harm_Veenstra's avatar
        Harm_Veenstra
        MVP
        Like I said, SYSVOL replication is done using DFSR, that's DFS replication. So it could be complaining about a missing replication partner
  • LainRobertson's avatar
    LainRobertson
    Silver Contributor

    nikitamobile855 

     

    Actually, I was going a bit too fast before without paying proper attention to detail. Specifically, the GUID from your Event Log error doesn't match anything below your ADSI Edit picture.

     

    As such, the Event Log error isn't related at all to your ADSI Edit picture. This is actually good news though as I'll explain after speaking to the Event Log error.

     

    The reference to UZTASSRV01.sm.local within the Event Viewer error is only saying which domain controller reported the issue, not that the domain controller is part of the issue.

     

    Dealing with the Event Log error:

    What we have from the Event Log error is a forward reference to the "msDFSR-Member" (i.e. objectClass = msDFSR-Member) object in AD. This object lives under the "CN=DFSR-GlobalSettings,CN=System" area, and it's this object that is missing a value for the "msDFSR-ComputerReference" attribute (which is what I was talking about before.)

     

    The new part is this: You need to run a search to see if a matching "msDFSR-Subscriber" object with the same GUID value for the "cn" attribute exists. If it does, it will be nested below the computer we're trying to find in order to fix the missing "msDFSR-ComputerReference" error from the Event Log.

     

    If you're familiar with PowerShell, you can find the msDFSR-Subscriber, and hence the missing computer reference using:

    Get-ADObject -Filter { (objectClass -eq "msDFSR-Subscriber") -and (cn -eq "c3b24e94-239f-4621-b82b-b356d6cc9bed") } | select distinguishedName

     

    If it does not exist then you should simply delete the object mentioned in the Event Log (i.e. "CN=<guid>,CN=Topology,CN=DFS,CN=DFSR-GlobalSettings, etc...".) Deleting the orphaned reference will stop event 6002 from being logged.

     

    If it does exist, you will get a value back that looks like:

    CN=c3b24e94-239f-4621-b82b-b356d6cc9bed,CN=DFSR-LocalSettings,CN=YourServerName,OU=SomeOU,...,DC=sm,DC=local

     

    What you want to do now is:

     

    1. Copy from "CN=YourServerName," to the end of the line above into something like Notepad;
    2. In ADSI Edit, edit the properties of "CN=c3b24e94-239f-4621-b82b-b356d6cc9bed,CN=Topology,CN=DFS,CN=DFSR-GlobalSettings,CN=System,DC=sm,DC=local";
    3. Set the value of the msDFSR-ComputerReference attribute to the value you copied into Notepad from Step 1;
    4. Click OK to accept the change.

     

    These steps will put the missing computer reference back into the msDFSR-ComputerReference attribute, which will stop event 6002 from being logged.

     

    About the ADSI Edit picture (purely additional information for education and has nothing to do with your event log error):

    The GUIDs your looking at under the domain controller object in ADSI Edit are the forward references to the non-SYSVOL replicas to which the domain controller, UZTASSRV01.sm.local, is also a member.

     

    You do not have to check those at all unless there's errors relating to them. You can if you'd like, but unless you're really unlucky, you will find matching "msDFSR-Member" objects matching the GUIDs from your ADSI Edit picture below one of the replica groups somewhere beneath "CN=DFSR-GlobalSettings,CN=System,DC=sm,DC=local".

     

    Anyhow, as I say, this is purely additional information. The only thing you need to remember is that your ADSI Edit picture is totally unrelated to the Event Log error.

     

    Cheers,

    Lain

    • nikitamobile855's avatar
      nikitamobile855
      Brass Contributor

      LainRobertson 

       

      Thanks a lot for your detailed response!
      I have tried to run the PowerShell script and it doesn't return any values. And I didn't clearly understood how I can delete it now? 

       

      • LainRobertson's avatar
        LainRobertson
        Silver Contributor

        nikitamobile855 

         

        Okay, given you didn't get any values returned from that command, just delete the object listed in the Event Viewer error.

         

        In other words, delete the following object from AD (make sure you check I haven't typed the GUID incorrectly - you can copy-and-paste it from the Event Viewer error if you like):

         

        CN=c3b24e94-239f-4621-b82b-b356d6cc9bed,CN=Topology,CN=DFS,CN=DFSR-GlobalSettings,CN=System,DC=sm,DC=local

         

        Cheers,

        Lain

Resources