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?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.

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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Server Software

From novice to tech pro — start learning today.