Category Archives: Windows 10

Using Get-WUHistory Requires Finesse

I’m a big fan of PowerShell. That’s why I was excited to learn about a collection of cmdlets from the PowerShell Gallery named PSWindowsUpdate. Chief among its constituents is a cmdlet named Get-WUHistory that I’ve been finding both helpful and vexing. I say that using Get-WUHistory requires finesse because it works well on Windows 10, but hangs on PCs with longer “history trails” in Windows 11. Let me explain and illustrate what that means…

Why Using Get-WUHistory Requires Finesse

I’m only running Windows 10 on one actual PC (not counting VMs). By chance, that’s where I started working with the PSWindowsUpdate cmdlets. To begin with, you’ll need to install this collection, using this command:

Install-Module -Name PSWindowsUpdate -Force

If you haven’t visited the PowerShell Gallery before, you’ll be asked to grant various permissions so your PC (or VM) can access and use its contents. If necessary, please do so. Then, your installation will complete. After it’s done, you can use the Get-WUHistory command (among others — see a complete list of all 25 cmdlets from this package).

There’s something going on in Windows 11 that will sometimes cause Get-WUHistory to “hang.” How can you tell? The output won’t complete, you won’t get a prompt back, and the cursor keeps blinking. Indeed, it doesn’t even respond to CTRL-C to terminate the command. You must close the open PowerShell window (or tab) to regain control over Windows Terminal.

What’s the Trick to Make Things Work?

For some odd reason limiting the scope of output keeps the Get-WUHistory cmdlet working. Thus, in Windows 11 instead of simply entering Get-WUHistory at the command line, try this version instead:

Get-WUHistory -last 1000

This tells the cmdlet to limit its output to only the first 1000 entries it finds in the update history. Notice that on one of my test PCs, the actual number of entries in the update history is only 157 items, yet the command hangs anyway — except when it’s scoped. Go figure!

Unless scoped [-last 1000] Get-WUHistory hangs on Windows 11.

The lead-in graphic shows the first screen of output from a scoped version of the Get-WUHistory cmdlet. Notice that most of the updates relate to Windows Security (Windows Defender intelligence updates, antimalware platform updates, and so forth). Too much chaff, not enough wheat, IMO. Here’s a way to turn down the volume…

Reducing Get-WUHistory Output Volume

One can, of course, filter Get-WUHistory Output — in addition to limiting its scope — to reduce the output volume. Here’s a command string I found to be incredibly helpful in seeing what’s there, sans security-related stuff:

Get-WUHistory -last 1000 |
Where-Object {$_.Title -notlike "*Security*"}

What you see broken across two lines (or more) in the preceding is actually a single (if complex) PowerShell command string. Be sure to remove or ignore any internal line breaks when running this inside Windows Terminal. You’ll get back a mercifully much shorter list of items, mostly cumulative updates (CUs), MSRTs, Update Stack Packages, and the odd antimalware platform update. As you can see, this cuts 157 items down to a more manageable 12. Good stuff!

Eliminating the word security in the “Title” field filters out most of the dross. [Click image for full-sized view.]


Foiling False Upgrade Positives

I use a collection of tools to keep my Windows fleet updated. These include winget (in PowerShell), plus KC Softwares’ Software Update Monitor (SUMo) and PatchMyPC Home Updater. Occasionally one or more of these tools will throw a “false positive” — that is, report an update that doesn’t exist. When that happens I have my way of foiling false upgrade positives to prevent wasting time. Let me explain…

About Foiling False Upgrade Positives

This is a case where one tool can occasionally backstop another, so that one tool’s claim of an existing upgrade can be challenged successfully. Case in point: the item SUMo reported this morning, which refers to a new version of Microsoft PC Manager numbered — look at the lower right in the lead-in image above. A quick hop to the home page for Microsoft PC Manager (Beta), a download (you’ll find two buttons there), and display of Properties details from that  download shows:Foiling False Upgrade Positives.pcmgrproperties

Notice the version number reads Compare that to the “Version” column in SUMo: same!

Likewise, when I turn to winget inside PowerShell, I use its “list” command to show me what’s on my machine, then use its “show” command to show me the latest manifest in its public database. Again, both agree. That tells me pretty unequivocally that the latest version is indeed — and that’s the one I’ve already got. SUMo, in asserting that version is the most current, is somewhere off the beaten track.

What Now, Young Jedi?

I’ve got Kyle Katarn’s email and twitter feed at my disposal. So when something like this happens with SUMo I send him a message saying what SUMo reports and what the software maker (MS in this case) tells me. He’s usually very quick about fixing false positives (on a same-day basis, in fact). Ditto for issues with winget (I likewise interact with Demitrius Nelon, Winget Team Lead at MS). He is also responsive to feedback, and often provides same-day fixes as well. So far, I’ve not yet had a false positive experience with PatchMyPC (but it covers far fewer software items than SUMo’s 400+ and winget’s 2000+ manifests).

Good stuff!

Note Added August 9 Afternoon

At 4:15 PM Central (-05:00 GMT) Mr. Katarn sent me a message this item had been fixed. Ran SUMo again, and sure enough: the false positive is gone. THAT’s what I call customer service…


PowerToys Sources: WinGet & MSStore

I saw yesterday on Twitter (X?) that PowerToys version  v.0.72.0 dropped. So I started banging on WinGet to upgrade me. It’s been at least 20 hours since that announcement, but WinGet still has no manifest for the new version. Indeed, the lead-in graphic shows v.0.71.0 as current. But there are two PowerToys Sources: WinGet & MSStore. And sure enough, installing the Store version brought one of my Lenovo X380 ThinkPads up to the latest iteration. This features in the lead-in graphic as well. The second WinGet list PowerToys command shows the current version installed — with a WinGet source, no less — after I downloaded and installed the latest version from the MS Store. Go figure!

Why Two PowerToys Sources: WinGet & MSStore?

The answer to the preceding query depends on how organizations do updates internally. Those who let WU and the MS Store handle things should choose the Microsoft Store version of MS apps when they can. This will automatically handle things on its own. But those who control updates will find WinGet invaluable. It makes a great focus for automation via PowerShell scripts as and when their update windows open.

Does that mean one or the other source for updates is better? Not at all. But today, it looks like the updates through the MS Store track new releases faster than WinGet does — for PowerToys, at least. I’m also interested that even though my update comes from the store, it shows WinGet as its source. But as long as it’s updated quickly and correctly, that’s OK.


After OOO Upgrade Whirl Resumes

OK, then. We rolled back into the garage a little after 5 PM last night. We spent 4 glorious days in an around Marfa, TX. It’s an odd but charming hipster haven in the Big Bend region. This morning, I’m surveying the state of my slightly reduced PC fleet after my absence. I’m down to 9 machines right now, having returned a couple of loaners to Lenovo in hopes of some new review units in return. After OOO upgrade whirl resumes with a vengeance as I catch up on what I missed while gone.

Reporting on: after OOO Upgrade Whirl Resumes

Across my various PCs, I saw some auto-activity in Update history while I was gone. But as I worked with my PCs, each of them needed somewhere between half-a-dozen and ten upgrades/updates to catch up to the leading edge. In general, WinGet accounted for one to three of those items, WU for about the same, and SUMo for the rest.

Interestingly, Strawberry Perl had failed to update in WinGet and inside WingetUI just before I left town. I’d resolved to fix that this morning, but it seems to have fixed itself. WinGet did the upgrade job on its own with nary a hiccup nor error message (see lead-in graphic).

Across the fleet, here are the apps and applications I needed to update upon my return to “active duty” (in alphabetical order): Firefox, Driver Booster, Intel ARC Control, OhMyPosh,  Strawberry Perl, and Zoom. Given how long I was OOO (out of the office) I’d expected more. But hey, if I can take a break from the grind, so can everybody else, Cheers: it was fun to be gone, but it’s good to be back!


Introducing Microsoft PC Manager

Last Friday, I learned about a new Beta Windows utility from Microsoft called “PC Manager.” It’s available for download and use right now on both Windows 10 and 11. There’s just one problem: I couldn’t get it to install from the download for either OS. But since I’m introducing Microsoft PC Manager here and now, you know I’ve figured out a workaround. Yep: there’s a Winget package for this tool, and it installs through that approach just fine.

Still Introducing Microsoft PC Manager, Despite Installer Fail

If you run the download file named MSPCManagerSetup.exe it simply hangs, even when you agree to its terms and conditions. It just sits there, doing nothing, like so:

Introducing Microsoft PC Manager.install-hang

Even after agreeing to the terms, the installer presents no option to actually install the tool. Stuck!

I figured there might be a winget package manifest for this tool, seeing as how it’s a Microsoft thing. I was right. It took a bit of poking around, but I eventually hit paydirt on the string “PCManager.” Here’s a screencap with the right install syntax (and a successful installation).

Winget install Microsoft.PCManager does the trick!

Again: Introducing MS PC Manager

Here’s what the startup window from the application looks like. It provides information into PC health, storage, processes and startup apps, as well as cleanup and security stuff.

Introducing Microsoft PC Manager.program-running

OK then: here’s the home window for the Microsoft PC Manager (Beta) utility.

Health check takes a couple of minutes to run, and found excess files and baggage, as well as numerous startup items to cancel out. Storage Manger offers options for deep cleanup, large file management, app management and storage sense. Deep cleanup found and removed another 3.6 GB of “stuff” on my PC; large files created a single-pane display of all files over 100 MB on my system (you can set thresholds at 10, 50 and 100 MB, and 1 GB: pretty handy). Manage apps simply moves you to Settings → Apps → Apps & features, where you can review and manage what you’ve got. Storage Sense does likewise for Settings → System → Storage → Configure Storage Sense or run it now. All pretty handy, and worth fooling around with. Check it out!

In a future blog post, I’ll dig further into the Security button at the lower right. It has at least one interesting capability that I’ll also be writing about in an updated story for ComputerWorld soon (I hope).


WinGet Upgrade PowerShell Working

At the end of last month, I blogged about an interesting issue: when you used WinGet to upgrade PowerShell (in PowerShell) that operation would complete, but the screen wouldn’t update properly. As I reported, it showed cancelled and required opening a new PS session to see the current, upgraded version number. No more: now, MS has WinGet upgrade PowerShell working as it should be. See the lead-in graphic for visual proof.

If WinGet Upgrade PowerShell Working, Then What?

No more weirdness in the self-upgrade process, I guess. The lead-in graphic shows that PowerShell updated the initial session window to match the current version (7.3.6) with the version number at the top of the that window. Indeed, I’m forced to *SWEAR* it said 7.3.5 when I started, and appeal to the 2nd line of the WinGet upgrade output because I didn’t think to capture “before” and “after” screencaps. LOL, it didn’t occur to me that the developers would rewrite the terminal window to update the version number. But they did!

I contacted Demitrius Nelon, Team Lead for WinGet at MS to report this weirdness, which he confirmed for me. What he didn’t tell me was that they fixed this in the 7.3.6 release. But its behavior, as shown in the lead-in graphic, speaks for itself. Good stuff and thanks, people: good job.

Got It on Another PC!

I went to upgrade another PC and *DID* capture the initial screen showing 7.3.5 at the top. No more swearing: here’s the screen before the 7.3.6 upgrade completes so you can see the old version number in its top line.

WinGet Upgrade PowerShell Working.X390

See!? There’s the old version number before the 7.3.6 update completes. It’s like magic!

Note added 7/19: looks like this capability (no cancelled and updating version number) may only be in Windows 11. When I updated my sole remaining Windows 10 physical PC this morning, the cancelled message recurred as in my earlier blog post on this subject. Go figure!


Windows Terminology: Enablement Package KB (eKB)

In Microsoft’s Windows Client roadmap Update: July 2023 (published yesterday, July 13) I came across a new (to me, anyway) buzzword with associated acronym. As I add to my Windows terminology, enablement package KB (eKB) is now on the list.

Here’s the quote that got me looking around to learn more (I bolded those key words):

The upcoming Windows 11, version 23H2 shares the same servicing branch and code base as Windows 11, version 22H2. What does it mean for you? If you’re running Windows 11, version 22H2, it will be a simple update to version 23H2 via a small enablement package (eKB). Do you remember updating from Windows 10, version 1903 to 1909? Or how you’ve managed recent updates beginning with Windows 10, version 20H2 through 22H2? It will be that simple. Moreover, since both versions share the same source code, you don’t need to worry about application or device compatibility between the versions.

There’s also a Note of some interest as well. It reads:

Note: The eKB is not available on Volume Licensing Service Center. Media packages contain the complete Windows 11 operating system.

In fact, that last item is what really caught my attention and got me looking around, because eKB is an abbreviation/acronym I’d not seen before. My take: if MS thinks eKB is a thing, I’d like to know what kind of thing it is. Here goes…

Chasing Down Windows Terminology: Enablement Package KB (eKB)

A search on the acronym took me back to March 2022, to an post. Entitled “What is Enablement Package KB (EKB)…?” it took me to an early instance of that terminology. It also references the KB5003791 announcement, which talks about enablement packages in general (though it doesn’t use the eKB term itself).

In the simplest of terms, it means that we’ll transition from 22H2 versions of Windows 11 to 23H2 versions through a small and simple Cumulative Update (CU), rather than a lengthy Windows install-based upgrade. A long story, for a short conclusion.

And if you look at the big quote above, the part that starts “Do you remember updating…?” provides some recent, notable examples of an eKB even if it doesn’t tie it directly to that term.

Now I know what an eKB is. And, if you’ve read this through, so do you. Cheers!


Gadget Fixes Notification Issue

I have to laugh. Sunday morning, I was at my desk before 8 AM having made it back from my daily walk kinda early. I forgot that I’d turned on the external speakers (I usually use headphones). No sooner did I get to my desktop than my speakers started chiming as a flood of notifications bonged in — pretty loudly, too. And because those notifications appear on top of the notification area of the taskbar, I couldn’t get to the volume control to turn the volume down. This caused some mild panic, because I didn’t want to wake up other family members still asleep Ultimately, I used the Sound item in Control Panel to reduce the volume. But a gadget fixes notification issue one and for all, after I get past that initial flurry.

Gadget Fixes Notification Issue.controlpanel-sound-speakerlevels

The Levels pane in the Sound item for the default output lets me turn things down…”

How a Gadget Fixes Notification Issue

Gadgets appear elsewhere on the desktop, so they aren’t rendered inaccessible when a flood of notifications appears. I can go to the Volume Control gadget shown as the lead-in graphic above any time, and click on the sound level I want to raise or lower volume levels.

The name of the gadget depicted is “Volume Control.” It appears on Page 3 in the 8GadgetPack collection (lower right; details at bottom).

Volume Control 1.2 makes it easy to raise or lower volume without accessing the notification tray Volume Control.

This may not seem like a big thing, but when you’re trying to let sleeping … err … family members …err lie, it’s kind of a lifesaver. ‘Nuff said!


PowerToys Team Closes WinGet Gap

Now THAT’s what I like to see. Yesterday morning, I noticed a new version of PowerToys (v0.71.0) was out. So quite naturally, I ran WinGet to upgrade same. No dice. At 11:45 AM (Central) I tweeted  about this. I observed it was “kind of surprising to see a new PowerToys release…without a matching WinGet upgrade manifest.”  8 minutes later, the team leader responded “we’re working on it.” And by that afternoon, the PowerToys team closes WinGet gap. There’s a working manifest for version 71 in place. Neat-o, and thanks, people!

PowerToys Team Closes WinGet Gap Quickly

It’s a real testment to the energy and drive of the teams involved that things were already in progress as I reported in. (In fact, I heard from the WinGet team lead, too.) This morning I installed PowerToys on the Lenovo ThinkPad X1 Extreme (8th-gen i9, 32 GB RAM, 1.5 TB SSD) and got the latest version. That sequence appears as the lead-in graphic above.

If you look at that graphic, you’ll see that WinGet found only a Zoom upgrade. Oops! That’s because PowerToys wasn’t installed on this PC — yet. But when I did install the .exe version (Microsoft. Powertoys) 0.71.0 (shown as v0.71.0 in the thumbnail at lower right) appears. That’s exactly what should have happened,. It also shows the WinGet manifest for that version of PowerToys is present and working properly.

Always Nice When Things Work Out…

I must say that both the WinGet and PowerToys teams have always been great to work with. They respond to input, questions, and feedback quickly. And when they have to act, they tend to do so sooner than later. Thus, my thanks to Demetrius Nelon (WinGet team lead) and his merry munchkins, as well as Clint Rutkas (PowerToys team lead) and his peppy people, too.  Please: keep up the good work.



Sussing Out WinTerm Color Schemes

In my writing and research work for TekkiGurus, I’m pursuing a GitHub project that works within the Windows Terminal environment. It’s called ColorTool. Simply put, ColorTool shows the colors used in the console window; it also lets you tweak them. Its color charts are kind of interesting and I’ve trying to figure them out. MS has a tendency to show them inside an Ubuntu command session inside Windows Terminal. I show them as they pop up in PowerShell in the lead-in graphic. As I’m learning how this all works, I’m sussing out WinTerm color schemes, too.

Bing Chatbot Helps When Sussing Out WinTerm Color Schemes

I’ve been reading a lot, and asking around to try to learn how to decode the values that show up in the display form of a Windows Terminal color scheme. So far, it’s proved rather more challenging than I had expected. So far, I’ve been attacking output strings to tease out their meanings. This is what I’ve learned so far, mostly thanks to the Bing Chatbot in Windows 11 Canary (Build 25393):

  • The string “gYw” that appears in the columns of rows 2-10) stands for gray, yellow and white. It uses prevailing foreground color, whatever that may be.
  • The values 30m through 37m that appear as row heads (first column left) are ANSI escape codes for foreground colors
  • The values 40m through 47m that appear as column heads (second column through 9th column left) are ANSI escape codes for background colors.
  • Looking at the color chart, the text strings “gYw” show the foreground color, while the solid bar for each column shows the background color.

In profound contrast, Ubuntu puts foreground colors as columns, and background colors as rows. I also shows escape sequences instead of color names. Initially, this bamboozled me. But now I see what’s going on…

Sussing Out WinTerm Color Schemes.ubuntu

Notice that background appears as double rows with escape codes at left in column 1, and foreground colors appear as the text for escape codes in rows 2-9).

Wow, it’s all starting to make a certain amount of sense. And I mostly have the Bing Chatbot to thank for explaining such extremely low-level details. Apparently, those who work with terminal/console color charts know all this stuff already.

Now, I finally understand that a color scheme assigns a range of color values to the 8 ANSI escape codes for the foreground colors 30m through 37m (which may also be expressed as ESC[30m …). It does the same for the 8 ANSI escape codes for the background colors, too (40m through 47m, likewise ESC[30m).

OK, Now I Know What’s What

Suddenly, I feel armed with the information I need to make sense of the Windows Terminal color schemes and their related color charts. This should make my jobs of explaining them, and their customization, a WHOLE LOT easier. I’m jazzed…