Category Archives: WED Blog

Insider stuff, Recent Activity, Thoughts & concerns, WED Blog, Windows 11

Benefits from Buying One Generation Back

Leave a comment

Patience isn’t a virtue many tech shoppers cultivate. But here’s the thing: waiting just one product cycle can put serious money back in your pocket. Buying one generation back is one of the smartest, most underappreciated moves in the PC-buying playbook. You get hardware that was cutting-edge twelve months ago, at prices that make last year’s flagship look like a budget pick.

Case in point: a June 19 Windows Central story entitled “Dell’s stunning XPS 13 drops to under $1,000, packing a massive 32GB of RAM.” Careful reading and a little thought reveals that with the newer, faster, more efficient CPUs now out in the market, a markdown seems the right way to clear out this older inventory.

Why Buying One Generation Back Makes Sense

When a manufacturer ships a new laptop model, retailers have a problem: they’re sitting on inventory of the outgoing model. They need it gone. Fast. So prices drop — sometimes dramatically — to clear shelf space and warehouse stock.

Here’s the kicker: the old hardware didn’t suddenly get worse. The processor that impressed everyone last year still handles your spreadsheets, video calls, and browser tabs just fine. Performance gaps between consecutive generations are usually modest — often 10–15%. That’s not worth full MSRP. But a 25–40% discount? Now we’re talking.

Retailers, manufacturers, and third-party sellers all play this game. The window is finite, though. Once inventory clears, deals disappear.

Real Savings, Real Hardware

Don’t take my word for it. Here are four real examples of what buying one generation back actually looks like in dollar terms:

  • Dell XPS 13 (9345) with Snapdragon X Elite: Dropped from $1,399.99 to $999.99 — that’s a full $400 in savings — after newer XPS models landed on shelves.
  • Dell Inspiron 15 (13th-gen Core i5, 2K touchscreen): Fell from $849.99 to $549.99 at Best Buy — $300 off — as 14th- and 15th-gen Inspirons took over the lineup.
  • HP OmniBook 3 (Snapdragon X, 14-inch, 16 GB RAM): Slid from $949.99 to $549.99 — a whopping $400 discount — following the launch of the updated OmniBook 5 and 7 models.
  • Lenovo Yoga Slim 7x (Gen 9, Snapdragon X Elite, 14.5″ 3K OLED): dropped from $1,300 to $800 at Best Buy — a $500 savings — as the 2026 Gen 11 (Snapdragon X2 Elite) arrived to replace it.

Those aren’t rounding errors. That’s real money. On the XPS 13 and Slim 7X alone, you’d save $900 combined. Buy both and you’ve basically gotten one laptop free.

Where to Hunt for Such Deals

You have to know where to look. The best hunting grounds are the Dell or Lenovo Outlet stores, HP’s certified refurbished storefront, and Best Buy’s clearance section (online and in-store). Open-box listings at major etailers are also worth bookmarking.

Timing matters. The best deals on buying one generation back typically surface right when a successor model is formally announced or begins shipping. That’s your signal. Manufacturers and retailers want the old stock gone before the new wave arrives.

Pro Tip

Set price-drop alerts using tools like CamelCamelCamel (for Amazon) or Google Shopping alerts. You’ll catch markdown as they pop up, before the good stuff disappears.

Bookmark those clearance pages right now. Set price alerts on the models you’ve been eyeing. Then act fast when the drop hits. Wny? Because quantities on outgoing inventory are always limited, and once it’s gone, it’s gone. Buying one generation back rewards the prepared shopper, not the hesitant one. A little patience up front means a lot less money out the door at checkout.

Here in Windows-World, we must grab our savings while the discounts persist. He or she who hesitates is lost. Get your budget together and keep you eye on the “new new” PCs, so you can cash in on the “old new” PCs!

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

WinGet Copilot CLI Update Gets Interesting

Leave a comment

By design, the WinGet package manager is pretty conservative about working on apps that are running. With Copilot now active on my desktop most of the time, and even accessible in Windows Terminal (or rather, Intelligent Terminal) this goes double. Yesterday, in fact, my attempt at a WinGet Copilot CLI upgrade gets interesting when it fails with an “access denied” error message. Let’s figure this out, and apply a dead-easy fix.

What to Do When WinGet Copilot CLI Update Gets Interesting

You can see the first Winget failure, the fix, and a successful upgrade in series in the lead-in screencap. That fix provides a way to get Copilot out of the way so WinGet can do its thing without the possibility of messing anything up. Figure that Copilot is nearly always on my systems these days into your consideration and the runtime context.

That fix is:

Stop-Process -Name Copilot -Force -ErrorAction SilentlyContinue

Now, let me explain what’s going on, and this fix does the trick.

Why the First WinGet Upgrade Failed

The root cause is straightforward Windows behavior. The operating system won’t let any process overwrite a running executable. If you had an active terminal session that loaded the Copilot CLI — or any background shell or process that previously invoked it — the old copilot.exe is locked. The installer cannot swap in the new binary, so it fails, and reports explanatory error info.

This is not a WinGet bug. But WinGet could arguably handle it more gracefully. It could detect running processes before the upgrade begins and warn the user. Instead, it downloads everything, then fails at the last step. That may be disconcerting, or perhaps even frustrating, but it’s easily fixed.

The Fix: Kill All Copilot Processes, Then Retry

The fix is a two-step sequence. First, kill any running Copilot processes. Then retry the WinGet upgrade. In PowerShell, do that by running these two commands in sequence:

Stop-Process -Name copilot -Force -ErrorAction SilentlyContinue
winget upgrade GitHub.Copilot

[Note the first two lines are actually a one-liner with a spillover resulting from local formatting; run as a single command.] That’s what the screenshot at the top of this post illustrates. The first command runs cleanly even if no matching process exists. The
-ErrorAction SilentlyContinue flag does that by design and intent.

The second winget upgrade command then finds the package again, verifies the hash, extracts the archive, and this time completes successfully. You will see two confirmations appear: “Overwriting existing file” for the WinGet Links path, and “Command line alias added: ‘copilot’.” Then, finally: “Successfully installed.”

Noteworthy Postscript

A couple of additional observations from this experience deserve mention. First, note that Copilot CLI lists Microsoft.PowerShell (version 7.0.0 or later) as a required dependency. If you have not yet upgraded to PowerShell 7.x, WinGet may attempt to pull that in first. In this case, PowerShell 7.6.2.0 was already current, so that dependency check passed instantly.

Second, if you run WinGet from within VS Code’s integrated terminal, Windows Terminal, or any shell that has previously invoked gh copilot, (gh = GitHub, and is the target for copilot requests in a shell environment) you may hit this exact error. Opening a completely fresh PowerShell window before running the upgrade is often enough to sidestep the issue entirely. In that case, no Stop-Process is needed.

Third, this pattern is not unique to Copilot CLI. Any WinGet-managed package that ships as a standalone executable can run into this same locked-file problem during upgrades. Ditto for Web browsers (e.g. Chrome, Edge, Firefox, etc.) which many users, including your humble correspondent, tend to leave running all the time. For browsers the update may fail, it may not run at all, or you may need to “Relaunch” the browser so the updater applies that change file.

A Predictable Bump in the Road

WinGet is a solid package manager. It delivers smooth, hands-off upgrades nearly all the time. When it stumbles — as it did here — its error messages are descriptive enough for a quick diagnosis and fix.

One command to kill the offending process, a second WinGet command to retry, and you’re done. It is a minor contortion, but now you know that two-step. Here in Windows World, it’s good to keep tools current. To that end, don’t let a transient file lock slow you down. Fixed!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Hardware Reviews, Insider stuff, Recent Activity, USB devices, WED Blog, Windows 11

MCIO Ups the Ante on OCuLink

Leave a comment

For most of computing history, the connectors with the fastest, most reliable PCIe signal paths lived in rack servers. They did not sit on your desk inside a palm-sized box. That divide is eroding quickly. MCIO, short for Mini Cool Edge IO, is a connector standard that Amphenol Communications Solutions developed. Better yet, the PCI-SIG formally adopted it for PCIe CopprLink internal cabling. Standardized as SFF-TA-1016, it packs PCIe Gen 5 performance, and soon Gen 7, into a slim 0.60 mm-pitch form factor. Until recently, you would only find it in a data center. In 2026, it is showing up in mini PCs you can buy on Indiegogo, as I learned reading news at TechPowerUp this morning.

How MCIO Ups the Ante on OCuLink

You can see how the MCIO receptacle compares with USB-C, which Thunderbolt 4/5 and USB 2/3/4/5 use. It’s a little bigger but not much. Indeed, MCIO deserves a closer look. It is a next-generation internal interconnect under the OverPass platform. Its defining characteristic is density without compromise. The connector’s 0.60 mm pitch keeps it compact while supporting data rates from 16 Gbps up to 64 Gbps per lane at PCIe Gen 5. Developers are also working on PCIe Gen 7 variants that run at 128 GT/s using PAM4.

Lane configurations span 4x, 8x, 16x, and 20x. The same connector body handles both cable-to-card and card-edge applications. That versatility reduces BOM complexity. It also supports PCIe, NVMe, and SAS, and the connector is rated for cable runs up to one meter. Designers originally created it to enable modular, scalable, easy-to-service data center architectures. As it turns out, those same traits also fit compact, high-performance personal computing.

Bandwidth Showdown: MCIO vs. the Field

To appreciate what MCIO brings to the table, it helps to line it up against the standards it competes against (and leapfrogs). Thunderbolt 4 tops out at 40 Gbps total bandwidth. But it tunnels PCIe thru an Intel controller, adding overhead at every step.

USB4 v2.0 is where things get faster: up to 80 Gbps, or asymmetric 120 Gbps when video bandwidth gets priority. It is the current mainstream performance sweet spot, and it appears in more mini PCs and laptops. Thunderbolt 5 pushes the ceiling higher, delivering roughly 63 Gbps of effective compute bandwidth, or up to 120 Gbps asymmetric for display workloads, with PAM-3 signaling. In real-world eGPU tests, Try Some Tech measured roughly 5.6-5.8 GB/s of host-to-device throughput.

OCuLink is an enthusiast’s current favorite for eGPU use (see my June 8 post on this topic). It’s a native PCIe external connection that sidesteps tunneling overhead entirely. In the same real-world testing, OCuLink hit roughly 6.6 GB/s host-to-device—beating Thunderbolt 5 by approximately 16% in sustained throughput. USB6 is still on the horizon as of mid-2026, not yet officially released, with predictions pointing toward roughly 160 Gbps using PAM-4 modulation.

Then there’s MCIO 8i running PCIe 5.0 x8: approximately 256 Gbps bidirectional at PCIe 4.0 speeds, and up to 512 Gbps bidirectional at full PCIe 5.0. That’s not an incremental improvement over the competition: it’s a category jump. GPD’s G2 eGPU enclosure, which launched in 2026 using MCIO 8i, claims just 2% performance loss when running an RTX 4090 externally. No Thunderbolt or OCuLink setup has come close to that. OCuLink typically imposes a 4–25% performance penalty depending on the workload; Thunderbolt 5 can push past 25% in bandwidth-intensive scenarios.

Data Center Roots, Professional Credibility

MCIO didn’t earn its reputation in hobbyist labs. It earned it in RAID controllers, host bus adapters, JBOD enclosures, NVMe storage arrays, AI inference servers, and high-density compute racks. In those environments, signal integrity and sustained throughput are vital. PCI-SIG adopted MCIO in its CopprLink cable spec in 2021, and Amphenol announced the PCIe Gen 7 variant for CopprLink internal cabling in 2025. It targets AI inference clusters and next-generation high-bandwidth networking.

Molex also manufactures MCIO connectors under the Mini Cool Edge brand, and the pricing reflects the standard’s enterprise practicality: raw surface-mount 8x PCIe Gen 5 connectors can be found for around $2.41 per unit, while a pre-assembled 16x cable assembly runs closer to $66. In enterprise bill-of-materials terms, that’s modest. For context, a Thunderbolt 5 controller chip alone can cost more than an entire MCIO cable assembly—one reason system designers are increasingly drawn to MCIO for cost-sensitive high-performance designs.

MCIO Shows Up in Mini PCs and eGPUs

GPD is best known for its gaming handhelds. But it made a significant statement in April 2026 by announcing two MCIO-equipped products at the same time. First came the GPD BOX mini PC, powered by Intel’s Core Ultra 300 “Panther Lake” processors. Second came the GPD G2 eGPU enclosure. The G2 launched on Indiegogo at $385 early-backer pricing ($459 MSRP) and is designed to pair directly with the GPD BOX over MCIO 8i. Beyond the headline MCIO port, the G2 is a capable dock in its own right. It includes a 16-pin GPU power connector (12VHPWR), an M.2 storage slot, USB 3.2 ports, dual connectivity via USB4 v2.0, and 100W USB Power Delivery output.

TOPC, another Chinese mini PC maker, also entered the MCIO space in 2026 with the TA255—an AMD Ryzen 7 H 255-powered system priced at approximately $394 (16 GB) to $438 (24 GB). The TA255’s MCIO port runs at PCIe 4.0 x8, delivering 128 Gbps—double the bandwidth of a standard OCuLink PCIe 4.0 x4 connection. That said, its current CPU generation stops it from reaching full PCIe 5.0 speeds.

One important caveat worth calling out: unlike OCuLink or Thunderbolt, MCIO is not hot-swappable and was not designed for casual cable-swap scenarios. It requires a deliberate, secure connection. For users building a modular compact workstation or eGPU setup intended to stay put, that’s a perfectly acceptable tradeoff. For users who want to plug and unplug an external GPU the way they’d swap a USB drive, MCIO is not the it—at least, not yet.

Should You Care About MCIO?

Let’s be honest: MCIO isn’t mainstream. As of mid-2026, device support is limited to a handful of mini PCs and eGPU docks. Most of them are Chinese OEMs with uncertain global reach. If you need broad compatibility today, USB4 v2.0 remains a safe, widely supported choice. If you own a capable mini PC or handheld and want the best eGPU performance, OCuLink is a good choice.

But if you’re thinking a few years out—or building a compact computing setup around modular, high-performance components—MCIO deserves serious consideration. PCI-SIG’s formal adoption of MCIO in its CopprLink cable spec for PCIe Gen 7 signals real institutional backing. It’s not just a niche vendor experiment. I expect to see MCIO appear in more PCs, edge boxes, and workstations in 2026/2027 as the ecosystem matures.

In connector technology, the server rack and the desktop have always eventually converged. On that trail, MCIO looks like the next proving ground. Stay tuned: this story is moving faster than most. Ultimately, it should mean that external NVMes work and run the same as internal NVMes. That’s HUGE.

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

Using Copilot on Intelligent Terminal

Leave a comment

OK then, I just got my first chance to give Copilot in the “new” Intelligent Terminal app a shot. You’d think it would be easy, but there are a few hurdles to get over before Copilot will do its thing inside Windows Terminal, intelligent or otherwise. Indeed, using Copilot on Intelligent Terminal requires a GitHub Copilot account of some kind (Free, Pro, Pro+ or Max) before you can run queries inside the app. Otherwise, you’ll see something like this instead:

As you can see, no GitHub Copilot status means you can ask Copilot stuff inside WinTerm, but you can’t get anything except a “not authorized” error message in return.

Using Copilot on Intelligent Terminal
Takes Time & Effort

Ironically enough, I used Copilot outside of WinTerm to tell me how to get it working inside Intelligent Terminal. Turns out I had to set up a GitHub account, sign up for GitHub Copilot Free, then wait for registration to “take” so my login attempt would then be authorized.

Copilot told me it it would take 15 minutes to an hour for the sign-up process to result in a working session. As you can see in the lead-in graphic, when I put a query to Copilot inside Intelligent Terminal this morning, it worked. Having set the account up mid-afternoon yesterday, that was the expected outcome. But it still came as a welcome and pleasant surprise.

Now, To Learn How This REALLY Works…

As I understand it, GitHub Copilot Free limits users to 50 chat messages per month. Here are its other limits, again courtesy of Copilot itself:

  • Unlimited inline code completions (the lightweight autocomplete model)
  • Access to the GitHub.com Copilot Chat UI
  • Access to Terminal Chat (same 50‑message pool)
  • No access to premium models
  • No agent‑mode operations
  • No AI credits of any kind

Obviously I need to spend some time messing around with the tool, and get it working on scripting tasks for me. That seems to be the best way to put it work within the limited confines of the Free plan in which I’m currently enrolled.

At least, I got Copilot working inside Intelligent Terminal. Here in Windows-World, you have to take your victories, however minor, as you earn them. Stay tuned! I’ll be chiming in on this tool and related topics as I start making my way up the learning curve…

Facebooklinkedin
Facebooklinkedin
Insider stuff, Security, Thoughts & concerns, WED Blog, Windows 11

Evolving Windows Device Security Hardware

2 Comments

This weekend, I pulled up the Windows Security Device security panel on my ThinkPad P16 Gen 3 (2025 build) and my ThinkPad X380 (2018 build; made a 2017 debut), and put them side by side. The difference showed me something interesting — namely,  evolving Windows Device Security hardware.

Both machines run Windows 11. Both are solid, business-class Lenovo laptops. However, the P16 Gen 3 panel is full: every tile is lit, every checkmark is present. The X380 panel, OTOH, shows obvious gaps. It closes out with a blunt verdict: “Standard hardware security not supported.” The lead-in screenshot tells a story of Windows device security hardware evolution over 7 years.

The X380 isn’t a bad machine. It was just built before the security landscape it now lives in actually existed. That distinction matters, so it’s worth unpacking what’s missing and why.

What Evolving Windows Device Security Hardware Means

The most visible absence on the X380 is the Secured-core PC badge. Not surprising when you check the timing: MS launched the Secured-core PC initiative on October 21, 2019. That’s over a year after the X380 shipped. The X380’s 8th-generation Intel Core (Kaby Lake Refresh) silicon predates the Dynamic Root of Trust for Measurement (DRTM) and System Guard Secure Launch capabilities that Secured-core status requires.

In sharp contrast, the P16 Gen 3 runs Intel Core Ultra 9 silicon that fully implements Intel Hardware Shield. That’s what underpins DRTM and Kernel DMA Protection at the hardware level. In addition, Secured-core mandates HVCI (Hypervisor-Protected Code Integrity) enforced at the silicon level. Older CPUs can enable this in software. Alas, they cannot deliver the hardware-based capability that Microsoft’s Secured-core PC requirements demand.

The second gap is the Security processor tile. The P16 Gen 3 surfaces an explicit tile confirming that TPM is visible, active, and reports correctly to the Windows Security layer. The X380 does have a TPM  (Lenovo shipped TPM chips on all commercial machines by 2017). However, Windows Security on the X380 doesn’t surface that tile. Its firmware TPM integration doesn’t offer stricter attestation-visibility that newer UEFI and firmware stacks expose to the operating system. The chip is there, but the trust handshake simply isn’t good enough for Windows to show it as an attestable asset.

The X380 Bottom Line Is…Not Quite There

That brings us to the X380 bottom-line verdict: “Standard hardware security not supported.” Windows delivers this message when a device cannot simultaneously confirm TPM 2.0 attestation, Kernel DMA Protection, and VBS readiness at the hardware level. The X380 can satisfy some of those requirements individually, but not in hardware. As a result, it falls short of the full baseline. That is not a misconfiguration, but falls out because the required silicon-to-firmware-to-OS trust chain simply wasn’t designed into the X380.

What Both Machines Get Right

Let’s be fair to the X380, because calling it obsolete would be wrong. Core isolation runs. And indeed, Virtualization Based Security operates in software mode. Secure Boot is fully active, with all certificates up to date. BitLocker encrypts the drive. These are the foundational Windows security capabilities that survive on older hardware, and they aren’t trivial. The X380 still protects data at rest and guards boot integrity against tampering. It simply cannot make the firmware-to-OS trust chain guarantees that silicon-rooted security delivers. There’s a meaningful difference between those two tiers, but the lower tier is not nugatory.

A Seven-Year Gap in Numbers

Between 2017 and 2025, Intel moved from 8th-generation Kaby Lake Refresh to Core Ultra (Meteor Lake and Arrow Lake). AMD traveled from Ryzen 1000-series to Ryzen AI 300. Along the way, Microsoft introduced Secured-core PC certification (2019), Windows 11’s hard TPM 2.0 requirement (2021), the Pluton security processor co-design with AMD and Intel (2022 ), plus evolving memory encryption standards. Thus, the Device Security panel on a 2025 machine doesn’t just reflect software updates . It also reflects seven years of deliberate co-design among Microsoft, Intel, AMD, and various OEMs, baked directly into the silicon and firmware before the OS even loads.

Wondering About Continued Viability?

If you’re running a 2017/8-era machine and wondering why your Device Security panel looks thin, it’s not your fault and it’s not your settings. It’s the silicon that falls short. The hardware security stack that Windows 11 fully expects is built into CPU microarchitecture and firmware design from 2019 onward. No amount of registry tweaking can close that gap. That said, your older machine isn’t broken. Instead it’s working at a lower tier of the trust hierarchy, but it still does real security work. When it is finally time to refresh, pull up the Device Security panel on your new, Secured-core PC. It  fills those gaps, and offers more and  better security capability. Worth it!

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

Long Trip From 26H1 To 25H2 On P16G3

Leave a comment

Now that I have a Snapdragon X2 PC with a “REAL” version of Windows 11 26H1 installed, I no longer needed the “experimental” version on the Lenovo ThinkPad P16 Gen 3 Mobile Workstation. SO I decided to clean install Windows 11 Pro for Workstations 25H2 on that machine instead. Wow! Did I ever choose a wicked path to follow. It turned out to be a long, long trip from 26H1 to 25H2 on P16G3 (machine name for the afore-named ThinkPad). Buckle up!

Why Such a Long Trip From 26H1 To 25H2 On P16G3?

TLDR answer: Secure Boot foul-ups. After the install, I ran garlin’s Check_UEFI-CA2023.ps1 script on my ThinkPad P16 Gen 3, fully expecting the usual audit output I see on other Windows 11 machines. Instead, I got something that stopped me cold — a warning that certain Secure Boot certificate operations were blocked. The focus keyword here is Secure Boot Deployed Mode ThinkPad P16 Gen 3, and if you’ve landed on this post, you’re probably staring at the same bewildering output I was.

Here’s the short version: the machine was stuck in UEFI Deployed Mode — the strictest Secure Boot state in the UEFI specification. Windows reported Secure Boot as “On,” everything looked fine in Windows Security, and yet the Secure Boot certificate update operations the script needed to perform were completely blocked. No error. Just a quiet wall.

As it turns out, Lenovo began shipping 2024-and-newer ThinkPads — including the P16 Gen 3 — in Deployed Mode by default. That’s a deliberate policy change, not a quirk or a misconfig. And once I understood what it meant, the fix turned out to be a two-minute BIOS menu operation. Let me walk you through it.

What Is UEFI Deployed Mode, Exactly?

The UEFI specification defines four platform security modes, and it helps to know all of them before you go poking around in the BIOS.

Mode Platform Key (PK) DeployedMode Flag Can Modify Secure Boot Variables?
Setup Mode Not installed Off Yes — fully open
User Mode Installed Off With proper authentication
Audit Mode Not installed Off Yes — for testing only
Deployed Mode Installed On No — physical BIOS access required

Deployed Mode is the strictest of the four. The vendor’s Platform Key (PK) is installed, and a separate DeployedMode flag is set to active — which means no software running inside Windows, no matter how privileged, can touch the Secure Boot variables: PK, KEK, db, or dbx. The firmware physically refuses those writes. Therefore, any tool that tries to update Secure Boot certificates from within the OS is going to hit a hard stop.

Here’s the generational split that matters: ThinkPads from 2023 and earlier shipped in User Mode, where the PK is installed but the DeployedMode flag is off, leaving the certificate database accessible via authenticated software. The P16 Gen 3 — along with other 2024-and-newer Lenovo models — ships in Deployed Mode by design. That’s a meaningful architectural difference, and it’s why older tutorials and community scripts don’t account for it. [Source: Lenovo CDRT Docs — Guide to Secure Boot Modes]

Garlin’s Scripts Hit A Wall

Let me be clear: garlin’s PowerShell scripts are excellent community work. The Check_UEFI-CA2023.ps1 and Update_UEFI-CA2023.ps1 scripts are the most thorough tools available for migrating from the expiring 2011 UEFI CA to the 2023 UEFI CA. That’s a transition Microsoft is pushing hard as it tightens Secure Boot enforcement. However, they presuppose a machine in User Mode, where certificate variable writes are at least possible with the right credentials.

On a machine in Deployed Mode, that presupposition falls flat. The firmware’s DeployedMode flag instructs the UEFI runtime to reject all Secure Boot variable modifications originating from the OS environment — full stop. Garlin himself acknowledges as much: you can’t make certain changes while the vendor’s PK is in place and the DeployedMode flag is active. The scripts detect this condition and report it, which is exactly what I saw.

There’s a second layer to this on my specific machine. The P16 Gen 3 runs Windows 11 Pro for Workstations — a meaningfully different edition from Home, Pro, or Enterprise. Pro for Workstations ships with Virtualization-Based Security (VBS) and HVCI enabled by default and uses an edition-specific SkuSiPolicy.p7b file. In addition, it’s designed for domain and enterprise management workflows. The scripts were built around the more common consumer and business editions; Pro for Workstations introduces just enough architectural divergence that some operations require extra care. As a result, even if Deployed Mode weren’t in the picture, this wouldn’t be a straight plug-and-play situation.

The Fix: Exiting Deployed Mode via BIOS

Here’s what I did. The good news is that Lenovo provides a clean, supported path to exit Deployed Mode directly from the BIOS Setup interface — without clearing Secure Boot keys, without entering Setup Mode, and without reinstalling anything. The machine transitions from Deployed Mode to User Mode: the PK stays installed, Secure Boot stays on, and the OS-level certificate update path opens back up.

⚠ Warning — Read Before You Touch Anything

Do NOT select “Reset to Setup Mode” or “Clear All Secure Boot Keys” in the BIOS menu. Either action removes the Platform Key entirely, disables Secure Boot, and requires full manual key reinstallation to recover — a process that is very much not two minutes. If you’re unsure at any step, “Restore Factory Keys” is a safe fallback that gets you back to Lenovo’s shipped state.

Step-by-Step: Exit Deployed Mode on the ThinkPad P16 Gen 3

  1. Enter BIOS Setup. Restart the machine. Press F1 (or Fn+F1 if function-key lock is on) repeatedly at the Lenovo logo during POST. The ThinkPad UEFI BIOS Setup menu opens.
  2. Navigate to Security → Secure Boot . Use the arrow keys. You’re looking specifically for the sub-entries one level down.
  3. Select “Exit Deployed Mode.” This is the one you want. Confirm the action when prompted. This clears the DeployedMode flag only — the Platform Key remains installed and Secure Boot stays active. The machine moves from Deployed Mode to User Mode.
  4. Save and exit. Press F10 and confirm the save. The system reboots.
  5. Verify in Windows. Open msinfo32 (Win+R → msinfo32 → Enter). Under System Summary, confirm: Secure Boot State = On and Platform Mode = User Mode. Both should now read correctly.
  6. Re-run garlin’s Check script. Open an elevated PowerShell prompt and run Check_UEFI-CA2023.ps1 again. The Deployed Mode warning should be gone, and the script should now report actionable certificate update steps as intended.
💡 Tip

If “Exit Deployed Mode” doesn’t appear in your Key Management menu, confirm you’re running a current BIOS version. Lenovo has updated the P16 Gen 3 firmware several times since launch — older BIOS revisions may expose the option differently or label it under a slightly different path. [Source: Lenovo Support HT515493]

Bottom Line

The ThinkPad P16 Gen 3’s Deployed Mode is a feature, not a bug — Lenovo added it to give enterprise customers the highest available firmware integrity assurance right out of the box. Garlin’s scripts are genuinely excellent community tools for the Secure Boot CA 2023 migration, but they presuppose User Mode and a standard Windows edition. Alas, on the P16 Gen 3 running Pro for Workstations, those assumptions don’t hold without first making one BIOS menu change. That said, once you exit Deployed Mode and land back in User Mode, the standard Windows Secure Boot update path works exactly as intended — and the whole detour costs you about two minutes and one reboot.

One more thing: Garlin will tell you to edit the registry and run a scheduled Secure-Boot-Update task. Works on most Windows editions, but not on Pro for Workstations. Follow his advice, unless you’re running that version. I wasted hours until I figured out it just wouldn’t work. Sigh.

Facebooklinkedin
Facebooklinkedin

Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11, Windows Update

Lenovo PC SVNs Can Vary

Leave a comment

I have multiple Lenovo machines in my office. This morning I was checking a ThinkPad P16 Gen 3 mobile workstation and a ThinkStation P3 Ultra desktop in the wake Patch Tuesday’s update. Both run Windows 11, with Secure Boot enabled. While poking around in their Secure Boot UEFI settings, I noticed something that stopped me cold. These two machines report different Secure Boot SVN values. Same vendor. Roughly the same generation. Same security feature switched on. So why the difference? As it turns out, the answer is genuinely interesting, and it matters if you manage a mixed fleet of Lenovo hardware. Bottom line: Lenovo PC SVNs can vary. Let’s explore…

How Is It That Lenovo PC SVNs Can Vary?

SVN stands for Secure Version Number — a monotonically increasing counter (meaning it only ever goes up, never down). It’s embedded directly in UEFI firmware. Its job is to record how many Secure Boot security revisions a device has seen over its lifetime.

Let’s distinguish the Secure Boot SVN from two things it often gets confused with. First, it is not the same as the Secure Boot DB/DBX (the UEFI allow-list and deny-list databases that control which bootloaders and drivers are trusted or revoked). Second, it is not the same as your plain BIOS version number. The BIOS version tracks firmware feature releases; SVN tracks security-policy changes.

The practical muscle behind the SVN is its rollback prevention. If a piece of firmware or a bootloader carries a Secure Boot SVN lower than the minimum value stored in non-volatile memory, the UEFI stack simply refuses to load it. That makes it much harder for an attacker to downgrade your firmware to a vulnerable older version — a classic attack vector the SVN is designed to close.

Lenovo P16 Gen 3 vs. ThinkStation P3 Ultra

The lead-in graphic shows the output from Garlin’s check script and the get-SecureBootSVN command on the P16. Here’s what I found on the P3 Ultra, by way of contrast and comparison:

For the P16 Gen3 SVN is 8.0; for the TSP Ultra, it’s 9.0. WTF?

My first instinct was that something was misconfigured. It was not. These two machines serve quite different market segments. The P16 Gen 3 is a mobile workstation, designed for road warriors and power users who demand both portability and security. The ThinkStation P3 Ultra is a compact desktop workstation, built for workstation-class compute in a fixed location, where stability and long-term reliability tend to trump rapid update cycles.

Critically, the two platforms ship from separate firmware engineering teams inside Lenovo, each running its own BIOS release cadence. ThinkPad-family machines — including the P16 series — have historically received more frequent UEFI updates, driven by the constant churn of mobile power-management tuning, thermal firmware, and rapid security patch integration. ThinkStation platforms, by contrast, follow a slower, more deliberate update cadence that prioritizes stability for long-running workloads. Neither approach is wrong. They just produce different Secure Boot SVN trajectories over time. This time, however, the usual order got stood on its head: the ThinkStation preceded the ThinkPad.

How the SVN Update Pipeline Works

To really understand the divergence, you need to know how the Secure Boot SVN update pipeline actually flows. It is a three-layer process, and each layer operates on its own schedule.

  1. Microsoft issues a Secure Boot policy change or DBX update. A concrete example: the revocation of vulnerable bootloaders tied to CVE-2023-24932 (the so-called BlackLotus UEFI bootkit vulnerability). Microsoft publishes updated Secure Boot DB and DBX payloads, and the associated policy mandates a new minimum SVN level.
  2. OEMs like Lenovo incorporate updated SVNs into a new BIOS/UEFI release. Here is where the divergence begins. Lenovo’s mobile and desktop firmware teams each pick up the Microsoft changes on their own schedules. The ThinkPad team typically ships updated BIOS builds faster; the ThinkStation team takes longer to validate the changes against its broader ISV (independent software vendor) compatibility matrix.
  3. Windows Update stages Secure Boot DB/DBX changes to end-user systems in controlled waves. Microsoft doesn’t push Secure Boot policy changes to every machine simultaneously. It uses a staged rollout — sometimes spanning months — so different machines in your fleet can legitimately sit at different SVN levels even if they have all received recent Windows updates.

One more wrinkle worth noting: Lenovo now pre-configures newer-generation machines from the factory with both the legacy CA 2011 and the new CA 2023 Secure Boot certificates already in place. Older units, however, need a BIOS update to pick up those 2023 trust anchors. That factory-level difference alone can produce an SVN gap between otherwise-similar machines.

ℹ️ Key Insight

SVN divergence across a mixed fleet is a normal artifact of the staged update pipeline — not a sign of a compromised or misconfigured machine. The goal is parity over time, not instant uniformity.

What Should You Do?

The good news is that remediation steps here are straightforward. Here is what I recommend:

  • Update BIOS/UEFI on all machines to the latest Lenovo-published version. Head to the Lenovo Support site (support.lenovo.com), search for your specific model, and grab the current BIOS update. For the ThinkStation P3 Ultra in particular, confirm the release notes explicitly mention CA-2023 certificate integration. Do not rely on Windows Update alone to deliver BIOS updates; go direct to Lenovo.
  • Verify CA-2023 is present in the Secure Boot DB using PowerShell. Run the following one-liner on each machine to confirm the 2023 trust anchor is actually installed:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’

A result of True means the CA-2023 certificate is in the DB and your Secure Boot SVN should reflect the update. A result of False means the machine still needs the BIOS update or the Windows Update wave has not yet reached it.

  • For managed fleets, track SVN parity via Intune or MECM compliance policies. Build a compliance rule that surfaces machines whose Secure Boot SVN falls below your defined minimum baseline. That way you can proactively identify stragglers before 2026 certificate expiration forces your hand.

Bottom line: Secure Boot SVN divergence across a heterogeneous fleet of Lenovo machines is normal, expected behavior. It’s no red flag. The firmware update pipeline simply operates in waves, and different product families move at different speeds. What matters is establishing a consistent minimum Secure Boot SVN across all your machines well before the 2026 CA expiration deadline arrives. Start the BIOS update sweep now, and you’ll have plenty of time to close gaps without deadline pressure.

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11

Post Patch Tuesday CA-2011 Certs Still Kickin’

4 Comments

Yesterday was Patch Tuesday, and I read about Secure Boot changes in that mix. I was curious to see if MS had revoked any CA-2011 boot certificates yet. You can see the post Patch Tuesday CA-2011 certs still kickin’, from the output of the Garlin check script (v.2026.06.08). So I went off looking, specifically to check expiration dates. Here’s what I found…

If Post Patch Tuesday CA-2011 Certs Still Kickin’, When Is Revocation?

I asked Google AI to tell me about expiration dates for the three Microsoft Secure Boot 2011 certificates. Here’s what’s coming down the pike:

  • Microsoft Corporation KEK (Key Exchange Key) CA 2011 expires June 24, 2026. Microsoft Corporation KEK 2K CA 2023 replaces that certificate going forward.
  • Microsoft UEFI CA 2011 expires June 27, 2026. Microsoft UEFI CA 2023 replaces it, and it’s used to sign 3rd-party bootloaders.
  • Microsoft Windows Production PCA 2011 expires on October 19, 2026. Microsoft UEFI CA 2023 also replaces this as well.
  • In addition, MS is adding the Microsoft Option ROM UEFI CA 2023 cert to the mix. As the name says, it’s used to sign third-party option ROMs.

Copilot confirms this info, and it’s also covered in an MS Support Note entitled “Windows Secure Boot certificate expiration and CA updates.”

Then End Is Near, But Not Yet Here…

Thus, it looks like MS has decided not to anticipate the two closest upcoming expiration dates, scheduled for the final Wednesday (6/24) and Saturday (6/27) of this month. I’d wondered about that. If MS issues a Preview CU for July on June 30 (as it often does) we may see it then. Stay tuned: I’ll keep you posted.

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Remote Desktop (RDP), Troubleshooting, WED Blog, Windows 11

Rare Update BSOD Proves Benign

Leave a comment

When better ways to shoot myself in the foot become available, I’ll invariably make use of same. Today, I found myself cleaning up after a surprise bluescreen (aka BSOD for “Blue Screen of Death”). This time, I did it to myself because I used a remote access session to drive updates for both my Intel and NVIDIA GPUs on the Lenovo P16 Gen 3 Mobile Workstation. Indeed, upon investigation, this rare update BSOD proves benign. You can see the error cascade from the Intel GPU update in the lead-in graphic (click that image to see the whole thing: it includes a “Shut down unexpectedly” error).

Why Say: Rare Update BSOD Proves Benign?

I couldn’t find any lingering bad behavior or unwanted side effects from this unexpected crash. Indeed, both Intel DSA (the tool I used to update the Intel ARC GPU) and the NVIDIA app (the tool I used to update the RTX Pro 5000 GPU) reported clean, successful installs when I fired them up to check what happened.

Indeed, that raises the interesting question: “Exactly what happened that caused the P16 Gen 3 to BSOD?” Short answer: me. Longer answer, courtesy of Copilot:

When you install a graphics driver over Remote Desktop:

  • Windows switches to a virtual display driver (RDPDD / Remote Display Adapter)
  • The real GPU driver is still being installed in the background
  • This creates a weird overlap between:
    • kernel graphics stack (dxgkrnl)
    • RDP virtual driver
    • the new GPU driver being initialized/unloaded

That’s exactly the kind of situation that can cause: KERNEL_MODE_HEAP_CORRUPTION (0x13A) → driver stomping memory during unload/reload. Even a perfectly “healthy” driver can crash in that transition.

The Devil Made Me Do It!

I confess: I prefer to work from my production desktop, even when I’m working on another PC. It’s a combination of convenience and laziness. Convenience, because I’ve got two big, clear 27″ monitors I can work from. Laziness, because I don’t have to get up from one chair in my office and move 8 feet over to the other desk where the P16 Gen 3 is running.

Occasionally, this means I get bitten or borked because I’m remoting in, rather than working on the machine directly. Here in Windows-World, I’ve learned to troubleshoot with a certain wry appreciation that I am often the cause of my own woes. Today was one of those days! That said, it all ends well because the system recovered completely upon a successful reboot.

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

OCuLink Offers A Viable TB4/5 Alternative

Leave a comment

Before we dig in, let me define the terms in the title so nobody gets left behind. OCuLink — short for “Optical-Copper Link” — uses the SFF-8611 and SFF-8612 cable specs, originally bred in the enterprise SAS and NVMe world, and now showing up on consumer PCIe expansion cards, eGPU docks, and mini-PC expansion modules. The reason OCuLink offers a viable TB4/5 aleternative is: it carries native PCIe lanes over a compact four-lane connector. Zero protocol translation is involved.

TB4 is Thunderbolt 4 — Intel’s certified 40 Gbps interconnect standard. It runs the Goshen Ridge controller and dominates today’s laptops and docks. TB5 is Thunderbolt 5, Intel’s 80 Gbps follow-up, running the Barlow Ridge controller. It started appearing on premium Copilot+ laptops and high-end docks in late 2024.

Intel has owned the high-speed external storage conversation for nearly a decade. I must ask: “Is there a credible alternative path for builders and prosumers who’d rather not pay the Thunderbolt toll?” Table 1 above says yes, emphatically. The rest of this post explains why the math works out that way.

Why OCuLink Offers a Viable TB4/5 Alternative

Start with the Intel moat, because it’s real and it matters. Thunderbolt certification ties nominally to the USB4 spec. In practice, Intel controls the gate through its mandatory certified controller requirement — Goshen Ridge for TB4, Barlow Ridge for TB5. Each controller adds $15–$25 to a device’s BOM. That cost tags along through the supply chain straight to your invoice. The certification program itself isn’t free either, which is why you see so many USB4 ports on budget laptops and mini-PCs that carry the USB4 badge but quietly skip PCIe tunneling entirely — because PCIe passthrough is optional in the USB4 specification. A port can wear the USB4 label, deliver USB 3.2 storage speeds, and be perfectly compliant. Go figure! Intel doubled the bandwidth ceiling with Thunderbolt 5. But the same certification architecture stayed intact. That structural dependency hasn’t gone anywhere.

The Tunneling Tax

Then there’s what tunneling costs you, and this part tends to get glossed over in spec-sheet marketing. Both TB4 and TB5 move PCIe data over a tunneled protocol stack built primarily for display connectivity. The protocol treats NVMe storage as a secondary concern. That overhead carries a measurable real-world cost. TB5’s 80 Gbps headline pipe delivers only around 6–7 GB/s to an NVMe enclosure in independent benchmarks

Alas, this lands below the sequential read ceiling for a single Samsung 990 Pro or WD Black SN850X. The bandwidth also gets split in ways the spec sheet doesn’t advertise. Run a TB5 dock with a 4K display and a storage enclosure at the same time. The NVMe gets whatever lanes aren’t already committed to display output. No firmware update can fix that. It’s simply how the tunneling protocol divides resources between display and storage traffic.

OCuLink sidesteps all of it, and the reason is almost embarrassingly simple: it carries native PCIe — no tunneling, no overhead, no protocol translation between the cable and the drive controller. The SSD on the far end of an SFF-8611 cable sees the host’s PCIe bus directly. It behaves exactly as if it were seated in a motherboard M.2 slot.

You need no Intel controller, no certification fee in the BOM, and no spec-version negotiation between host and peripheral. Any PCIe host with an SFF-8611 port talks to any OCuLink enclosure. The connector standard is generation-agnostic. OCuLink scales to PCIe Gen5 today, with a theoretical ceiling over 15 GB/s. Thunderbolt 5 can’t get close within its tunneling architecture. Intel spent a decade building a toll road. OCuLink is the county road that goes to the same place, faster, for free.

What Are OCuLink’s Trade-Offs?

I’d be doing you a disservice if I left it there. That’s because OCuLink’s edge comes with genuine limitations you need to price into a buy-in. Cable length is the hard ceiling for which there’s no current engineering workaround. Passive copper OCuLink tops out at 0.5 to 1 meter depending on implementation. TB5 copper passive reaches 2 meters. TB5 optical reaches 40 meters or more. For a storage enclosure sitting six inches from your PC, cable length is a non-issue. For anything across a room or mounted in a rack, it’s disqualifying. Know your use case before you order anything.

Hot-plug behavior is the next honest caveat. PCIe never supported hot-swapping natively. OCuLink inherits that reality. Some enclosure implementations handle safe removal gracefully through driver-level coordination. Others expect a full shutdown first. At minimum, eject the device properly from Windows before pulling the connector. TB4 and TB5 hot-plug is standardized, reliable, and boring in the best possible way. You unplug, Windows notices, the drive disappears from Explorer. No drama.

Ecosystem and Power: The Remaining Gaps

The OCuLink consumer ecosystem is thin compared to Thunder-bolt’s. The OCuLink ecosystem embraces dozens of enclosures from small-batch vendors. Thunderbolt counts hundreds of certified peripherals from Belkin, CalDigit, OWC, and others. Support responsiveness, documentation quality, and return policies reflect that gap. Also, OCuLink carries no power delivery over the connector itself — any drive or enclosure needs its own power source. TB4 and TB5 deliver up to 100W over the same cable that carries data. None of those are dealbreakers for a desktop prosumer. They could be for a road warrior expecting plug-and-play.

For desktop and prosumer builders, or anybody running a PCIe expansion card that exposes an SFF-8611 OCuLink port, you get a legit, lower-cost, higher-throughput alternative to Intel’s certified Thunderbolt ecosystem. The bandwidth math in Table 1 speaks for itself. OCuLink over PCIe 4.0 x4 already beats TB5’s real-world NVMe ceiling. PCIe Gen5 doubles that figure again with no new Intel controller, no certification program, and no tunneling tax required. Those are the deets. Intel built the tollbooth. OCuLink is the on-ramp they forgot to close.

It’s worth considering, and maybe buying into. I’m doing just that myself. You may want to do likewise, if you like the numbers as much as I do.

 

Facebooklinkedin
Facebooklinkedin