Link to home
Create AccountLog in
Avatar of Tim OBrien
Tim OBrien

asked on

Files - DFS Share Not Replicating or Not Saving Properly

Our company has DFS Shares and we are running into issues with replication between two servers where one user is not able to see changes by other user, I believe the share they are using is pointing to a different server on the share. Secondly the User is making changes but they are not being saved properly when the user attempts to reopen them later that day or next day.

I am studying for my 70-410 and reading about offline files, branchcache and configuring slow-link. They keep discussing it as it relates to a Share. Does DFS change the dynamics of how these functions work or can some of these functions assist with more efficient replication or  help with the issues we are having? I know several question just confused of how DFS fits into what I am reading as again they keep discussion it in terms of just a shared folder.
Avatar of Brendan M
Brendan M
Flag of Australia image

here is a blog post on Offline Files and DFS Shares

which could be causing conflicting files if the share is using the Offline Files feature
Regarding your first question, yes if your DFS targets are on different servers and are being replicated, this can certainly cause conflicts. DFS does *not* provide any locking mechanism so you have to plan for this when implementing DFS. DFS-R is great, for example, to get files from a remote site to a central backup site (where users aren't editing files) or to get read-only files from a central site to a remote site (for software deployment, for example) but is NOT well suited if there is a chance where multiple users will open the same file at the same time. Which is what it sounds like you are running into. This is an inherent limitation of DFS.

Regarding your second question, none of the features you name will help with your situation nor will they improve replication. They tackle different problems and certainly can be deployed with DFS. The dynamic of how they work doesn't change that much. But again, they aren't designed to solve your problem. They are intended (individually and potentially together) to solve other pain points in different topologies (mobile workers, small offices without a dedicated DFS server, unreliable WAN links, etc.)
Avatar of Tim OBrien
Tim OBrien


I don't think multiple users editing files is the main problem, It is more that other users are not seeing other files which have been created or the most up-2-date file. That is why I thought those other features I was reading may help to improve efficiency over the network.  Last question, any suggestion of a non-dfs solution?
Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
I appreciate your time and help.
You need to recheck the topology you have. Your DFS replication group might have work fine till now but now an unanticipated use is what causes your difficulty.
First thing to check is whether the user has access to the files they could not access the following day, that will point to the user having marked the DFS shared data as offline access as was mentioned earlier.  Viewing a listing on a folder, there is an option that will indicate that this folder is an offline reflection of the data.
Comparing the DFS target being accessed by this user will help clearup the matter further since you can then access the share and see whether the files are there and if not check the DFS/DFS replication event log to see whether there are issues there.

Others also covered the conflict detection/events.

what is the replication topology, make sure the member servers of the replication have 2 functioning connection to match the topology. I.e. If hub and spoke you have each server with an outgoing and receiving feed and both are marked as functional. One has the option to mark a connection though present as disabled preventing data from flowing through it.
Thanks Arnold. I will re view these.