Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
Avoid auto-enabled referral status for newly added replication targets

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

  • Thursday, January 31, 2013 7:24 PM
     
     
    Sign In to Vote
    0

    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

     

All Replies

  • Friday, February 01, 2013 9:04 AM
    Moderator
     
     
    Sign In to Vote
    0

    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 2:47 PM
     
     
    Sign In to Vote
    0

    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 5:33 PM
     
     
    Sign In to Vote
    0

    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 7:37 PM
     
     
    Sign In to Vote
    0

    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

     
  • Saturday, February 02, 2013 12:40 AM
     
     
    Sign In to Vote
    0

    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...

     
  • Monday, February 04, 2013 5:42 PM
     
     
    Sign In to Vote
    0

    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?