Category Archives: Windows 10

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 3.4.6.0 — 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 1.2.4.22027. 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 1.2.4.22027 — and that’s the one I’ve already got. SUMo, in asserting that version 3.4.6.0 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…

Facebooklinkedin
Facebooklinkedin

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.

Facebooklinkedin
Facebooklinkedin

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!

Facebooklinkedin
Facebooklinkedin

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).

Facebooklinkedin
Facebooklinkedin

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!

Facebooklinkedin
Facebooklinkedin

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 answers.microsoft.com 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!

Facebooklinkedin
Facebooklinkedin

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!

Facebooklinkedin
Facebooklinkedin

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.

 

Facebooklinkedin
Facebooklinkedin

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…

Facebooklinkedin
Facebooklinkedin

Teams App vs. Application Update Conundrum

I’m chuckling as I report this. Right now many people — including me — run both the app and the application version of Microsoft Teams on their Windows 10 and/or 11 PCs. I’ve been sussing out another update mystery in keeping Teams current, and have finally figured it out . . . I think. It seems there’s an easily overlooked Teams app vs application update conundrum in play. The Microsoft Store keeps the app version current on its own; regular applications often require human intervention for updates.  And to make things more interesting, this is apparently a case where WinGet isn’t always equipped with pointers to the latest, greatest update packages. Sigh.

One more thing: Because the Teams application runs as part of the Office (365 or 2019 or later “dated versions”) running update in Outlook, Word, PowerPoint and so on also takes care of the Teams application update. Good to know!

Solving the Teams App vs. Application Update Conundrum

I started twigging to my issue when I saw two entries for Microsoft Teams in my update scanner SUMo. Winget told me one of those instances was an application (ID: Microsoft.Teams; version 1.6.00.12455 was most current, but I was still running 1.6.00.6754). The other one was an app (ID: MicrosoftTeams_8wekyb3d8bbwe; version 23134.300.2089.5908; the _*weky… string in the ID is what tells you it’s an app, BTW).

That led to my “Aha!” moment. Microsoft Store keeps apps up to date pretty darn well without requiring human intervention. Regular applications, not so much. So I had to fire up the application, log in, navigate into Settings, and tell it to “Check for updates.” That did the trick, after which Teams was finally up-to-date. Amusingly it’s now running version 1.6.0.16322 — a higher version number than the SUMo recommendation that twigged me to this interesting issue in the first place. Go figure!

Keeping Windows apps and applications up-to-date is always interesting. In cases like this one, in fact, it may even be a little too interesting. But it’s always fun to figure things out.

Facebooklinkedin
Facebooklinkedin