Solved garlin's PowerShell scripts for updating Secure Boot CA 2023

fg2001gf11F · 2026-10-15T03:24:08-0400

garlin said:
.p7b files are binary files created from a XML policy file. You need a tool or script to convert the .p7b back to a recovered XML (which can be parsed for a version number)

Run the check script in -Verbose mode.

Code:

EFI Files --------- Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED. \\.\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi File Version: 28000.376, SVN 12.0 Registry: "WindowsUEFICA2023Capable" = 2 [Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager. SkuSiPolicy.p7b is CURRENT. \\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b Version: 3.0.0.19

I just realized the Check_BootMedia.ps1 script, doesn't actually report what version of the SkuSiPolicy file is being enforced. Should add that to the next version. I made that decision to simplify the boot media's script output, since it's currently overloaded with too may details.

Thanks.
Here it is:

I don't understand the list below for the FileRule, are those the builds that are blocked from booting?

Scott · 2026-10-15T03:51:30-0400

fg2001gf11F said:
I got it to work with this installation media that was made from uup-dump, I just copied the same SkuSipolicy.p7b from the system EFI partition S:\EFI\Microsoft\boot to the USB installation media E:\EFI\Microsoft\boot

Interesting. My Macrium boot media doesn't need that file to boot.

Or my Windows install media (built with UUPdump ISO)

fg2001gf11F · 2026-10-15T04:10:54-0400

Scott said:
Interesting. My Macrium boot media doesn't need that file to boot.

View attachment 186714

Or my Windows install media (built with UUPdump ISO)

View attachment 186715

Scott,
It depends on which version of SkuSIPolicy.p7b is installed on your running system. If it is not the latest current version 3.0.0.19, it may still work.
I have machines where that policy is completely missing in the EFI partition of the running system and they can boot any installation media.

I think the latest Policy 3.0.0.19 is really restrictive. It also would not boot with a lower Build, I have to use 26300.9711, the older build 26300.9457 installation media fails to boot even if I copy that policy file in the same folder.
Typical Microsoft confusion and lack of any explanation.

anchamp65 · 2026-10-15T10:01:58-0400

Scott said:
Interesting. My Macrium boot media doesn't need that file to boot.
Or my Windows install media (built with UUPdump ISO)

fg2001gf11F said:
Scott,
It depends on which version of SkuSIPolicy.p7b is installed on your running system. If it is not the latest current version 3.0.0.19, it may still work.
I have machines where that policy is completely missing in the EFI partition of the running system and they can boot any installation media.
I think the latest Policy 3.0.0.19 is really restrictive. It also would not boot with a lower Build, I have to use 26300.9711, the older build 26300.9457 installation media fails to boot even if I copy that policy file in the same folder.
Typical Microsoft confusion and lack of any explanation.

Like Gatlin explained in previous posts, SkuSIPolicy.p7b needs to be mannually installed by the user.
So it's never missing from a system, it's just not applied on that system's EFI partition.

Also, it's not more or less restrictive from version to version, it's a presence check.
If present on EFI partion, any OS or boot media will need the same version or higher compared to EFI partition version to allow booting.
If not present/applied on EFI partition, anything will be allowed to boot regardless of presence/absence of any SkuSIPolicy.p7b on the boot media.

garlin · 2026-10-15T11:51:01-0400

fg2001gf11F said:
I don't understand the list below for the FileRule, are those the builds that are blocked from booting?

The FileRules represent block lists. If your version of winload.efi falls inside one of the named ranges, it's banned.

Each of the different Windows release channels (Production, Insider, "ring whatever") can have a different version of winload.efi. Why does it really need to be different? Only MS really knows because it's their code. They're never going to detail it, because it's security by obscurity (Fight Club rules).

The SkuSiPolicy has to balance two objectives. The lower bound of any blocked range gets progressively raised over time to block older versions of winload.efi. But care has to be taken on the upper bound, as not to block future versions. Teams at MS have to co-ordinate because a Windows Insider might be in a dual-boot setup where one releases pushes out a policy file that unintentionally blocks the other release.

When you see a rule encompass 65555.65555.65555.65555, that's the policy's method of saying "infinity" for the Windows build number. An attacker can't pretend to number their winload.efi way higher than any recognized channel.

Given how quickly some preview builds are tossed out, SkuSiPolicy can sometimes end up a barrier to successful dual booting. This is why my scripts no longer recommend the user implement SkuSiPolicy whenever VBS is enabled. It's too hard to predict the future (of build numbers).

garlin · 2026-10-15T12:03:38-0400

Finally, as @suatcini54 likes to point out, you can skip the problem by not defaulting to the Windows boot manager as your primary boot device.

When Windows installs itself, it updates the BCD to create a Windows boot manager entry which is the top (or first) entry. If you allow the BIOS to boot from the bootmgr entry, the BIOS will boot from the assigned EFI volume. Any SkuSiPolicy present on the EFI volume you booted from will control what is boot chained next in line. This could be the same system disk as the EFI, another disk or a removable device.

You can interrupt the BIOS boot sequence with whatever Function-key interrupt for your BIOS, and then manually select the USB boot device from the BIOS's own list of bootable devices. Now the BIOS will read the boot manager or boot file from the USB. Since it bypassed the boot file on the system disk's EFI volume, there is no SkuSiPolicy to enforce. Well, unless you copied one to the USB drive.

Using this method is slightly more work, because you have to remember to interrupt the default boot sequence and manually pick some other boot device other than the Windows boot manager entry sitting at the top of the BCD order.

fg2001gf11F · 2026-10-15T12:26:36-0400

garlin said:
The FileRules represent block lists. If your version of winload.efi falls inside one of the named ranges, it's banned.

Each of the different Windows release channels (Production, Insider, "ring whatever") can have a different version of winload.efi. Why does it really need to be different? Only MS really knows because it's their code. They're never going to detail it, because it's security by obscurity (Fight Club rules).

The SkuSiPolicy has to balance two objectives. The lower bound of any blocked range gets progressively raised over time to block older versions of winload.efi. But care has to be taken on the upper bound, as not to block future versions. Teams at MS have to co-ordinate because a Windows Insider might be in a dual-boot setup where one releases pushes out a policy file that unintentionally blocks the other release.

When you see a rule encompass 65555.65555.65555.65555, that's the policy's method of saying "infinity" for the Windows build number. An attacker can't pretend to number their winload.efi way higher than any recognized channel.

Given how quickly some preview builds are tossed out, SkuSiPolicy can sometimes end up a barrier to successful dual booting. This is why my scripts no longer recommend the user implement SkuSiPolicy whenever VBS is enabled. It's too hard to predict the future (of build numbers).

No new MCT .9711 yet, at 9:25 AM Pacific time on Thursday, Oct 15,2026.

neldog · 2026-10-15T12:30:05-0400

garlin said:
Code:

Update-UEFI.bat -BootMedia

Hi Garlin,

I still get this below when I run; Update-UEFI.bat -BootMedia, v2610.10.14. I am on 26300.9711.
You think maybe it is because I use the Free version of Hasleo?

Thanks, I would like not to see that "BANNED" at the end, it's driving me nuts.

garlin · 2026-10-15T12:37:20-0400

fg2001gf11F said:
No new MCT .9711 yet, at 9:25 AM Pacific time on Thursday, Oct 15,2026.

abbodi's mentioned the typical release windows are 10 AM and 2 PM. The world's not ending yet.

garlin · 2026-10-15T12:41:42-0400

neldog said:
I still get this below when I run; Update-UEFI.bat -BootMedia, v2610.10.14. I am on 26300.9711.
You think maybe it is because I use the Free version of Hasleo?

Thanks, I would like not to see that "BANNED" at the end, it's driving me nuts.

It's banned because this USB drive has an older version of boot.wim. Try recreating the USB drive from Hasleo, it should pick up the current WinRE as the base image.

The update script can fix problems with the boot file, which is separate from boot.wim. When a boot.wim is outdated, you have to ask whatever created the USB recovery drive to start over and pull the most recent bits (which should be compliant).

neldog · 2026-10-15T12:43:34-0400

garlin said:
It's banned because this USB drive has an older version of boot.wim. Try recreating the USB drive from Hasleo, it should pick up the current WinRE as the base image.

The update script can fix problems with the boot file, which is separate from boot.wim. When a boot.wim is outdated, you have to ask whatever created the USB recovery drive to start over and pull the most recent bits (which should be compliant).

Okay, thanks. I did just make that USB media, but I will try it again. Thanks for all your help.

Monika1491 · 2026-10-15T13:06:14-0400

New ESDs have been released.

garlin · 2026-10-15T13:06:18-0400

Code:

>MCT_ISO_version.bat
Current MCT ISO is build 26300.9711 (October 2026)

Scott · 2026-10-15T13:25:18-0400

fg2001gf11F said:
It depends on which version of SkuSIPolicy.p7b is installed on your running system. If it is not the latest current version 3.0.0.19, it may still work.

I applied it on Tuesday with Update_UEFI-CA2023.ps1 -SkuSiPolicy.

garlin said:
You can interrupt the BIOS boot sequence with whatever Function-key interrupt for your BIOS, and then manually select the USB boot device from the BIOS's own list of bootable devices. Now the BIOS will read the boot manager or boot file from the USB. Since it bypassed the boot file on the system disk's EFI volume, there is no SkuSiPolicy to enforce. Well, unless you copied one to the USB drive.

That might explain it as that is the only way I boot to USB.

gunrunnerjohn · 2026-10-15T13:38:27-0400

garlin said:
Finally, as @suatcini54 likes to point out, you can skip the problem by not defaulting to the Windows boot manager as your primary boot device.

When Windows installs itself, it updates the BCD to create a Windows boot manager entry which is the top (or first) entry. If you allow the BIOS to boot from the bootmgr entry, the BIOS will boot from the assigned EFI volume. Any SkuSiPolicy present on the EFI volume you booted from will control what is boot chained next in line. This could be the same system disk as the EFI, another disk or a removable device.

You can interrupt the BIOS boot sequence with whatever Function-key interrupt for your BIOS, and then manually select the USB boot device from the BIOS's own list of bootable devices. Now the BIOS will read the boot manager or boot file from the USB. Since it bypassed the boot file on the system disk's EFI volume, there is no SkuSiPolicy to enforce. Well, unless you copied one to the USB drive.

Using this method is slightly more work, because you have to remember to interrupt the default boot sequence and manually pick some other boot device other than the Windows boot manager entry sitting at the top of the BCD order.

You clearly understand this stuff very well, probably better than a vast majority of folks here. How did you acquire all this knowledge about the inner workings since Microsoft doesn't necessarily want to share all the details.

fg2001gf11F · 2026-10-15T13:49:11-0400

garlin said:
Code:

>MCT_ISO_version.bat Current MCT ISO is build 26300.9711 (October 2026)

Downloading now, we'll see what it puts on the USB installation media.

neldog · 2026-10-15T14:25:00-0400

garlin said:
It's banned because this USB drive has an older version of boot.wim. Try recreating the USB drive from Hasleo, it should pick up the current WinRE as the base image.

The update script can fix problems with the boot file, which is separate from boot.wim. When a boot.wim is outdated, you have to ask whatever created the USB recovery drive to start over and pull the most recent bits (which should be compliant).

neldog said:
Okay, thanks. I did just make that USB media, but I will try it again. Thanks for all your help.

USB Drive D: "HASLEOBS"
Boot File [Windows UEFI CA 2023] is ALLOWED.

boot.wim:1 (WinRE 26100.1)
Boot Manager [Windows UEFI CA 2023] is BANNED.
winload.efi is BANNED.

Well, this will just not play nice, lol. I have tried every method, and nothing has worked. At this point, I am forced to find new backup software as I am unable to make Hasleo play ball. I think maybe Hasleo (I am using the free version) is trying to use the WinRE partition for source files.

Thanks for all your patience and help. It looks like the fix for my problems will be another software program.

C:\Windows\System32>reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: f84904b2-c66f-11f1-80fe-901057b98ecf
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0
Windows RE Version: 10.0.26100.9711

REAGENTC.EXE: Operation Successful.

garlin · 2026-10-15T14:26:34-0400

neldog said:
USB Drive D: "HASLEOBS"
Boot File [Windows UEFI CA 2023] is ALLOWED.

boot.wim:1 (WinRE 26100.1)
Boot Manager [Windows UEFI CA 2023] is BANNED.
winload.efi is BANNED.

Well, this will just not play nice, lol. I have tried every method, and nothing has worked. At this point, I am forced to find new backup software as I am unable to make Hasleo play ball. I think maybe Hasleo (I am using the free version) is trying to use the WinRE partition for source files.

Thanks for all your patience and help. It looks like the fix for my problems will be another software program.

Paging Dr. @KevTech

gunrunnerjohn · 2026-10-15T14:30:55-0400

fg2001gf11F said:
Downloading now, we'll see what it puts on the USB installation media.

I got this ISO: Windows11_Client_x64_en-us_26300_9457.iso

But my current build is this: 26300.9711

TheVisitor · 2026-10-15T14:45:16-0400

neldog said:
USB Drive D: "HASLEOBS"
Boot File [Windows UEFI CA 2023] is ALLOWED.

boot.wim:1 (WinRE 26100.1)
Boot Manager [Windows UEFI CA 2023] is BANNED.
winload.efi is BANNED.

Well, this will just not play nice, lol. I have tried every method, and nothing has worked. At this point, I am forced to find new backup software as I am unable to make Hasleo play ball. I think maybe Hasleo (I am using the free version) is trying to use the WinRE partition for source files.

Thanks for all your patience and help. It looks like the fix for my problems will be another software program.

C:\Windows\System32>reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: f84904b2-c66f-11f1-80fe-901057b98ecf
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0
Windows RE Version: 10.0.26100.9711

REAGENTC.EXE: Operation Successful.

What do you get if you run the bootmedia with -verbose I'm going to guess the SVN is not up to date: should be at '12' as of couple days ago I had to manually update the Hasleo boot file:

Hasleo 5.9.2.4
--------------
WinPE Boot Manager [Windows UEFI CA 2023] is ALLOWED.
C:\Program Files\Hasleo\Hasleo Backup Suite\bin\WADK\Boot\EFI_EX\bootmgfw.efi
File Version: 28000.376, SVN 12.0

Bootable Media
--------------

USB Drive G: "HASLEOBS"
Boot File [Windows UEFI CA 2023] is ALLOWED.
G:\EFI\Boot\bootx64.efi
File Version: 28000.376, SVN 12.0

boot.wim:1 (WinPE 26100.1)
Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\Windows\Boot\EFI_EX\bootmgfw_EX.efi
File Version: 28000.376, SVN 12.0

\Windows\System32\winload.efi is ALLOWED.
File Version: 26100.1

Solved garlin's PowerShell scripts for updating Secure Boot CA 2023

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Rancho Seldom Siesta

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Rancho Seldom Siesta

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Rancho Seldom Siesta

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Similar threads

My Computer

My Computers

My Computer

My Computers

My Computer

My Computer

My Computer

My Computers

My Computer

My Computer

My Computers

My Computer

My Computer

My Computers

My Computers

My Computer

My Computers

My Computer

My Computers

My Computer