The Storage Team Blog about file services and storage features in Windows and Windows Server.
When you set up a replication group in Windows Server 2003 R2, you are given the choice of several topologies, including hub and spoke. A common misconception about this topology is that the hub is a “master” and changes made on spokes will not be replicated back to the hub. Here’s an example of the questions we’re asked on this subject:
If the topology is set up for hub and spoke, and the spoke were to accidentally delete an item, this should not reflect back to the hub, correct? This should be a one way transfer. What we are seeing is our hub replicates out to the spokes perfectly, but if the spoke deletes an item, the item is then deleted from our hub share. It seems to be acting like a full mesh topology, but it was originally set up at as hub and spoke.
The behavior the customer describes is by design. Because DFS Replication is a multimaster replication engine, any change made on any spoke is replicated back to the hub and to the other spokes. To prevent changes from occurring on spokes, we recommend using shared folder permissions.
I've seen that Longhorn server will support Read Only Domain Controllers.
I suppose that this will include the SYSVOL folder, that will be replicated through DFSR.
Since DFSR is a mutimaster replication system, does this mean some evolutions are planned on this? Because it seems that RODC will act as a spoke.
I'm just being interested in this functionality, since there is a real need there.
Shared folders permissions and even NTFS permissions are not a viable option in a forest environment where each domain admins can change NTFS rights on the replicated folder when they want.
I'm not sure if this a formal way of setting up one-way replication but i just deleted the connection flow from the spoke to the hub (this is opposite flow from the hub to the spoke)
And so everytime i delete a file from the spoke, it's not reflected back to the hub.
I just realized from Microsoft's FAQ that it somewhat not recommended to do a one-way replication. http://technet2.microsoft.com/WindowsServer/en/library/f9b98a0f-c1ae-4a9f-9724-80c679596e6b1033.mspx?mfr=true
But they do state a few work arounds.
"Although it is technically possible to create a one-way replication connection, doing so can cause numerous problems including health check topology errors, staging issues, and problems with the DFS Replication database. A better solution is to simulate a one-way connection by using the following list:
• Train administrators to make changes only on the server(s) that you want to designate as primary servers. Then let the changes replicate to the destination servers.
• Configure the permissions on the destination servers so that end users do not have Write permissions. If no changes are allowed on the branch servers, then there is nothing to replicate back, simulating a one-way connection and keeping WAN utilization low."
burnt1ce, you are correct--we don't recommend one-way replication topologies for DFSR due to numerous drawbacks. Your best bet is to set up share permissions as described in the FAQ.