2

We are trying to secure a folder with over 1 million very small text files using Windows EFS on Windows Server 2008 R2. We already have an infrastructure in place for backing up keys and data.

We started the folder encryption overnight on Friday. It took around 8 hours to complete. The next day, we ran a tool as the EFS user to verify that the content of the files matched an uncrypted backup and found no differences.

This morning, about 60,000 of these files were unreadable. Trying to open them as the EFS user resulted in an output of gibberish characters. The rest of the files were fine.

So far, we have confirmed the following:

  1. All the files that were corrupted were created in 2016 or 2017.
  2. Not all the files that were created in 2016 or 2017 were corrupted.
  3. Running cipher /R shows that the proper user and recovery user certificates were used to encrypt the file. The output of the command is no different on the broken files vs. the ones that had no issues.
  4. Most bizarrely, renaming the parent folder seems to have fixed the broken files.

I am at a loss as to what may have caused this problem and welcome any suggestions of what to look into next.

Frank Riccobono
  • 131
  • 2
  • Sounds like some problem/corruption in the filesystem index. Did you have a power outage during any running processes regarding that? Did you try to contact Microsoft already? – Bob Ortiz Jul 17 '17 at 21:05
  • Up until your #4 I assumed there was data corruption during the encryption process for some files. I can't think of a reason renaming the parent folder would recover corrupted data. Were the old name and new name composed of normal (alphabetic only) characters? You mention the dates of the files seeming relevant, so that means you didn't observe problems with files older than 2016? – PwdRsch Jul 17 '17 at 21:25
  • 1
    There were no power outages during the encryption process or otherwise. For the new name, I justed added " - ENC" to the original name (without the quotes). The original name was just letters. Re the dates, that's right the dates seemed relevant but it may just be a coincidence. No files older than 2016 were affected we have files dating back to 2007 in this folder. My guess, though, it this has more to do with the order in which Windows processed the files rather than the dates themselves. – Frank Riccobono Jul 18 '17 at 17:44

0 Answers0