GenlLeeCSA1
asked on
DFS Namespace Members and Simultaneous File Access / Read Only
Hello!
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"?
Thanks!
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"?
Thanks!
ASKER
Ah, I see. Perhaps my suspicion for the cause of the issue was incorrect, then. We are indeed mapping to \\namespacepath\sharename\ schedule.x ls, 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.
Thanks.
Just trying to sort all of this out.
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
\\genleedomain.local\share
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.