A file that opens normally in Windows 2000 may still be EFS-encrypted. The system decrypts it transparently for the authorized signed-in user. After reinstallation or loss of the profile, the same files may therefore become unreadable. This guide inventories an existing legacy system; it does not call for reconnecting it to the internet.
Prepare without changes
Preserve the original system and its backup. Use the previously used authorized account and note the computer, account, drive and data folders to inspect. EFS is an NTFS feature, not the same as NTFS access permissions or a password inside an Office file. Access denied alone does not prove EFS encryption.
Read encryption status
- Open Start, Run and enter
cmdto open a command prompt. - Change to an existing data folder, for example
cd /d "C:\Data". Replace the example path with your folder. - First run only
cipher, without switches. The Windows 2000 documentation describes this as displaying encryption status for the current folder and the files it contains. - Read the status and record encrypted files with full paths. Hidden and system files are omitted by default;
cipher /halso displays them. - Inspect other data folders and subfolders separately. One folder’s result is not a complete computer inventory. Explicitly record inaccessible or unexamined areas as unresolved.
Do not use switches that encrypt, decrypt or generate new keys during this inventory. In particular, /e, /d and /k do not belong in this read-only check. Local help, cipher /?, describes the installed version; do not assume modern switches apply to Windows 2000.
Document key dependencies
For EFS findings, record which existing account can open a file without saving it again. Opening it proves access in that session, not recoverability after migration. Decryption requires the matching private key. A copy of encrypted data or a public certificate alone cannot replace it.
If the original Windows 2000 Resource Kit is already available, its Efsinfo tool can additionally display user, recovery-agent and certificate information. Microsoft identifies it as a Resource Kit tool, not something to assume is installed everywhere. A displayed agent identity does not prove that the necessary private key still exists.
Require a recovery test before moving
Have the responsible administrator securely back up the matching user or recovery keys and perform an authorized recovery test on data copies in an isolated test environment. Key material must not go into the inventory or a support message. Workgroup and domain recovery agents can differ; administrator rights alone do not prove decryption capability.
Until data and keys are demonstrably recoverable together, do not remove profiles, recreate accounts or reinstall the old system. A missing key or unreadable test copy stops migration of that data set. The inventory itself does not decrypt or modify files.