I’m doing this right now. It’s not impossible. We’ve currently migrated over 5000 windows xp workstations to windows 7 without Decrypting, or using any 3rd party product. The trick is to not only add the PGP drivers to your PE Boot Image, but also capture a Windows 7 image with PGP installed as well. There are documents from Symantec to help you do this.
Feel free to email me offline if you want to talk deeper about the hows. Thanks, Joshua From: [email protected] [mailto:[email protected]] On Behalf Of Marcum, John Sent: Tuesday, April 22, 2014 10:25 AM To: '[email protected]' Subject: RE: [mssms] Wipe the PGP MBR in a task sequence It's basically impossible to do a refresh of a machine with third party encryption in a single task. Managers "want" all sorts of things, some of them just can't be done. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Merenda, Kenneth Sent: Tuesday, April 22, 2014 10:51 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Wipe the PGP MBR in a task sequence My manager wants it all done in a single TS, where the technicians can kick it off and walk away. -Kenneth From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Tuesday, April 22, 2014 10:43 AM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] Wipe the PGP MBR in a task sequence Can you initiate the userstate store while in windows? Then just usb boot the machine and nuke the disk (without loading the pgp drivers). You would have to add a variable or two to the TS, so it would run as a refresh, and would know where the userstate was stored to. 3rd party encryption tools make imaging “exciting”. 😊 Sent from Windows Mail From: Merenda, Kenneth<mailto:[email protected]> Sent: Tuesday, April 22, 2014 11:37 AM To: [email protected]<mailto:[email protected]> I have an in-place refresh task sequence with USMT for upgrading XP to win7. Our XP clients are all encrypted with Symantec Encryption Desktop (formerly PGP) v10.3. Symantec provides instruction for adding the PGP drivers to the WinPE image, and that works. My task sequence is initiated via USB boot media, and loads into that modified boot image. A prestart command on the boot image (pgpwde --auth --disk 0 --p “passphrase”) unlocks the encrypted drive. The task sequence begins by capturing the user state to a SMP, then runs the disk format and partition step. Everything that I just described works, except for the disk format and partition step. While that step does complete without error, it does not get rid of the PGP MBR. The next time the task sequence restarts the computer, it loads into the PGP bootguard rather than into the WinPE image. I’ve tried a command line step to manually run diskpart clean, and while that step also completes, it still doesn’t touch the PGP MBR. After days of troubleshooting, I’ve identified that once the pgpwde –auth command unlocks the drive, the PGP filter drivers block access to the MBR, but they do so in a way that still allows tools like diskpart to complete without any error. The only Symantec-supported method to get around this is to fully decrypt the drive –a process that can take hours or days. I think the only solution is a 3rd party substitute for diskpart, like pldd or FAU DD. I can’t seem to find one, however, that works in WinPE x64 and works against PGP. Pldd is not supported in 64-bit PE (which I must use), and FAU DD doesn’t seem to function properly in WinPE. The diskpart clean command actually works fine if I use it before issuing the PGP –auth command, but obviously I have to issue the PGP command first so I can capture the user data and have somewhere to store the SMSTS packages. I can’t reboot after capturing the user data because I can’t modify the MBR to get it to boot to the WinPE image instead of PGP. Any ideas on how to blow away the MBR? Any known 3rd party tools that work inside 64-bit WinPE? Thanks in advance, -Kenneth Merenda ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. ________________________________ Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
