DFSR : Re-replication configuration
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.
Who is Participating?
Experts Exchange Solution brought to you by
"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.
Experts Exchange Solution brought to you by
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 trialUsing 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.
Cheers
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?
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
From novice to tech pro — start learning today.
-
Microsoft ApplicationsCertification: MOS Microsoft Office Specialist - PowerPoint 2007… 229 lessons
-
Microsoft ApplicationsCertification: MOS Microsoft Office Specialist - Excel 2007 Basic 239 lessons
Experts Exchange Solution brought to you by
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.
https://www.experts-exchange.com/articles/33311/Microsoft-DFSR-Issues-and-Resolution.html
and
https://www.experts-exchange.com/articles/33297/Microsoft-DFS-Deployment-Considerations-Best-Practises.html