Microsoft Office ownerfile with DFS

We run DFS shares on the file server side and Office 2007 or 2010 on the client side.

Clients access files on the file share through the dfs share, not a direct mapping to a server.

We replicate the dfs share and set only one copy as enabled in dfs management to avoid competing updates and replication conflicts.

When Microsoft Office opens a file (Word or Excell) it creates a Office Owner file that has the same name as the opened file but wit the prefix "~$". If the users closes this file it is supposed to be removed from the share. In our environment this owner file sometimes does not get removed and causes problems when another user wants to open that file and he/she is told the file is read only. Manullay locating the ~$ file and deleteing it solves the issue, but we really want to figure out, why in some cases the `$ file is not deleted when a user closes the document.

Any advise?
Who is Participating?
Chinmay PatelEnterprise ArchitectCommented:
On the similar notes... what I would suggest is develop a batch file and proivde a shortcut on User's desktop. So and train them to click on in whenever they face issue like this. As files are going to be locked if they are really being used we won't have any issue.

Chinmay PatelEnterprise ArchitectCommented:
Hi Gerhard_W,

This happens when an MS Office application ends unexpectedly[application crashes, OS crashes, user keeps the document open on his laptop, hibernates and moves on or ust detaches the network cable and walks away happily] and in some cases none of this. Even though you closed Word properly that file will stay there.

If I am not wrong, you are not going to get a definitive answer for this question and it case you get it, I will be waiting here.

Gerhard_WAuthor Commented:
Thanks for the response. The question is then, how to recover from it. In our scenario the file is locked unitl we  manually remove the ~$ ownerfile. I would expect some kind of automatic time out on this.  
Another option is to have a cleanup job running overnight on the fileshares that finds and deletes old ~$ ownerfiles.

Chinmay is completely right, and because of this there can't be any automatic timeout: The client application (Excel, Word...) creates this file and a timeout would only work if there would be any program available which checks the connection - as the program is on the client and this one disconnects unexpectedly nothing is left which could check for this file.
I'm afraid running a job which deletes such files automatically is the only chance you have. You can start such a job not only overnight, you should also be able to start it at any time you want because you can't delete such files accidentaly as long as the application/the OS locks them.


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.