Issue with Checkpoint Encryption on Refresh (Wipe & Load) Scenarios - “Unable to read task sequence configuration disk.”

[Stephensr]

Morning All, any ideas on this one would be greatly appreciated.

 

I am deploying our captured image using one task sequence that caters for the Bare metal and Refresh (now Wipe & Load I believe) scenarios, this has worked fined until we perform a Wipe & Load on the Checkpoint Encrypted laptops in the fleet.

 

These laptops have all partitions encrypted leaving no un-encrypted estate on them. You may already see where I am going with this….

 

The task sequence is being advertised to the user who runs the TS from within Windows enabling the capture of USMT data to the SMP. Once the USMT Capture is complete the system is rebooted to the PE boot image in order to run diskpart and apply the image etc…. This is where the TS fails. The Task Sequence config files have been staged to the c:\_SMSTaskSequence directory which is of course Encrypted within PE, we then receive the “Unable to read task sequence configuration disk.”

 

I have seen a number posts elsewhere that mention using a “Hook” that runs a diskpart script upon the restart to clean and re-partition the disk before TS begins to process. I am a little unsure how this would work as the config files will have been “blown away” by the diskpart script and surely the TS will fail again with same error, can any confirm my suspicions?

 

I have also seen some articles that mention changing the location of the Staging config files from c:\_SMSTaskSequence to x:\_SMSTaskSequence . Again I’m a bit unsure about this as I didn’t think X: was accessible prior to loading the PE boot image.

 

I hope this makes sense.

 

I look forward to hearing any suggestions..

 

Kind Regards,

 

Rich.

[The Bronx Bull]

I'm no expert on this, but in order for Windows PE to even see the encrypted file system to use the staged TS config files, don't you have to either boot to PE using Checkpoint's Alternative Boot Menu, or utilize their Dynamic Mount Utility? You cannot access the encrypted drive without authenticating into it first.

 

Things to try:

 

1) Instead of staging the config files on the local hard disk, you could set the packages and the boot image to be accessed directly from the network, instead of downloading them locally (not 100% on this).

 

2) As far as the Checkpoint authentication into the drive, I think you're going to need to need to create an additional boot image that has the Prot_Sys upper filter drivers installed (look for a utility called "pswinre" in your checkpoint files; this utility can inject them into your boot WIM).

 

3) Also, as you stated, you can most definitely perform a diskpart format in Windows PE on an encrypted drive. Have you tried making the first step of the task sequence a "run command line" step that references a diskpart script? You simply need to find a way to execute this step prior to the staging of the TS files.

 

i.e. diskpart.txt

 

select disk 0

select volume 1

format fs=NTFS quick override

exit

[continue with TS]

 

You need the override command to perform the format because while encrypted with Pointsec, the disk is technically in use.

 

 

Sorry I couldn't be of more help. I do have experience in making WinPE boot media that is accessible to encrypted drives, but anything beyond that, I have no yet explored.

[The Bronx Bull]

.

[Stephensr]

Thanks for your response Bronx Bull….

 

3^rd party Encryption and OSD really don’t play nice and it’s giving me a bad headache! ;-)

 

1. All packages are being run directly from the DP’s however when the TS runs it automatically stages the TS config files (_SMSTaskSequence) to a local drive, then boots to PE and references the _SMSTaskSequence directory… I think re-directing the staging directory to a network share sounds like it could get really quire messy, if as you say it is even possible. I will investigate further…
   
2. I have heared about the Checkpoint filter drivers but from what I have read they seem to be for Bart PE and have not seen or heard of any succesfull SCCM OSD Win PE integrations…
   

1. Not really possible as the OS is running at the time of TS execution… so the process is:
   

• If the user initiates the TS and the config files are staged locally on the encrypted C partition,
  
• The TS then runs USMT and stores data on the SMP
  
• The system then reboots to WinPE
  
• (I will test the following tomorrow) Create TSHook and a Diskpart script to run prior to the TS starting which blows away the encryption & _SMSTaskSequence directory and creating a new un-encrypted file system acessablie from WinPE
  
• I will test but I expect the TS will fail as the _SMSTaskSequence containing the TS config files has been blown away by Diskpart…unless I’m missing something??
  

 

 

I suspect for the encrypted laptops I will need to remove USMT from the TS and use Separate TS’s for Back-up (USMT Scanstate) and Restore (USMT Loadstate) and have the field guys PXE boot the encrypted laptops and process the TS as a “New Computer” thus blowing away the encryption straight away - Only after the user has successfully run the BackUp TS though…..

 

Fun & Games… J

 

Rich.

[The Bronx Bull]

Hmmmm... there might be a way to set a task sequence variable just prior to the diskpart that keeps _SMSTaskSequence and wipes around it... but that's a long shot. In my hardlinks' task sequence, the "OSDStateStore" variable is set, and the drive is wiped around that particular folder.

 

One thing though - it doesn't sound like the USMT is the problem? Since the scanstate is running successfully and the user's data is being stored securely on a network share, shouldn't the first step of your TS be to partition and format the drive? See the attached screenshot - this task sequence of mine runs the partition step first and immediately after execution (without needing any TS files, then reboots, *then* stages the boot WIM and other TS config files.. I do not believe the boot WIM is staged the first time around when PXE booting or from boot media?

 

Then you would simply need to integrate a loadstate into the tail end of your TS - or is there something I'm missing?

 

It definitely sounds like you have your hands full though!

[Stephensr]

Morning Bronx Bull

 

The OSDStateStore sounds interesting, although because the whole drive is encrypted I wonder if this will still work. Because the TS is running a Refresh(Wipe & Load) it is being run from within the OS… I don’t think you can diskpart the C partition when the OS is running…

 

I totally agree that USMT isn’t the issue..and yep like your TS I have UMST loadstate is in the tail end of the TS, which works as expected. This TS including USMT works absolutely fine on un-encrypted systems, it’s purely the encrypted laptops that are causing the issue..

 

From the image provided you can see that:

1. Refresh scenario is initiated from within the exisiting OS in order to perform USMT tasks on WinXP or Win7 using the variable = SMSTSInWinPE = False)
   
2. USMT Scanstate completes….
   
3. The system then performs the Reboot task to the associated boot image which stages the following to the encrypted drive in the _SMSTaskSequence directory prior to actually rebooting:
   

• TSEnv.dat
  
• Backup directory
  
• Logs directory
  
• WDPackage directory
  
• WinPE directory
  

1. The system the reboots, Checkpoint encryption then prompts for logon credentials which are then entered.
   
2. Win PE then boots and attempts to initiate hardware devices, however because the disk is not yet accessible and is actually still encrypted at this moment in time the “Unable to read task sequence configuration disk” message is displayed and the task sequence fails
    
    
   Please see the TS attached…
   

[The Bronx Bull]

Ok here's what I think you have to do - and once again, I'm no expert on this, just trying to help.

 

I assume you're using Checkpoint Pre-Boot Authentication. Just as normal, execute the task sequence from the Windows OS. Once it reboots, enter the Checkpoint credentials at the login screen, which will bring you to the first attachment below.

 

At this screen, hit "CTRL+F10" (you will get no visual indicators that you have done so), then hit continue... Checkpoint's Alternative Boot Menu will load, looking like the second attachment.

 

From here, I *think* you're going to boot to the hard drive (to continue to the next step in the TS), but your boot image has to have those Checkpoint upper filter drivers installed.. you can also try fiddling with PXE booting from the ABM.. The drivers can be located in their Dynamic Mount Utility pack. And good luck getting support from Checkpoint on this issue! (Ha!)

 

I can tell you this: in order to see and read data from the drive while in WinPE, you need two things: 1) your WinPE boot WIM has to have the Checkpoint filter drivers injected, and 2) you have to boot from the ABM. Once you do those two things, you can see the encrypted drive just fine, since you've "authenticated."

[The Bronx Bull]

Attch 1: PSWinRE Utility (mounts and injects drivers)

Attch 2: Filter Driver Location

 

If you do this, I wouldn't overwrite your base x86 WinPE boot.wim - snatch a fresh boot.wim from the WAIK Program Files to test with, and then import your "Checkpoint boot.wim" into SCCM, update the task sequence to use the newer boot image, etc.

[Stephensr]

Bronx Bull,

 

I've been working away in the lab and after a few teething issues with DMU compilers I can confirm that with the filter drivers injected the TS is working fine on the Encrypted systems!

 

If I am ever in Upstate NY I owe you a beer or two!!

 

Thanks-for taking time out to assist, really appreciated!

 

Issue Resolved!

 

Rich.

[bjohn]

Stephen/Bronx B,

 

I'm doing USMT hardlinking going from XP to 7. I added the filter drivers and the TS is able to continue. But after the imaging is complete, the pointsec preboot screen still comes up and when I login the OS will bluescreen and reboot, probably because the drive is still encrypted? and windows 7 can't access the drive.

 

How did you get around this?

 

Thanks

[Stephensr]

Hi there...

 

Yes you are correct...the blue screen is occuring because the pointsec pre-boot sector is referencing data on the drive that no longer exists...

 

Are you re-sizing the partitions?

 

I'm pretty sure that hard linking on an encrypted disk is not possible if you are resizing the drive... we are using a State Migration Point to store our backed up data....

 

because we resized the partitions I had to break the refresh senario into two phases using two task sequences on encrypted laptops..

 

1st ) A simple back -up TS which runs USMT and stores the data on the SMP

2nd) A deploy TS which deploys the image etc...however the encrypted laptops have to be pxe booted to this in order to re-partition and remove the pointsec pre-boot sector on the drive.

 

 

Rich.