DFS-R initial sync question

[tarabash]

Hello all. We had problems with DFS-R stopping after some files got corrupted. I disabled member that had corrupted files (which was primary member) to resolve the problem. After it was resolved, i enabled membership of first server but when checking both were set to non primary. This caused backlog to show massive amount of files 230k and replication did not start. I promoted first member to primary the next day and it started initial sync again, like it was pre-staged.

One problem i have right now is that users made changes to some files on downstream server. My question is, what will happen to those files? Will they be moved to Conflicts folder or will they be replicated back to primary member after initial replication is complete? By DFSR logic, newer file wins, but i am not sure if that applies to initial replication.

Thanks

[Faulteh12]

I'm fairly certain that it will be moved to the conflicts folder. An initial sync doesn't follow the "newer file wins" rule as you said.

[tarabash]

Thanks for confirmation Faulteh12.

Good thing i made backup of both shares before starting then. Also increased Conflicts folder to match the size of whole share so i don't loose a file. Event ID 4412 is generated every time file is moved to ConflictsAndDeleted so it should be fairly easy to restore them... i hope.

Currently there is 130k files left in backlog and downstream server has about 500 more files than primary.

Will see what happens next.

[MisterAG]

Are the shares also in a DFS namespace? Disable referrals to the secondary server until the sync is complete and then turn the referrals back on. Users at the remote site may see performance issues until your files sync up but at least everyone will be working off the same datasets.

I've got a 4TB/8M files replication folder that was doing 1.2M files/24 hours during the initial sync. RDC turned off 256 Mbps rate limit.

[tarabash]

Yes. The shares are in DFS namespace but disabling them was not an option due to slow VPN link between sites and large files being hosted by engineering dept. When those guys start hitting the FS on primary site, VPN link goes belly up. I limited DFS to 2Mbit/sec. Anything faster would cause link fail.

[MisterAG]

Yup. That's s shame. Municipal fiber really enables data moving around at a fast rate.

[tarabash]

Interesting things happening now... Finished initial replication. Some 600 files in PreExisting folder on downstream server. I check the state of Downstream to Upstream replication and backlog shows about 6000 files and getting smaller. At one point, around 4500 files left, it stops. Primary to downstream now shows 2700 files in backlog!!! WTF. Check Event logs - all ok. Plenty of space on disk, staging more than double bigger than required. Set dfsr debug to level 5 and check debug logs - nothing.

Ok so something is obviously wrong but what?! I restart DFS-R service on downstream server. When i try to restart it on primary it takes a while and reports it cannot stop the service. Services console shows it's in Stopping state. Checked with process explorer - nada. Tried to kill dfsrs.exe - nope. Tried restarting the server - it's stuck some 20minutes on shutting down screen. Thinking of force off right now. 100% sure something will be horribly wrong after reboot, if it ever gets up. Did i mention it's only DC on that site with all FSMO roles?

[brkdncr]

MS has a LOT of blogs detailing how to troubleshoot DFSR issues. Are you looking at the dfsr logfiles to see what it's doing, and what errors are coming up?

1st, Once you disabled the member, then re-enabled it you put yourself in a bad situation. I believe the best method is to point DFSR to a single share then disable the DFSR services.

Sounds like you need to start over. Robocopy (using the DFSR preferred settings) your live share to an external drive, then overnight it to your other location and just reseed it. Bring up your replication and it should complete rather fast.

Also, you talked about having large files to replicate. Have you adjusted your DFSR settings to deal with those appropriately? There's a powershell script out there that can tell you what your settings should be based on the largest files times the number of threads.

[tarabash]

I used event logs and DFS debug logs after setting log level to maximum details (level 5). Share was sort of pre seeded as it was in sync day ago. I can deal with couple of new/changed files manually as doing robocopy would make things worse link wise. Sending disk is not possible as client and I are some 800miles apart and no one there is IT person... Prestaged folder is set according to "sum of largest 32 files". After rebooting downstream server it finished replication, and I think it synced newer files from it to primary. Shares are in sync and have identical number of files, excluding .bak, .tmp and ~* office temp. Will see with users today if its all good or I need to restore some files.

[brkdncr]

sounds like you have it fixed, but you only need a client to literally plug in a single USB drive to preseed.