Endpoint Encryption

Our Windows XP (x86) computers are encrypted using PGP/SED. I have followed the guides on Symantec.com to create a WinPE 3.0 boot image. I am able to boot to this WinPE image, open a command prompt, and use "pgpwde.exe --auth" to enable access to the encrypted disk. I'm using SCCM 2012 R2 to deploy an in-place refresh task sequence that uses USMT to capture and restore user data. The task sequence begins execution inside of Windows XP where it creates a file (TSEnv.dat) on the encrypted disk, then it captures user data, runs "pgpwde.exe --add-bypass" to skip the preboot authentication screen, then it restarts to the PGP-enabled WinPE image. Once the WinPE image loads, the task sequence engine looks for TSEnv.dat, which causes a critical failure because the file is stored on the encrypted disk. Has anyone else encountered and successfully worked through this issue?

Hi kmerenda,

To the best of my knowledge WinPE 3.0 is not yet supported.
(Not sure if this can affect the functionality, though.)

Windows PE & BartPE Tools for Symantec Encryption Desktop 10.3.1 - TECH210436
--- snip ---
See the attached Technical Note which provides instructions for creating the following types of WinPE images:

• 32-bit WinPE 1.x
• 32-bit WinPE 2.0
• 64-bit WinPE 2.0

--- snip ---

Windows PE & BartPE Tools for Symantec Encryption Desktop 10.3.2 - TECH214419
--- snip ---
See the attached Technical Note which provides instructions for creating the following types of WinPE images:

• 32-bit WinPE 1.x
• 32-bit WinPE 2.0
• 64-bit WinPE 2.0

--- snip ---

However, it seems that you would need to change the boot process of the PE disk, so that it authenticates against the disk before the USMT task sequence starts.

I believe this is currently not supported. If you think this is an important feature missing, please contact the Technical Support to file a Feature Request and bring traction to this request.


Rgs,
dcats

I must admit, I'm unclear on why you run the "--add-bypass" command if you only go onto to boot from WinPE anyway.  The bypass option only means the next time you boot from the encrypted disk, it will go straight into Windows and not the PBA.  As you're booting to WinPE anyway, the command has no effect.

Also, while you don't mention it explicitly, after you boot to WinPE and before you attempt to access the TSEnv file, can you confirm you do run the pgpwde --auth command and that this succeeds without error?

Thanks for your help, but it turns out I misunderstood the actual problem.

After SCCM starts the task sequence and completes the user profile capture, it downloads the WIM file for WinPE and stores it on the encrypted disk.  Once the PC reboots, the boot manager can't access the WIM file and we end up with "Missing operating system"

 

Not sure how to work around that one, other than moving to BitLocker.

Yeah, that sounds more consistent with how I thought SCCM operated.

As you're using PGP already, have you considered going down the Altiris route (another Symantec Product)?  Because it uses PXE, it's not subsceptible to the issue of writing a WinPE partition to an encrypted drive.  Not to mention that using PXE means you can perform a bare-metal restore of a machine if need be.

Plus, the Altiris Client Management Suite includes something called PCTransplant, which pretty much does what the USMT file does.