The problems with EFS can be greatly compounded if you are not looking for it as a possible culprit. When a user tries to access a file that has been encrypted by someone else, depending on the type of access attempted or the application being used, the user will generally get one of two messages: Access Denied or This File Appears To Be Corrupted.

If the Access Denied message appears, most end users assume that an admin has improperly locked them out, so they contact the help desk. If the person troubleshooting the problem just looks at the permissions on the file or folder, there’s no indication that a user has been denied access. Only bringing up the file’s advanced properties will reveal the problem. Many man-hours can be wasted pursuing other potential problems, such as group permission conflicts.

Of the two common messages users receive when they are not allowed to read the file due to EFS, the Access Denied message is the good one. Users receiving a message indicating that the file appears corrupted may go so far as to delete the file. Since EFS will not stop the deletion, users will be able to do so. If the person troubleshooting the situation is not looking for EFS as the potential problem, things can get far worse when the message This File Appears To Be Corrupted occurs. There are quite a few horror stories already being attributed to this scenario. Take the following example:

Two users working different shifts share the same Vista system. The user working the evening shift has a fair amount of downtime and uses it to explore different aspects of the system. Upon discovering the Encrypt Contents To Secure Data setting, he decides to activate this feature. "What’s wrong with securing the data?" he says to himself.

He has selected a file in a folder shared by both users, and the default EFS setting indicates that not only should the file be encrypted, but the parent folder as well. The user accepts this and clicks OK. Now every file created in this folder will be encrypted to the user who created it and unreadable by the other user. The user in the evening modifies these files without issue and believes everything is working fine.

When the daytime user tries to open a file in this folder, she receives a message indicating that the file’s data appears to be corrupted. She calls the help desk and indicates that there’s a problem. The files in this folder needs to be written to every day as part of their jobs, so the problem needs to be solved quickly. A help desk tech shows up and begins troubleshooting the problem. The tech tries deleting and restoring the file from the nightly backup, but unfortunately EFS files back up encrypted. So the restored file also comes up corrupted. The tech believes this signals a problem with the application used to edit the file. The tech reinstalls the application, but the problem persists.

Needing to solve the problem quickly, the tech decides to reload the operating system, since there is a backup of the data. The reload of the OS erases the keys used to encrypt the data, and it’s now completely unreadable!