DFS Replication Across a VPN: Locking Is Not What You Get

The link is encrypted, always on and fast enough, so the shared folder ought to behave like one folder at both sites. That is the assumption behind most DFS Replication designs that surprise people later. DFSR is multi-master and asynchronous: each replica tracks versions independently, and nothing in the protocol holds a lock across servers. The VPN carries traffic between them and adds none of the coordination the assumption needs. Plan the writing pattern and the capacity model, or the first genuine conflict becomes a support incident.

The myth: a VPN makes the replicas one filesystem

A tunnel is a transport. It gives you a permitted path between two servers and hides the hops in between. It says nothing about who may edit a file, in what order versions arrive, or what happens when two edits race.

Encryption and availability are properties of the link; consistency is a property of the replication engine and of your workflow.

What DFSR actually replicates

Each server keeps its own copy and its own version metadata. Changes propagate when the connection and schedule allow, and the engine uses remote differential compression to send only the parts of a file that changed. When two replicas change the same file before either update arrives, one version wins and the other is moved aside as a conflict copy. No server blocked the second edit, because blocking would need the distributed lock that DFSR does not provide.

A namespace path makes the copies convenient to reach, and it does not make them coherent.

Staging space is working capacity, not backup

Staging is the scratch area replication uses while it assembles changes. Microsoft's sizing guidance uses the combined size of the 32 largest files in the replicated folder as a minimum, with extra room useful during initial replication. A tree of tiny documents and a folder holding several large archives therefore need different staging shapes. When staging runs out, replication stalls in ways that look like a network fault. Size it from the data, then keep watching as the data changes.

Staging is not a backup, and propagating changes is not a version history.

Pre-seeding is an optimisation, not a shortcut

For a large existing tree, supported pre-seeding with Robocopy can cut what has to cross the link during initial synchronisation, and Microsoft's guidance covers preserving file information and handling locked or skipped files. It is an optimisation, not a promise that the destination is already correct, so initial replication still has to complete and be verified. Skipping that verification is how a site ends up serving files that were never in the replicated set.

Verify the initial state before users depend on the destination, not after the first complaint.

Choose the window and define current

Replication schedule and bandwidth controls decide when the partners may exchange data. A narrow after-hours window is a legitimate design that leaves a backlog during the day, provided everyone agreed that the remote copy only has to be current by morning.

Write that sentence down, because "the backlog is forty minutes" is only alarming if nobody defined the target.

Accept with the workflow, not one file

Test with the files people actually use: a large document, a routine edit, a deletion, and a deliberate simultaneous edit at both sites. Confirm the conflict behaviour matches what you told the business, and confirm the recovery path from backup is separate from the replicas. Then watch change volume, queue growth and staging headroom against the service window for a few weeks. VPN capacity is one limit among several, and it is rarely the first one you reach.

A design that documents its lag and editing rules is far easier to support than one that promises identical copies.