Using One-Way Connections in DFS Replication

[FileCAB-Team]

First published on TECHNET on Aug 16, 2007

We’re starting to see more and more questions about how to establish a “master” or source server in a DFS Replication topology. In this blog post, we explain what one-way connections are and why they are not a recommended configuration to solve these scenarios.

NOTE: Windows Server 2008 R2 includes a feature called read-only replicated folders . This feature can be used to configure such deployment topologies, where replication in only one direction is desired.

What are one-way connections?

Configurations which feature one way connections are those in which replication related updates are permitted to flow only in one direction. Let us explore this scenario with a real world example.

Figure 1 demonstrates Contoso’s patch deployment scenario. Contoso has one file server per site from which users can download patches and hotfixes. For instance, the server ‘design.contoso.com’ serves all users in Contoso’s design department. The servers ‘design.contoso.com’ and ‘marketing.contoso.com’ contain replicas which are synchronized with the central datacenter server (‘datacenter.contoso.com’).

Contoso requires that the data center server be authoritative with respect to the contents of the replicated folder ‘Hotfixes’. Contoso wants to prevent changes made on the servers ‘design.contoso.com’ and ‘marketing.contoso.com’ from replicating to the server ‘datacenter.contoso.com’. Therefore, Contoso would like to set up one-way connection from each of these site servers to the data center server. This may seem like a good idea, but we recommend against doing so for many reasons as described below.

The DFS Replication Service

The DFS Replication service in Windows Server 2003, R2 was designed to be a multi-master replication engine. This means that the replication engine is engineered to handle updates occurring at any node in a given replication topology. The DFS Replication service is designed to keep track of updates occurring to the contents of a replicated folder on any replication member server and to intimate the other replication member servers of those updates. It also has sophisticated conflict resolution algorithms which are designed to work best with scenarios involving updates at multiple nodes. Assume that we disable the outbound connection from design.contoso.com to datacenter.contoso.com as shown in Figure 2 . Note that deleting the outbound connection will also achieve the same result as disabling the outbound connection.

As shown in Figure 2 above, the outbound replication is disabled from ‘design.contoso.com’ in an effort to ensure that changes on this server do not replicate back to the datacenter server (‘datacenter.contoso.com’) and also to ensure thereby that these updates do not find their way to other site servers such as ‘marketing.contoso.com’. Despite configuring things in this manner, the replicated folder on the server ‘design.contoso.com’ will never be guaranteed to be an exact copy of the data on the source server (‘datacenter.contoso.com’). Here are some scenarios which could cause Contoso problems:

Deletions on branch office servers (‘design.contoso.com’)

In case files or folders are deleted (either accidentally or on purpose) on the site server (‘design.contoso.com’), DFSR will generate update records for these delete operations with the intent of transferring these records to the other replication member servers. This is basically how deletes propagate for normal replication scenarios. Now that the outbound connection has been disabled, these updates will merely queue up on the site server (‘design.contoso.com’) with no way to propagate to the other replication member servers (such as ‘datacenter.contoso.com’). These now manifest as permanent replication backlogs.

Assume that a folder (‘Server 2003 SP2’) has been deleted on the server ‘design.contoso.com’ and an update is made to a file or folder that is a child of this folder on the datacenter server. For instance, an update has been made to the file update.exe as shown in figure 3 above. Since the design of Contoso’s patch deployment network requires that the changes on the datacenter server be authoritative, these changes will replicate out from the datacenter server to ‘design.contoso.com’. However, on ‘design.contoso.com’, the folder has already been deleted. The DFSR service now is unable to apply such updates since the parent folder is non-existing. Therefore, unexpected errors can be seen in the event logs.

Recovery from Database corruptions

In case a DFSR database corruption occurs on the site server ‘design.contoso.com’, it will not be able to “self heal” itself by synchronizing its recreated database with other servers (such as ‘datacenter.contoso.com’). Note that database corruptions are very rare scenarios and the DFS Replication service is designed to preclude that occurrence to the extent possible.

Health report errors

Since the DFS Replication service is not designed to work with connections in one direction disabled, the health report will display ‘replication topology errors’ with such a configuration until the same is “fixed”. If an administrator chooses to “fix” such a replication topology by adding the missing outbound replication connection, any backlogged changes on the site server ‘design.contoso.com’ could flow out to the datacenter server and potentially corrupt the contents of the replicated folder (eventually on all replication member servers).

Why are one-way connections not recommended?

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.

Our Recommendations

To ensure a healthy replication topology, we recommend that customers set up two-way replication between the source and ‘read-only’ servers and prevent changes from being made on the ‘read-only’ servers by:

• Training administrators to make their changes on specific source servers and let the changes flow out.
• Applying shared folder permissions to ‘read-only’ replication member servers so that end users cannot change anything that could overwrite authoritative data on the source server.

On Windows Server 2008 R2, the read-only replicated folders feature can be deployed in such scenarios.

------- Mahesh Unnikrishnan