ESP is an abbreviation for the EFI System Partition, where a PC uses its contents to boot a PC far enough along to start loading Windows. For almost as long as I can remember, that partition has been created and sized during Windows installation at 100 MB. But this is changing. Here’s a “known issue” for  KB5089549, Microsoft’s May 2026 Patch Tuesday cumulative update for Windows 11. It can fail mid-installation on systems with a critically full EFI System Partition (10 MB or less free space). What do we, and OEMs, do as Windows outgrows 100 MB ESP? Get bigger!

Other Evidence That Windows Outgrows 100 MB ESP

I polled the 7 PCs (2 desktops, 5 laptops) here in my office at Chez Tittel to check their ESPs and observed something interesting. Here’s what I found:

Notice that the ESP sticks at the 100 MB mark until 2024, at which point it jumps to 260 MB. Then, on this year’s May-delivered Lenovo Yoga Slim 7X Gen 11 (X2 Snapdragon) it jumps again to 450 MB. There’s no doubt about it: the EFI is getting bigger!

What is the ESP, Anywho?

The EFI System Partition — ESP, in the shorthand everyone actually uses — is a small, dedicated FAT32 partition that lives on GPT-formatted disks and serves as the staging ground for everything the system needs before the operating system proper gets involved. Boot loaders live there. Firmware drivers live there. UEFI utility executables live there. If the system can’t find and read the ESP at power-on, it goes nowhere. It is, in other words, foundational infrastructure — and like most foundational infrastructure, nobody pays attention to it until something breaks.

Microsoft’s own documentation has recommended a minimum ESP size of 200 MB for UEFI/GPT systems since at least the Windows 8 era, with 260 MB or larger as the preferred target for new installations. That guidance has been sitting in plain sight on Microsoft Learn for years. OEMs, however, have a long tradition of shipping machines with a 100 MB ESP because, at the time those machines were built, Windows fit comfortably within it. The margins were thin, but they existed. That era is over.

Why 100 MB Isn’t Enough Anymore

Every Windows feature update — and, increasingly, every cumulative security update — must write updated boot files, recovery sequences, and language-specific font sets into the ESP. As the Windows boot stack has grown over successive releases, the items demanding ESP real estate have multiplied: Secure Boot validation assets, BitLocker metadata, UEFI capsule drivers, and a collection of per-locale font files for the pre-OS boot interface that can alone consume several dozen megabytes. If 100 MB was ever “enough,” Windows has long since moved those goalposts.

The specific tripwire for KB5089549 is tight, but telling. Microsoft confirmed that the failure triggers when the ESP has 10 MB or less of free space remaining. On a 100 MB partition that has been hosting Windows through several years of cumulative updates, that threshold is entirely realistic. The update proceeds normally through its initial phases — progress bars, the usual theater — and then dies during the restart phase, right around the 35–36% completion mark. The CBS.log entries are unambiguous: SpaceCheck: Insufficient free space and ServicingBootFiles failed. Error = 0x70. The accompanying companion error code, 0xc1900104, surfaces during feature-update upgrade attempts and carries the same root cause. The partition is simply full.

Increasing ESP Lebensraum

The community has converged on two main workarounds, and it is worth being clear-eyed about both of them.

The first is the “fonts delete” trick. You mount the ESP using mountvol Y: /S from an elevated command prompt, navigate to EFI\Microsoft\Boot\Fonts, and delete everything inside — typically recovering somewhere between 30 and 60 MB in a single sweep. It is fast, it is effective, and it is entirely unsupported by Microsoft. The risk is real: those font files support non-English boot environments. If your machine ever needs to display Cyrillic, Japanese, or Arabic characters in the pre-OS recovery interface, you will have a bad time. For an English-only deployment sitting quietly in a US office, the practical risk is low. In any multilingual environment, it should be treated as a last resort only.

Microsoft has also offered its own short-term registry tweak for KB5089549 specifically: running reg add “HKLM\SYSTEM\CurrentControlSet\Control\Bfsvc” /v EspPaddingPercent /t REG_DWORD /d 0 /f from an elevated prompt, followed by a reboot. This reduces the padding buffer the update engine reserves in the ESP, giving just enough headroom to slip the update through. It buys time. It does not fix the underlying problem.

The second, more durable option is partition resizing — shrinking the C: volume and extending the ESP to somewhere between 260 MB and 512 MB. Tools like MiniTool Partition Wizard (MTPW) can accomplish this from within Windows on many configurations. That said, a WinPE offline environment is the proper path since you are modifying a sometimes live boot partition. This is the correct fix. It is also disruptive, carries a non-trivial risk of data loss if anything goes wrong mid-operation, and absolutely requires a verified backup before you touch anything. Done properly, you will not need to revisit this for years. Done carelessly, you will spend an afternoon with recovery media and a sinking feeling. I experienced this myself recently on an ASUS Zenbook A14 laptop.

MS Is Mum on Remediation

Microsoft has not, as of this writing in mid-2026, provided an official, automated remediation path. There is no inbox tool that detects an undersized ESP and expands it gracefully. Ditto no Setup-phase blocker with a clear, actionable error. There is a Known Issue Rollback for KB5089549, which automatically propagates to consumer and unmanaged devices and prevents the broken update state — useful, but it leaves the machine unpatched. Enterprise admins can deploy the associated Group Policy to apply the KIR on managed fleets. None of this changes the underlying geometry of the partition. Something’s got to grow — and soon!

The other day I said it was coming. Yesterday, it arrived at my door about noonish. Today, I want to share my first impressions. TLDR version: I expected a lot from the Snapdragon X2, and I wasn’t disappointed. In today’s post, I’ll describe Lenovo Yoga Slim 7x Gen 11 unboxing & setup. In subsequent posts I’ll go into more detail. Here goes…

Digging Into Yoga Slim 7x Gen 11 Unboxing & Setup

Lenovo’s getting pretty good at the notion of low-footprint, low-carbon packaging and delivery. The box includes 2 eggshell carton style cradled for the laptop, a bamboo fiber sleeve for same, a cardboard holder for the one-piece 65W brick, which comes wrapped in a disposable paper sleeve. That last is black, and easy to miss: I didn’t even notice it until I checked it for the power rating info. Good job, packaging team!

I jostled the power switch (right edge of keyboard deck) as I picked up the unit, and it came right up with a full charge. I’m happy to report that “instant-on” remains as fast and reliable on X2 models as it was on their X1 predecessors. I logged right into the Lenovo review account and got going, and jumped into the setup process. That has its own story (complete with interesting bumps in the road). First, let me offer a table to compare Snapdragon X1 and X2 laptops:

Snapdragon X1 vs. X2: Good Gets Better

The key points to absorb from the following info are: more and faster cores, more cache, DX12 Ultimate, 80 TOPS NPU, PCIe 5.0. This laptop is noticeably faster than my 8 core Ryzen 7 5800X desktop with 64GB RAM, especially on CPU-intensive tasks. Impressive!

One Small Little Gotcha…

My only real disappointment with the review unit was that it shipped to me running Windows 11 Home. That’s because I rely on RDP (through Remote Desktop Connection, aka mstsc.exe). Thus, I had to upgrade to Windows 11 Pro to make that work. However, this is a minor beef, and one easily remedied at purchase time for an extra US$50.

Here’s the configuration Lenovo sent (aside from the already-mentioned OS): X2E Elite 88-100 CPU, 32GB RAM, 1TB PCIe Gen4 SSD, 1920×1200 OLED display. As configured, the Lenovo store currently lists the price at US$1,795.49. Comparatively speaking, I believe this is a good deal, given current prices for RAM and SSD.

Setting Up the Yoga Slim 7X Gen 11

Things got interesting right away. I made a misstep and associated my MSA with the Lenovo review account — not smart. As a result, I ran a factory reset to see what would happen. Indeed, it took about 22 minutes all told (pretty darn fast, AFAIK). That put me back into the base OOBE for Windows 11. Then, I burned an MVP key to upgrade from Home to Pro, which went amazingly fast — less than 2 minutes from hand-off to the Pro desktop. Overall, given intense non-gaming workloads, this unit screams!

Along the way, I learned that you can target ARM CPUs in WinGet using the --architecture ARM parameter and argument during installs. That helped me get the right versions of CrystalDiskMark, PowerShell 7, and a couple of other odds and ends up and running on the X2 laptop. In addition, I used a combination of PatchMyPC Home Updater and WinGet to get all the usual tools and applications up and running. On the whole, that process took about 2 hours and was pretty enjoyable.

I did hit a typical snag in getting RDP to work. Specifically, I was unable to get into the laptop (machine name: Yog7X2) using a Microsoft Account (MSA), despite various well-known fixes — namely, requiring Hello compliance for all logins, and making sure to sign in with the password at least once to get the MSA registered with the LSA. Consequently, I resorted to the equally well-known workaround of setting up a local account and using that instead.

First Impressions: Bedazzled and Enthused

I’ve actually purchased two Snapdragon X1 laptops for our household already (in 2025). For instance, I own an ASUS Zenbook A14. Meanwhile, my son has a ThinkPad T14s Gen 6 that we bought to replace a ThinkPad X390 after its display cracked. Obviously, I’m already enamored of the value proposition: decent performance, great battery life, and a slim, portable form factor. Indeed, both of us emphatically like those older models.

Surprisingly, the Slim 7X Gen 11 runs noticeably faster than most of the fleet here at Chez Tittel. To be clear, that fleet includes high-end Lenovo models like the ThinkPad P16 Gen3 Mobile Workstation and the ThinkStation P3 Ultra — so that’s a significant statement.

In addition, the unit is incredibly light at 1.17 kg (2.58 lbs). At the same time, even the low-end OLED display is brilliant and easy on the eyes. Astonishingly, reviews published so far (it’s early in the life cycle) put battery life in a range from 25 hours (mixed real-world usage) to 31 hours (local video playback), with Lenovo claiming “up to 29 hours” in its CES 2026 announcement. Naturally, I’ll see how that pans out in my own testing and usage.

All in all, this is a machine I wanted to see and use. Now that I’ve gotten started, I’m favorably disposed. Furthermore, I’m expecting my ardor and appreciation to grow as I get more time with this snazzy little laptop. Stay tuned: I plan to post three more items about this device in the next two weeks.

One More Things (Added 1 Day Later)

The Yoga Slim 7X Gen 11 also offers another feature I definitely appreciate. I concur with Michael Crider’s recent PC World story that OEMs should provide USB-C ports on both sides of their laptops for ease of access to chargers and docks in cramped conditions and on on office desktops. And guess what? Lenovo provides 3 (!) USB-C ports on this model: 2 on the left side, and one on the right. Good stuff!

Here’s a fun way to start a Monday: you fire up a PowerShell script you’ve run many times — maybe it provisions a batch of AD accounts, maybe it sweeps stale GPOs — and it simply vanishes. No error dialog. No event log entry. Quarantine warnings not provided, either. The file is just gone, like it offended someone. Which, as it turns out, it did.

The culprit? Recent changes to Microsoft Defender’s Attack Surface Reduction (ASR) rules — specifically, tightened enforcement arrived with Windows 11 23H2. And it has only grown more aggressive in 24H2/25H2. If you manage Windows endpoints for a living, this one deserves some notice.

How and Why Windows Defender May Delete PowerShell Scripts

Microsoft has been steadily ratcheting up ASR rules over the past couple of years. Two rules in particular have become dramatically more assertive: “Block execution of potentially obfuscated scripts” and the newer “Block execution from known script interpreter paths” (rule GUID 9e6c4e5a-1037-4377-92f4-2db0f7e629e7). The latter now matches elevated execution paths that have nothing to do with user shell startup, which means your perfectly legitimate admin scripts can get caught in this net.

Here’s the insidious part. Starting with the 23H2 and 24H2 Defender sensor updates, script-blocking ASR rules are now enforced at the kernel driver layer (via WdFilter.sys, Defender’s minifilter drive) — before process creation even occurs. That means scripts launched via WMI, COM+, or scheduled tasks can be silently killed or quarantined without generating an event log entry. You get no breadcrumbs. The script just doesn’t run, and the script file itself may disappear.

This has caused a wave of false positives hitting legitimate PowerShell scripts, SCOM monitoring agents, Active Directory management tools, and enterprise deployment scripts. If you experienced déjà vu reading that, you’re not wrong. In January 2023, a faulty Defender signature update (builds 1.381.2134.0 through 1.381.2163.0) caused the “Block Win32 API calls from Office macro” ASR rule to go haywire and mass-delete Start menu and taskbar shortcuts across enterprises. Microsoft had to ship a dedicated recovery script (AddShortcuts.ps1) and a taskbar repair utility to clean up the mess. Consider this the sequel — quieter but just as disruptive.

How to Recover Deleted or Quarantined Files

If Defender has eaten your scripts, don’t panic. Work through these steps in order:

1. Check Defender’s quarantine via the GUI. Open Windows Security → Virus & threat protection → Protection history. Filter by “Quarantined Items.” If your script is there, select it and choose Restore.
2. Browse the quarantine folder directly. Quarantined files live in C:\ProgramData\Microsoft\Windows Defender\Quarantine. They’re encrypted, but they show that Defender took them.
3. Use PowerShell for deeper inspection. Run Get-MpThreatDetection and Get-MpThreat to list recent detections and see exactly which ASR rule fired. To restore from the command line, use MpCmdRun.exe -Restore -ListAll followed by MpCmdRun.exe -Restore -Name <ThreatName>.
4. Add targeted exclusions. Use Add-MpPreference -ExclusionPath “C:\Scripts” or configure per-rule exclusions via Intune or Group Policy to prevent recurrence.
5. Restore from backup. If the file is gone from quarantine entirely, fall back to File History, system restore points, or your backup solution of choice.
6. For enterprise environments: check the Microsoft 365 Defender portal’s quarantine and Action Center — detections from managed endpoints often surface there even when local logs stay silent.

That leads to what I’ll call a “Pro tip” for admins to consider. Before enabling any new or aggressive ASR rule, set it to Audit mode first (value 2) rather than Block mode (value 1). Audit mode logs what would be blocked without actually deleting anything. Run it for a week or two, review the results in Event Viewer under Microsoft → Windows → Windows Defender → Operational (Event IDs 1121 and 1122), and then flip to Block. This single practice would have prevented most of the heartburn described above.

You Win Some, You Lose Some…

Let me be clear: Defender’s tighter ASR rules are genuinely good for security. Blocking script execution at the kernel level before a process even spawns is a meaningful defense against fileless malware and living-off-the-land attacks. But Microsoft badly needs to improve logging transparency when scripts get blocked at the kernel driver layer. Silent enforcement with no audit trail isn’t “defense in depth” — it’s “debugging in the dark.”

Until that gets fixed, the playbook is straightforward: keep good backups, audit before you block,  and test ASR changes in a staging ring before pushing to production. Remember: your antimalware solution is only as smart as its latest signature update. As the January 2023 shortcut debacle proved, even Microsoft’s own rules can bite the hand that feeds them. I think these just bit me. Don’t let it happen to you!

But Wait! There’s More…

In my usual ElevenForum readover this weekend, I stumbled on a thread that mentioned scripts — and an encrypted password file — disappearing from the poster’s Windows 11 PC. As I responded to that thread “This is deeply disturbing.” It just doesn’t seem right that Defender can cause scripts (and more) to vanish via rule enforcement. You need to steer around this pothole until it gets filled. Not an unfamiliar strategy, alas, here in Windows-World.

When it comes to my Microsoft Accounts (MSAs), I must laugh at what historian Hayden White unsmilingly called “the burden of history.” That is, it seems I’ve acquired quite a number of MSAs over the years. Thus, I had to shoulder that burden recently when I decided to clean things up a bit. Last week witnessed my own “great MSA massacre of 2026.” Indeed, I rid myself of 4 old MSAs and cleaned up what remained. It wasn’t exactly bloody, as such things go, but it was indeed a burdensome task.

What Spurred the Great MSA  Massacre of 2026?

As the lead-in graphic should suggest, the impetus came from devices associated with my many and varied MSAs. Indeed, I discovered numeous evaluation units from Lenovo, Dynabook, HP, MSI, and others. Some went as far back as the early 2020s.

One source of issues is that I didn’t practice good “eval return hygiene” on many loaner units. I would log in to them using an MSA, but didn’t unenroll them from device lists before sending them back. This, it seems, could cause them to persist for up to 6 months after return and presumable oblivion. At least, as far as logins from my MSA were concerned.

I spent about two weeks of concerted effort, visiting the managed devices page for my still-active MSAs. Each day, I would remove all stale entries (I call them “zombies”) only to see them pop up again. But over time, and with grim repetition, I finally consigned those stubborn devices to rest in eternal peace (hopefully).

What’s Left to Do?

I’ve got one MSA that’s a bit of a zombie itself. Its home email server was shut down last year, as its owner went out of business. I want to keep that account alive because it carries 20 years of — please don’t laugh out loud — Microsoft Solitaire history that I don’t want to lose. It’s tied to my cell number, so I can still prove my identity as long as that sticks with me, so I should be good.

I’m now shuffling all of its devices over to my primary MSA, so I can keep the ones I actually use all in one place. Going forward, I have a plan as I return eval units to Lenovo (or whomever else might send me a review unit). I’ll make sure to unenroll them from my registered device and MS Store device lists to keep things current and correct. Copilot opines further it’s a good idea to factory reset those units, too, to wipe all MSA traces. I’ll do that, too.

As IRL, in Windows-World actions have consequences. I’m doing my best to remember that using my MSA to login and play with eval units means I have to manage them more actively as they come and go. Fingers crossed I’ll do that properly from now on…

In reviewing Reliability Monitor for my peppy and capable ThinkStation P3 Ultra Gen 2, I saw recent repeated APPCRASH errors. If you could drill down into the lead-in graphic — as I did — you’d see 3  between March 11 and 14. So I asked Copilot to tell me more about this error. I learned that this utility is recommended, not required. I also learned that what’s blowing up reflects some kind of telemetry error when the app tried to phone home. So I uninstalled it. This Alexandrine solution fixes ThinkStation Diagnostics (think: Gordian knot) and smooths out my reliability ratings.

How the Alexandrine Solution Fixes ThinkStation Diagnostics

In this context I’m reminded of the well-known DCOM Event 10016 error, which pops up dozens to hundreds of times a day in Windows 10 and 11. It’s not really an error, it’s the result of a design choice that tries a series of component object model (COM) and distributed COM (DCOM) components as it performs routine tasks such as running shell components, search indexing, UWP apps and background services. It appears as an error, even though the actual work to which such errors are tied actually succeeds. Noise, in other words.

In the same vein, the ThinkStation Diagnostics (TD) software is:

1. Recommended, not required
2. The “critical error” relates to the software’s operation, not the system it monitors
3. Copilot reports that Lenovo documents numerous cases where TD fails this way owing to external device voltage issues, unsupported cables or dongles, power state transitions (sleep/resume)

Indeed the error is something on the back end, not in the system itself, and doesn’t really signal an actual problem. Ironically, it’s the system for reporting problems that’s itself causing problems.

Noise, Not Signal Makes Alexander Right

Nobody could untie the Gordian knot, so they couldn’t get in the door, either. Alexander cut it off, and got the door open right afterward. I’m taking the same approach with this tool. It’s not because I don’t want it to tell me useful stuff; it’s because I don’t want it to crash for uninformative reasons.

Here in Windows-World, there’s always a certain amount of noise to go along with valid signals. When I feel like the noise is swamping the signals, I’m glad to remove a source of such noise. There are plenty of ways for me to find out what’s going on, using other means. Basta!

In poking around the fleet here at Chez Tittel lately, I can’t help but notice that my Windows PCs seem to pick up detritus at a good clip. Nearly every time I run a tool such as Disk Cleanup (cleanmgr.exe), PC Manager, or even the ancient but still servicable UnCleaner utility, I put at least 800MB-1GB  of storage back into the free pool. One of my mottos has been (and remains): “Keep your Windows clean.” And there’s more to suggest driven by that impetus…

What Keep Your Windows Clean REALLY Means

As you can see in the lead-in graphic, even after running PC Manager’s “deep clean” facility, Uncleaner still finds another GB of trash to take out. Indeed, multiple tools often focus on multiple sources of unwanted or unnecessary stuff. Using them in combination will usually take out more trash than a single item can ferry into oblivion on its own.

But wait: there’s more! Other things in Windows besides file storage need an occasional cleanup. Here are some examples:

• Use a tool such as RAPR (DriverStore Cleaner) to remove obsolete or duplicate device drivers from the Windows driver store
• Use DISM to do likewise for the Windows Component Store (e.g. DISM /Online /Cleanup-image /StartComponentCleanup)
• Various identity and authentication cleanups, including credential manager, Windows Hello/NGC, AAD/Workplace Join, cached identity tokens, and more

I’ll blog about this final item tomorrow, because I’ve been spending a lot of time on that kind of stuff lately, and have some useful PowerShell to share along those lines. Stay tuned.

And remember: a clean Windows install is a happy and healthy Windows install. Cheers!

A routine UEFI firmware update brought unexpected trouble to the Flo6 system yesterday. What should have been a simple BIOS flash turned into a boot failure. The cause? A major change in Secure Boot keys. This event highlights how firmware updates can affect system trust and stability. As I was figuring out how UEFI flash overturned Flo6, I had to work my way through another CMOS reset, GPU disconnect, and more. Buckle up: here come the deets!

How UEFI Flash Overturned Flo6, and Killed Normal Boot-up

The BIOS update for Flo6 included more than microcode or AGESA changes. It replaced the Secure Boot Platform Key (PK), Key Exchange Key (KEK), and the Allowed Signatures Database (DB). These new keys came from Microsoft’s 2023 certificate chain. They replaced the older 2011 certificates that had been in use since Windows 8. This was a full trust-chain rollover, not a routine patch.

Why Did Boot Balk Afterward?

After the update, Flo6 failed to boot. The reason was a mismatch between the new firmware keys and the bootloader signatures. Windows had already staged boot components signed with the 2023 certificates. But the firmware update reset the trust chain. The system no longer recognized the bootloader as valid. Secure Boot rejected it, and the system dropped into firmware setup.

Recovery and Realignment

Once the firmware finished installing those new keys, Windows rebuilt its boot entries. It aligned its bootloader with the new DB. The system re-entered User Mode and Secure Boot resumed normal operation. Flo6 booted successfully again. The trust chain was restored, and the system stabilized.

Along that seemingly simple path, however, I had to reboot Flo6 at least a dozen times. Maybe more than that: I kinda lost count. At one point I had to pop the CR2032 CMOS battery. At another, I unpowered the GPU so the system would be forced to reset GOP stuff during a next restart, destined and designed to fail. Along the way I worked through nearly ever aspect of the ASRock board’s Secure Boot capabilities, setting things back to rights.

Lesson Learned

Firmware updates that modify Secure Boot keys are not routine. They change the foundation of system trust. If the OS and firmware are not aligned, boot issues can result. Understanding how PK, KEK, and DB work helps prevent surprises. Always check BIOS release notes for Secure Boot changes before flashing.

The Flo6 incident shows how a UEFI flash can affect more than performance or features. It can change the system’s trust model. With Secure Boot evolving, it’s more important than ever to understand what firmware updates really do.

Secure Boot has definitely  made life more interesting here in Windows-World. I’ve just ordered an MSI MAG Tomahawk B550 board to replace the ASRock model. Hopefully, it will show itself more robust in the face of Secure Boot changes. We’ll see…

Here at Chez Tittel, I’ve been on something of a Secure Boot tear lately. Late last week, it dawned on me that this might require a change in recovery media, too. I checked: it does. Indeed, MS spells out the notion that secure boot recovery means new media in a couple of MS Learn Documents:

• Secure boot
• Signing with the new 2023 Microsoft UEFI certificates: what submitters need to know (MS Tech Community, MSA req’d)

Basically, this boils down to the following data points, all of which determine whether or not recovery media will work properly after enabling Secure Boot:

• Recovery media must use MS-signed UEFI bootloaders
• Bootloaders signed with a certificate trusted in db
• Bootloaders signed with the old 2011 CA blocked in dbx
• Updated WinRE images (incl. new recovery media) signed with the 2023 CA

What Secure Boot Recovery Means New Media Comes Down to…

Simply put: once a PC has secure boot enabled and reports the presence of CA 2023, it needs matching secure boot media for recovery and repair. Older media won’t work because it lacks the new CA 2023 certificate. Bootloaders will fail, and/or WinRE won’t run. This will provoke a “Secure Boot violation” error or “invalid certificate” message in the bootloader. Sounds bad, eh?

The fix is easy, as long as you’ve turned Secure Boot on, and have installed the CA 2023 certificate (Garlin’s scripts at ElevenForum do this job nicely). With all these pieces in place, your current runtime meets the afore-stated requirements. Then, you can use Windows built in “Create a recovery drive” feature to build new recovery media to match this new state. Done!

Here in Windows-World when things change the supporting infrastructure must change to follow suit. Today that means generating fresh, new recovery media to match Flo6’s “secure boot on, CA 2023 installed” state. Takes only a few minutes, but means that future recovery efforts are far more likely to succeed. Good-oh!

On February 4th, I recounted the Secure Boot status of my local fleet, along with machines possessing CA 2023 secure boot certificates. At that time, I had 3 of 11 PCs with no CA 2023 secure boot certs. One also couldn’t enter UEFI with Secure Boot enabled. My secure boot report card is now perfected. All 11 machines have secure boot enabled AND CA 2023 certs in their credentials stores.

How Did I Get Secure Boot Report Card Perfected?

Short answer: time, effort and (in one case) a hardware purchase. Now for a somewhat longer answer. Both holdout machines with SB enabled, but no CA 2023 present were two ThinkPads. First, the X380 Yoga, a 2018 vintage 7th-gen Intel-based laptop. Second was X12Hybrid, a 2020 vintage 10th-gen Intel based tablet.

The same fix worked for both machines. The inestimable long-time member at ElevenForum.com named @Garlin has a terrific thread. It’s entitled garlin’s PowerShell scripts for updating Secure Boot CA 2023. It includes a script named Check_UEFI-CA2023.ps1. If you run that script it not only tells you if the CA 2023 cert is present or absent. If CA 2023 is absent, it also provides two commands to put it in place. That worked for both of my ThinkPad holdouts.

Note: The lead-in graphic for this story shows the following:
1. Invocation and output from the Check script just mentioned.
2. Execution of the reg edit and scheduled task to add CA 2023.
3. Final check string to show CA 2023 is present in the SecureBoot UEFI db (database).

The Third Holdout Proves a Bit Trickier

The old NVIDIA GeForce RTX 1070Ti installed in the upstairs ASRock B550/AMD Ryzen 5 5800X desktop named “RyzenOfc” wouldn’t enter UEFI with Secure Boot enabled. Turns out the firmware on its older GPU just couldn’t coordinate with TPM changes. I bought a Gigabyte RTX 5060 because it was compact enough to fit the smallish RyzenOfc Antec A-201 case. That got me back into UEFI where I could install the default keys and get secure boot working properly.

After that, the same Garlin script cited above also got CA 2023 into the credentials store on RyzenOfc. It’s taken a good chunk of the last two weeks, and cost me a chunk of change — I also bought a new mouse and keyboard that skips USB enumeration issues and Fn key gotchas in getting to UEFI, plus the GPU — to finish this journey.

Just for grins I checked CA 2023 status on the ThinkPad P16 Gen 3 that showed up on Monday. It didn’t have the new certs, either, so I fixed it with commands from the Garlin check script, too. All good!

But at last, all my machines are Secure Boot enabled with the CA 2023 certificate installed in that environment. What a long, strange trip that turned into. I’m glad it’s over, and I learned a LOT along the way. I also heartily recommend the Garlin scripts to anybody facing uncertainty or issues in getting CA 2023 Secure Boot certs onto their PCs. Great stuff!

Back in late 2021/early 2022, I bought a pair of motherboards for side-by-side PC builds. One for me, one for my son to use at home. I also bought an NVIDIA 3070Ti GPU so he could game away. But that latter plan didn’t turn out because his PC case — an Antec A201 — was too small inside for that GPU. We stuck with our older 1070Ti models because they fit. Just recently, I’ve been working to get Secure Boot running on those PCs. I wasn’t able to get it up on Flo6 (my office desktop, now in a bigger case) until I swapped the 1070 GPU for that 3070 model. I still haven’t been able to get back to UEFI on the upstairs model (his former desktop). That’s why I’m buying newer GPU for RyzenOfc (desktop machine name). Let me explain…

Why Buying Newer GPU For RyzenOfc Could Help

The older 1070Ti has Pascal generation firmware, while the newer 4070 has Ada generation firmware. The 1070 firmware is 11 years old, or thereabouts, and lacks features and capabilities that newer firmware environments — including UEFI, TPM and Secure Boot — need. Copilot put a feature table that lays things out nicely for easy perusal and comparison.

Basically, I was unable to get past the graphics output protocol (GOP) phase during boot-up with the 1070 installed. The PC froze there every time. I could still get to Windows (straight to the lock screen, in fact) but I never could see the Asrock initial boot-up logo, nor could I use Del or F2 to get into UEFI.

Can’t Do Secure Boot Except via UEFI

That last little bit is a dealbreaker. If I can’t get into UEFI, I can’t turn secure boot on. Nor can I load the default Secure Boot keys, essential to resetting TPM to let the whole Secure Boot infrastructure get put in place. Bit of a problem, that…

So I ordered a used compact NVIDIA 4070 GPU to replace the 1070Ti. It’s due in next week. And I’m betting a reasonably substantial sum that when I pop the new GPU into the PCIe x16 slot the 1070 currently occupies, I’ll be able to get through Secure Boot installation.

We’ll see: I’ll report back then. Stay tuned, and check your own PCs for status. On older builds you, too, may need to start making some changes. In PowerShell, Confirm-SecureBootUEFI  shows “True” if it’s on, “False” if it’s off. Likewise, Get-SecureBootUEFI -Name db will show you if you have the new UEFI CA 2023 certificate installed or not (the old 2011 certificates expire later this year, so it’s time to get ready).

Here in Windows-World the old saw from Roseanne Roseanna-danna often applies: “It’s always something!” And indeed, this time it could be something somewhat costly, as well. Sigh