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.

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

Similar threads

My Computers

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computers

My Computer