From: big country on 17 Mar 2010 17:04 Hey all I have a WinXP SP2 workstation. It has an external hard disk that is failing and there are some files that are encrypted that we cant decrypt. So we cant move the files. The user is not sure who initially encrypted the files but the file shows an AD account that is specified as a data recovery agent for that file. When I went to group policy on the local machine there was not a EFS policy defined so I created one with the data recovery account from AD. The account shows a valid cert so I logged into the pc using the data recovery account and I still cant decrypt the file. Any thoughts?
From: Shenan Stanley on 17 Mar 2010 19:55 big country wrote: > Hey all I have a WinXP SP2 workstation. It has an external hard > disk that is failing and there are some files that are encrypted > that we cant decrypt. So we cant move the files. The user is not > sure who initially encrypted the files but the file shows an AD > account that is specified as a data recovery agent for that file. > When I went to group policy on the local machine there was not a > EFS policy defined so I created one with the data recovery account > from AD. The account shows a valid cert so I logged into the pc > using the data recovery account and I still cant decrypt the file. > Any thoughts? No backups? Encryption, hard drives, etc... They can all go south without warning. Backups are the only "backup plan" that has much of any validity when they do. ;-) Is this data is so important/security sensitive - it doesn't have backup copies? One could then argue that data that important/security sensitive better have a backup copy. ;-) Encryption is made to keep people out. Secure the data. If something goes wrong with the physical drive, memory when reading it/writing it, lost key, etc - it makes no promises about you being able to recover the data. -- Shenan Stanley MS-MVP -- How To Ask Questions The Smart Way http://www.catb.org/~esr/faqs/smart-questions.html
From: Twayne on 24 Mar 2010 17:27 In news:%23vhg0VhxKHA.5940(a)TK2MSFTNGP02.phx.gbl, big country <someone(a)microsoft.com> typed: > Hey all I have a WinXP SP2 workstation. It has an external > hard disk that is failing and there are some files that are > encrypted that we cant decrypt. So we cant move the files. > The user is not sure who initially encrypted the files but > the file shows an AD account that is specified as a data > recovery agent for that file. When I went to group policy > on the local machine there was not a EFS policy defined so > I created one with the data recovery account from AD. The > account shows a valid cert so I logged into the pc using > the data recovery account and I still cant decrypt the > file. Any thoughts? If you can't locate the keys & certs that were used when the data was encrypted, it's lost for good. Nothing you create now will allow access to it, period. Hope you have backups if it's important. MS did one thing right; their encryption structure is unbeatable without a lot of time and money. See help & support for EFS for more details; look for certificate exports. HTH, Twayne`
From: Jim Nugent on 25 Mar 2010 11:14 "big country" <someone(a)microsoft.com> wrote in message news:%23vhg0VhxKHA.5940(a)TK2MSFTNGP02.phx.gbl... > Hey all I have a WinXP SP2 workstation. It has an external hard disk that > is failing and there are some files that are encrypted that we cant > decrypt. So we cant move the files. If you just want to get the files off the failing drive before it dies, still encryped, use ntbackup and put them in a .bkf file. Ntbackup will not try to decrypt them, but will simply store them. (This is Microsoft's recommended way of transporting files to the recovery agent for assistance in decrypting.) When you are ready to work on decrypting them, restore them from the .bkf file onto a good drive. Sorry I can't help more with EFS, but usually I think the local Administrator account becomes the default recovery agent on a computer when EFS is first used. Some people call EFS the Windows Delayed Recycle Bin. HTH, == Jim
|
Pages: 1 Prev: perflib_perfdata_63c Next: Patch verification registry key in another Language |