First published on CloudBlogs on Mar, 15 2007
We have a lot of folks out there who use client side caching as a way to have consistent copies of the work they do as they travel and are not always well-connected to their corporate networks.
If you redirect a folder like My Documents, such as via group policy, having a copy of the user’s data on a share that is backed up, and the user having a local copy they can travel with on their laptop, is a pretty slick piece of technology.
There’s the added aspect that the user can make changes to the copy they are travelling with and be a more productive and industrious person. Then, when they have returned and are once again connected to their corporate network, their files that have changed will automatically synch with that remote share and pass along those updates.
There is one permutation of the above that several customers have seen lately that I wanted to pass along to you all out there. Hopefully it will arm you with the tool you need to address it as needed. Particularly if you are one of the many IT organizations that provides their executives with the folder redirection and client side caching technology so they can keep working on the road.
If you are using Word or Excel on a client side cached file and edit that file while you are in an offline state you may run into a situation where you updates are not synched as expected when you go online once again. So, alterations to the file made in that offline state appear to be lost.
The reason for this is that some Office applications need share permission access greater than Read and Change-they need Full Allow. Note that I’m talking about Sharing permissions-not NTFS permissions. From a Vista client, the code that reconciles how to deal with the updated TMP files seems to need a little more access to get the job done.
From a general diagnosis standpoint, other than the share permissions, you will see SMB traffic between client workstation and remote share that it is syncing witt. This traffic will include SMB sessions to the <filename>.DOC and the <GUID>.TMP file mentioned. A typical SMB error received for this will be STATUS_PRIVILEGE_NOT_HELD for the .DOC file, and a less cryptic STATUS_ACCESS_DENIED to the .TMP file.
The solution for this is to allow Full Allow Share permissions for the appropriate user(s) or a group they are a member of. This, of course, needs to be done on the remote share side of the folder redirection.
Generally speaking we don’t recommend that folks set sharing permissions for access to a share anyway. NTFS permissions are much more granular and configurable. There’s the added concern that NTFS permissions are a bit more reliable, in a long term manner, than the share permissions simply because they are stored on the volume file system as opposed to the registry.
As always folks just post to the blog if you have questions or comments, or if I can help out.
