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:
Please note that configuring one way connections is not supported by Microsoft Product Support Services.
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:
On Windows Server 2008 R2, the read-only replicated folders feature can be deployed in such scenarios.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.