DFS Namespace Members and Simultaneous File Access / Read Only


Our organization has a DFS filesystem / replication configured between two member servers, with settings configured to refer the client to the server with the least load.

What appears to be happening is that a client who is assigned to server "A" is able to open the file "schedule.xls" in a given share for editing.  Harmless, right?  Yes, until a second client, assigned by DFS to server "B" is able to open the same file, stored on the second member, for editing as well.  Then, when client 1 saves and exits the file, and then client 2 saves and exits after, the only modifications to "schedule.xls" that are posted are those made on server "B".

This has created a fair deal of frustration.  Any suggestions for how to resolve this, or will I be forced to remove the second member from the namespace for that particular share?

Is there a way to trigger the traditional "Read-Only" prompt in Excel to a user connected to server "B" if the file is already open on server "A"?

Who is Participating?
GenlLeeCSA1Author Commented:
This issue was resolved by configuring target priorities in DFS Management > Namespaces > [namespace] > [share] > Properties > Advanced.

Configuring as such for all shares (must be configured manually for each share) points all users to an administrator-defined DFS server, but allows for failover to a secondary DFS server in the event that the primary stops sharing files for some reason.
DFS namespaces should be used when mapping files.  If you're users are opening \\ServerA\sharename\schedule.xls and \\ServerB\sharename\schedule.xls, there would indeed be a conflict, as the two servers are trying to replicate the same file to one another, and in this case, whoever makes the last change to the file wins.  Instead, you should have your users open their files like:


This way, the file will be open within the namespace, and not locked instead to a specific server.  This will result in User2 opening the file in read-only mode.
GenlLeeCSA1Author Commented:
Ah, I see.  Perhaps my suspicion for the cause of the issue was incorrect, then.  We are indeed mapping to \\namespacepath\sharename\schedule.xls, instead of to the specific servers, yet somehow the files were not being opened in read-only mode (or, at least, changes made to files were not preserved after they were saved).  Is it possible that file replication somehow overwrote changed files with their unchanged counterparts from the other member server?

Just trying to sort all of this out.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.