DFS replication issues

Zalastar 

Sorry, I was just out doing the Saturday morning run-around with the family.

Glad it's all sorted!

Cheers,

Lain

LainRobertson 

A big thank you for the time you spend here on this thread! I am so happy right now. Not a single error in the Forest. And my Delta sync times are way down now too

Source DSA          largest delta    fails/total %%   error
 BABBAGE                   26m:58s    0 /  10    0
 IOS-SEA-A1                13m:01s    0 /  20    0
 IOSLA-DCFS                08m:24s    0 /  15    0
 OR-VM-1                   07m:06s    0 /  10    0
 PS-BAY-AD1                21m:10s    0 /  10    0
 PS-I-AD1                  23m:23s    0 /  15    0
 PS-I-AD2                  22m:06s    0 /  25    0


Destination DSA     largest delta    fails/total %%   error
 BABBAGE                   21m:14s    0 /   5    0
 IOS-SEA-A1                   :26s    0 /  20    0
 IOSLA-DCFS                13m:02s    0 /  15    0
 OR-VM-1                   03m:01s    0 /  20    0
 PS-BAY-AD1                27m:01s    0 /  15    0
 PS-I-AD1                  22m:08s    0 /  15    0
 PS-I-AD2                  23m:25s    0 /  15    0

 I finally understood what you meant about getting rid of the FRS leftovers

PS C:\Users\administrator.IOSDOMAIN> Get-ADObject -Filter { (cn -ne "File Replication Service") } -SearchBase "CN=File Replication Service,CN=System,$((Get-A
DRootDSE).defaultNamingContext)" -SearchScope Subtree | Select-Object -Property objectGUID, objectClass, distinguishedName
PS C:\Users\administrator.IOSDOMAIN>

LainRobertson 

and thank you sir

PS C:\Users\administrator.IOSDOMAIN> net share

Share name   Resource                        Remark

-------------------------------------------------------------------------------
C$           C:\                             Default share
IPC$                                         Remote IPC
UDP_APM$     C:\Program Files\Arcserve\Unified Data Protection\APM

ADMIN$       C:\Windows                      Remote Admin
NETLOGON     C:\Windows\SYSVOL\sysvol\iosdomain.local\SCRIPTS
                                             Logon server share
SYSVOL       C:\Windows\SYSVOL\sysvol        Logon server share
The command completed successfully.

PS C:\Users\administrator.IOSDOMAIN>

Ok I ran through the steps and I am beginning to understand what it did

After the Error 4114 I saw quite a few 4412 errors starting with this one

The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder.

Additional Information:
Original File Path: C:\Windows\SYSVOL\domain\Policies\{1F60C4D9-39CC-4A52-956E-0715D20D84B2}\GPT.INI
New Name in Conflict Folder: GPT-{D9CFBC30-0905-453D-A1F6-403F6DF348CF}-v166.INI
Replicated Folder Root: C:\Windows\SYSVOL\domain
File ID: {6CF9F740-471F-4A0A-99D6-EA74625846E9}-v66
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: 8EC04617-53A4-4148-AB24-4CDD050A1716
Replication Group Name: Domain System Volume
Replication Group ID: 860C23C1-6213-4EDC-8AA3-0C4B75F238DA
Member ID: 43A19C80-D9AB-4DCC-8434-7BC4987D3B5B
Partner Member ID: 806D1444-4493-4ADF-8A0F-DA75BBDF6FA9

and finally ended up with the magic error 4604

The DFS Replication service successfully initialized the SYSVOL replicated folder at local path C:\Windows\SYSVOL\domain. This member has completed initial synchronization of SYSVOL with partner OR-VM-1.iosdomain.local.  To check for the presence of the SYSVOL share, open a command prompt window and then type "net share". 
 
Additional Information: 
Replicated Folder Name: SYSVOL Share 
Replicated Folder ID: 8EC04617-53A4-4148-AB24-4CDD050A1716 
Replication Group Name: Domain System Volume 
Replication Group ID: 860C23C1-6213-4EDC-8AA3-0C4B75F238DA 
Member ID: 43A19C80-D9AB-4DCC-8434-7BC4987D3B5B 
Sync partner: OR-VM-1.iosdomain.local

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

Zalastar 

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

LainRobertson 

The migration was done before I inherited the position, fortunately its the only DC in the forest with an issue.

The result of that last command

objectGUID                           objectClass     distinguishedName
----------                           -----------     -----------------
01c80ee4-dc5a-4bfa-8ddf-2500a62a3e7e nTFRSReplicaSet CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=iosdomain,DC=local
37442159-8097-461b-8466-bbddce3e6723 nTFRSMember     CN=WIN-NAAPRAMLU0A,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=iosdomain,DC=local

Yes I did follow that method but I am wondering how long I should wait for replication to finish before changing the flag and moving on to the next step? How do I tell how long my forest replication takes to finish?

Zalastar 

Okay, so I think you mentioned earlier something about the FRS migration status being okay, which leads me to assume that an FRS to DFS-R migration took place at some point?

There's still things we can do but I'm keen to check some things first, as they're all edging closer to that "point of last resort" concept.

Does the following command return anything?

Get-ADObject -Filter { (cn -ne "File Replication Service") } -SearchBase "CN=File Replication Service,CN=System,$((Get-ADRootDSE).defaultNamingContext)" -SearchScope Subtree | Select-Object -Property objectGUID, objectClass, distinguishedName

Secondly, were you following the process here when you reset DFS-R ealier?

Force synchronization for Distributed File System Replication (DFSR) replicated sysvol replication - Windows Server | Microsoft Docs

Note: It says D2-like, but it's not actually the older BurFlags process.

Cheers,

Lain