locked
DFS Branch to Hub replication for backup only and one way replication. RRS feed

  • Question

  • We have Windows 2003 servers using DFS to replicate from Branch sites to a central Hub server.  This is strictly for backup purposes and users only access their Branch server.  A configuration article stated to disable the replication connection form the Hub to the Branch leaving a one way connection from the Branch to the Hub in place.  Since then, we've found articles stating not to setup one way replication.  It's been about a week now with the one way setup.  Do you have any clarification on this configuration?
    Thursday, March 17, 2011 4:28 PM

Answers

  • With Windows Server 2003 one way replication with DFS is NOT supported and should NOT be used.  There are a variety of reasons for this discussed in the links below.  Starting with Windows Server 2008 R2, this changed, kinda.  One way replication is supported but not by deleting any of the connections.  Instead, a filter driver is used to limit user's ability to write to the location in question (even if they do have NTFS permissions).  Take a look at the articles below:

    First, take a look here if you're currently using one way replication and you want to fix it:
    http://blogs.technet.com/b/askds/archive/2009/06/23/recovering-from-unsupported-one-way-replication-in-dfsr-windows-server-2003-r2-and-windows-server-2008.aspx

    Next, check out this link if you're interested in how one way replication is supported in Windows Server 2008 R2:
    http://blogs.technet.com/b/askds/archive/2010/03/08/read-only-replication-in-r2.aspx

    Finally, read this article.  It explains WHY using one way connections for DFSR is not recommended or supported:
    http://blogs.technet.com/b/filecab/archive/2007/08/16/using-one-way-connections-in-dfs-replication.aspx

    Specifically read the bottom of the blog:

    "We recommend that customers avoid configuring such one way connections to the extent possible since:

    1.The DFS Replication service’s conflict resolution algorithms are severely hampered if the outbound connection from a member server is deleted (or disabled). Therefore, scenarios where the DFS Replication service is unable to over-write undesired updates occurring on the ‘read-only’ member server with the authoritative contents of the hub/datacenter server may arise.

    2.Accidental deletions on the ‘read-only’ server (in this case, site server ‘design.contoso.com’) could cause issues with the replication updates being trapped on that server. Further, as described above, updates from the authoritative server can potentially not be applied since the parent folder could have been deleted locally. Therefore, with time it is possible to see substantial divergence in the contents of the replicated folders across all replication member servers.

    3.Problems with the deployment are difficult to detect without regular and meticulous monitoring. There might be a lot of false positives in the health report and system eventlogs owing to the fact that the replication topology is being set up to do something DFSR wasn’t designed to handle. Mining through these false positives and monitoring servers can be a challenge.

    4.Administrators need to develop their own scripts to identify which files are backlogged on the ‘read-only’ member (in this case site server ‘design.contoso.com’) and replicate authoritative content back to that ‘read-only’ site server. This can be quite tricky to get right and might need a lot of very close monitoring (perhaps, at times on a per-file basis). Microsoft does not supply any tools for this purpose.

    5.There is a risk of administrators inadvertently creating the missing connection and causing backlogs to flow to and corrupt the contents of an authoritative server. With these changes getting replicated out further from the authoritative server, the contents of the replicated folder could get out of sync and corrupt on all replication member servers very quickly. 

    Please note that configuring one way connections is not supported by Microsoft Product Support Services."


    Also, since it sounds like no users are accessing your HUB (since it's just for backup purposes), don't share the data out from it.  DFSR doesn't require the replicated folders be shared in any way.  By not sharing the data on the hub server, you reduce the chance of it being changed there.

    I hope this helps!

    Thursday, March 17, 2011 6:43 PM

All replies

  • With Windows Server 2003 one way replication with DFS is NOT supported and should NOT be used.  There are a variety of reasons for this discussed in the links below.  Starting with Windows Server 2008 R2, this changed, kinda.  One way replication is supported but not by deleting any of the connections.  Instead, a filter driver is used to limit user's ability to write to the location in question (even if they do have NTFS permissions).  Take a look at the articles below:

    First, take a look here if you're currently using one way replication and you want to fix it:
    http://blogs.technet.com/b/askds/archive/2009/06/23/recovering-from-unsupported-one-way-replication-in-dfsr-windows-server-2003-r2-and-windows-server-2008.aspx

    Next, check out this link if you're interested in how one way replication is supported in Windows Server 2008 R2:
    http://blogs.technet.com/b/askds/archive/2010/03/08/read-only-replication-in-r2.aspx

    Finally, read this article.  It explains WHY using one way connections for DFSR is not recommended or supported:
    http://blogs.technet.com/b/filecab/archive/2007/08/16/using-one-way-connections-in-dfs-replication.aspx

    Specifically read the bottom of the blog:

    "We recommend that customers avoid configuring such one way connections to the extent possible since:

    1.The DFS Replication service’s conflict resolution algorithms are severely hampered if the outbound connection from a member server is deleted (or disabled). Therefore, scenarios where the DFS Replication service is unable to over-write undesired updates occurring on the ‘read-only’ member server with the authoritative contents of the hub/datacenter server may arise.

    2.Accidental deletions on the ‘read-only’ server (in this case, site server ‘design.contoso.com’) could cause issues with the replication updates being trapped on that server. Further, as described above, updates from the authoritative server can potentially not be applied since the parent folder could have been deleted locally. Therefore, with time it is possible to see substantial divergence in the contents of the replicated folders across all replication member servers.

    3.Problems with the deployment are difficult to detect without regular and meticulous monitoring. There might be a lot of false positives in the health report and system eventlogs owing to the fact that the replication topology is being set up to do something DFSR wasn’t designed to handle. Mining through these false positives and monitoring servers can be a challenge.

    4.Administrators need to develop their own scripts to identify which files are backlogged on the ‘read-only’ member (in this case site server ‘design.contoso.com’) and replicate authoritative content back to that ‘read-only’ site server. This can be quite tricky to get right and might need a lot of very close monitoring (perhaps, at times on a per-file basis). Microsoft does not supply any tools for this purpose.

    5.There is a risk of administrators inadvertently creating the missing connection and causing backlogs to flow to and corrupt the contents of an authoritative server. With these changes getting replicated out further from the authoritative server, the contents of the replicated folder could get out of sync and corrupt on all replication member servers very quickly. 

    Please note that configuring one way connections is not supported by Microsoft Product Support Services."


    Also, since it sounds like no users are accessing your HUB (since it's just for backup purposes), don't share the data out from it.  DFSR doesn't require the replicated folders be shared in any way.  By not sharing the data on the hub server, you reduce the chance of it being changed there.

    I hope this helps!

    Thursday, March 17, 2011 6:43 PM
  • Thank you
    Thursday, March 17, 2011 7:24 PM
  • I have a question about 'implementation'...

    DFS is causing problems, despite our replicated directories, in this case roaming profile directory, being very 'un-dynamic', some read/writes, but nothing regular. A user can delete files from his/her desktop and sometimes they re-appear and other times, these deletions 'stick'.

    I'd like to use one-way replication to have a relatively 'recent' mirror I can switch to in case the original goes down.

    Is there an inherent problem with using one-way DFS replication, from primary to secondary, BUT using standard UNC's to map to drives, e.g.:

    DFS share=\\domain\share\folder with \\server1\folder replicating to \\server2\folder, and the user is mapped to \\server1\folder.

    I would not use a 'DFS mapping' for user access, but use the DFS replication functionalty in the background to keep the primary and secondary pretty closely mirrored.

    Is there a better way of doing this?

    Thanks!

     

    Friday, June 17, 2011 8:57 PM