none
Avoid auto-enabled referral status for newly added replication targets

    Question

  • Hi,

    We need to do some shuffling around on our DFS servers. Four 2008R2 servers are deployed, all 4 are replicating all folders, and only one serves as the referral target for all folders. On one of the servers (not a referral target) we need to rebuild disk that holds replicated folders. So the process would look like this:

    - Disable replication (Replication > Memberships > right click entry for that server > disable. This will automatically remove entry under Namespaces > Folder Targets as well.

    - Do what we need to do on the disk / folder, and then re-enable replication. Most of the files at this point will be robocopied from another server to speed up replication, but some will be missing as it is a big folder and changes are written to it constantly.

    Once we re-enable replication replication for that member, a Folder Targets entry is added under namespaces and is automatically enabled. This will create a problem for us because even though we can disable this server as referral target in 2 seconds after replication is enabled, it is possible some clients will pickup this referral target and will be looking at an outdated copy, until referral cache expires.

    Is there any way to disable this behavior, and allow server to become part of replication group without it becoming a referral target automatically? If not, the only option we may have is to set referral cache duration to 1 second? 

    Thanks

    Thursday, January 31, 2013 7:24 PM

All replies

  • Hi,

    When trying to disable it in Replication - Memberships, a message occurs "this operation should only be used if the content in the repilcated folder is no longer needed on the selected member. To temorarily pause replication to the selected member, disable the member's connections."

    So actually this is not a correct way to do the update. You can disable the replication group and disable the folder target in DFS namespace. After robocopy, re-enable replication group and folder target. Or you can simply delete it from replication group and add it after robocopy.


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

    Friday, February 01, 2013 9:04 AM
  • Hi,

    Not to worry. Enabling a namespace is one part and scheduling it for replication is another part.

    When you add a namspace in the DFS console, it will only be added nothing will replicate. Only after you add that member  to the replication group, it will start replicating the data.To be more precise, it will try replicating the data.

    Why do you think your users will talk to this new referral target when you enable,if there are no one on that site. If these servers are in same site, they are already accessing the folders with the existing referral which is still working. So they wont get this new referal that soon.

    What sort of disk rebuilding are you doing? May i know the rebocopy syntax which you are trying to use? That matters a lot during replication.


    Regards, Server Engineer - Server Support


    Friday, February 01, 2013 2:47 PM
  • Hi Shaon / Server Engineer,

    I was reading this article : http://support.microsoft.com/kb/961655 and only now realize this applies to 2003, we have 2008R2. Deleting a member and adding it later will take its data (if any) and consider that as current copy and replicate to other members. In other words, if you delete member, delete all files from previously replicated folder and add member back into replication group, DFSR will replicate empty folder to other members, deleting all your data. I've seen this thing happen here when we were running 2003, just before we upgraded to 2008R2. Not sure if this is still the case, but I figured it would be on the safe side to do it as I described above.

    @Server Engineer : This rep group is behind an already used namespace and we have some 50 clients already using this for their daily operations.

    Here is what I need to do (almost done actually) : E: disk is composed of 2x 2TB disks, spanned into 4TB volume. I'm replacing this with another volume, 3x 1.95TB, total ~6TB. I stopped replication to two folders that were on E: disk, changed E: to F:, added the new disk and formatted as E:, then robocopied data from F: to E: using robocopy F:\source E:\destination /MIR /COPYALL /B /MT:48.

    What's left to do now is add this member back into these two replication groups, immediately disable it as a referral target, and let DFSR do the initial replication and catch up with any changes done since replication was disabled. If I did everything correctly, only last couple of days worth of changes should be replicated and we should be good to go.

    I believe /B switch for robocopy is critical to copy data in backup mode, which should take care of all permissions and such. We'll see, I'll post if this worked the way I intended.

    Thanks

    Friday, February 01, 2013 5:33 PM
  • Here is an update : I've executed the change as described above, and all went ok. However, after I re-enabled DFS member, a huge backlog showed up on our monitors. Files stay in place, there is not much in terms of network traffic between servers, but there is plenty of disk activity on the added member server. The problem appears to be with pre-seeding, specifically with outdated version of Robocopy.exe distributed with 2008R2 which doesn't copy permissions correctly, causing preexisting file hashes to be different than in other locations and DFSR is now trying to fix that. This is mentioned here:

    http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx

    The fix is here : http://support.microsoft.com/kb/2639043/en-us

    Unfortunately the fix required a reboot before new robocopy can be used, so I'll have to time that.

    Also read lesson #1 from here, very useful : http://www.kendalvandyke.com/2009/07/things-you-need-to-know-if-you-use-dfs.html

    Friday, February 01, 2013 7:37 PM
  • And another update : after applying the hotfix and confirming robocopy.exe is now the correct version, I'm still having the same issue : after robocopying files from one disk to another on the same server, and enabling replication, there is a backlog approximately equivalent to the number of files in replicated folder. I use syntax stated above and that should cover everything (/COPYALL includes security and all).

    I'm in the process of copying another folder, and will use DFSRDIAG.exe filehash command to compare a few files before I turn replication back on. Stay tuned...

    Saturday, February 02, 2013 12:40 AM
  • And... no good. I did filehash command, showing all is good on half a dozen files, however once I re-enabled replication for that member, backlog for that folder went up to about the number of files in it.

    At this point I'm at a loss - what am I doing wrong? Robocopy looks ok, filehash looks ok, DFSR still thinks all files changed?

    Monday, February 04, 2013 5:42 PM
  • Did you ever find a fix for this? I am also having an issue with DFSR

    Recently added a new file server, added it to some existing replication groups after doing a pre-stage and all works fine, i have one share that is not part of a replication group, just a name space. did a pre-stage of the data, added it to the name space which asks you if you want to create a replication group, said yes, and after a while I get the event log

    "The DFS Replication service initialized the replicated folder at local path D:\Dept\IT. This member is the designated primary member for this replicated folder. "

    a little while later, on the new server with the pre-staged data, the data starts getting moved to the Preexisting folder.

    I have done everything, removed it all, cleaned it all up, re-added it, set the primary member, re-set  the primary member again but no joy.

    I am really at a loss since the other replicate groups that already existed that i added the new server to with pre-staged data work find (much smaller in size)

    I came across this paragraph on the following site
    Site Link

    "When the server is once again available, the administrator can add this server back to the list of targets and configure replication. The data will be moved to the preexisting folder where it can be compared with file IDs sent over on the change orders from the initial master. If the file ID is the same, it will be pulled from the preexisting folder instead of across the WAN to reduce network traffic."

    Yet, i cannot find that ANYWHERE else on the net about it being "pulled back from the preexisting folder" nor any additional information\fix as to why the pre-staged data keeps getting moved to the preexisting folder

    Thursday, February 20, 2014 1:25 PM