DFSR : Re-replication configuration

Hi Team,

A DFSR scenario suggestion needed.

There was a Replication Group that mapped  \\server1\sydney and \\server2\sydney. Someone deleted this Replication Group sometime back and now server2 has old data. I performed following steps to fix it:

1. Renamed DFSPrivate in server2 to DFSPrivate.old
2. I ran below ROBOCOPY in server1 to copy incremental difference from server1 to server2:

robocopy "D:\Data\sydney" "\\server2\sydney" /XO /V /TS /FP /TEE /E /ZB /L /R:1 /W:1 /MT:64 /xd DfsrPrivate /COPYALL /tee /LOG+:C:\logs\sydney.log

3. Recreated replication group.

Now, when I run below command to compare backlog, it keeps returning huge numbers, unexpected to my understanding.

dfsrdiag backlog /RMem:server1 /SMem:server2 /RGName:"Sydney" /RFName:Sydney

Am I doing it wrong? What's the right way to deal with this situation?

Thanks, much appreciated.
Nitin PandeyInfrastructure EngineerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

No need to rename dfsrprivate junction point, it should be deleted, when you create new replication group, it will automatically create new dfsrprivate junction point

Since you have robocopy incremental data, the steps you taken are correct, check DFSR event logs on DFSR servers

High backlog are there may be due to insufficient staging quota OR two many open files at source. May be you are syncing users profiles or outlook PST files
These two things won't replicate until open and unnecessarily remains in queue as being open files and chocking bandwidth and replication as well, in that case it will take time

Check below link might be useful.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Patrick BogersDatacenter platform engineer LindowsCommented:

Using robocopy causes the same load on the network as DFSR sonthis step was notnreally needed.
You should have reconfigured the distribution group and point to server 1 as the primairy. This decides which server is the leading one looking datawise and will update/perge data on server 2.

Nitin PandeyInfrastructure EngineerAuthor Commented:
Thanks Mahesh. Seems it's Staging Quota.

One last question. Can I change the default location of Staging from it's existing drive to another drive on the fly? What factors do I need to consider? Any repercussions?
You can change staging quota location
Changes are not applied immediately. The updates must be replicated to all domain controllers, and the member must poll its closest domain controller to obtain the changes. The amount of time this takes depends on AD DS replication latency and the short polling interval (5 minutes) on the member.

Or you can force AD replication after changing quota location and on each dfsr member run dfsrdiag pollad command from elevated prompt
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.