Windows Server Hacks: Finding All Encrypted Files on a Volumeby Mitch Tulloch, author of Windows Server Hacks08/31/2004 |
The Encrypting File System (EFS) of Windows 2000 and later is a useful tool for preventing unauthorized access to important business documents, but using this feature carelessly can place your business operations in jeopardy.
Say you're at a small firm that has a single domain controller, and you decide to promote one of your file servers to the role of domain controller in order to provide fault tolerance for Active Directory. After you've promoted your new domain controller, you start getting complaints that users can't access their files stored in shared folders on the machine. Why? When you install Active Directory on a machine, it automatically deletes any cryptographic information (keys and certificates) that were stored on the machine. The result is that users who had encrypted their files using EFS can no longer decrypt those files, and if the recovery agent's certificate and keys were not backed up, the information in those encrypted files is permanently lost.
Obviously one way of determining whether a file or folder is encrypted is to use Windows Explorer or My Computer. A file or folder that is encrypted is displayed in green by default:

Figure 1. Encrypted files and folders are colored green.
Of course, this won't work if you're color-blind. In that case you could open the Properties sheet of each file or folder on your machine and view the Advanced Attributes box to check the encryption bit of that file or folder:

Figure 2. The advanced attributes for an encrypted folder.
That route is likely to lead to tendinitis, though. Using the command line is a better approach.
Using Efsinfo
To guard against rendering encrypted files permanently inaccessible, you can use Efsinfo, a command-line tool for managing EFS. You have two ways to get this tool:
- For Windows 2000 you can download the tool from Microsoft's web site.
- For Windows XP and Windows Server 2003 you can install the Windows Support Tools from the \Support\Tools folder on your product CD.
To illustrate the use of this tool, say we have two directories named Support and Sales on volume G:, and both of those directories contain files named 002.doc, 2003.doc, and 2004.doc. Say also that the Support folder and all its contents are encrypted using EFS. To verify this scenario, run Efsinfo from the command prompt like this:
C:\>efsinfo /s:g:
G:
.: Not Encrypted
support: Encrypted
Users who can decrypt:
TESTTWO\administrator [administrator(administrator@TESTTWO)]
sales: Not Encrypted
System Volume Information: Not Encrypted
G:\support\
2002.doc: Encrypted
Users who can decrypt:
TESTTWO\administrator [administrator(administrator@TESTTWO)]
2003.doc: Encrypted
Users who can decrypt:
TESTTWO\administrator [administrator(administrator@TESTTWO)]
2004.doc: Encrypted
Users who can decrypt:
TESTTWO\administrator [administrator(administrator@TESTTWO)]
G:\sales\
2002.doc: Not Encrypted
2003.doc: Not Encrypted
2004.doc: Not Encrypted
Since we're interested only in which files are encrypted and not in any of the other information displayed, piping the output of this command to the Find command helps clean things up:
C:\>efsinfo /s:g: | find ": Encrypted"
support: Encrypted
2002.doc: Encrypted
2003.doc: Encrypted
2004.doc: Encrypted
Now, before we promote our machine to the role of domain controller, we should verify that the system volume and data volumes have no encrypted files on them. For example, running this command on the system volume of my machine gives the following results:
C:\>efsinfo /s:c: | find ": Encrypted"
C:\>
The lack of output indicates that no encrypted files are on the volume. Repeat this with all volumes on your machine, and if the results are similar, it's safe to promote our machine to the role of domain controller.
Final tip: full syntax and examples for using Efsinfo can be found in KB 243026.
Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.
Return to WindowsDevCenter.com.

