Insider stuff, PowerShell

Using ICACLS To Update UFD Boot Files

Leave a comment

In yesterday’s post, entitled Updating Outdated Win11 Boot Media, I walked through why USB Flash Drive (UFD) boot media ages out and how to refresh same. That’s easy enough in theory, but in practice things get interesting fast. When you actually try to replace SkuSiPolicy.p7b inside a mounted WinPE, WinRE, or Windows image, Windows stops you cold. That happens, even when you’re running with elevated privileges (admin). There’s a direct collision with Win11 UFD boot file permissions, and it catches admins off guard. The culprit? Those files aren’t owned by the Administrators group at all. They’re owned by NT SERVICE\TrustedInstaller — and that’s entirely by design. That’s why using ICACLS to update UFD boot files is a must.

How Using ICACLS To Update UFD Boot Files Works

 Windows Resource Protection (WRP) deliberately makes TrustedInstaller the owner of critical system files (including SkuSiPolicy.p7b)to prevent unauthorized modification, even by local Administrators. This is not a bug. It’s a carefully engineered feature. Indeed, it’s part of Windows’ layered defense-in-depth strategy. The intent is to ensure that only trusted, Microsoft-signed processes can alter these files during normal operation.

However, when we work with mounted images offline using DISM, we’re operating as the administrator of the host system. That’s no as privileged as the mounted image’s internal TrustedInstaller service. That service simply doesn’t exist in the context of an offline mount. Thus, we must temporarily take ownership of the file, make our change, and then restore TrustedInstaller ownership and permissions immediately and without exception. That leaves the file in exactly the same protected state as before. I can’t stress “temporarily” enough here. Never leave these files with altered permissions. Not even for a minute. It’s asking for trouble.

Where Does ICACLS Come In?

ICACLS stands for Integrity Control Access Control List. It is a built-in Windows command-line utility that permits users to view, modify, back up, and restore NTFS file and folder permissions (known as access control lists, or ACLs). Because TrustedInstaller owns the files we want to replace, we use ICACLS to take them over, make our change, then put things back the way they were (with TrustedInstaller back in charge).

The 7-Step Win11 UFD Boot File Permissions Cha-Cha

This is the heart of the post . Frankly, I wrote it so I could convey this info. The sequence below applies equally to files inside a mounted boot.wim (Index:1 for WinPE, Index:2 for Windows Setup), a mounted install.wim (any edition index), or a mounted WinRE.wim. Throughout, I use C:\mount\winpe\Windows\
System32\SkuSiPolicy.p7b as the example target path — substitute your own mount point and image file.

Before you start: Open your Command Prompt or PowerShell 5.1 window as Administrator. Every single one of these commands requires elevation. Without it, you’ll get cryptic errors — or worse, silent failures that look like success until you go to unmount.

Step 1 — Mount the image
Dism /Mount-Image /ImageFile:"G:\sources\boot.wim" /Index:1 /MountDir:"C:\mount\winpe"

This mounts boot.wim Index:1 (the WinPE environment) to a local folder so the files inside become accessible to the host OS. Without mounting first, there’s nothing to edit. Substitute /Index:2 for Windows Setup. Otherwise, point/ImageFile to install.wim or WinRE.wim as your need dictate.

Step 2 — Take ownership with takeown
takeown /F "C:\mount\winpe\Windows\System32\SkuSiPolicy.p7b"

This transfers file ownership from NT SERVICE\TrustedInstaller to the currently logged-on Administrator account. Ownership transfer is the prerequisite for any ICACLS permission changes. Why? Because you cannot grant permissions on a file you don’t own. Think of it as getting the deed to the house before you start renovating.

Step 3 — Grant Administrators full control
icacls "C:\mount\winpe\Windows\System32\SkuSiPolicy.p7b" /grant Administrators:F

Even after taking ownership, the original ACL may not include explicit write access for the Administrators group. Hence, this step grants Full Control (F) explicitly. Without it, the copy command in Step 4 will fail with an unhelpful “Access Denied” error. You’ll be scratching your head wondering why ownership wasn’t enough.

Step 4 — Copy in the updated file
copy /Y "C:\work\SkuSiPolicy.p7b" "C:\mount\winpe\Windows\System32\SkuSiPolicy.p7b"

This overwrites the old SkuSiPolicy.p7b with the updated version you extracted from a fresh MCT-generated UFD or ISO. The /Y flag suppresses the overwrite confirmation prompt. This is handy when you’re working across multiple images and don’t want to babysit the process. This is the actual update step. Everything else in this sequence exists purely to make this one command work!

Step 5 — Restore TrustedInstaller ownership
icacls "C:\mount\winpe\Windows\System32\SkuSiPolicy.p7b" /setowner "NT SERVICE\TrustedInstaller"

Return ownership of the file to NT SERVICE\TrustedInstaller — immediately. This is not optional, and it is not a suggestion. Leaving Administrator as the owner breaks Windows Resource Protection and can trigger integrity check failures at boot or during servicing operations. Restore ownership the moment the copy is done.

Step 6 — Restore TrustedInstaller permissions and remove inherited overrides
icacls "C:\mount\winpe\Windows\System32\SkuSiPolicy.p7b" /grant:r "NT SERVICE\TrustedInstaller":F /inheritance:r

This resets the ACL to give TrustedInstaller Full Control as an explicit permission> It simultaneously removes any inherited or residual permissions left over from our earlier grant in Step 3. The /grant:r flag replaces (rather than adds to) existing grants. The /inheritance:r flag removes inheritance propagation. The intent is to match the original hardened ACL state. Together, these two flags put the security descriptor back where it belongs.

Step 7 — Unmount and commit
Dism /Unmount-Image /MountDir:"C:\mount\winpe" /Commit

Commits all changes and cleanly unmounts the image. Without /Commit, DISM silently discards every edit you just made. And yes, I’ve done that. (Self-deprecating aside duly noted.) If something goes sideways during any of the earlier steps, use /Discard instead to abandon all changes safely. But assuming everything went cleanly, /Commit is your finish line.

But Wait: There’s More…

Repeat this exact 7-step sequence for each image and each index you need to update — boot.wim Index:1, boot.wim Index:2, each install.wim edition index (I’ve seen up to 9 on some Windows 11 media), and WinRE.wim. Only the /MountDir path and /ImageFile path change between runs. Everything else stays the same.

A Few Gotchas Worth Watching For

  • Always run elevated. Every command in this sequence requires an Administrator command prompt or PowerShell window. Failures without elevation range from cryptic error codes to silent no-ops — neither of which is helpful at 2 AM before a deployment. And remember to run Powershell.exe (version 5.1) not the PowerShell app or typical Winterm element (version 7.6.4 as I write this). DISM Mount commands work only in 5.1, as I discovered to my consternation and horror in researching this.
  • Verify the copy before unmounting. Run icacls "C:\mount\winpe\Windows\System32\SkuSiPolicy.p7b" after Step 6 — it should show NT SERVICE\TrustedInstaller:(F) as the explicit ACE. If it doesn’t, do not commit.
  • Don’t leave mounts open. DISM mount directories can lock up after system events, sleep cycles, or other processes touching the mount path. Get in, make your change, and unmount promptly.
  • Check for stale mounts first. If DISM throws “The process cannot access the file,” run Dism /Get-MountedImageInfo to see what’s lingering. If you find anything, clean up with Dism /Cleanup-Mountpoints before retrying.

Wrapping Up

The seven-step sequence above is, as far as I can tell, the only safe and fully reversible way to swap WRP-protected files in offline Windows images. Furthermore, this approach isn’t limited to SkuSiPolicy.p7b — it applies to any file under Windows Resource Protection ownership. The pattern is always the same: take ownership, grant access, make the change, restore ownership, restore permissions, commit. In that order. Every time.

If you hit any edge cases I haven’t covered here — unusual mount paths, multi-edition install.wim quirks, or WinRE-specific oddities — drop a note in the comments below. I read all of them, and  community answers are often better than mine. I’ll echo good stuff here as and when it shows up your comments.

I decided to document this cha-cha (it really reminds of a dance chart) because it takes time and attention to work through the sequence. It requires focus, timing and dedication. And it takes a while to learn and understand what’s going on. And, like dancing, once you get it, it’s kind of fun!

Ultimately, it also helps to explain why I recommend regenerating boot media from scratch, rather than repairing existing, outdated UFDs. Too much time and effort, too much work. I used MCT to build a new UFD in under 20 minutes yesterday. Working through this permissions stuff takes about that much time by itself, and it’s just one part of an ongoing dance doing manual UFD repair. The whole shebang took me the better part of 10 hours, spread across several days, to complete.

As I said in yesterday’s post “Don’t fix a boot media UFD unless you absolutely must.” Build a new one instead. It’s faster, easier with far fewer steps to master, including the ones I covered here to handle permissions. But for me, it was worth it, because I learned some new Windows image manipulation tricks.

Facebooklinkedin
Facebooklinkedin

Cool Tools, Insider stuff, PowerShell, WED Blog, Windows 11

Spiffing Up P3 Ultra WinTerm

Leave a comment

Having just restored the ThinkStation P3 Ultra Gen 2 to a clean, plain-vanilla Windows 11 image, I’m now tweaking things to make them comfortable and right. One of my primary targets for improvement is the command line. In turn, that has me spiffing up P3 Ultra WinTerm to get things the way I like them.

What Spiffing Up P3 Ultra WinTerm Entails

What follows is the four-layer stack I put together on the P3 Ultra to make Windows Terminal customization actually mean something. You can see the results in the lead-in screenshot above: a segmented Oh My Posh prompt, a rendered 7-Zip application icon courtesy of winget sixels, and a gloriously color-coded directory listing from Terminal-Icons. Here’s how it all fits together.

WinTerm Customization: Font Foundation

The very first thing I do after any clean Windows install — before the wallpaper, before the taskbar tweaks, before I remember I’m supposed to be “keeping it minimal” — is set up a proper terminal environment. On the P3 Ultra running 25H2, that meant opening Windows Terminal and immediately confronting the default Cascadia Mono font, which is fine in the way that a gas-station sandwich is fine. It works. You’re not going to brag about it.

The secret to this entire Windows Terminal customization stack is that absolutely everything else — the Oh My Posh prompt glyphs, the Terminal-Icons file badges, the whole visual language — depends entirely on a Nerd Font being the active terminal font. Without one, every single glyph-based feature renders with less pizazz. You get a terminal that looks like it’s having a small crisis. Not the aesthetic I’m going for.

My pick is CaskaydiaCove Nerd Font Mono v3.4.0 — the Nerd Fonts project’s officially patched version of Microsoft’s own Cascadia Code. That lineage matters. indeed, it looks completely native in Windows Terminal because it essentially is Cascadia Code, just supercharged with 10,000+ additional Nerd Font glyphs packed into the private-use Unicode ranges.

I installed it per-user to %LOCALAPPDATA%\Microsoft\Windows\Fonts, then promoted it system-wide since the P3 Ultra session was already running elevated. One JSON edit in Windows Terminal settings (hit Ctrl+Shift+, to open the file directly), setting “face”: “CaskaydiaCove Nerd Font Mono” inside profiles.defaults.font, and that foundation is laid.

OMP Puts Prompts Right

Oh My Posh (OMP) is the tool that turns my drab PS C:\Users\ed> prompt into a segmented, information-dense status bar that actually tells me things I want to know. In my current setup — visible in the screenshot — the left side shows my username (ed), the current directory, a key glyph, the terminal icon, and the last command’s execution time. The right side displays the shell name (pwsh) and a live clock. It looks and feels sharp. Frankly, it’s the main reason I get excited about a new terminal setup.

Speaking of execution time: the screenshot shows a 0ms result for a quick winget list –details 7zip run, which is gratifying. Less gratifying but no unexpected is the 990ms that appears on the subsequent dir command. That’s Terminal-Icons loading its full icon map on first call, not OMP behaving badly. Well. Mostly not OMP behaving badly. The 990ms is the price of a pretty terminal, and I have decided it is worth it in the same way I decided heated seats were worth it when I bought my last car. Once you have the temperature drops below freezing, the idea of going without feels almost uncivilized.

OMP installs cleanly via winget with winget install JanDeDobbeleer.OhMyPosh. Then, getting it running in PowerShell 7.6.4 (the version running on the P3 Ultra, as you can see in the startup banner in the screenshot) takes exactly one line added to your $PROFILE. That’s an oh-my-posh init pwsh call pointing at your chosen theme JSON. That’s it. Minimal friction, maximum visual payoff.

Winget Icons: Sixel Graphics Come to Life

Here’s the one that still makes me do a small double-take every time I see it: that 7-Zip logo in the terminal is not ASCII art. It is not a colored block approximation. It is the actual, rendered 7-Zip application icon, displayed as a real bitmap inside the terminal window, courtesy of sixel graphics support added to winget in Preview build 1.29.50 and later.

Important: Two Different Settings Files

Enabling sixels requires editing winget’s own settings file — opened with winget settings — not Windows Terminal’s settings.json. These are two entirely separate JSON files. Editing the wrong one produces a very confusing non-result, and I say that with the authority of someone who absolutely did exactly that on the first attempt.

Once you’re in the right file, the change is simple: add “visual”: { “enableSixels”: true } to the JSON, do a full restart of Windows Terminal (not just a new tab — a full close and reopen), and then run –winget list -details [packagename] to see the icon appear. Coverage is currently somewhere around 25–30% of installed packages — Win32 (exe/msi) apps show icons reliably. MSIX packages mostly don’t yet. But seeing 7-Zip’s logo materialize in a terminal window never quite gets old.

Terminal-Icons: Color-Coded Dir Listings

The final piece of the stack is Terminal-Icons. This PowerShell module by Brandon Olin transforms your Get-ChildItem output from a monochrome wall of filenames into a color-coded, glyph-annotated directory listing .. Bonus: it’s easier to scan at speed. Folders get folder glyphs in teal. JavaScript files get the JS badge in orange. Binaries, config files, images, and scripts each get their own visual treatment, all driven by the Nerd Font glyph library that CaskaydiaCove Nerd Font Mono v3.4.0 provides.

Installation requires a single PowerShell line: Install-Module -Name Terminal-Icons -Repository PSGallery -Force. Permanent activation requires adding Import-Module Terminal-Icons to your $PROFILE. After that, dir, ls, and Get-ChildItem all pick up the icons and colors automatically — no further configuration needed. It simply works, which in my experience is not always a given with PowerShell modules.

OK, I’m Happy Now…

Installing this stack — CaskaydiaCove Nerd Font Mono, Oh My Posh, winget sixels, and Terminal-Icons — took me about 10 minutes. The result is exactly what you see in that lead-in screenshot: a terminal that looks like it means business, with a prompt that tells me what I need to know, icons that let me spot my packages and files at a glance, and one very satisfying 7-Zip logo that I have already shown to more colleagues than strictly necessary. It is, as I said to myself at the time, a very spiffed-up terminal. Round Rock, TX never looked so good from a command line. Here in Windows-World, I count that as an accomplishment, of sorts…

 

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

Insider Preview Build Expiration

Leave a comment

In today’s coverage at Windows Central, I found an interesting item. Indeed, the title is a little scary “Windows Insiders have one week to update their PCs, or else.” It seems that Insider Preview builds come with “flight certificates” that include an expiration date, and numerous builds will be hitting that date next Tuesday, August 11. Insider Preview build expiration comes with some gotchas, so it’s a good idea to update in advance to avoid them. Let me explain…

What Does Insider Preview Build Expiration Mean?

Thankfully, any Insider Preview expiration date is easy to find. If you look at the snippet of winver.exe output above, you’ll see it identifies itself as “[t]he Windows 11 Pro Insider Preview operating system…” It also provides expiration data, i.e. “Expires 10/31/2027 6:43 PM.”

As it happens, Microsoft embeds time-limited cryptographic certificates in every Windows Insider Preview build. These are called flight certificates, and when they expire, things get weird, fast. This post covers what flight certificates actually are, how to check whether your build has been renewed, and what happens if you let that clock run out.

Not Just a Pun:  Flight Certificates

A flight certificate is a code-signing certificate that Microsoft embeds directly into every Windows Insider Preview build. The name comes from Microsoft’s internal terminology for Preview builds — “flighting” — the practice of distributing pre-release builds to rings of volunteer testers. Think of the certificate as both a seal of authenticity and a built-in expiration thing.

Both of the flight certificate’s jobs are straightforward. First, it authenticates that the preview build you’re running is genuinely from Microsoft. That is, it’s not some 3rd-party repackage of dubious origin. Second, it acts as a gentle but insistent timer. As the certificate approaches its expiration date, the system begins reminding you to update. Let it fully expire, and the nudging stops being gentle.

There are some things a flight certificate is not: it has nothing to do with product activation, your MSA, or installed apps and files. Your activation status is unaffected by certificate renewal. The cert lives at the build level, not the license level.

Flight Certificates Come and Go Regularly

Microsoft renews flight certificates routinely, with an updated cert inside each new Insider Preview build. What’s unusual about the current renewal cycle is its scope. Historically, certificate renewals have mainly been a Canary Channel issue. This time, the renewal covers all channels (Experimental, Beta, and Canary). That’s a broader reach than typical and tells us that the flight certificate now applies across all active Insider flighting channels.

Here’s the thing (and the reason for the clickbait style Windows Central article title). The old certificate expires August 11, 2026. For Beta Channel on 25H2, the minimum renewed build is 26220.9022, which has been available since July 31, 2026. If you’re on that build or later, you’re already good through October 2027.

If not, unpleasant things may happen to your PC if you don’t upgrade in advance. As the Windows Central article states: “You will also stop receiving automatic background updates once the flight certificate expires.” See next section for more icky details.

Finding Flight Expiration Info

Checking your expiration date takes about ten seconds. Press Windows key + R, type winver, and hit Enter. The About Windows dialog that pops up will show an Evaluation copy line near the bottom, followed by an expiration date. If that date is after August 11, 2026, congratulations — you’re already on a renewed build and can stop worrying.

If your date is on or before August 11, 2026, you’ll want to act before the deadline arrives. Here’s what happens if you don’t:

  • A persistent “This build will expire soon” watermark appears on your desktop. You can’t dismiss, minimize, or right-click it away.
  • Automatic background updates stop arriving. You fall off the flighting pipeline entirely.
  • The machine doesn’t stop working, but it does become an isolated island: no new Insider Preview builds, no flight certificate renewal, no path forward except a manual update (clean install).

The fix is mercifully simple. Head to Settings > Windows Update > Check for updates. Then, let it find and download whatever’s on offer, install it, reboot. One update cycle and you’re current. The renewed certificate ships with the build, the watermark goes away, and normal flighting resumes.

I’ll admit: I’ve watched cert expirations play out on test machines over the years. But this one genuinely caught me off guard — not because it snuck up on me, but because my Beta Channel machine had already sorted itself out entirely on its own before I’d even noticed there was a deadline to worry about. Silent competence from Windows Update. Here in Windows-World that counts as success.

Further Reading

If you’re running multiple test PCs across channels the way I do, this is worth bookmarking now rather than rediscovering in a scramble on August 10th. For a solid news-side breakdown of the timeline and urgency, start with Sean Endicott’s Windows Central report, which does an excellent job of framing the stakes for everyday Insiders.

For the authoritative technical detail straight from Microsoft, including channel-by-channel minimum build numbers and step-by-step renewal instructions, Microsoft’s flight certificate renewal FAQ is the definitive doc. And if you’re new to the Insider Program or just want a solid orientation on how the whole flighting system works, the Windows Insider Program on Microsoft Learn is a good starting point. For a comprehensive look at which builds are available in which channels right now, the Windows Insider Flight Hub tracks the complete build-by-channel matrix.

Stay current if you can. The whole point of Insider Preview build expiration is to keep the testing community on builds that reflect where Windows is headed, not where it was six months ago. Keeping up is part of the Insider credo. You’ll get used to it: I sure have!

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

Take the Long Way Home

5 Comments

I’ve been writing about Windows since version 3.1. I remember the floppy disk shuffle. I remember the joy of actually getting TCP/IP running on Windows for Workgroups. You’d think, after thirty-plus years, I’d have an easier time convincing my own workstation to accept a clean OS install. You would be wrong. Instead, in the words of Supertramp I had to “Take the long way home.”

Why I Had to Take the Long Way Home…

My go-to test PC is a Lenovo ThinkStation P3 Ultra Gen 3. It’s a legitimately serious machine, the kind with big SO-DIMM memory modules and a front panel that looks like it means business. It was humming along on Windows 11 24H2 without complaint. Then Microsoft quietly lit up the Windows 11 25H2 branch, and I figured: let’s do this. Simple in-place upgrade, twenty minutes, done by lunch. Instead, I got error code 0xC1900101-0x20017. Twice.

Driver Madness and Mayhem

If you’ve tangled with Windows upgrade failures before, you know that particular error code is frustratingly vague . Indeed, it lives in the SAFE_OS phase of the upgrade process, which means Windows has already swapped out its core OS files. But it chokes when it tries to apply drivers during the rollback-protected transition. In plain English: the driver stack fell over at exactly the wrong moment. I pulled the SetupDiag logs, confirmed it was a driver-related hang in the SAFE_OS phase, and stared at the ceiling for a while.

There’s a particular flavor of irony in being a professional Windows tech writer whose own PC refuses to cooperate with a Windows upgrade. I considered filing it under “job security” and moved on. After two failed in-place attempts, the logs were clear enough: a clean Windows 11 25H2 install was the only sane path forward. OK, fine. Now it’s time to go the long way, and do it the hard way.

Day 2: USB Media Chaos

I grabbed my trusty ADATA S102 32GB USB 3.0 flash drive — the one that has lived in my desk drawer for so long it practically has squatter’s rights. Next, I fired up Rufus to build a bootable installer. Rufus is usually my go-to. Usually.

This time, Rufus misdetected the hybrid image structure inside the Windows 11 25H2 ISO and produced a drive that my P3 Ultra’s UEFI couldn’t see. No error. No explanation. Just a polite boot menu that pretended the USB drive didn’t exist as a bootable option. Lovely.

Switch to balenaEtcher. Flash succeeds cleanly, the drive is recognized, the installer begins to load. Next, it promptly fails because install.wim inside the 25H2 ISO clocks in north of 5 GB. Alas, the FAT32 filesystem that UEFI boot requires has a hard 4 GB per-file ceiling. We’ve known about this limitation for years. It still bites people. It bit me.

The fix is DISM‘s /Split-Image switch, which carves the oversized WIM into a set of smaller SWM files. The command looks like this:

Dism /Split-Image /ImageFile:install.wim /SWMFile:install.swm /FileSize:4000

That produces install.swm, install2.swm, and however many additional slices it needs to keep every piece under the 4 GB limit. The elegant part: Windows Setup natively recognizes and reassembles SWM files on the fly when it finds install.swm sitting on the same drive. This calls for no extra flags, nor manual stitching. You just copy the SWM files onto your FAT32-formatted USB alongside the rest of the installer content and walk away.

For good measure, I also tried my Kingston DataTraveler 70 (USB-C) routed through my Acasis TB5010Pro USB4/Thunderbolt enclosure. That combination booted without a fuss, confirming the Thunderbolt chain was playing nicely with the UEFI boot stack. Good to know for the future.

Day 3: Secure Boot Shenanigans

With bootable media finally usable, I plugged in the drive, rebooted, and hit the BIOS. ThinkStation P3 Ultra runs Lenovo’s UEFI firmware, and if you’ve never spelunked the Lenovo workstation BIOS, know this: it is thorough. Very thorough. There are settings in there I’m fairly certain have never been touched by human hands.

The Secure Boot section alone offers three distinct modes: Setup Mode, User Mode, and Audit Mode. My machine had been enrolled in Secure Boot with Microsoft’s standard production key. That’s normal for a production workstation. Darned if the USB installer  didn’t trigger a Secure Boot violation on the very first boot attempt. The system refused to load the installer, flagging it as untrusted.

So, I turned Secure Boot off (Disabled). That’s enough of a foothold to get the installer running. Post-install, I turned it back on and everything was properly locked down again. Annoying? A little. Correct behavior by the firmware? Absolutely.

I also needed to check the Startup tab in the BIOS to confirm boot device priority. As expected, the NVMe SSD was sitting above the USB device in the boot orde. That’s normally what you want and exactly what you don’t want when you’re trying to boot from USB. Bumped the USB device to the top, saved, rebooted. Whoever designed UEFI menus clearly never had to navigate one under deadline pressure. That said, at least the ThinkStation’s implementation is logically laid out once you know where to look.

Day 4: BitLocker’s Takes the Stand

By Day 4, I was feeling cautiously optimistic. The installer booted. The language selection screen appeared. Life was good.

Then Windows Setup looked at my target NVMe drive and politely informed me that it was BitLocker-encrypted and couldn’t be formatted without the recovery key. Of course it was. I had BitLocker enabled on the previous 24H2 install. That’s the default, after all. And, alas, I hadn’t decrypted the drive before starting this whole adventure. Classic.

I retrieved the BitLocker recovery key from my Microsoft account at account.microsoft.com/devices/recoverykey, then dropped into a pre-installation WinPE command prompt from the installer’s repair menu. Using manage-bde, I unlocked the drive with the recovery key and kicked off decryption. Depending on drive size and how much data is on it, this can take a while — budget accordingly.

Building Better Boot Media

With the drive decrypted, I used diskpart to nuke the partition table entirely and start clean:

select disk X
clean
convert gpt

This gives you a genuinely fresh GPT partition table, not just a reformatted volume with old metadata lingering in the corners. Worth the extra two minutes every time.

One more wrinkle worth flagging: the ThinkStation P3 Ultra uses a firmware TPM 2.0 via Intel PTT — the chip Windows 11 relies on for both BitLocker and Secure Boot attestation. Decrypting and wiping the drive before the  fresh install prevents TPM ownership conflicts that can otherwise surface post-install, when Windows tries to re-seal the new BitLocker keys to the TPM and finds stale metadata from the previous OS. Getting ahead of that saved me a likely Day 5 headache.

Day 5: Clear Skies at Last

On Day 5, everything finally cooperated. Bootable media: sorted. Secure Boot mode: disabled. Drive: decrypted, wiped, and wearing a fresh GPT partition table. I plugged in the USB drive, rebooted, and watched the Windows 11 25H2 Setup wizard run from start to finish without complaint. It almost felt anticlimactic.

Post-install, the news got better. All Lenovo ThinkStation-specific drivers installed cleanly through Windows Update and Lenovo Vantage. I needed no manual INF hunting, nor saw any Device Manager yellow triangles. The NVIDIA professional GPU drivers (ThinkStation ships with a range of NVIDIA RTX options depending on configuration) updated through Windows Update without drama. The resulting install is fast, clean, and correctly locked down with Secure Boot and BitLocker re-enabled on the fresh volume.

Was it a walk in the park? Not even slightly. It was more obstacle course than OS upgrade — and every single obstacle was one I’ve written about in some form over the years. There’s a certain humbling quality to running face-first into your own documented knowledge. But the system at the end of it is genuinely better for the process: no upgrade cruft, no lingering driver artifacts from the 24H2 stack, no half-migrated settings. Just a clean Windows 11 25H2 install the way the OS was meant to be experienced.

A Looooong Way, Indeed

Supertramp was onto something: sometimes the long way is the only way home. At least when you take the long way, you learn every pothole in the neighborhood. Bonus: you’ll know exactly where they are next time.

Lessons Learned

  • Disable BitLocker before any OS swap. Decrypt the target drive before you ever launch Setup — it will save you a WinPE detour.
  • Split WIM files over 4 GB. Use DISM’s /Split-Image switch; Windows Setup handles the SWM reassembly natively.
  • Undo Secure Boot mode before booting to USB. Disable temporarily if your production keys block the installer.
  • Use diskpart to clean the target drive. A full clean and convert gpt ensures you’re starting with a genuinely fresh partition table.

This was a wild adventure, and one strewn with interesting gotchas. About par for the course, here in Windows-World. I hope not to walk this road again soon, but if I must, I’ll know how to dodge and duck. Sigh.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, WED Blog, Windows 11

Understanding Windows Hardware Error Service

Leave a comment

This morning, I ran across an item on the TechPowerUp news forum entitled “Microsoft Denies New Tracking Service in Windows 11.” I was intrigued to learn about Whesvc (the corresponding abbrevation and the name of a folder for storing telemetry data beneath C:\Windows\Temp). Its job, says Copilot is to handle “WHEA (Windows Hardware Error Architecture) events [such as] machine check exceptions, PCIe AER, CPU internal errors, bus timeouts,…” and more. The lead-in graphic shows what voidtools Everything found in that folder.

Surprisingly, Whesvc stuff eats nearly 1GB of storage space.

Why Understanding Windows Hardware Error Service Matters

This folder provides a place where WHESVC keeps information about various related events, including when:

  • a hardware error is raised
  • the system is preparing a WHEA telemetry bundle
  • the OS is about to submit a hardware error report
  • a WHEA LiveKernelEvent is generated
  • a PCIe or CPU error needs additional context

Yes, you can indeed report this stuff to Feedback Hub, but I find no documentation to indicate that the OS does this automatically. But it seems like uploads to report stuff would be at least a good idea, if not a given. My best guess it is gets folded into normal Windows telemetry and phone home that way…

PowerShell to the Rescue

Using PowerShell gets you over this particular hurdle. If you want to see what’s in the folder, try this one-liner:

Get-ChildItem -Force -Recurse "C:\Windows\Temp\Whesvc" | Select-Object FullName, Length, LastWriteTime

This produces list of event trace logs (.etl files) you can share with Feedback hub if you’d care to. The following PowerShell will zip it up for you into a file named Whesvc-Diagnostics.zip:


$src = "C:\Windows\Temp\Whesvc"
$dst = "$env:USERPROFILE\Desktop\Whesvc-Diagnostics.zip"
Compress-Archive -Path $src -DestinationPath $dst -Force

I’d be inclined to label the collection as something like “Whesvc output for dd/mm/yy” when you turn it over to MS for inspection. And indeed some of the object names are pretty interesting, as they include strings like “slow app launch,” “long delay,” “app hang,” and so forth. Sounds like potentially useful stuff!

Given that this is transient info, you need not worry about keeping folder contents around. Once you share it with Feedback Hub (or not), it’s safe to delete. As Copilot says “These are scratch files not persistent logs.” ‘Nuff said.

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

It’s the Layout Not the UFD

Leave a comment

Every so often, Windows administrators run into a problem that looks like one thing but turns out to be something else. My recent adventure with Lenovo’s USB Recovery Creator is a good example. What started as a simple attempt to build a recovery USB stick for a ThinkStation P3 Ultra Gen 3 turned into a deep dive into how Windows, UEFI firmware, and USB controllers decide what counts as “removable media.” Spoiler alert: it’s the layout, not the UFD. To access this tool visit Lenovo Support, plug in your Lenovo PC serial number, go to the Drivers & Software page, then click the Submit Recovery Media Order button.

Why I’m Sayin’: It’s the Layout Not the UFD

If you’ve ever plugged in a perfectly good USB flash drive only to have Lenovo’s recovery tool refuse to see it, you’re not alone. I tried half a dozen drives. They included 32+GB models from SanDisk, Kingston, Mushkin, Transcend, ADATA, even a brand‑new 256GB USB‑C DataTraveler. Every single one failed Lenovo’s removable‑media test. Windows saw them. Explorer saw them. Disk Management saw them. But Lenovo’s tool? Nada. The dropdown menu stayed stubbornly empty.

That’s when the real troubleshooting began.

Why the Tool Rejects “Unspecified” Devices

Lenovo’s USB Recovery Creator is picky. Indeed, it’s far pickier than most users expect. It doesn’t simply look for a USB drive. It looks for a USB drive that reports itself as MediaType = Removable through Windows’ storage stack. Anything else—SSD, HDD, or the dreaded Unspecified—gets ignored.

Here’s the catch: many modern USB flash drives, especially high‑performance ones, identify themselves as fixed disks rather than removable media. This is intentional. Manufacturers optimize for speed, wear leveling, and controller behavior to mimic SSDs. Windows is fine with this. UEFI is fine with this. Most tools , ditto. Lenovo’s USB Recovery Creator tool is not.

When I ran:

Get-PhysicalDisk | Select FriendlyName, BusType, MediaType

every single UFD I owned showed up as:

  • BusType = USB
  • MediaType = Unspecified

That’s the kiss of death for Lenovo’s recovery tool. It will never list a device that reports “Unspecified,” no matter how new, fast, or reliable it is.

Proper Cleaning, Formatting and Partitioning Works

Here’s where the story takes a turn. Conventional wisdom says formatting or repartitioning won’t change how a USB device identifies itself. And that’s true — MediaType doesn’t change. But Lenovo’s tool isn’t only checking MediaType. It’s also checking the partition layout, and that’s where things finally broke open.

After trying multiple drives and ports, I decided to go nuclear and rebuild the USB stick’s layout from scratch using DiskPart. The magic sequence turned out to be:

diskpart
list disk
select disk X
clean
convert gpt
create partition primary size=32000
format fs=fat32 quick
assign
exit

The moment I did this — and I mean immediately — the Lenovo USB Recovery Creator dropdown lit up and showed the UFD. No hesitation. Nothing ambiguous. No more empty menu.

This was the breakthrough: Lenovo’s tool requires a very specific starting layout before it will accept a USB device, even if the device reports MediaType = Unspecified.

In other words, the tool doesn’t just care about whether the drive is removable. It cares about:

  • GPT vs MBR
  • Partition count
  • Partition size
  • Partition type
  • File system
  • Whether the drive is “clean”
  • Whether Windows has mounted it consistently

Once the drive was wiped, converted to GPT, given a single 32GB FAT32 primary partition, and mounted cleanly, Lenovo’s tool recognized it instantly. That’s when the lightbulb lit up: it’s the layout, not the UFD.

Why Lenovo’s Tool Needs a Clean GPT/FAT32 Layout

Lenovo’s recovery creator expects to take full control of the USB device. It wants to:

  • wipe the drive
  • repartition it
  • write a bootloader
  • copy the recovery image
  • verify checksums

If the drive has:

  • multiple partitions
  • leftover boot sectors
  • exFAT or NTFS formatting
  • odd alignment
  • remnants of previous boot media
  • a corrupted MBR
  • a GPT with unexpected metadata

the tool simply refuses to show it in the list of acceptable targets. This explains why even brand‑new drives failed: they shipped with factory formatting that didn’t match Lenovo’s expectations. That said, once the layout was corrected, the tool behaved exactly as designed.

The Real Lesson: Modern USB Behavior Requires Modern Troubleshooting

This experience taught me something important: modern USB flash drives aren’t the simple “plug‑and‑play removable media” devices they used to be. They behave more like miniature SSDs, and their factory formatting often reflects that.

Lenovo’s USB Recovery Creator, however, still expects a classic removable‑media layout. When the layout doesn’t match, the tool silently ignores the device. Fortunately, the fix is straightforward once you know what the tool wants to see.

Lesson Learning

If you’re struggling with Lenovo’s USB Recovery Creator, don’t assume your USB flash drive is bad. Don’t assume the ports are faulty. Don’t assume the controller is misbehaving. The real issue is usually the partition layout on the UFD. Clean it. Convert it. Create a simple FAT32 primary partition. Then watch the Lenovo tool recognize it instantly.

In other words: it’s the layout, not the UFD. Here in Windows-World these little details matter. They sucked up my morning and tossed it away. This afternoon, I’m back on the hunt. Whew!

Facebooklinkedin
Facebooklinkedin
Device drivers, Insider stuff, Recent Activity, WED Blog, Windows 11

Bitlocker Makes Transplanted NVMe Inaccessible

Leave a comment

Here’s a scenario that trips up even seasoned Windows power users. You yank a perfectly healthy NVMe drive from your desktop or laptop, slide it into a USB or Thunderbolt enclosure, and Windows either refuses to unlock it or asks for a BitLocker recovery key that doesn’t unlock anything. A BitLocker NVMe enclosure combination produces what looks like data loss — but isn’t. Not yet, anyway. Understanding why this happens requires a quick tour of how BitLocker actually seals your data to your hardware. The point, however, is worth noting: using Bitlocker makes transplanted NVMe inaccessible. You can’t read it unless you put it back whence it came.

After an initial warning asking for a Bitlocker key that WILL be rejected, the affected drive shows up as “Unknown” in Disk Management. That’s what you see as the lead-in graphic for this blog post.

Why Bitlocker Makes Transplanted NVMe Inaccessible

BitLocker doesn’t just encrypt your drive and hand you a recover key. By default, it uses the TPM (Trusted Platform Module) — the dedicated security chip on your motherboard — to seal the VMK (Volume Master Key) against a specific hardware fingerprint. That fingerprint is a set of PCR (Platform Configuration Register) measurements recorded at the moment BitLocker was first enabled. Think of it like a wax seal on an envelope: the seal was made using your exact hardware setup, and it can only be broken by that same setup.

The most important register in modern configurations is PCR7. It tracks the Secure Boot policy state — specifically, the UEFI firmware’s Secure Boot signature databases (db and dbx), the boot manager, and the OS loader’s cryptographic signatures. When your PC boots normally, the TPM recalculates PCR7 from scratch. If that fresh measurement matches what was recorded at sealing time, the TPM automatically releases the VMK, BitLocker decrypts the drive in the background, and you never see a prompt. The entire process is silent and seamless. That’s the design goal.

When the PCR7 measurement doesn’t match — because something in the Secure Boot chain has changed — the TPM refuses to release the VMK. BitLocker then falls back to prompting for a recovery key. That’s expected behavior. A drive enclosure, however, is a different problem entirely.

Why the Enclosure Breaks Everything

When you move the NVMe to an external enclosure, the TPM doesn’t come along for the ride. It’s soldered to your original motherboard. The enclosure presents the drive to a completely different environment — or no TPM at all, if you’re plugging into a machine without one, or directly into another system as a USB mass storage device. There is no trust anchor. No Secure Boot validation chain. No PCR match is even possible.

To appreciate the full picture, it helps to know the other key registers. PCR0 captures the UEFI firmware code itself. PCR2 captures option ROM measurements — the firmware on expansion cards and storage controllers. PCR4 records the boot manager. PCR11 is BitLocker-specific, covering its own policy settings. Normally, all of these must match the original sealed profile for the TPM to cooperate. In an enclosure, none of them can be reproduced. This is not a bug. It is precisely the theft-prevention feature Microsoft designed BitLocker to deliver.

The VMD/RST Complication

There is a subtler wrinkle that catches power users off guard: VMD (Intel Volume Management Device) and RST (Rapid Storage Technology). Many modern Intel-platform systems configure their NVMe storage through the VMD controller, which routes NVMe drives through Intel’s RST driver stack during the boot process. That RST driver participates in the boot chain and alters the PCR measurements — particularly PCR2 and PCR0, which capture option ROM and firmware behavior.

When you pull that NVMe and attach it to a plain USB or Thunderbolt enclosure, the RST and VMD stack is completely absent. Even if you moved the drive to another Intel machine with a TPM, the PCR profile would not match because the storage controller mode is different. The sealed measurements were taken with VMD/RST in the picture; your new environment has neither. Many users never realize their BIOS storage controller mode is part of the BitLocker trust equation. Now you know.

Why The Recovery Key Doesn’t Work

Here’s the misconception that causes the most panic. Your recovery key isn’t being rejected because it’s the wrong key. The deeper problem is that BitLocker in TPM-only mode never even reaches the stage where it checks the recovery key in a normal boot flow. The TPM unsealing fails first — and in an external enclosure, there’s no TPM at all. BitLocker can fall back to recovery-key mode, but only if the drive’s key protectors actually include a recovery password protector. If BitLocker was configured in TPM-only mode with no recovery password added, you are looking at an encrypted brick. The data is mathematically inaccessible.

This is why Microsoft’s guidance is emphatic: always back up your recovery key. Store it in your Microsoft Account, print it, or escrow it to Active Directory or Azure AD. Every one of those options beats learning this lesson the hard way at 2 a.m.

Pro Tip

Before pulling an NVMe from an encrypted system, run manage-bde -protectors -get D: to review the drive’s protector configuration and PCR profile. Confirm a recovery password protector exists. Then decrypt fully with manage-bde -off D: before removal. Re-encrypt after reinstallation in the new system. That sequence keeps your data safe and accessible every time.

BitLocker’s hardware binding is a feature, not a flaw — and a pretty powerful one. A TPM-sealed VMK means a stolen drive is worthless without the original motherboard’s trust environment. But that same strength makes casual NVMe swaps treacherous if you aren’t prepared. Decrypt before you disconnect. Check your protectors before you assume. And for everything else, learn more about BitLocker recovery options directly from MS before you need ’em.

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

Overhauling WU Orchestrator and Arbiter

Leave a comment

Windows Update (aka WU) has always been something of a “black box.” One clicks “Check for updates,” and watches a progress bar lurch along. At it sticks at various points along the way to completion, one wonders what’s going on inside the PC. The answer comes from two little-known components that handle updates behind the scenes. These are the Windows Update Orchestrator and Arbiter. As MS promises it’s overhauling WU Orchestrator and Arbiter, it’s a good idea to dig in and understand what they are, and what they do. Buckle up! Here we go…

Why Is MS Overhauling WU Orchestrator and Arbiter?

Simply put, the progress bar as it currently works doesn’t do its job. Also, when the update process finishes, post-update cleanups don’t exactly bring Windows up to full performance any time soon. TLDR version: this overhaul intends to address those things, probably in the upcoming August 11 Cumulative Update, due next Patch Tuesday.

What Is the Windows Update Orchestrator?

The Windows Update Orchestrator — formally the Update Orchestrator Service, or UsoSvc — is the scheduling brain of the entire update pipeline. It decides when your PC checks for updates, when downloads begin, and when installation kicks off, all without direct user intervention.

Think of the Orchestrator as an air traffic controller. It coordinates between your active hours, battery and network conditions, and Microsoft’s own delivery servers. When conditions align, it clears the update to land.

The Orchestrator talks to Windows Update’s policy engine, reads Group Policy and MDM settings on managed machines, and queues work for downstream services. It runs quietly in the background, even when you’re not thinking about updates at all. You can see a schematic of this workflow as the lead-in graphic above.

What Does the Arbiter Do?

If the Orchestrator is the scheduler, the Arbiter is the referee (as its cognomen is meant to declare). The Arbiter’s job is to resolve conflicts between competing update requests — for example, when a driver update and a cumulative security patch both want to run at the same time, or when a pending restart faces an active user session.

The Arbiter also decides which updates take priority. It weighs patch criticality, determines if a reboot is already pending, and whether or not the device is on a metered connection. When the Arbiter approves an update, it signals the Orchestrator to proceed. Without that handshake, nothing moves.

Together, the Orchestrator and Arbiter form a tightly coupled scheduling and arbitration layer that sits above the actual download and install services — but below what you see inside Settings.

Why They’ve Frustrated Users for Years

The problem has never been that the Orchestrator and Arbiter do their jobs poorly. Generally, they do not. The problem is that they remain nearly opaque to the progress reporting layer that feeds  Settings. It’s more than a bit of a disconnect, in fact!

For example, you might see the Windows Update progress bar freeze at 0 percent, spike to 74 percent, then crawl back to 12 percent. That odd behavior is not the update failing. It’s the Orchestrator and Arbiter operating normally. Alas, their internal state isn’t accurately mapped to a UI percentage value. The progress bar has essentially been guessing. When it guesses wrong, things jump around. That happens…pretty regularly.

Post-update sluggishness is a related phenom. Once installation completes, Windows leaves temporary staging files, old component-store fragments, and residual update scaffolding behind. It then cleans up lazily over the next few minutes. On lower-powered PCs (the kind that technically meet Windows 11’s TPM 2.0 and CPU requirements but aren’t exactly fast) such cleanup makes some systems feel broken right after reboots.

What Microsoft Is Fixing Right Now

In builds 26200.8968 and 26100.8968 Microsoft has shipped two targeted improvements. These represent the latest Release Preview updates for 25H2 and 24H2, respectively and just appeared last week.

First, progress reporting among the Orchestrator, Arbiter, and the Settings UI is rebuilt. The percentage displayed now reflects actual download and installation state rather than a guesstimate. Going forward, a progress bar that stalls at 45 percent genuinely means the update is 45 percent complete. It’s no longer because the Orchestrator just stopped talking to the UI.

Second, post-install cleanup runs more aggressively at the end of the update cycle rather than spreading work across the next several minutes. Systems should reach full responsiveness faster. This should be a welcome change for anyone who reboots after Patch Tuesday and wonders why things feel sluggish for the next 10 minutes (or more).

When Will Orchestrator and Arbiter Change?

These changes are in Release Preview now and should show up for mainstream Windows 11 users via a Patch Tuesday cumulative update within one to two months. I’m thinking August 11, but it could be September 8, depending on telemetry from these latest Release Preview CUs. MS will hold them back if it needs to tinker some more. Hopefully, it happens sooner, not later.

Neither fix is glamorous, but both address complaints that Windows users have logged for years. A trustworthy progress bar and a snappy post-update experience are not unreasonable expectations for a modern OS. Here in Windows-World, we’ll wait and see how things go. Stay tuned: I’ll keep you posted…

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

PC Manager Browser Space Is Mostly Volatile

Leave a comment

I just ran PC Manager’s Deep Cleanup on my Flo6 desktop. As usual, it cleaned a lot of what it found: 11.4 of 14.6 GB wound up gone. Also, as usual it shows around 3GB remaining for my three browsers — namely, Firefox, Chrome and Edge. So I asked Copilot: why do these programs show up in their numbers? It opines (and I concur) that PC Manager Browser space is mostly volatile. Indeed the figure is kind of illusory. It’s worth understanding before treating browser cache cleanup as a valid way to recover disk space.

Take a look at the final results from my Deep Cleanup just now from the lead-in screencap. Notice that it shows 1 GB for Firefox, 1.6 GB for Chrome and ~277 MB for Edge. Keep those numbers in mind.

Why Say: PC Manager Browser Space Is Mostly Volatile?

Here’s the core issue: browser cache is engineered to be ephemeral. It’s written, read, and purged in a continuous cycle governed by cache-expiry headers, per-origin storage quotas, and the browser’s own self-management routines. The moment you fire up your browser after a cleanup and start clicking around, the cache begins refilling. Within 30 to 60 minutes of ordinary browsing, most browsers will have rebuilt several hundred megabytes of cached content — sometimes more, depending on how media-heavy the sites you visit are.

Chrome and Edge both enforce internal storage quotas and will self-evict stale or low-priority cache entries automatically when those quotas are approached. In other words, the browser is already managing this space on your behalf, without you lifting a finger. Firefox operates similarly under its own quota management framework.

In short: you didn’t “save” 2 GB when you cleared browser cache. You borrowed 2 GB temporarily — until your next browsing session rebuilt most of it. Sort of like the storage equivalent of pushing water uphill.

Check out these numbers: they represent the memory footprint for my three browsers.

Note that those numbers fall near the potential savings that PC Manager reports for each one. That’s no coincidence, it simply represents reclaiming space that the browsers will suck back up as soon as you turn them back on, and open some tabs.

What Real, Valid Savings Look Like

Contrast browser cache with the categories that represent genuinely permanent space recovery. Windows Update cleanup files — the old installer packages and superseded component stores left behind after updates — can run anywhere from 500 MB to 2 GB, and once deleted, they do not return. Windows Error Reporting logs are similarly non-regenerating under normal conditions. The Recycle Bin is obvious. Orphaned app data left behind by software you’ve already uninstalled is another solid target. Thumbnail cache does rebuild, but far more slowly than browser cache, so it offers a more durable short-term gain.

A typical monthly cleanup on a moderately used Windows 10 or 11 machine might yield up to a 5 GB of truly permanent, non-regenerating space. That’s a lot less dramatic than the headline figure PC Manager flashes at you — but it’s real. And it stays real.

Do You Need to Clean Browser Cache?

Maybe, but go into that effort with adjusted expectations. Clearing browser cache could deliver a brief responsiveness improvement. Thus, if the cache has grown bloated with stale or corrupt entries, or to make room in storage-intense scenarios, such as recording a long screen capture session, installing a large application, or freeing up breathing room on a drive that’s genuinely running tight. Otherwise, don’t expect much either in the short or long term.

If you’re truly short on disk space, PC Manager’s Large Files finder and the Windows Update Files cleanup row are far more useful targets. The browser cache, left alone, will look after itself. That’s the point!

Here in Windows-World keeping things clean does have its reward. But some things are more worth cleaning up than others. Browser cache is near the end of that list, and best left alone.

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

Jumping WinGet’s Install Technology Hurdle

2 Comments

Wow! It’s hard to believe that WinGet has been around for over 6 years now (it made its debut on 5/19/2020). Over those years I’ve seen the upgrade block shown in the lead-in graphic many times. I’ve also learned to deal with it in more roundabout ways. Let me call this jumping WinGet’s install technology hurdle, so I can explain one particular technique worth investigating.

What Jumping WinGet’s Install Technology Hurdle Means

The text at the head of the screen cap recommends “Uninstall each package, then install the newer version.” This will work if there’s no other way. But if — as you can see is the case with Oh My Posh (OMP) — there’s an internal update mechanism, this often works just fine without requiring wholesale removal (uninstall old version) and replacement (install new one).

Indeed, it just so happens that OMP will happily update itself at the command line using the built-in command

oh-my-posh upgrade --force

So that’s what I did instead of running one WinGet command to remove the old package, and another to install the new one. This situation pops up when WinGet detects that a normal upgrade is not feasible. It blocks upgrades whenever the install technology changes from one release to the next. That’s how it avoids potential problems with the package and its supporting infrastructure that might otherwise occur.

But the teams who develop such packages know their inner workings. They can (and often do) support such upgrades because they understand how to hand off from the older install technology to the newer one. When I run into this situation, I look for a built-in update mechanism in the package (or its related app) itself. It will often jump the hurdle for me, and let me keep using WinGet thereafter. Indeed, I’ve done this myself with Adobe Acrobat too. Furthermore, GitHub documents similar cases with MS Edge, PowerShell 7, Oracle VirtualBox, LocalSend, and other packages as well.

But Wait…There’s More!

Even after I got to the latest version, I found a couple of older versions of OMP also installed. Ultimately, I DID have to uninstall those to make them go away. That’s because OMP lets multiple versions run in parallel. This time, I used msiexec and the GUIDS (for the no-longer-wanted versions) for that purpose

msiexec /x "{97557535-43B6-44EF-BA97-86563C1AC80A}"
msiexec /x "{85B43182-5A11-40E5-9E09-7EF6EB1CFDF7}"

Now, I’ve got just the one (updated) version and a clean Oh-My-Posh setup. Here in Windows-World, it’s always something. Thank goodness that Copilot was able to help me steer through the wreckage, and clean up the older versions properly. Now I see only the latest version when I run winget list, and OMP is working as it should be. AND I solved a problem I didn’t know I had. Good-oh!

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness