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

Ed Tittel · 2026-08-20T18:31:27-0400

On my previous check your zipped version produces an error, but your most recent standalone version works. Here's the output:
Most recent standalone:
EFI Files
---------
SkuSiPolicy.p7b is CURRENT.

Image Files
-----------
Skipping "": File not found.

USB Drive g: "RECOVERY"
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.

boot.wim:1 (WinRE 26100.1)
Boot Manager [Windows UEFI CA 2023] is ALLOWED.
winload.efi is ALLOWED
From the .ZIP file, I have to laugh: my output is exactly the same. I bet you switched something out on me!
Have to laugh. Keep up the good work. This is a real adventure. I've been blogging about this a lot lately. FYI, it's a lot easier to generate new bootable media to meet Secure Boot requirements than it is to fix old ones!
Cheers,
--Ed--

SaliesBuzz · 2026-08-20T18:58:27-0400

garlin said:
I created a Recovery Drive, and here's my observations:

1. boot.wim is hidden, but otherwise it's a WinRE image (which is expected).

2. There are several WIM files for recovery data, named \sources\Reconstruct.WIM, Reconstruct.WIM2, and Reconstruct.WIM3. Maybe more files if your restore image is larger.

3. Since the formatted drive is FAT32, each WIM is under 4 GB in size. What is unusual, is MS doesn't use a split WIM, but creates multiple standalone WIM files with the different file extensions.

4. Recovery Drive doesn't intend to restore Windows in the traditional method (copying individual files to the \Windows\ folder). Rather it wants to restore the \Windows\WinSxS component folders, and run some DISM repair mechanism to recreate file hard links from WinSxS. This presumes your WinSxS is healthy before you started running the tool.

5. winload.efi can be found in Reconstruct.WIM, but not bootmgfw.efi. The boot manager is there, hidden inside the WinSxS component folders, but it can't be easily scanned since there's multiple WIM's and if you applied multiple Monthly Updates on the system, older versions of bootmgfw.efi can be lurking inside the WinSxS folders. You would have to track down the highest version of bootmgfw.efi

While the script can check if this USB drive is bootable, it cannot verify if your restore image is out of date or not.

From a AI search re IFW Recovery Media:
the IFW-Create Recovery Boot Disk shortcut (part of the TeraByte suite) is used to create a TBWinRE (TeraByte Recovery Environment) build, which is based on a Windows WIM (Windows Imaging Format) file.

According to the documentation, this tool:

Creates a TBWinRE WIM (specifically boot.wim) that can be used as a bootable recovery disc or USB flash drive.
Can be configured to directly boot the WIM file from a standard build, allowing the system to restart into the recovery environment without external media.
Allows for the inclusion of custom drivers and scripts within the WIM build for automated imaging operations

garlin · 2026-08-20T18:59:00-0400

Ed Tittel said:
On my previous check your zipped version produces an error, but your most recent standalone version works. Here's the output:

Thanks. Keep an eye out for any new glitches.

Ed Tittel said:
Have to laugh. Keep up the good work. This is a real adventure. I've been blogging about this a lot lately. FYI, it's a lot easier to generate new bootable media to meet Secure Boot requirements than it is to fix old ones!

Honestly the prevailing direction appears to be: Tools that create bootable images should use a copy (or modified copy) of your current WinRE image. They should not depend on providing a static WinPE or WinRE image (looking at you Macrium...) which can get out of date.

The Secure Boot certs are the same no matter what Windows release you're running (W10 22H2, W11, or Server). Once you've installed them, that part is permanently finished (unless you're forced to reset the UEFI to factory defaults).

Other boot-time restrictions like the SVN and SkuSiPolicy don't involve any certs. Instead of tracking each successive change, it's easier to check if WinRE has been properly updated, and copy that image to the USB drive. For booting purposes, it doesn't matter if you use WinPE or WinRE. But if your Windows maintains an up-to-date WinRE, recovery tools should use that version.

You can take a WinPE and apply updates to it, but why bother when WinRE gets that treatment every month?

anchamp65 · 2026-08-20T20:56:20-0400

garlin said:
Honestly the prevailing direction appears to be: Tools that create bootable images should use a copy (or modified copy) of your current WinRE image. They should not depend on providing a static WinPE or WinRE image (looking at you Macrium...) which can get out of date.

The more you explain all this working, the more I agree with you and can't understand why companies that make recovery software and include mecanisms to build recovery drives or partitions, like Macrium, Hasleo and others, have not incorporated a proper process to build the WinRE / WinPE... !

It's not like the 2023 certificates came has a surprise in the last 6 months and caught them off guard !

Terabyte IFW, which actrually started even before Macrium, stands out and seems to have thought of all these things.
One more reason why I'm seriously considering it as my replacement once my Macrium X licences expire in 2028.

t2s50 · 2026-08-21T01:20:03-0400

garlin said:
I can't repro this bug. Here's the code snippet:

I just displayed the two variables, it seems to be a PowerShell version thing:

The output of Get-Volume -DriveLetter $DriveLetter seems to be identical, but for Powershell 5.1 $Volume.Count doesn't seem to give any output if it's not zero. For an empty driveletter it works, though:

garlin · 2026-08-21T01:28:56-0400

t2s50 said:
The output of Get-Volume -DriveLetter $DriveLetter seems to be identical, but for Powershell 5.1 $Volume.Count doesn't seem to give any output if it's not zero. For an empty driveletter it works, though:

OK. I changed the condition to "-ne $null"

t2s50 · 2026-08-21T01:59:04-0400

OK, thank you- I'll try your version later.

This worked for me:

Code:

       foreach ($File in $Paths) {
            if ($File -match '^[A-Z]:$') {
                $DriveLetter = $File -replace ':'

                $Counter = $(Get-Volume -DriveLetter $DriveLetter -ErrorAction SilentlyContinue | measure).Count
               
                if ($Counter) {
                    Check-DriveVolume -DriveLetter $DriveLetter
                }
                else {
                    "Skipping unmounted drive $File."
                    $Token = $true
                }

But I'm not a programmer, just fiddled a little with a solution from https://stackoverflow.com/questions/11526285/how-to-count-objects-in-powershell

EDIT

Yes, your version works, too!

garlin · 2026-08-21T11:02:13-0400

t2s50 said:
$Counter = $(Get-Volume -DriveLetter $DriveLetter -ErrorAction SilentlyContinue | measure).Count

The normal convention for functions like Get-Volume is to return:

- no result (null value or empty array)

- a single result (single object or array of one object)

- multiple results (array of several objects)

Get-Volume is quirky because if you use -DriveLetter with an undefined drive letter, it throws a hard exception. You can chose to trap exceptions using try/catch or specify a different -ErrorAction. PowerShell can get very inconsistent on how the different ErrorAction states are handled.

When we use Silently Continue, it ignores the error. PS 5 appears to throw an exception, which is then ignored, but never properly returns a result back to the user (skipping that step). The returned result isn't $null, but "nothing was ever returned". In that case, you can't get a direct object count.

For PS 7, they fixed the binding or decided Silently Continue should recover and return a null result. A count of $null always returns 0.

The strange thing is when I started writing the scripts, I only used PS 5 figuring PS 7 was (mostly) backwards compatible. Then users complained the scripts failed in 7, so I switched to spending all my time in 7. And now we have an error which I would caught had I been using 5.

garlin · 2026-08-21T11:24:03-0400

UPDATE: 2026-08-21

1. Reset To Setup Mode hidden behind "Default Key Provisioning" on Acer AMI Aptio desktop + SetupMode detection bug
2. WinRE images don't have a correctly updated UBR, and must depend on the WIM index details
3. Scripts are unable to find files marked as hidden
4. Don't report the boot manager's SVN when Get-SecureBootSVN returns value of 0.0
5. Add support for Windows Recovery drives created by RecoveryDrive.exe
6. Check_BootMedia.ps1 cannot find a drive volume (by letter) running on PowerShell 5.1

Minor bug fixes. Added support for reading Windows Recovery drives.

Phil_C · 2026-08-21T13:50:38-0400

Running Check_BootMedia now gets the error shown in the last line. Anything to worry about?

Powershell:

Macrium v10.0.8843
------------------
    WinRE Boot Manager [Windows UEFI CA 2023] is ALLOWED.
        c:\boot\macrium\WinREFiles\media\EFI\Microsoft\Boot\bootmgfw.efi
        File Version: 28000.352, SVN 9.0

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

USB Drive K:
    Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
        K:\EFI\Microsoft\Boot\bootmgfw.efi
        File Version: 28000.352, SVN 9.0

This command cannot be run due to the error: The system cannot find the file specified.

garlin · 2026-08-21T14:29:21-0400

Phil_C said:
USB Drive K:
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
K:\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 28000.352, SVN 9.0

This command cannot be run due to the error: The system cannot find the file specified.

he script's trying to call one of the helper tools (wimlib, 7z, or offlinereg). Run this command:

Code:

cd \users\philc\appdata\local\temp
del *.exe
del *.zip

Now re-run the script.

Phil_C · 2026-08-21T14:43:43-0400

garlin said:
he script's trying to call one of the helper tools (wimlib, 7z, or offlinereg). Run this command:

Code:

cd \users\philc\appdata\local\temp del *.exe del *.zip

Now re-run the script.

That didn't do it, but I deleted everything in the temp folder (except for some persistent stuff) and that did do it.
Thanks.

garlin · 2026-08-21T14:50:58-0400

I'll add more error handling to confirm the helper tools are present. The idea is the script only has to install them once (they don't need to be updated to newer versions), and the script will re-use the files. But if they're missing, then the script will re-install them.

Phil_C · 2026-08-21T15:05:44-0400

FYI, I ran Check_BootMedia again and it went back to the same error. Deleting everything in the temp folder does not help now. I also tried a restart, where a batch file empties the temp folder, and that didn't help either. Very odd.

garlin · 2026-08-21T15:08:56-0400

Phil_C said:
FYI, I ran Check_BootMedia again and it went back to the same error. Deleting everything in the temp folder does not help now. I also tried a restart, where a batch file empties the temp folder, and that didn't help either. Very odd.

Can you check if Defender or your AV is picking up one of the tools as blocked?

garlin · 2026-08-21T15:10:57-0400

Try this updated version, it has more visible error handling.

UPDATE: wimlib.net is offline (again)...

Banjoman301 · 2026-08-21T15:15:17-0400

Ed Tittel said:
it's a lot easier to generate new bootable media to meet Secure Boot requirements than it is to fix old ones!

Agree

Phil_C · 2026-08-21T15:19:52-0400

I don't see Avast AV blocking anything. Same error with new script.

Powershell:

EFI Files
---------
    SkuSiPolicy.p7b is CURRENT.
        \\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b
        Version: 3.0.0.17

        FileRule             MinimumFileVersion MaximumFileVersion
        --------             ------------------ ------------------
        ID_FILEATTRIB_F_0044 0.0.0.0            10.0.14393.9399
        ID_FILEATTRIB_F_0042 10.0.14400.0       10.0.17763.9099
        ID_FILEATTRIB_F_0040 10.0.18000.0       10.0.19041.7639
        ID_FILEATTRIB_F_0041 10.0.19100.0       10.0.20348.5479
        ID_FILEATTRIB_F_0046 10.0.20400.0       10.0.22621.7494
        ID_FILEATTRIB_F_0049 10.0.23000.0       10.0.26100.9140
        ID_FILEATTRIB_F_0045 10.0.26100.32000   10.0.26100.33249
        ID_FILEATTRIB_F_0048 10.0.26172.0       10.0.26172.33249
        ID_FILEATTRIB_F_0047 10.0.27000.0       10.0.28000.2684
        ID_FILEATTRIB_F_0043 10.0.29426.0       65535.65535.65535.65535



Macrium v10.0.8843
------------------
    WinRE Boot Manager [Windows UEFI CA 2023] is ALLOWED.
        c:\boot\macrium\WinREFiles\media\EFI\Microsoft\Boot\bootmgfw.efi
        File Version: 28000.352, SVN 9.0

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

USB Drive K:
    Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
        K:\EFI\Microsoft\Boot\bootmgfw.efi
        File Version: 28000.352, SVN 9.0

This command cannot be run due to the error: The system cannot find the file specified.

Sony Vaio sve · 2026-08-21T15:29:54-0400

Hello all. I have read all 176 pages on all these subjects and all of you been great on your ideas, fixes, and end results. I truly mean it!
To begin this "I'm truly sorry" to be putting this out there! I'm doing this because I'm at my last resort of what to do so please be and have patience with me. I'm so so cautious of messing with my UEFI/BIOS because I can't afford another computer. I mostly work with spreadsheets and a CAD program. I really need advise what to do and how to do it. Not for work. I just poured a 1/4 bottle of Kahlua into my coffee, so here it goes. I just don't know if I should do the update or just leave as is? I really want to update though. When upgrading to Windows 11, I had to bypass all requirements. Thank you.
I'm in the bios as Administrator and secure keys is custom. This is what I see when I see if I can manually input UEFI files.

SECURE BOOT DATABASE: Installed and Locked.
ENFORCED SECURE BOOT: Enabled.
USER CUSTOMIZED SECURITY: No.
ERASE ALL SECURE BOOT SETTINGS: Disabled. (I can erase.)

Here's my system info:

garlin · 2026-08-21T15:34:57-0400

Phil_C said:
I don't see Avast AV blocking anything. Same error with new script.

I think I fixed it. Subtle error in the Wayback Archive's backup file.

The file URL isn't the actual file link on the server, you're downloading a web response because they normally serve your browser a download dialog. Replaced with the direct download link.

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

Well-known member

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

Active member

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Well-known member

Attachments

My Computer My Computer

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 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 Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

Attachments

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Member

My Computer My Computer

At a glance

Well-known member

Attachments

My Computer My Computer

At a glance

Similar threads

My Computers

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computers

My Computer

My Computers

My Computer

My Computers

My Computer

My Computer

My Computer

My Computers

My Computer

My Computer