Secureboot preventing booting into windows after imaging

[ahaeder]

FOGProject version 1.6.0-beta.5136 running on Ubuntu 26.04.1 LTS and php 8.5.4.

I am working with Dell Optiplex 3000 thin clients. I have successfully done the following with secureboot disabled (UEFI enabled):

• Manually created a golden image of Windows 10 IoT, ran sysprep
• Booted to FOG PXE and done a complete inventory
• Captured the hard drive image to my fog server
• Deployed the image to a different Optiplex 3000
• Successfully booted that 2nd system. Even joined my windows domain, after changing the hostname

Where I run into problems is with secureboot. I successfully followed the instructions to get MOK.der accepted by the clients (did it manually from the pxe boot menu), so now I can enabled secureboot in the bios and the fog menu options work (inventory, debug, deploy image). However, when I attempt to boot the imaged WIndows 10 IoT after secureboot is enabled, I get an error.

If I let the system boot normally from pxe, I get the fog menu, which select ‘boot from hard drive’ after 3 seconds. It tries to SAN boot the partitions on the drive, and each one says “Verification failed: Security Policy Violation”. If I attempt to boot directly to the hard drive, the Dell bios immediately goes into testing mode because it can’t find a partition it can boot from.

I know this is 100% a secureboot problem because as soon as I disable secureboot in the bios Windows boots up and everything is happy.
On the original Optiplex that I created the golden image on (I installed Win10 IoT from a usb flash drive) I am able to perform the entire install while secureboot is enabled. So I know that secureboot can work with Windows on these thin clients.

But for some reason I can’t get it to work after fog deploys a good image to one.

What am I not understanding about the secureboot process? I even went into the bios, select ‘custom keys’ and reset all the keys to the defaults. I also tried running “bcdboot C:\Windows /s S: /f UEFI” post-image deploy, with secureboot disabled, trying to get windows to recreate the uefi partition. Turned secureboot back on, still didn’t work.

I’m running out of things to troubleshoot here, and I’m hoping some folks with more experience in secureboot have some ideas for me. Thank you!

[ahaeder]

For anyone else struggling with this, I finally figured it out. FYI this is not a fog issue, it’s a Windows secureboot UEFI issue.

Once I image a machine, I need to make sure secure boot is disabled, boot windows, and run these commands from an elevated command prompt:

mountvol s: /s
del s:*.* /f /s /q
bcdboot %systemroot% /s S:

That will rebuild the EFI partition files.

I did this, rebooted to the bios, re-enabled secureboot, and Windows successfully booted. Hooray.

My only issue now is that I can’t do unattended reimaging with secureboot enabled. If I push my golden image back to this system with secureboot enabled, Windows will fail to boot again until I make it rebuild the EFI partition files. What’s so weird to me is that I don’t have this problem on Wyse 5070 thin clients - I can leave secureboot enabled all day, reimage a system, and Windows boots just fine. But these Dell Optiplex 3000s sure don’t like it.

[Tom Elliott]

Glad you have a workaround. I think the cause is the Windows boot manager certificate change, not the image.

Your golden Optiplex installed Windows with Secure Boot on. Windows servicing then added the “Windows UEFI CA 2023” certificate to that machine’s db, and switched the boot files to a boot manager signed with it. The other Optiplex 3000s only trust the 2011 Microsoft certificates, so they reject that boot manager. bcdboot works because it copies the older 2011-signed boot manager.

Can you confirm with two checks, in admin PowerShell, on the golden machine and on one target?

[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

mountvol S: /s
(Get-AuthenticodeSignature S:\EFI\Microsoft\Boot\bootmgfw.efi).SignerCertificate.Issuer

If the golden machine says True and the target says False, that is the cause. A newer Dell BIOS may include the 2023 certificate in its default keys. I am also looking at having FOS add it during the Secure Boot enrollment task.