Windows Offline Files: Problems and Solutions
This is a collection of bugs, errors and problems I encountered working with Offline Files, along with possible solutions or at least workarounds. For more information about Offline Files see also my other articles about this topic.
Too Many Files Available Offline
You have administratively assigned one or more directories to be available offline. However, the users have files from other directories in the Offline Files cache, too.
In one manifestation of this issue the customer had administratively assigned drive H: to be available offline. However, several users reported that when they looked at the files actually available offline (by starting Manage offline files and clicking View your offline files), they had files not only from H: but also from K: (which points to another share in the same DFS namespace).
The users affected by this problem were absolutely certain the had not manually made the files from K: available offline. Having enabled the Group Policy setting Remove “Make Available Offline” command we believed them.
This is most likely one of the countless bugs in Offline Files. We worked around it by changing the configuration of those network shares that were not supposed to be available offline. After ticking No files or programs from the shared folder are available offline and logging off and back on the superfluous cached files were gone.
Background Synchronization Not Working
You have configured Offline Files to synchronize in the background. The synchronization runs as planned: the Offline Files icon in the notification area of the taskbar spins regularly and the Offline Files event log (Applications and Services Logs -> Microsoft -> Windows -> Offline Files -> Operational) has events with source OfflineFiles and ID 1002 (“background synchronization successful”). There is only one problem: no files are synchronized.
We found the reason to be redirected Cookies and IE History. Those two folders can only be redirected by changing the values of the registry key User Shell Folders directly. We had done that through a custom ADM template and redirected to a subdirectory of H:. That broke synchronization. Once we changed the location of Cookies and History back to the default locations in the user profile and rebooted, Offline Files synchronization worked as expected.
Note: Other redirected folders that can be redirected “officially” did not negatively impact synchronization, e.g. Documents or Favorites.
Another thing that may prevent background synchronization from working is incorrect configuration of your network shares. Make sure you have enabled Offline Files synchronization on each share by checking Only the files and programs that users specify are available offline:
If you are using DFS, this setting must be configured for every share in the path, including the DFS root share. Example:
If the path is \\full.qualified.domain.com\dfsroot\users, the synchronization must be enabled on dfsroot (which is a share on your domain controllers) and on users (which probably is a share on your file server).
Viewing the Content of the Offline Files Cache
Windows Offline Files caches files in the directory C:\Windows\CSC. Unfortunately, very strict permissions prevent even administrators to peek inside the cache – only SYSTEM has full access.
The free tool Run As System can start arbitrary processes as local system. Pick your favorite file system browser, run it as system and you have full acess to the CSC. Windows Explorer does not work, though: it cannot be run as different user. I used Total Commander; other similar applications should work well, too.
Accessing the File Server Directly
When troubleshooting Offline Files it is often necessary to compare the view of the file system presented by Offline Files with reality, in other words compare the content of the offline files cache with the file server.
When Offline Files is enabled, network access is filtered and potentially redirected to the local offline files cache. That is how Offline Files work. To look directly at the file server a path must be used that is not configured to be available offline.
In most networks file shares can be reached via 5 paths:
- Fully qualified DFS name, e.g. \\domain.com\dfsroot\share
- NetBIOS DFS name, e.g. \\domain\dfsroot\share
- Fully qualified server name, e.g. \\server.domain.com\share
- NetBIOS server name, e.g. \\server\share
- Server IP address, e.g. \\IP address\share
Offline Files caching is per absolute path. Offline Files considers \\server.domain.com\share and \\server\share 2 independent namespaces.
That means: if \\server.domain.com\share is configured to be available offline, accessing that path shows you the content of the offline files cache, but \\server\share shows you what is stored on the file server.
About the “explorer cannot be run as a different user” – that’s only partially true. The key to do so is the “explorer elevated unelevated factory” registry as described in http://www.msfn.org/board/topic/144776-unable-to-open-an-elevated-windows-explorer-window/
The only caveat with this method: It’s hard to distinguish different explorer instances that run under different accounts ;-))
I have also often the problem that subfolders and files are not offline available. We have Notebooks with redirected Documentsfolder to the server and activated the gpo setting for subfolders, but this does not work proper.
Is there a possibility to set the “Always available offline” option in one step for all subfolder and files? I tried it with powershell and the wmi options, but this didn’t work.
I’ve no end of frustration (scrap that – outright hatred) for Offline Files. In XP and 7 it worked, with a little testing, a firm hand from a kind server admin, and a lot of background / understanding.
On Win 8, however, forget it. The problems are too numerous to mention!
I say “problems”; I’m sure there’s ONE guy in Redmond to whom many of the answers to my questions are obvious. If so, he hasn’t done a very good job of communicating them, has he? (/she? Doubt it. CSC has the mark of an arrogant man at its core…)
You can also access the shares directly by using $NOCSC$ on the end of the path:
This will force windows to connect to the share rather than looking locally.
It’s actually $NOCSC$ at the end of the server name: \\servername$NOCSC$\Sharename (works on a DFS path too)
In case you have FQDN then $NOCSC$ should come after full FQDN and before \Share. Something like \\server.domain.com$NOCSC$\share. It works with hidden shares also.
James – you are a legend!! fixed my issue!!
I have configured offline files to sync on log on and log off, my issue though is what happens if a user creates files\folders on their laptop and just unplugs the network\closes the lid, offline files have not been able to sync so when the user logs in those newly created files are not available
I encountered this problem on my home network. After having it work for a day, I had to reboot for some prob. When it came back up about 1/3rd of the files wouldn’t sync.
I use Win7SP1x64 as a desktop and use a Linux server for the “backend” — in this case, importantly as storage for most of my files. I tried several workarounds, including the two registry key additions to no effect. So I decided to investigate on the server. It showed several oplocks — One of which was on the directory that was giving problems. The time/date stamp on the oplock, BTW, coincided with a weekly full scan by MS-Sec-Essentials the prior night. Dunno why it was still locked as that job would have finished hours ago.
The way I found to work around the problem is suited for network files that are NOT edited by multiple people, as cached files have an informative lock placed on them to allow them to be cached. If someone else comes along and writes to them, the lock is
removed and the next time you try to sync, it will see the broken lock and invalidate the locally cached copy. As long as someone holds the info lock (i.e. if they cache the same content), it will read as busy.
Anyway, I added
“fake oplocks = yes”.
in the global and the specific share I wanted to cache. The manpage says it is a per-share flag, so I added it both globally and the share I needed. The effect of this is that samba will always tell win-clients that they have successfully placed an info-lock and it is ok to cache it. This is fine for me, being the only one who would alter it anyway, and it would be fine for multiple people if the content is “read-only”, But it won’t work with multiple people editing — but given that I was being locked out of caching by “myself”, it seems only 1 person can cache it at a time and if the lock isn’t removed somehow, it will also block the same person who obtained the initial lock (i.e. me).
I’d think making it read-only should allow for multiple people to cache it, but it wasn’t working — probably some other tweak (or reboot) needed. But allow uncontrolled “caching” (which I suspect may be the majority usage, since the controlled caching only allows 1 person to hold the lock (which doesn’t recognize the same person if they restart their machine and start a new smb-session with the server.