EliteDesk 800 G1 does not boot UEFI hard drives immediatly after BIOS->UEFI change

[DonZoomik]

I'm trying to change our boot configuration from BIOS to UEFI. I've tried to simplify the problem.

I'm booting via BIOS PXE to SCCM task sequence and performing following actions:

1. Apply UEFI Secure Boot configuration with BiosConfigUtility (Secure Boot enable, boot order that is ignored anyway...)
2. Set disk partition type as GPT
3. Create Fat32 partition for EFI boot and NTFS volume for data
4. Apply WinPE to NTFS and copy boot files (bcdboot) to Fat32
5. Set Fat32 volume as ESP
6. Reboot

Now BIOS will not allow me to boot this disk. Disk shows up in "Device configuration" but not in Boot order.

If I boot again to PXE (now in UEFI mode) and check disk contents, all seems in order. If I reapply my script to redo steps 4 and 5 then on following boot the disk will apper in Boot Order and boot.

If before first UEFI attempt I put in a known UEFI bootable disk, the system will not boot it either.

I'm thinking that there's a bug in BIOS.

I've seen something similar with Z620. When applying some config changes to BIOS, system will no longer show valid boot hard drives in Boot Order (that attempt was in BIOS mode). Switching controller emulation to RAID and back to AHCI worked around it then. But this time I'm not changing controller emulation.

Also BiosConfigUtility reports that it has set boot order changes but when reading them back (before or after reboot, they're the same). That's not as important but

BiosConfigUtility 4.0.15.1

BIOS v2.68

[soccer_dan]

I think you are missing the step where the machine is up and running when you boot SCCM's WinPE, and you are making changes to the BIOS and imaging 'after' changing the BIOS settings... Those BIOS settings would require a reboot to take effect

So, make the changes with BCU to reflect your need to enable SecureBoot and Boot order configuration. Reboot, and go back to pxe loading your WinPE to continue your task

[DonZoomik]

Imaging disk to GPT and BIOS configuration modification happen in one session.

I actually want configuration change to happen during restart.

So...

Boot BIOS mode

Format disk to GPT and UEFI boot

Reconfigure BIOS with BCU

Reboot - I'm expecting UEFI Secure Boot to take effect and boot to first hard disk and continue TS. Disks not checked for UEFI boot files, can only continue to PXE

I want system to boot to GPT disk so TS can continue uninterrupted for technicians.

[Duane_D]

@DonZoomik

Please refer to @soccer_dan for continued assistance for your matters. 

Thank you 

[soccer_dan]

Since you are rebooting after the BCU command, i see no reason you could not do the following in your task sequence

* boot winpe in standard bios/legacy mode

* clean drive

* format drive as per requirements for windows 10

        https://msdn.microsoft.com/windows/hardware/commercialize/manufacture/desktop/configure-uefigpt-base...

* make sure the larger partition has a label of OsDisk so the rest of the task sequence can apply the image to the right one

* run bcu to change bios settings for windows 10, uefi, secureboot, etc.

          enable 'fast boot'

          enable 'secureboot'

          enable 'uefi native mode'

          enable 'deep sleep'

* reboot

[soccer_dan]

My replied earlier seemed to imply that following certain steps will allow SCCM, WinPE, and its OSD task sequences to image a system that booted in BIOS mode with UEFI and GPT in a single sequence. There are, however, some built-in processes in SCCM task sequences that make this hard or impossible without special tweaks

Please, read the information in this link to see why it does not work as you would hope, and how it could work with manual additions and changes to the imaging sequence

http://ccmexec.com/2016/07/switch-from-bios-to-uefi-seamless-using-configuration-manager-ts-in-6-sim...

i did learn something new here - i found this link from an HP resource

Again, this is NOT a hardware or BIOS issue, but how OSD task sequences are implemented in SCCM

[DonZoomik]

Your referenced blog post was actually my starting point before hitting the issue.

And it doesn't work on EliteDesk so I starting trying to simplify the problem and make boot more standards compliant, if this was the issue.

Blog post implicitly uses HP laptops (BCU settings syntax is a bit different between desktops and laptops) and desktop and laptop BIOS seem to use different implementations so I think problem is desktop specific. I don't currently have any EliteBooks at hand for comparison. I'll try to get a few to lab.

So far I've tried a few other manufacturers systems (mainly Lenovo) and they work fine with the same process (format to GPT, change BIOS config, reboot). Both plain FAT32 boot as in blog post and ESP partition method work.

Only EliteDesk doesn't boot UEFI disks after boot mode change. It just doesn't seem to check at all if disk has any boot files and I can't even tell BIOS manually to boot to local hard disk.

SCCM and OSD TS are a red herring. I'll put together a repro without SCCM but plain WinPE to better illustrate the problem.

[DonZoomik · Accepted solution]

My repro led nowhere (successful boot) but I was engaged by HP support and while responding to their email, I accidentaly found the issue.

My BIOS configuration script had a command to temporarily disable BitLocker in case configuration is reapplied for an already deployed system.

manage-bde -protectors -disable c:

However this inexplicably caused FAT32 partition to become encrypted. If I booted to UEFI PXE SCCM WinPE during next boot, WinPE silently cleared encryption and system would boot to hard drive again, causing further confusion.

But when for a test, I booted a Linux LiveCD, it showed encryption.

I guess it has been like this for a while but only in this case C: happened to be UEFI boot partition (usually it's system partition). In retrospect, my WinPE repro image didn't also have BitLocker components...

I removed BitLocker command and now it normally boots to local hard drive after configuration change. Case closed for HP and time to engage Microsoft support...