Question for Garlin: Ran that latest Check-UEFI-CA2023.ps1 script from GitHub. (GitHub - garlin-cant-code/SecureBoot-CA-2023-Updates: PowerShell scripts for checking and applying Secure Boot CA 2023 updates for Windows.) *Instead of uploading these files; point people to your GitHub site. 1 central point. No mix up with old an new files. Always the latest.*
Sometimes I will upload a work-in-progress build to ElevenForum, before committing a formal release to GitHub. This allows me to get faster feedback on bug reports. There are more traditional devs who put out beta branches on GitHub, but I'm trying to keep as simple for normal users.
I still see "[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING." As this is an optional feature as mentioned should I ignore it? Found an old winsipolicy.p7b file that dates from 01-04-2024 on my Boot partition. (Found SKUSiPolicy.P7b (xx-05-2026) in the C:\Windows\System32\SecureBootUpdates directory where MS updates it's KEK, DB and DBX .bin files by updates.)
MS recommends you deploy a SkuSiPolicy as an additional security feature, whenever VBS is used. For a simple Windows user who isn't playing around with a dual-boot setup, or using a Macrium-like recovery disk then SkuSiPolicy is perfectly fine. SkuSiPolicy lists a set of file rules, mostly banning certain versions of winload.efi.
If you have a dual-boot setup, especially when playing with an Insider build, the SkuSiPolicy's banned versions may conflict with booting the other Windows. Or your bootable USB drive will have a base WinRE that contains a blocked version. I can't predict when that could happen. So the script recommends SkuSiPolicy as an optional step you can take.
You can manually copy the SkuSiPolicy from the SecureBootUpdates folder to \EFI\Microsoft\Boot, or have the update script do with the "
-SkuSiPolicy" option.
In earlier results and the latest version I saw no drive mentioned like; "Disk 0: Windows Boot Manager..", "Disk 1:...", or "\\?\Volume{GUID}..." In the above "EFI Files" section. This because my C-drive resides on Disk 3. But still it should find by it's GUID? (Just a cosmetic remark. Despite the lack of it it's functioning fine.)
Windows allows you to access files on the ESP, using the volume {GUID} filepath. This avoids the need to mount (assign a drive letter). But the problem is everyone likes the read the fine details on the report, and they don't understand that GUID's are random numbers. Switching to the HarddiskVolume notation is more compact, and you can actually use it to list and copy files from.
One of the problems I realized was that some users have really unique disk layouts. Folks who are cloning drives, doing failed migrations, etc. so you can't simply assume the ESP is on disk 0, and typically the first partition. Disk [N] by itself is inprecise for this reason. A volume GUID is the most accurate, but non-technical users don't know how to use the path.
it's also wise to update any bootable USB stick in order to bring their bootx64.efi (<drive>:\efi\Boot) up to date. No changes are made in \EFI\Microsoft\Boot... Should that also not be the case??.... A while back I booted from an USB-stick and the system told me that I used the wrong SVN version and shutdown. The same with an alternative that I burned onto an bootable DVD. (Found 1.0, wanted 3.0 and Found 3.0 and wanted 7.0) Could not understand what was wrong and how to fix it, now I do; "Update-UEFI -bootmedia" *Apart from that \EFI\Microsoft\Boot modify question*
There are WinPE and WinRE style boot media. WinPE is mostly bootx64.efi and a few other files, WinRE is essentially using bcdboot (or the equivalent action) to copy more folders and files to \EFI\Microsoft\Boot.
When the UEFI cannot find \EFI\Microsoft\Boot\bootmgfw.efi, it falls back to booting \EFI\Boot\bootx64.efi. If you're updating boot media, it's best to recognize the media type and do the right things. I used to have a bug where bcdboot didn't do anything because of a missing colon in the drive letter (some PS functions want a colon for the drive letter, other functions don't...).
bcdboot nevertheless doesn't throw an error, and reports boot files have been copied. When nothing happened.
Note: In Update-UEFI.bat you forgot to add "where pwsh >nul 2>nul" as is the case with Check-UEFI.bat. Got an error while I tried my USB bootmedia's saying "'pwsh' is not recognized as an internal or external command, operable program or batch file." With that line added to the script the script did it's job.
I have "where pwsh >nul 2>nul" in
Update-UEFI.bat, but apparently the GitHub folder has the old version of the file.
Will fix in the next release.
A very nice collection of scripts by the way! (especially the option -bootmedia) 
It does more than cjee21 scripts does.
One of cjee21's scripts was my inspiration for the scripts, but I had to start this project because the reporting wasn't as clear as I thought it needed to be and users need to know what actions they're supposed to take. It shouldn't be your job to interpret random reg values or search through Event ID's to figure what to do next.
And the update script provides immediate feedback, either it worked or it didn't. If the update failed, then you have an unsupported BIOS and manual help is required. But the script is non-destructive and has safety checks built in. The hard part is getting users to navigate their BIOS screens if you have to manually enroll KEK CA 2023 (ideal) or enter Setup Mode (as the last resort).
www.elevenforum.com
