Backup/Restore, Device drivers, Insider stuff, Recent Activity, WED Blog, Windows 11

Two Checkboxes Means 12X Faster

Leave a comment

I plugged a Samsung 990 Pro 1TB NVMe into the Thunderbolt 5 port on my Lenovo ThinkPad P16 Gen 3 mobile workstation. ICYDK, TB5 promises up to 80 Gbps bandwidth. The 990 Pro is one of the fastest consumer NVMe drives money can buy. I expected fireworks. I got a firefly. Fortunately, I determined that clicking two checkboxes means 12 faster results. This comes from foregoing quick disconnect and enabling write caching. Let me explain…

Exploring: Two Checkboxes Means 12X Faster

As shown in the lead-in graphic, CrystalDiskMakr tells the ugly truth. As you can see on the left hand side, read speeds looked good. But writes are stuck in what I’d charitably call “USB 2.0 territory.” Something was very, very wrong — and it wasn’t the hardware. Results come from CrystalDiskMark 9.0.2 x64 software.

Now, look to the right, you can see that write speeds jumped significantly, while read speeds stay more or less the same. Indeed, the Thunderbolt 5 (TB5) link and Acasis TB501Pro enclosure weren’t the whole bottleneck. Sequential writes jumped from 473 to 5,943 MB/sec for a 12.6X speed boost.. Even more amazing: 4K Q1T1 writes leapt from 1.04 to 110 MB/sec, for a 105X gain.

All this came from two little checkboxes, on the Policies tab from the Properties window for the Acasis TB501Pro enclosure. Deets follow…

Two Related Settings in DevMgr Do the Trick

Here’s the 30-second procedure:

  1. Open Device Manager → expand Disk drives → right-click your external NVMe → select Properties → click the Policies tab.
  2. Switch from “Quick removal” (the default) to “Better performance.” This unlocks the write caching option that’s otherwise grayed out.
  3. Check the box for “Enable write caching on the device.” This is the setting that actually turns on write caching.
  4. Click OK, then rerun your benchmarks and enjoy the results.

Both settings are required. Selecting “Better performance” alone without the write caching checkbox won’t deliver these numbers. You need both.

Here’s the Tradeoff

Windows defaults to Quick Removal for a good reason: it protects against data loss if you yank a drive without ejecting it first. With Better Performance and write caching enabled, you must use “Safely Remove Hardware” before unplugging, or you risk losing data still sitting in the write cache.

That’s the tradeoff. For a stationary workstation drive that stays plugged in during work sessions, it’s a no-brainer. For a drive you hot-swap constantly throughout the day, think twice. I’m going for maximum speed on backups and restores, so I’ll make myself remember this tradeoff if I need to unlplug the NVMe enclosure.

The Results Could Still Be Better

I’m still of the opinion that — as I opined in my Feb 20 blog on this topic — that buying a TB5 NVMe enclosure isn’t worth the added expense. TB4 enclosures cost about US$100 less, and deliver nearly the same performance as TB5 (it’s a 10-15% difference at best). Doubling the price for a modest gain just doesn’t make sense. TB5 shines for video and networking. For storage links, not so much, because controllers basically limit links to PCIe x3/x4 levels.

That’ still true today. But I was pleased to get much more out of my rig once I made the enclosure behave more like a USB drive and less like a USB stick! Here in Windows-World you sometimes have to take your wins where you can find them…

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

How-To: Light Up Winget Icons

Leave a comment

Thanks to numerous requests, I’m providing step-by-step instrux in this unusual second blog post for today. It’s based on something that made me unreasonably happy earlier this week. That is:  WinGet can now display colorful package icons right inside Windows Terminal, rendered via sixel graphics. It’s a small visual upgrade that makes winget list –details output dramatically more readable. You get actual application icons inline with package data instead of a wall of monochrome text. But getting there requires a few specific steps. Here’s the complete recipe so you, too, can light up WinGet icons.

Why Must You Light Up WinGet Icons?

The current production version of WinGet is v1.28.220 as I write this post. The latest Preview version is v1.29.70-preview. Production is still catching up, so preview is a must for the moment. I imagine, though, that this will change with the next production version update. As with all moving targets, this one keeps changing along with everything else!

Step 1 — Get a Preview Version of Winget

Sixel icon support requires WinGet version 1.29.50-preview or later. The current stable release doesn’t include it. Check your version with winget -v. If you’re behind, try this first:

winget upgrade Microsoft.AppInstaller –source winget

If that doesn’t pick up the preview build, head to the microsoft/winget-cli releases page on GitHub, download the latest .msixbundle. If a double-click won’t install it, you can install it manually with Add-AppxPackage. Fair warning: on some machines the Microsoft Store installer handles dependencies automatically. On others, you’ll need to sideload VCLibs and Microsoft.UI.Xaml packages yourself.

Step 2 — Enable Sixels in Winget’s Settings (Not Terminal’s!)

This is the gotcha, and it got me for a short while. I confess: I mixed it up myself. The sixel toggle goes in WinGet‘s own settings file, NOT in Windows Terminal’s settings.json. Run winget settings to open the file. Add or merge a visual block so it looks like this:

{
“$schema”: “https://aka.ms/winget-settings.schema.json”,
“visual”: {
“enableSixels”: true,
“progressBar”: “rainbow”
}
}

The enableSixels: true setting tells WinGet to emit sixel graphics in its output. The progressBar key is optional —”rainbow“, “accent”, and “retro” work well (“sixel” works, but is hard to see). Any of these gives you graphical progress bars during installs, as a nice bonus.

Step 3 — Restart Terminal and Run It

Kill Terminal completely — not just close a tab. Right-click the taskbar icon and close the window, or kill the wt process outright. Relaunch. Then run:

winget list –details

Icons should appear for Win32 packages (exe/msi installers). MSIX packages won’t show icons — that’s a known limitation of the current pipeline, not a configuration error on your part. You can filter to a single package to test things quickly (I chose 7Zip, as it’s at the top of my ASCII sort order):

winget list –details 7zip

What to Expect

Not every package gets an icon. In my testing across two ThinkPads, icon coverage ranged from 26% to 31% of total installed packages. The dividing line is 100% correlated with installer category: Win32 packages (exe/msi) get icons, MSIX packages don’t. That’s an architectural gap Microsoft hasn’t bridged yet.

But what works, works beautifully. The icons are crisp, properly sized, and render instantly. It turns a dull text dump into something you can actually scan visually — which matters when you’re staring at 150+ installed packages trying to figure out what needs updating. Once you’ve got it set up, you won’t want to go back to the plain-text version. Cheers!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

X12 Tablet Gets Clean Install

Leave a comment

Something cratered the Lenovo ThinkPad X12 Detachable Tablet this weekend. I’d been screwing around with Secure Boot, recent updates, and more. When I sat at my desk Sunday morning, it was refusing to boot, and throwing error code 0xc0000428, which signals a winload.efi signature mismatch with what’s in firmware (see lead-in graphic). I did get the machine booted to recovery media on a UFD. I could’ve repaired and recovered the previous installation. But I decided that X12 Tablet gets clean install instead, so I could check a bunch of things out about a fresh, clean Windows 11 install. Here goes…

After X12 Tablet Gets Clean Install, Some Initial Checks

Having wrestled so much with Secure Boot lately, my first check was on that security layer. Indeed, Garlin’s check script revealed it was present, and more-or-less up-to-date. With minimal effort I was able to bring the X12 into full compliance with modern Secure Boot settings.

Next, I checked Smart App Control in Windows Security. It is currently set to Evaluation mode. I’m supposed to be able to switch between the On and Off states now. I need to finish configuring this PC and get an image backup tool in place, before I start fooling around with things. But the signs are promising. Right now SAC is working, and behaving just the way it’s supposed to work.

More About OOBE

After the post-GUI installation in Windows 11, the Out-of-Box Experience (OOBE) appears to guide users through final steps of the process. This time, I did get to choose the machine name I wanted (kept it at X12Hybrid) where it works properly. The network setup found my WAP right away, and I was off and running right away, too. It was also amusing to see how many, many backups I could’ve used when installing this PC (including an older X12 version dating back to 2022). But since I wanted a clean install experience, I skipped all that stuff.

Now Comes the Rest of the Job…

I’ve got to set up and customize the X12 to my usual liking. That’s probably going to mean an hour or two a day for the next few days. This afternoon I think I’m going to try using WinGet to export most of my app set from Flo6 to X12, and see how that works.

Stay tuned! It’s possible that things in my little corner of Windows-World are about to get interesting. If so, you’ll get more follow-up from  your humble correspondent. So far, so good, though.

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, WED Blog, Windows 11, Windows Update

OOB KB5086672 Pops Up

Leave a comment

I just got back from my morning constitutional. Windows prompted me for a PIN upon login. Then, the “Welcome” screen took 30-plus seconds to spin before I got to the desktop. “Hmmm,” I said to myself, “whaddya bet an update’s been applied to Flo6?” And indeed, upon inspection of the Update History, out-of-band (OOB) KB5086673 pops up at the head of the Quality Updates list.

Why Say: OOB KB5086672 Pops Up?

Flo6 is set up for maximum stability. Thus, it doesn’t sleep. So, for it to prompt me for system entry, I was pretty sure the PC had rebooted. So I asked Copilot to write me a PowerShell check. And sure enough, the results of running said script (see lead-in graphic) show two quick reboots back-to-back just after 1:30 this morning.

The boot type for both shows up as “0x0” which indicates a cold boot that otherwise proceeded and concluded normally. And indeed certain updates — including this one, as shown — do require a pair of reboots to successfully complete their efforts. Copilot says “That 95-second gap is textbook CU finalization timing” and “the reboot…was Windows completing the update you saw in Update History.” Good stuff!

How the Pop-Up Happened

I’ve got the toggle for “Get the latest updates as soon as they’re available” turned on. I’ve also got active hours set from 7AM to 6PM. So when the update triggered last night nothing stopped it from getting downloaded, applied, and rebooting on its own schedule. That’s how the pop-up happened, and why I saw a login prompt when I sat down in front of Flo6 this morning.

Here in Windows-World, things work the way they’re supposed to quite often behind the scenes and (mostly) unnoticed. The login prompt drew my notice, and I’m happy to say “nothing more to see here.” Let’s get back to work, shall we?

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Dude, Where’s My Icons?

Leave a comment

I just spent a couple of frustrating but informative hours trying to get icons to show up with WinGet on the latest Canary build (29558.1000). What started out as a minor visual quirk turned into a deep dive into the innards for App Installer, feature flags, and system-level packages. I’ll provide a step-by-step list of what I did, what I learned, and what others running Canary builds should know. At this point I’m still asking “Dude, where’s my icons?” for WinGet output. But I now know I won’t see them any time soon. I’ll explain…

Steps in Resolving “Dude, Where’s My Icons?”

The first step was to verify the WinGet version and its capabilities. Running winget –info revealed I was on version 1.29.50-preview. Notably, that output lacked usual capability lines including VT Support or Rich Output. That was my first clue that something wasn’t quite right.

Next, I visited the Microsoft Store. I navigated directly to the App Installer product page using the canonical link. The Store offered an Install button. When I clicked same, I expected it to overwrite the preview build with the stable version. After installation, the Store indeed reported the app as Installed. It lied!

I then closed all terminal sessions and opened a fresh CMD tab to recheck winget –info. Unfortunately, the version remained 1.29.50-preview. Worse still, the missing icon issue persisted. To investigate further, I ran PowerShell as Administrator and executed Get-AppxPackage Microsoft.DesktopAppInstaller -AllUsers. The output showed only one package: version 1.29.50.0, marked as NonRemovable. Was I stuck?

Yes, I Was Stuck…

The crux of the matter rests on how Canary builds handle App Installer. On these builds, the preview version of App Installer is baked into the OS image. Indeed, it’s registered as a system-level package. Because it is marked NonRemovable, neither the Microsoft Store nor PowerShell can uninstall or override it. That explains why even though the Store shows the stable App Installer as Installed, Windows continues to use the preview version.

Yep, sez right at bottom: NonRemovable: True

This locked-in preview build lacks support for feature flags like Visual Icons and Rich Output. Alas, their lack also explains the missing icon column in WinGet output. No attempts at reinstalling, resetting, or tweaking settings.json can override this limitation. Stuck indeed.

Note: the lead-in graphic for this story comes from the Build 29558.1000 announcement blog. I can see that damnable delectable icon there in the posting, but I’ll be darned if I can make it show up on my Canary install. Go figure!

 

 

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, Recent Activity, WED Blog

Magician Internal Updater Lags Behind

Leave a comment

I have to chuckle. In making my morning rounds, I see at TechPowerUp.com that there’s a new version of Samsung Magician out — namely, 9.0.1. So I jump into Magician and check its internal updater, which tells me I’ve got the latest version: 9.0.0. Alas, as Copilot tells me, it’s not unusual for the utility to do this. Indeed, as a matter of observed practice, the Magician internal updater lags behind Samsung’s software release schedule. It’s all laid out in the lead-in graphic. Let’s explore…

Why Magician Internal Updater Lags Behind

Apparently, Samsung waits until a new release has been out for some while before updating its xml-based manifest to make it known to the Magician updater through its update servers. According to Copilot, Samsung has been ill-served during previous release cycles by “buggy Magician releases,” “firmware-pushing issues,” “NVMe driver conflicts,” and so forth.

Thus, the company releases the new software first through public channels such as TechPowerUp, MajorGeeks, SoftPedia and other file-sharing sites. It then watches user responses from early adopters for up to a few days, and sees what the uptake and reactions are like. It’s not unusual for the manifest to lag behind by hours or days.

As you can see from the lead-in graphic, 9.0.1 was released today (3/30/2026). So it could be later today,  tomorrow, or even later this week before the built-in updater catches up. Unless Samsung pulls 9.0.1 back and decides to push out another, hopefully better release later on.

Here in Windows-World, the release paths for software often tell a story. The one for Samsung Magician is pretty interesting, and shows the value of lessons learned from prior history. You might say “Better later than sooner, especially if problems present!”

Note Added 2.5 Hrs Later: It’s Here!

Reading over ElevenForums traffic in the Devices & Drivers forum just now, saw a user report that Magician is offering 9.0.1 now. Just checked here and — there it is! Installing now, and glad to see it was a matter of hours, not days (or a pullback, either).

Works, too! Looks like we get to do things the easy way this time.

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Thoughts & concerns, WED Blog

Sandbox Effect Keeps Spreading

Leave a comment

OK, I admit it. I run Adblocking software inside my web browsers. To see web pages nowadays, that means I bump them up to 150% so I can read the text. That leaves less room for other stuff, especially ads. But I’ve noticed that an increasing number of websites simply won’t let viewers visit unless those visitors permit the ads to show. So I open those sites inside Windows Sandbox because it works as a no-filters and no-blocks-applied environment. Alas, this “Sandbox effect” keeps spreading as more and more sites make me do this.

Why Say: Sandbox Effect Keeps Spreading

I got a particularly rude wake-up call about this on Wednesday. In fact, I didn’t even figure it out until this morning. Two days ago, I noticed that WinAero was coming up in Firefox (where it’s in my favorites) as an all-back page. I even asked Copilot what might be wrong and it speculated that something with the CDN (Content Distribution Network — e.g. Akamai, etc.) might be wonky.

Wrong. This morning, it dawned on me that this “black screen” might be a particularly draconian implementation of a “no ad blocking” policy. And indeed, that’s what it appears to be (lead-in graphic, left). When I open the same site in Windows Sandbox (lead-in graphic, right) it comes up in readable form right away. Wowie-Zowie.

The Sandbox List Is Growing

Minutes ago, I had a similar experience at Thurrott.com. I suppose I should be grateful, because that site operator at least had the courtesy to tell me what was going on. Here’s what it showed me after a click-through from a “problem loading the page” error message:

Life is interesting when one is inclined to appreciate being informed that they must watch ads on a website, or skedaddle. Here in Windows-World, gratitude often takes unusual forms. This one, methinks, is more unusual than most. Happy Friday!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, Networking, Recent Activity, WED Blog, Windows 11

Reverse DNS Lookup Reveals Router Change

2 Comments

I’m pretty fond of the free network scanning tool named Advanced IP Scanner. It’s much more predictable and reliable than the Network facility built into File Explorer. It also makes it easy to do stuff to and over the network. I’ve been noticing on my LAN recently that an increasing number of PCs (and other devices) get DHCP names that end in “.lan” (see the lead-in graphic for more info). So I used a PowerShell script to do a reverse DNS lookup to double-check this. And indeed, this reverse DNS lookup reveals router change in my SAC2V1A Spectrum-supplied router. Looks like it got a recent firmware upgrade that changed its DNS/DHCP behaviors.

How Reverse DNS Lookup Reveals Router Change

I created a PowerShell script to talk to the router and give me DHCP names for all of the nodes it handles, using the ARP (address resolution protocol) as my foundation. If you look at this WinTerm screencap, the pattern is unmistakable:

I forcibly used ARP to drive reverse DNS lookups (from IP address to name from the router’s name table) for all active IP addresses. Notice that every single name here ends with the “.lan” suffix. That tells me Spectrum pushed a firmware update to the box, because it didn’t used to do that consistently for all items.

Why Advanced IP Scanner Shows Some Unadorned Names?

Advanced IP Scanner uses multiple techniques to resolve IP addresses to names. Among this is the NetBIOS Name Service (NBNS), Link-Local Multicast Name Resolution (LLMNR), Multicast DNS (mDNS), SMB/NetBIOS over TCP, and Reverse DNS (PTR lookup). Some or all of these return bare machine names, lacking the .lan suffix. As far as I can, whichever of these lookups responds first is the one that makes it to the name table. And that’s why Advanced IP Scanner shows different name strings than does my script.

Weird and wonderful are the ways of Windows-World. And few are anywhere near as weird, or as wonderful, as the ones that make name resolution work on Windows networks. QED!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Troubleshooting, WED Blog

Device Zombies Roam Among Us

Leave a comment

Every so often, Windows throws you a curveball that feels less like a bug and more like a ghost story. One of the stranger ones I’ve run into lately is what I’ve started calling “device zombies.” This is a state where Windows believes a device is still alive, or the Microsoft Store insists it’s still alive and kicking. Here at Chez Tittel, I know I sent these devices back to Lenovo, Dynabook or Panasonic up to 5 months ago. That’s why I declaim, in shock and horror: “Device zombies roam among us!” Let me explain…

Proving Device Zombies Roam Among Us

In my case, I often get and return as many as a dozen computers a year on loan from their makers. You’ve read my unboxing, intake, and other stories about them. Right now, through the lens of https://account.microsoft.com/devices (that’s where you login to check devices registered to some specific MSA) I can see four Zombies plain as day:

  • T14Snap: A ThinkPad T14s Snapdragon based laptop I returned to Lenovo in November, 2025.
  • X13G6: A ThinkPad X13 Gen 6 intel based laptop I returned to Lenovo in January, 2026.
  • Flo6: The previous incarnation of my current production desktop based on the flaky and frustrating ASRock B550 Extreme4 mobo. I just decommissioned this over the weekend.
  • X40M2: A Dynabook (formerly Toshiba) Portege X40-M laptop that I returned to Dynabook in January, 2026

When I first checked this out over the weekend, I had 3 more such items showing, but I used the “Remove your device” pane shown for the X40M2 in the lead-in graphic to drive another stake in their hearts. Some of these appear to have caused them to shuffle off the device list, if not the mortal plane.

Sames Goes For Store, But…

The same page in the account. microsoft.com hierarchy has an entry for Microsoft Store device management. It purports to show a list of devices linked to that online asset. But mine keeps coming up empty, even though right now some attempts to install new software tell me I’ve exceeded my device limit. Note the text at lower left in the screencap that reads “Device limit 0 of 10” (no more new ones will be accepted).

It’s even harder to kill zombies when you can’t point an interface at them to order their removal. Thus, these might be considered zombie ghosts because they’re there, but you can’t seem ’em.

Time Cures All Ills, Even Zombies

Turns out that the Store and the MSA Device Log use telemetry to maintain the list of supposedly live items. Thus, when I sent the units back to their makers, they reset their “life timers” by up to 90 days when they fired them up (and opened my MSA login, even if they didn’t use it) before resetting and reimaging them for their next reviewer. At some as-yet-unknown future point in time, though, these machines should vanish from the device list for my MSA. I can only hope the MS Store will treat them the same way…

In the future, here’s what I need to do to prevent Zombies from remaining in my lists:

    1. Remove them from the list while they’re still under my control
    2. Reset the Microsoft Store (wsreset -i) to kill lingering cache associations
    3. Reset the PC so it can’t generate another login to my MSA

As with so much else in Windows-World, the best way to stay out of “Zombie trouble” is never to get into it in the first place. Going forward, I’ll be sure to keep that in mind.

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Understanding UEFICA2023Status=NotStarted

Leave a comment

With the introduction of the Windows UEFI Certificate Authority 2023 (CA‑2023), Microsoft updates the Secure Boot trust chain to enhance platform security. As part of this transition, Windows systems may report a registry value under the key HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing named UEFICA2023Status. This value reports the status of the Secure Boot servicing task that migrates systems to the new CA‑2023 trust model. Understanding UEFICA2023Status= NotStarted is important, because it doesn’t mean CA2023 is not in use in the running Secure Boot environment. Let me explain…

What UEFICA2023Status=NotStarted Means

There are two reasons why UEFICA2023Status can take a value of NotStarted. The obvious one is when the CA-2023 certificate is ready to be added to the Secure Boot value stores, and the Servicing Task hasn’t yet been scheduled or run. The other, as I’m about to describe happens when the Windows PC is already up-to-date. Huh?

The UEFICA2023Status value can take on several states, including NotStarted, PendingReboot, Completed, and Failed. A common misconception is that a NotStarted value signals failure to apply the CA‑2023 update. In reality, this value might also mean that the Secure Boot servicing task has not been triggered. Why? Because the system already meets all necessary criteria for CA‑2023 compliance, and that task need not be run.

Specifically, Windows only initiates this servicing task if all of these three conditions are met:
1. The system firmware does not already trust the Microsoft UEFI CA 2023.
2. The EFI System Partition (ESP) does not contain a bootloader signed by the CA‑2023.
3. A servicing stack update or cumulative update requires the migration to complete.

If the system firmware already includes the CA‑2023 certificate and the ESP contains a CA‑2023‑signed bootloader, Windows deems migration unnecessary. In such cases, the registry value remains NotStarted, which is both normal and acceptable. Even so, it took me aback when I checked this value and saw that status (see lead-in graphic). It spurred me to investigate, and led to this very blog post.

As it happens, the BIOS/UEFI flash I conducted to get the MSI MAG Tomahawk B550 motherboard working updated Secure Boot and included the CA-2023 certificate data as well. And, somewhere along the way the EFI partition got rebuilt to include the CA-2023 signed bootloader. My desktop, Flo6, simply doesn’t need Windows to run the UEFICA2023 update task.

Verifying the EFI Bootloader Signature

It’s easy to confirm that the system is booting with a CA‑2023‑signed bootloader. Indeed, one need only examine the signature of the boot manager located on the ESP. This typically resides at S:\EFI\Microsoft\Boot\bootmgfw.efi (where S: is the mounted ESP). Using PowerShell, execute the following one-liner command:

Get-AuthenticodeSignature "S:\EFI\Microsoft\Boot\bootmgfw.efi" | Format-List *

If it’s current, the output shows the [Issuer] as Windows UEFI CA 2023. (Otherwise it shows as Windows UEFI CA 2011.) Seeing CA 2023 here confirms that the firmware uses a bootloader signed with the updated certificate authority.

Comparing with the OS Copy

Windows also maintains an OS copy of the boot manager at C:\Windows\Boot\EFI\bootmgfw.efi. This file is not used for booting but may be referenced during servicing operations. It is common for this file to remain signed by the older Microsoft Windows Production PCA 2011 certificate. This does not impact Secure Boot functionality, because the firmware uses the ESP copy. We’ve just confirmed the the ESP copy is current and correct for CA-2023.

This Time, NotStarted Is All Good

Appearances to the contrary notwithstanding, a UEFICA2023Status value of “NotStarted” does not always indicate a problem. Instead, it can simply reflect that the system complies with the Secure Boot requirements for CA‑2023 (and got there before MS could). We verified the ESP bootloader is signed by the Windows UEFI CA 2023. We also confirmed that the firmware trust store includes the appropriate (2023) certificate. Passing these checks means that users can be confident that the system is operating within the latest, current Secure Boot regime despite this “interesting” status. No further action is required unless future updates say otherwise.

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness