0

Current setup: 3 app servers (2008 r2, terminal services XenApp 6.5), 2 file servers (2008 r2).

Situation: user1 opens up an excel file that is on server1 and starts to work. user2 goes to open that same file, and does NOT get a message that the file is 'locked for editing' message. So they go in, make their changes, save out and close the file. Their work is never saved to the file. A open file session is never created for user2 on the file server, but they see and work as though all is normal.

The app server doesn't seem to come into the equation, but file server 2 does not exhibit the same issues as file server 1. And with that, those issues are not happening 100% of the time on file server 1. There are times where user1 will access a file [also happening with random excel files, not limited to just 1], and user2 will wait a few minutes, go in and they do not see an lock message. User2 closes excel, then user3 goes in and gets the lock message.

The common piece to the randomness is file server 1 and why its not registering the excel session as an open session, which will then alert another user that it's already open.

Open to any suggestions.

soMuch2Learn
  • 333
  • 1
  • 6
  • 16

1 Answers1

0

There's a possible answer at: https://helpdesk.yourofficeanywhere.co.uk/kb/a183/excel-loses-file-locked-for-editing-when-accessing-data-on-network-drive-mapped-via-group-policy.aspx

In summary: If the file is on a drive mapped by group policy, the periodic policy refresh can disconnect and reconnect the drive, causing the lock to vanish. You can change the action setting on the group policy from Replace to Update which should ensure that the connection doesn't get dropped.