Category Archives: Insider stuff

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

Oh My Posh Shows Real ARM vs x64 Differences

Leave a comment

Following the Oh My Posh documentation, I recently ran oh-my-posh font list on my ASUS Zenbook A14 . It’s a Qualcomm Snapdragon X Elite ARM64 machine running Windows 11. The result? Nothing. No output, no error, no interactive list, just a blinking cursor that eventually handed the prompt back to me. That same command works beautifully on all my x64 PCs and laptops. Thus, Oh My Posh  shows real ARM vs x64 differences. Indeed, this sent me down a rabbit hole to figure out what OMP’s font subsystem does under the hood.

How Oh My Posh Shows Real ARM vs x64 Differences

When you run oh-my-posh font list on a working x64 machine, you get a list of available Nerd Fonts pulled live from GitHub. You can scroll that list, select a font, and it copies the name into the paste buffer for subsequent re-use. It’s helpful.

On my ARM64 Zenbook, none of that renders. The command exits silently. No crash, no error code, no partial output. That silence is itself a clue.

Inside the Oh-My-Posh Font Subsystem

OMP is written entirely in Go, and its font subsystem layers several platform-specific APIs and third-party frameworks. Understanding what those are and how they work explains why ARM64 falls short.

The first dependency is Bubble Tea a terminal oriented display and interaction UI. OMP’s font commands use Bubble Tea’s program model to launch, render, and manage the font list. Bubble Tea drives the terminal via ANSI/VT escape sequences and calls into Go’s golang.org/x/term package to manipulate terminal raw mode. On x64 Windows, Windows Terminal’s VT rendering pipeline handles these sequences without issue. On ARM64, subtle gaps in how the ARM64 console host processes certain VT sequences — particularly around alternate screen buffers and raw-mode toggling — can cause Bubble Tea’s rendering loop to fail before it draws a single line.

The second dependency is a live HTTPS call to the Nerd Fonts GitHub Releases API, which is how OMP fetches the current font list. This call goes out over Go’s standard net/http TLS stack. On ARM64, Go’s TLS implementation compiles natively, but the ARM64 binary links against a slightly different set of system crypto libraries. If that HTTP call fails silently, owing to a timeout, a TLS handshake hiccup, or a missing response, Bubble Tea never receives the data it needs to populate the list, and the program exits with nothing to show.

The third set of dependencies covers font installation: GDI32’s AddFontResourceW function (called via Go’s syscall and unsafe packages), Windows Registry writes through golang.org/x/sys/windows/registry, and a PostMessageW broadcast carrying WM_FONTCHANGE to notify the shell that new fonts are registered. These are the plumbing that oh-my-posh font install uses after the list is displayed. They are less relevant to the silent-exit problem, but they represent additional surfaces where ARM64’s native API behavior diverges from x64.

Where ARM Falls Down (or Out)

The core issue is that OMP’s font tooling was developed and battle-tested on x64 Windows. The Bubble Tea TUI path, the live GitHub fetch, and the GDI32 font registration flow all work reliably there. ARM64 Windows is a native platform now — not emulation — but the console host, terminal rendering, and system library behavior still carry edge cases that x64 does not.

Bubble Tea’s dependency on terminal raw mode and VT escape handling is especially fragile on ARM64 because Windows Terminal’s ARM64 build has historically lagged behind x64 in VT conformance. A Bubble Tea program that initializes correctly on x64 can silently short-circuit on ARM64 if golang.org/x/term‘s raw-mode call returns an unexpected result, causing the event loop to spin zero times and exit.

The irony is that OMP itself — the prompt rendering engine — works great on ARM64. The font management tooling sits on a different, more complex stack, and that stack exposes the seam between x64-matured tooling and an ARM64 Windows environment that is still catching up.

Takeaways for ARM Users

If you hit silent output from oh-my-posh font list on an ARM64 Windows machine, you now know it is not user error. It’s a real platform gap rooted in Bubble Tea TUI compatibility, live HTTP fetching, and ARM64 console API edge cases. The workaround for the moment is to install Nerd Fonts the old-fashioned way: grab the zip directly from the Nerd Fonts GitHub releases page and drop the TTF files into your user fonts folder manually. It’s not as elegant as OMP’s interactive installer, but it gets the job done.

This kind of difference is exactly why I find ARM Windows fascinating. The platform is capable, but it still surfaces small, instructive wrinkles like this one. Though I’ve seen nothing to make me question my investment in ARM hardware, oh-my-posh font list returning nothing is about as vivid a demonstration as I have seen of possible impacts of platform differences. That’s a thing worth watching out for, here in Windows-World.

Note: Only newer OMP versions (30.X.X) and higher support the font list capability. If you’re run the bog standard version on x64 (v29.0.2) you won’t see it, either. Winget should get the latest version (30.6.5) into its pipeline soon, after which you can see it, too. On the right kind of PC, anyway…

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

The Incredibly Bogus MSI BIOS Update

1 Comment

Windows Update pinged me yesterday, August 18, with a firmware notification: my MSI motherboard had a BIOS update available. My reaction was less “Great, let me install that…” and more “Wait! I just did.” The week before, I’d downloaded MSI’s latest BIOS package, copied it to a FAT32 USB drive, booted into MSI’s M-Flash utility, and flashed the thing the old-fashioned way. It worked perfectly. So why was Windows Update acting like none of that had ever happened? Thereby hangs the tale of the incredibly bogus MSI BIOS update. Here goes…

Hunting Down the Bogus MSI BIOS Update

The “bogus” here isn’t the update itself. Indeed, Windows Update found it and sought to deliver it. What was bogus was any awareness on WU’s part that I’d already installed it. When I flashed the BIOS using MSI’s UFD-based utility, that transaction happened entirely outside of Windows. No registry entry. Windows Update history records missing. No UEFI firmware capsule delivery for WU to track. As far as Windows Update was concerned, the update had never been applied, and it was doing its best to make sure I got it.

I confirmed the BIOS version in the UEFI settings. Indeed, it matched the version WU was offering. I checked Windows Update history: no entry for the flash, naturally. Optional updates, Driver updates: WU really wanted me to install this update. So I did, and of course it failed because MSI is smart enough to refuse a second install of the same UEFI version (I’ve had this happen on Lenovo PCs/laptops as well).

WU Remains Oblivious to OOB BIOS Updates

Windows Update tracks firmware updates it delivers itself. Typically, they come via UEFI firmware capsule updates. Those hand off to the firmware installer, and WU records the update in its history database. When you flash a BIOS using a manufacturer’s standalone tool (e.g. MSI’s M-Flash, a DOS-based utility, or a UFD flash from UEFI) Windows is completely out of the loop. There’s no handshake, no callback, no “hey, Ed already did this” signal.

The result: WU sees the target BIOS version, compares it against its own records (which show nothing). It concludes the update is needed. It’s not wrong, exactly. It just doesn’t know what it doesn’t know. And because the update failed anyway (I couldn’t figure out how to kill the pending item before it was applied, even with Copilot’s help) it appeared every time I checked updates in WU.

Until I hid the update it kept trying and failing to install after a mandatory restart. Vexatious!

PSWindowsUpdate Hides the Bogus Offer

For this case, the solution wasn’t to install the update again. Reflashing a BIOS that’s already current is unnecessary and might cause problems. The goal was to tell Windows Update, in terms it would respect, to quit offering that item. That’s a job for the PSWindowsUpdate module from the PowerShell Gallery.

I imported the module, enumerated all pending updates to confirm the BIOS entry was there, and then hid it. The complete sequence is in the lead-in graphic, but here it is in text form for easy access (info following # is purely descriptive and need not be entered):


Import-Module PSWindowsUpdate #Invokes PSWU cmdlet set
Get-WindowsUpdate -MicrosoftUpdate #Calls WU for upd chk
Hide-WindowsUpdate -Title "Micro-Star..." #Hides MSI upd

You can use the Title or the KB number for an update to block it. Then you can use the Get-WindowsUpdate -MicrosoftUpdate -IsHidden cmdlet to show you if your efforts succeeded.

Problem Solved, Mostly

After running Hide-WindowsUpdate, Windows Update stopped flagging the firmware update. No more notifications, no more badge on the WU icon, no more politely worded insistence that I was a BIOS version behind. A quick recheck of Get-WindowsUpdate showed a clean list.

One thing: hiding an update using PSWindowsUpdate is reversible. You can unhide it later with Show-WindowsUpdate if you ever want WU to see it again. And if you’re in the opposite situation (WU is offering a BIOS you genuinely haven’t installed), the Install-WindowsUpdate cmdlet handles that well. Either way, PSWindowsUpdate gives you control that the standard WU interface simply doesn’t.

Here in Windows-World, it’s always something. This time, it was a weird and unwanted BIOS update. Whatever it may be next time, count on me to tell you about it, and how to work with, through, or around it as circumstances might require. Cheers!

Facebooklinkedin
Facebooklinkedin
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

Insider stuff, PowerShell, Secure Boot, WED Blog, Windows 11

Updating Outdated Win11 Boot Media

Leave a comment

There’s a scenario that may feel familiar to plenty of Windows power users and IT admins. You’ve got a USB flash drive, aka UFD, sitting on your desk. You carefully imaged it months ago using MCT, or a backup too, or Rufus, or whatever. It booted perfectly, it installed or ran cleanly, and life was good. Fast forward to today: alas, that once-trusty UFD is probably out of date. In fact, if you try to boot using that UFD, you may get a “Secure Boot Violation” error message from UEFI and nothing more. That’s why updating outdated Win11 boot media is a real maintenance item, especially after Patch Tuesday rolls through and reshuffles key files inside the Windows boot chain.

Why bother? Because Patch Tuesday updates don’t just patch the running OS on your machines. They also advance critical files that get embedded in installation media — things like Secure Boot policy manifests, component catalogs, and EFI boot binaries. Hence, a UFD built on a pre-patch image may carry stale versions of those files. Indeed, subtle boot-time validation mismatches are possible. Worse, your installation media might silently enforce an older policy against a fully updated target system.

In this post, I’ll walk through exactly what changes, which files on your UFD need attention, and explain how to make things current, step by step. Spoiler alert: I also advise against such repairs unless they’re absolutely necessary. It’s much easier to generate fresh boot media than to repair outdated UFDs.

Why Updating Outdated Win11 Boot Media Matters

One might think of Patch Tuesday as a monthly ritual that involves rebooting workstations and crossing your fingers that nothing breaks. Fair enough. However, other side effects come from updates. That is, they reach inside the Windows installation ecosystem and bump version numbers on files that govern how setup media validates and boots a system.

The most relevant example for this post, and the primary driver for updating outdated Win11 boot media right now, is SkuSiPolicy.p7b. The most recent Patch Tuesday advanced this file from version 3.0.0.16 to version 3.0.0.17. That’s a tiny increment, but carries real significance.

So, what exactly does SkuSiPolicy.p7b do? In short, it’s a Secure Boot SKU policy file. It governs which Windows editions (SKUs =Home, Pro, Enterprise, Education, and so on) that Secure Boot views as trusted and bootable.

When the running OS expects version 3.0.0.17 and your UFD’s boot chain presents version 3.0.0.16, you get validation mismatches. Those mismatches may not always produce a hard error, but they represent a policy drift you don’t want living in your production boot media. Worst case: no boot with the dread “Secure Boot Violation” error message showing (see my August 4 post for an illustration).

Bottom line: whenever SkuSiPolicy.p7b advances, it’s time to audit your UFDs. You may also end up having to update or replace/regenerate them.

Possible UFD Deltas After Patch Tuesday

Here’s the thing: SkuSiPolicy.p7b doesn’t live in just one place on your UFD. It lives in multiple places. Some are obvious, others live inside image files. Plus, other boot-chain components may also need refreshing. The following table lays out that landscape, where the numbered list that follows briefly explains each item.

UFD Component Location on UFD Affected by SkuSiPolicy Bump? Action Required
SkuSiPolicy.p7b \sources\ Yes — primary location Replace with updated version
boot.wim \sources\ Yes — embedded in index:2 Mount, update, unmount/commit
install.wim / install.esd \sources\ Yes — per-edition indexes Mount each index, update, commit
efisys.bin / efisys_noprompt.bin \boot\ Occasionally Replace if ISO version is newer
bootmgr.efi / bootx64.efi \efi\boot\ or \boot\ Occasionally Replace if ISO version is newer
cdboot.efi \boot\ Rarely Check version; replace if needed
winpe.wim / WinRE.wim Varies (recovery partition) Yes — if recovery env. included Mount, update, commit

Working through the List

Now let’s go through each item in the same order as the table:

  1. p7b (\sources\SkuSiPolicy.p7b on the UFD): This is the standalone Secure Boot SKU policy file that Windows Setup reads directly during the installation process. As noted, this file advanced from version 3.0.0.16 to 3.0.0.17 on the most recent Patch Tuesday. This is the clearest, most unambiguous indicator that your boot media needs updating or replacing. You must replace it with the current version, which you can extract from a freshly downloaded Windows 11 ISO or from a mounted updated WinPE image.
  2. wim (\sources\boot.wim): This is the WinPE and Windows Setup environment image. It contains two indexes: index:1 is the minimal WinPE environment (the initial RAM disk boot stage), and index:2 is the full Windows Setup environment. Both indexes embed their own copy of SkuSiPolicy.p7b inside \Windows\System32\. Index:2, in particular, participates in Secure Boot policy enforcement during setup and therefore should be updated. Index:1 is discussed separately later in this post.
  3. wim / install.esd (\sources\install.wim or \sources\install.esd): This is the main OS image that actually gets deployed to the target drive. Each edition index (Home, Pro, Enterprise, etc.) embeds its own copy of SkuSiPolicy.p7b inside \Windows\System32\ within the image. Therefore, each applicable index needs to be individually mounted and updated. Note that install.esd files are compressed and cannot be mounted directly — they must first be converted to install.wim format using DISM’s /Export-Image with /Compress:none before mounting.
  4. bin / efisys_noprompt.bin (\boot\ folder): These are EFI boot sector binary files. They are not directly version-stamped by SkuSiPolicy.p7b changes; however, when a cumulative update also updates the broader boot chain, newer versions of these files may ship in the refreshed ISO. Consequently, it’s worth doing a file-date comparison between your UFD’s copies and those in the freshly downloaded ISO.
  5. efi / bootx64.efi (\efi\boot\ or \boot\ folder): The EFI boot manager binaries. The same considerations apply as for efisys.bin: they don’t change with every Patch Tuesday, but when they do advance, you’ll want the fresh copies on your UFD. Always compare versions against a current ISO before deciding whether to replace.
  6. efi: This EFI binary handles optical-media boot paths. If your UFD was created from an ISO (as most are), this file is present. It is, however, less commonly updated than the other EFI binaries. Worth checking, but don’t lose sleep over it.
  7. wim / WinRE.wim — If your UFD includes a Windows Recovery Environment, that image also embeds SkuSiPolicy.p7b. The update workflow is identical to the boot.wim process: mount the image, overwrite the policy file inside \Windows\System32\, commit, and unmount.
Note

Not all of these components will change with every Patch Tuesday. The SkuSiPolicy.p7b version bump is your clearest indicator that a media refresh is warranted. On August 11, for example, the version jumped from 3.0.0.16 to 3.0.0.17. OTOH, EFI binaries may remain unchanged over several update cycles.

How to Update Each Affected UFD Item

Alright — here’s where we roll up our sleeves. The process is methodical, but it’s not complicated. Follow these steps in order, and you’ll have a fully refreshed UFD by the time you’re done.

Step 1: Gather Your Prerequisites

Before you touch any files, have the following at your disposal:

  • DISM — Built into Windows 10 and Windows 11. No additional download required. Run all commands from an elevated command prompt (right-click > Run as administrator). You MUST run powershell.exe (version 5.1) not PowerShell 7 (the app, or from inside Windows Terminal). Why? Because the DISM wim mount commands don’t work inside the newer PS version.
  • A fresh Windows 11 ISO — Download the current release directly from Microsoft’s Media Creation Tool at com/software-download/windows11, or from MSDN/VLSC if you have a volume license subscription. Do not use an ISO that’s more than a few weeks old — the whole point is to work from a current image.
  • Sufficient disk space — Mounting WIM images requires working space. Budget at least 15–20 GB on your working drive (typically C:\) for mount directories, working copies, and temp files.
  • A writable UFD — Sounds obvious, but double-check that your UFD’s write-protect switch (if it has one) is off. I’ve also learned the hard way that some UFDs work when building Secure Boot compliant media, and others don’t. If you get stuck, try switching to a faster, newer name brand device (I’ve had good luck with never Kington Data Travelers recently, for example).
  • Ownership and permissions — Some protected files on the UFD or within mounted images may require you to take ownership before overwriting them. We’ll cover that in detail in tomorrow’s post. It’s kind of a doozy!

Step 2: Extract the Updated SkuSiPolicy.p7b from the Fresh ISO

Mount the fresh ISO in Windows Explorer (double-click the ISO file — Windows will mount it as a virtual drive, typically D:\). Then, navigate to D:\sources\ and copy SkuSiPolicy.p7b to a working folder on your local drive. For example:

mkdir C:\work copy D:\sources\SkuSiPolicy.p7b C:\work\SkuSiPolicy.p7b

This extracted file is your authoritative source for all subsequent update steps. Keep it handy — you’ll be copying it into several locations.

Step 3: Update the Standalone SkuSiPolicy.p7b on the UFD

This is the simplest step. Simply overwrite the existing file in \sources\ on your UFD. Assuming your UFD is drive E:\:

copy /Y C:\work\SkuSiPolicy.p7b E:\sources\SkuSiPolicy.p7b

The /Y flag suppresses the overwrite confirmation prompt. Done. One location down, several to go.

Step 4: Update boot.wim (Index:2 — Windows Setup)

This requires DISM to mount the image, copy in the updated policy file, and then commit the changes on unmount. First, create your mount directory:

mkdir C:\mount\boot

Then, mount index:2 of boot.wim from your UFD:

Dism /Mount-Image /ImageFile:”E:\sources\boot.wim” /Index:2 /MountDir:”C:\mount\boot”

Next, copy the updated SkuSiPolicy.p7b into the mounted image’s \Windows\System32\ folder:

copy /Y “C:\work\SkuSiPolicy.p7b” “C:\mount\boot\Windows\System32\SkuSiPolicy.p7b”

Finally, commit and unmount:

Dism /Unmount-Image /MountDir:”C:\mount\boot” /Commit

Warning

Never terminate a DISM mount session midway. If your session is interrupted (e.g. power loss, unexpected reboot) use Dism /Cleanup-Mountpoints to recover before attempting to remount. Partially committed mounts can corrupt your WIM.

Step 5: Update install.wim (Each Edition Index)

The install.wim (or install.esd) update is the most time-consuming step, because you need to process each edition index individually. Start by listing the available indexes:

Dism /Get-ImageInfo /ImageFile:”E:\sources\install.wim”

This will show you something like Index 1 = Home, Index 2 = Home N, Index 3 = Pro, Index 4 = Pro N, and so on — depending on which edition set your ISO contains. For each index you wish to update, repeat the mount-copy-commit workflow:

mkdir C:\mount\install  REM — Example for Index 3 (Pro): Dism /Mount-Image /ImageFile:”E:\sources\install.wim” /Index:3 /MountDir:”C:\mount\install” copy /Y “C:\work\SkuSiPolicy.p7b” “C:\mount\install\Windows\System32\SkuSiPolicy.p7b” Dism /Unmount-Image /MountDir:”C:\mount\install” /Commit

Repeat for each index. It’s tedious, admittedly — but it’s the thorough approach.

A note on install.esd: If your UFD uses install.esd rather than install.wim, you cannot mount it directly. Therefore, you must first export it to an uncompressed WIM:

Dism /Export-Image /SourceImageFile:”E:\sources\install.esd” /SourceIndex:1 /DestinationImageFile:”C:\work\install.wim” /Compress:none

Repeat the export for each index you need to update, then mount, update, and commit the resulting install.wim. When finished, copy the updated WIM back to your UFD (replacing the original ESD, or alongside it as a WIM if your media configuration supports that).

Step 6: Replace EFI Binaries (If Newer Versions Exist in the ISO)

Compare the file dates on the following pairs — ISO source vs. UFD destination — and replace only if the ISO version is newer:

  • D:\boot\efisys.bin → E:\boot\efisys.bin
  • D:\boot\efisys_noprompt.bin → E:\boot\efisys_noprompt.bin
  • D:\efi\boot\bootx64.efi → E:\efi\boot\bootx64.efi
  • D:\boot\bootmgr.efi → E:\boot\bootmgr.efi

If the ISO’s copies are dated more recently, copy them over. If they match, leave your UFD copies alone — there’s no point in replacing identical files.

Garlin’s check_bootmedia Reports a Non-Problem

Here’s the thing: if you run the check_bootmedia script — a tool from Garlin’s GitHub repo that inspects boot media for version consistency across boot-related files — you may encounter a flag that looks alarming at first glance in your freshly-updated UFD. Specifically, the script reports that boot.wim’s index:1 (the base WinPE environment) contains an older version of SkuSiPolicy.p7b than at index:2 (the Windows Setup environment) after you’ve completed Step 4 above. You can see its output for my updated UFD (Drive I:) in the lead-in graphic for this blog post.

Take a breath. This does not actually represent a real problem. Indeed, this UFD booted right into the Windows 11 installer (as it should). Here’s why the info may look scary, but isn’t:

  • What index:1 actually does: Index:1 in wim is the minimal WinPE environment — the initial RAM disk stage that loads just enough of an operating environment to hand control over to the Windows Setup process. It is responsible for loading drivers, initializing hardware, and presenting the early pre-Setup UI. It does not participate in Secure Boot SKU policy enforcement during a normal Windows installation.
  • Where SKU policy enforcement actually happens: The actual Secure Boot SKU policy enforcement — the part that p7b governs — occurs at the OS loader level. That means it relies on index:2 of boot.wim and the standalone \sources\SkuSiPolicy.p7b on your UFD. Both of those, as a result of Steps 2–4 above, are now current.
  • Why check_bootmedia flags it anyway: The script is thorough — admirably so. It compares p7b versions across all image indexes and the standalone sources copy, and reports any mismatch it finds. For completeness and consistency-checking purposes, that’s the right behavior. However, in practice, having an older SkuSiPolicy.p7b sitting inside index:1 of boot.wim creates no functional issue whatsoever during a Windows installation.
  • Can you update index:1 anyway? Yes, absolutely — and if strict consistency is important to you (perhaps for audit or compliance reasons), go ahead. Use the same DISM mount/update/commit workflow with /Index:1 instead of /Index:2. It won’t hurt anything.
Bottom Line

If check_bootmedia is the only tool reporting a version discrepancy, and the discrepancy is limited to boot.wim index:1, you can safely disregard that flag. Your media is functionally correct. The flag is informational — a cosmetic inconsistency, not a real-world boot problem. I had that situation pop up on a test UFD, and it booted into the Windows 11 Installer just fine (no Secure Boot issues presented).

Wrapping Up: Key Takeaways

Let’s bring it all home. If you’ve made it this far, you now have a solid handle on why updating outdated Win11 boot media matters, what files are involved, and fixed involved. Here’s the condensed version for your notes:

  • Patch Tuesday can advance p7b and other boot-chain files. The most recent update bumped SkuSiPolicy.p7b from version 3.0.0.16 to 3.0.0.17. That’s your cue to refresh your UFDs.
  • Multiple UFD locations are affected, not just \sources\. The policy file is embedded inside wim (index:2), inside each edition index of install.wim, and potentially inside recovery environment images as well. All those locations need fixing for a complete update.
  • The Garlin check_bootmedia flag for wim index:1 is interesting, not definitive. Index:1 doesn’t enforce Secure Boot SKU policy during Windows installation. You can update it for strict consistency, but it is absolutely not required for correct boot media behavior.
  • EFI binaries deserve a version check, not an automatic replacement. Compare bin, bootmgr.efi, and bootx64.efi from your UFD versus a fresh ISO; replace only if the ISO copies are newer.
  • Tomorrow’s post covers ownership and permissions for protected files. For good reason, MS goes out of its way to protect boot files and images. Thus, there are certain steps you must take before you can overwrite system-owned files inside mounted WIM images. Stay tuned: I’m writing a whole ‘nother post on this topic. Again: it’s a doozy, and taught me more about ICACLS than I ever wanted to know.
  • Keeping boot media current is a best practice for Windows IT admins and power users. Stale media isn’t just a minor annoyance — it’s a policy gap. A few DISM commands and twenty minutes of your time is all it takes to close it.

Ask Yourself: Is Repair Really Needed?

Determining repairs took me the better part of day, and then getting things fixed in Windows 11 installation media for the SkuSiPolicy version bump. I could’ve simply grabbed a fresh Media Creation Tool (MCT) from the download Windows 11 page, and built a new UFD in under an hour.

Now that I’ve been through this ordeal, I’ve learned a valuable lesson. Don’t fix a boot media UFD unless you absolutely must. If you can regenerate a fresh, new updated one, do that instead. It’s faster and much, much easier that way. Here in Windows-World, going the long way around sometimes underscores the value and importance of workable shortcuts. My advice: take this shortcut, if you can. Otherwise, you’ll spend real time going the long way!

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

Where’s My WIMMount?

Leave a comment

There I was on my primary desktop Flo6, running what should have been the most unremarkable task in a Windows admin’s day: mounting a WIM image offline with DISM. The command ran. Nothing blew up dramatically. It just… sat there, and did nothing. No cryptic error code, no helpful message, and zero indication of what went sideways. Welcome to the world of WIMMount driver missing DISM failures — where the tool you depend on vanishes without so much as a farewell note. Hence the question: “Where’s my WIMMount?”

DISM mount failures are maddening precisely because they leave no obvious breadcrumbs. You stare at the console, you re-read the command three times over, and everything looks good. Spoiler: the problem isn’t syntax. It’s something deeper and darker. Let me explain…

“Nowhere” Answers “Where’s my WIMMount?”

WIMMount, aka winmount.sys, is kernel-mode filter driver. Windows uses it to mount WIM (Windows IMaging format) files as virtual volumes. It’s the plumbing behind the scenes that works with DISM to let you mount, unmount and operate on images to inspect them, analyze them, or change them. Indeed the driver does the heavy lifting with images at the file system level.

Without WIMMount, mount operations fail with errors like 0x8007007b (“filename, directory name, or volume label syntax is incorrect”) or 0x80070002 (“system cannot find the file specified”). Neither error message tells you “hey, your kernel driver is gone,” which is half the problem. The driver ships both with the Windows ADK (Assessment and Deployment Kit) and, on most builds, inside Windows itself.

Diagnosing the Problem on Flo6

My first instinct was stale mount points. I’ve been burned by those before. So I ran DISM /Cleanup-Mountpoints from an elevated prompt. No joy — it completed cleanly and changed nothing.

Next stop: component store health. Running DISM /Online /Cleanup-Image /ScanHealth returned errors suggesting corruption in the component store itself. Interesting, but not yet the smoking gun.

Then I ran the command that cracked the case open: sc query wimmount. The response was interesting: a big fat nothing. Further investigation showed the service existed nowhere.  Indeed, the WIMMount driver was entirely absent from Flo6. Not stopped. Not disabled. Gone. A quick peek at HKLM\SYSTEM\CurrentControlSet\Services\WIMMount in the registry confirmed it: the key didn’t exist. No driver, no service, no mount. Mystery illuminated, though the hard work still lay ahead.

Repair Attempts — What I Tried

First, I reinstalled the Windows ADK, hoping that would drop wimmount.sys back into place. Setup completed without complaint. But running sc query wimmount again afterward returned the null response. The binary was still missing from C:\Windows\System32\drivers\.

I got creative and tried manually registering a service entry: sc create wimmount binPath= "C:\Windows\System32\drivers\
wimmount.sys" type= kernel. The service record was created, but starting it threw error 2 — “The system cannot find the file specified” — because the .sys binary itself was nowhere on disk. You can’t register a ghost.

I ran SFC /scannow, which found and repaired a handful of files. DISM was not one of them; wimmount.sys apparently isn’t tracked by Windows File Protection on this build. I then tried DISM /Online /Cleanup-Image /RestoreHealth — it ran to completion but didn’t restore the missing driver either. The conclusion was unavoidable: the driver binary and its registry entries had been removed or never correctly installed, perhaps a casualty of a failed or partial ADK setup, or an aggressive third-party cleanup utility that decided wimmount.sys looked expendable.

Ultima Ratio Regum: Windows Reinstall

At this point the path forward became clear, if a little painful. With the WIMMount binary missing, no repair tool (e.g. ADK reinstall, SFC, or DISM RestoreHealth) would bring it back. The component store itself must have been partially corrupt, which ruled out any confidence in an in-place repair of individual files.

I went with an in-place upgrade repair install to preserve apps and data. I used Settings > System > Recovery > Reinstall Windows. After the reinstall, I ran sc query wimmount immediately — STATE: STOPPED. DISM mount commands worked on the first try (and STATE changed to RUNNING). The entire diagnostic-and-repair saga, start to finish, consumed the better part of a day that a reinstall would have resolved in under an hour.

Lesson learned, yet again: when a kernel-mode driver disappears entirely from the system, a reinstall is almost always faster than hunting down a manual fix. The math rarely favors the manual route.

If your DISM mount commands start failing and you can’t figure out why, make sc query wimmount the second command you run. Like, immediately after the obvious syntax check. Ruling out a missing WIMMount driver takes fifteen seconds and can save you hours of chasing component-store rabbit holes. wimmount.sys is a small but essential cog in the DISM machinery. When it’s gone, DISM mount abilities suffer, too.

Here in Windows-World, the little things sometimes matter a lot. This was one of those times. I’m glad to have survived!

 

Facebooklinkedin
Facebooklinkedin
Hyper-V and VMs, Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11

The Dog Ate My Boot UFD

Leave a comment

I’ve been trying to document how to repair recovery media when MS updates its VBS boot policy (as happened with Tuesday’s updates). Instead I’ve been fighting with UFD oddities that keep me from making the changes I need to bring them into line with said new policy. I’m feeling flustered and flabbergasted by an improbable series of setbacks, which is why I’m saying “The dog ate my UFD.” Honest: it kind of did.

Digging Into Why the Dog Ate My Boot UFD

As it turns out, the first setback was Smart App Control (SAC). It’s a Windows 11 security feature that evaluates application reputation through Microsoft’s cloud-based Intelligent Security Graph before allowing anything to run. When I tried to mount an image using DISM, it kept citing a permission block. Media checks showed no blocks, so it turned into a “whack-a-policy” hunt.

Long story short: my research suggested that turning SAC off might fix things. Alas, it didn’t help my problem. So I had to keep looking.

Next Suspect: HVCI

Once I worked around SAC (more on that in a moment), I ran into obstacle number two: HVCI, which stands for Hypervisor-Enforced Code Integrity. Microsoft also calls it Memory Integrity, and you’ll find it under Windows Security > Device Security > Core Isolation. HVCI runs kernel-mode code verification inside an isolated Virtualization-Based Security (VBS) enclave. It’s essentially a walled-off compartment that the rest of the OS can’t touch. On Flo6, HVCI was enabled by default, which is typical in most new Windows 11 installs.

Here’s the rub: many bootable UFD environments load kernel-mode drivers that predate HVCI’s signing requirements.  That goes double for older Windows PE (Preinstallation Environment) images. When HVCI sees a driver it doesn’t recognize or trust, it rejects it. The UFD boot process stalls or silently falls back to the local drive. This is by design, not a bug (I keep telling myself that). Unfortunately, that design choice has zero sympathy for the guy who just wants to test a drive image before his second cup of coffee.

Turning it off didn’t help things, either. So I’ve still got a problem, and must keep looking for the cause. Sigh.

Still No Joy…

I still need to mount a windows image (.wim) file so I can fiddle with its bits to make it current. But first, I have to figure out how (or possibly, where) to make this happen. It comes in service of a story to document how to repair or replace outmoded UFD’s for repair, recovery, restoring backups, and so forth. That’s important stuff, but it’s not surrendering its secrets easily.

I wish I knew exactly what I needed to do. I’m still figuring it out. Since I’ve not succeeded yet, consider this an interim status report. Here in Windows-World, an inordinate amount of head-scratching is sometimes required to fix things.

Stay tuned! When I do get it sorted, I’ll post again here. It’s a fascinating fix hunt, but I’ll be glad to get to the end of this road.

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

Pending Update Hangs WinGet

Leave a comment

Yesterday was Patch Tuesday (Aug 11), so I got a change to watch something go down I’d  not yet seen. Just before lunch, I fired off a quick winget upgrade --all --include-unknown. I figured it would chew through those updates in time for me to switch to sandwich construction. Wrong! Instead, WinGet got stuck and sat frozen, spinning its wheels on a package install. Only slowly did it dawn on me I’d just gone through the monthly update cycle. Further inspection showed … sure enough … a pending update hangs WinGet (or rather, a pending restart from said update gums up the works). Let me explain…

Why Pending Update Hangs WinGet

The most common culprit is a prior installation that never cleanly resolved or completed. Windows Package Manager tracks install state in its internal database, and if a previous run was interrupted (by a power cut, forced close, network drop, etc.) that package can stay flagged as “installing” or “pending.” As a result, subsequent upgrade attempts collide with that ghost state and stall out.

In addition, App Installer (Microsoft.DesktopAppInstaller) itself may be out of date. WinGet is delivered as part of App Installer via the Microsoft Store, and an outdated build can exhibit hang behavior. That goes double after a major Windows update reshuffles underlying framework dependencies. Therefore, ruling out a stale WinGet client is always step one before you go deeper.

Source index staleness is another common trigger. WinGet pulls its package catalog from indexed sources. When those indexes go stale or become partially corrupted, upgrade queries can time out or loop indefinitely. Finally, UAC and permission conflicts can silently block the installer process. This happens mostly often if you’re running without elevation or if a previous elevated session left a lock on a staging directory. Watch for exit code 0x8A15000F (installer still running). That’s Windows Package Manager’s way of telling you it thinks something is already in flight. (See the WinGet exit codes reference for deets.)

What happened to me yesterday was that the pending restart left some unresolved packages in limbo, including the AppInstaller itself. A quick restart took care of those gotchas, and allowed WinGet to do its thing unimpeded.

Fixing a WinGet Pending Update Hang

Work through these fixes in order. Each one resolves a progressively deeper layer of the problem, so start at the top and stop as soon as WinGet is moving again.


winget upgrade --all --include-unknown
winget source update
Install-PackageProvider -Name NuGet -Force Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery Repair-WinGetPackageManager -Force -Latest
winget upgrade --id --silent
winget source reset --force

And, of course, if it’s Patch Tuesday, or some kind of Windows Update has been applied recently, check for an restart notification first. If one is pending, get it out of the way. That’ll keep it out of WinGet’s way, too. Here in Windows-World, it never pays to overlook the obvious. Cheers!

Tip: Check the Logs
When a hang is stubborn, the logs will tell you exactly where the process is choking. Run winget --info to find your log directory, or navigate directly to:
%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_
8wekyb3d8bbwe\LocalState\DiagOutputDir (reassemble onto single line to cut'n'paste, or do like me and point Everything at DiagOutputDir).
You can also append --logs or --verbose-logs to any WinGet command to capture a full diagnostic trace of that specific run.

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

OneDrive Photos Proves Elusive

Leave a comment

Given the considerable flap that’s erupted online about MS dropping a OneDrive Photos app willy-nilly on Windows PCs recently, I’m having trouble finding same. Indeed, on the 8 PCs running Windows 11 here at Chez Tittel right now, it pops up on only one of them. It could be present on another, but I can’t tell right now. Thus, for me at least, finding OneDrive Photos proves elusive if not outright mysterious.

Why OneDrive Photos Proves Elusive

For one thing, there is no separate “OneDrive Photos” app, all the recent flap nothwithstanding. It’s actually part of the OneDrive executable itself OneDrive.App.exe. That said, it shows up on Windows 11 PCs with work and school accounts, even though it works only with personal MSAs. Thus, uninstalling it on corporate and school accounts is a real concern. For examples, see the coverage at WinAero, Windows Central and Windows Latest for a good sense of what’s been shaking.

I wanted to see the gosh-darned thing, but had trouble finding it. Turns out you have to be running version 26.139.0720.007 (it’s a preview version) AND you must be running a personal MSA for it to show up as such. Then you login into onedrive.live.com with said MSA, click the photos button at top left of onedrive login home and Presto! there you are.

As for uninstalling it if you can’t use it? That’s coming, but not quite here yet. But before I uninstalled it, I wanted to see it in the first place. Thus, as Murphy would have it, first I had to find it. Gosh! I have to laugh at the things that occasionally happen here in Windows-World. It’s a real gut-buster, sometimes…

Facebooklinkedin
Facebooklinkedin
Backup/Restore, Cool Tools, Insider stuff, Recent Activity, WED Blog

Lenovo Recovery UFD Works, But…

1 Comment

I’ve been documenting the path away from a stuck (and incorrect) Dev Channel build to a clean install of production 25H2 on my ThinkStation P3 Ultra for nearly two weeks now. Today’s episode is a simple one. After problems getting the device to boot to any UFD, I ordered a Lenovo factory recovery USB directly from Lenovo (see my “It’s the Layout, Stupid” post for more info). Last night, it arrived in a plain padded envelope, and I inventoried it. That’s the whole story. Except, of course, there’s more to it than that. I’ll explain…

Why Say: Lenovo Recovery UFD Works, But…

The first thing I noticed when the envelope hit the desk was the lack of any Lenovo branding on the drive itself. What I pulled out was an ADATA UVI128 32 GB USB 3.2 Gen 1 flash drive (available for about US$8 online; old enough to be unavailable from big US e-tailers). No ThinkStation logo, nor Lenovo red trade dress. No embossed branding of any kind. For a machine that runs somewhere in the neighborhood of four grand, I appreciate the transparency. It’s just a recovery drive, nothing more.

What’s On That UFD, Anyway?

I plugged it into Flo6  (my main Windows 11 PC here at Chez Tittel) and ran a quick PowerShell inventory. That let me see what I had in hand. These numbers came back: 26.41 GB used on a ~29.3 GB drive, with 2.86 GB free. Every major payload file was timestamped August 3, 2026, which tells me this was a fresh burn, not a dusty warehouse pull. That’s genuinely good to know.

7 Folders With Lots of History

The folder structure is straightforward once you know what you’re looking at. At the root you get seven directories: \boot, \EFI, \mfg, \preboot, \RECOVERY, \SWWORK, and \tvtos.

\boot and \EFI handle dual-mode booting — Legacy BIOS and UEFI respectively, with \boot packing 30-plus MUI language files for good measure. \mfg carries manufacturing metadata and a document called W11_RUSB_TEMPLATE_64_DEV.docx that makes absolutely explicit what this thing is: a Windows 11 recovery set. It’s just manufacturing boilerplate, but as internal tells go, it’s a nice one — you can see exactly which template Lenovo’s recovery build team signed off on. \SWWORK is a staging scratch area, and it’s essentially empty.

The real substance lives in \RECOVERY and \tvtos. The \RECOVERY folder holds the actual image payloads — the largest being LCAFKQ2BA0.IMZ at 957 MB, which is the core Windows 11 OS image, plus fifteen or more companion .IMZ bundles covering P3 Ultra-specific drivers and Lenovo’s software suite. Familiar utilities ride along for the restore process: imagex.exe, bootsect.exe, bcdboot.exe, 7z.exe, and a few Lenovo-proprietary tools including hddcln.exe and rcadm.exe. \tvtos is where the bulk of the 26 GB lives. That’s home to the WinPE-based ThinkVantage OS environment, which is the preboot shell that actually orchestrates the whole restore operation.

Python 2.6 Drives the Lenovo Recovery Engine

Here’s where the archaeology gets interesting. The recovery orchestration engine living in \preboot runs on Python 2.6. Python 2.6 reached end-of-life on October 29, 2013 — nearly thirteen years ago. It has not received a security patch since Barack Obama’s first term. I resisted the urge to feel old about this. Mostly unsuccessfully.

The image format is equally vintage. Those .IMZ files are Lenovo’s proprietary compressed image format. Indeed, there’s no public tooling to mount, extract, or meaningfully modify them. They travel with .CRI catalog companions and are handled entirely by Lenovo’s own restore .exe files. You are explicitly not intended to poke around. You are meant to click Restore and walk away while the progress bar does its thing.

ThinkVantage itself tells a similar story. Lenovo quietly retired the brand years ago, replacing it with Lenovo Vantage on the consumer side and Lenovo Commercial Vantage for enterprise. The preboot environment on this Lenovo factory recovery USB is frozen legacy infrastructure now past its expiration date. It’s functional, tested against this specific hardware configuration, and going absolutely nowhere. It works. It just works using technology that’s old enough to have its own nostalgic Reddit threads.

I Meant What I Said, and I Said What I Meant

All that said: it does the job. Boot it using F12 at the Lenovo splash screen, then select the USB from the boot menu. Bam! The ThinkVantage preboot environment launches and walks you through a factory restore of the P3 Ultra to its original Windows 11 configuration, complete with all Lenovo drivers and software. No internet connection required. MSA prompts, nada. No drama, either. On a machine this complex, that’s pretty cool.

The dual-mode boot support, confirmed by both \boot and \EFI folder trees, means the drive works whether the firmware is set to Legacy or UEFI mode. Coverage is thorough: Windows 11, P3 Ultra-specific drivers, the full Lenovo software bundle. All available on one generic flash drive in one plain envelope.

My verdict: label it clearly, drop it in the P3 Ultra’s machine folder with the rest of the hardware documentation. Then, treat this Lenovo factory recovery USB exactly as the break-glass emergency media it is. I wouldn’t try to explore the ThinkVantage environment for entertainment. Why not? Because it’s a straight-up restore wizard, not a sandbox, and it doesn’t reward curiosity. And don’t get any ideas about cracking open those .IMZ files, either. You’ll need AI or serious programming chops in Python 2.6 to get anywhere.

That’s not my thing. Here in Windows-World, I’m OK with treating a black box as such. Shoot! I’m just surprised it came on a USB-A UFD. After my local success only with the USB-C Data Traveler to bring the P3 Ultra back to life, I’d expected the same kind of UFD to show up from Lenovo. I was wrong…

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