Microsoft Sync Framework and the Pains with EFS

I have been using SyncToy since the days of good old Windows XP ;-) I has been a reliable companion for swiftly backing up my data. With the update to SyncToy 2.1 on Windows 7 the situation has changed dramatically. As the source directory is EFS-encrypted and the destination directory is a network share, SyncToy fails to create new files at the destination. Unfortunately, the situation is even worse as SyncToy seems to be the victim - like myself.

SyncToy is a free tool by Microsoft for backing up files and folders. It manages folders pairs and synchronizes the contents between these locations. Different update mechanisms allow for one or both locations to be authorative concerning the contained data:

Whenever a file is copied from an EFS-encrypted location to a directory on a network share, the process fails with an error 6000 stating that the destination file cannot be encrypted. As I am storing my sensitive data on an EFS-encrypted volume and using a network share as the safe storage, this makes my backups significantly harder. SyncToy is built on top of the Microsoft Sync Framework which seems to be ultimately responsible for the issue in SyncToy. This is also described in Microsoft’s forums. But this situation cannot be blamed solely on SyncToy and the Sync Framework because the same issue affects at least ten more backup tools I have tested recently. Either these tools are all based on the Sync Framework or some API change has caused them all to fail on EFS-encrypted files. It seems Microsoft deems this kind of operation to be compromising for the security of EFS.

My Plea to the Community

Have you encountered the same problem with the Sync Framework? Have you found a workaround? Is it possible to use the Sync Framework to decrypt files on-the-fly? Are you using a tool not prone to this issue?

My Plea to Microsoft

SyncToy has stopped working for EFS-encrypted files with version 2.1 whereas version 2.0 worked like a charm. Is the current version some new APIs? Or was there an update to the APIs used? Microsoft, please update the responsible piece of code (be it an API or the Sync Framework) to override the behaviour. Let the user decide whether to deactivate this protection.

Feedback is always welcome! If you'd like to get in touch with me concerning the contents of this article, please use Twitter.