Category Archives: PowerShell

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

WinGet Updates PowerShell, Error Aside

Leave a comment

I have to chuckle. There’s a new PowerShell 7.4.4 out. I just used WinGet to update my production PC and it applied the update package. But when it got the end of the update, it reported “Installation abandoned” and ended the WinGet update session. Because 7.4.4 came when I closed, then re-opened, Windows Terminal it looks like WinGet updates PowerShell, error aside. You can see the sequence in the lead-in graphic.

WinGet Updates PowerShell, Error Aside

Notice that a “Cancelled” item shows up below the “Installation abandoned” notification. I’m guessing this last item refers to jumping out of the WinGet update sequence, because you see a normal command line prompt (spiffed up, thanks to Oh-My-Posh).

And sure enough, running WinGet upgrade –all –include-unknown finishes up the remaining items that appeared below PowerShell in the update list. In the next screencap I show a two-pane Windows Terminal session. On the left, you see the sequence of update packages installed; on the right, you see the PS Version is now 7.4.4.

To the left you see WinGet at work; to the right a newly-opened PS session says it’s v7.4.4. [Click image for full-sized view.]

One more thing: the final item in the upgrade sequence on the X1 Extreme was Winget itself (which appears as Microsoft.AppInstaller inside the upgrade list). At its conclusion, WinGet closes things out a bit more reasonably. It says:

Successfully installed. Restart the application to complete the upgrade.

Cancelled

I think that confirms my suspicion that the cancelled item refers to the WinGet session itself. It even throws a couple of Ctrl-C (^C) characters to make sure things get closed out. Here’s a screencap:

Facebooklinkedin
Facebooklinkedin
Cool Tools, PowerShell, Recent Activity, WED Blog

Update and Check Windows Terminal Versions

Leave a comment

When I checked over the PC fleet this morning WinGet let me know an  update for Windows Terminal was pending. It would take the program from version 1.20.11381.0 to 1.20.11781.0. Easy-peasey. But once is was done, I asked myself: what’s the best way to check that the new version is running. Thus, I found myself digging into how to update and check Windows Terminal versions. The lead-in graphic, in fact, shows two ways to version-check, captured from the colorful Lenovo Yoga Slim 7x Copilot+ PC.

For the record those two checks are:

1. Winget list Microsoft.WindowsTerminal shows the current installed version on the PC.
2. Click the down-caret in the WinTerm title bar, then click “About” from the pop-up menu to get the “About” mini-window atop the Windows Terminal application window.

How-to: Update and Check Windows Terminal Versions

The update part is easy using the general WinGet upgrade –all –include-unknown command. But if you want to target WinTerm explicitly, Winget upgrade Microsoft.WindowsTerminal will also work.

One thing to remember, as you’ll see in the next screencap: once you’ve updated Windows Terminal, you need to close the current session, then open a new one. Why? Because the process that’s running the old version won’t quit, and a new process to run the new version won’t take over, until you’ve done the “out with the old, in with the new” routine that this accomplishes. Good stuff!

Update and Check Windows Terminal Versions.ps-details

One more cool little detail: as soon as WinGet updates WinTerm, it bails back out to the command line. That’s so you can close/re-open your session and keep going…

Just another routine day here in Windows-World. I really enjoy working at the command line a LOT more, now that I’ve learned how to jazz things up and make best use of WinGet to keep them current.

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

Font Handling Works Through Settings

Leave a comment

OK, then: In the wake of the clean install on the Lenovo ThinkPad P16 Mobile Workstatation, I’ve been reworking some of my runtime stuff. Customizing Windows Terminal comes under that heading, near the top of my priorities. To take proper advantage of OhMyPosh, I have to add a so-called Nerd Font to that PC’s collection. Turns out this is way easy in Windows 11 because font handling works through Settings in that OS. Let me show you!

How Font Handling Works Through Settings

Once upon a time installing fonts in Windows meant visiting the C:\Windows\Fonts directory and dropping the various .ttf (typeface) files there. Then Windows could add them to its collection and display them in a variety of forms in the Control Panel element named Fonts.

And indeed, the Fonts CPL is still alive and well. But if you visit Settings > Personalization > Fonts you see the add fonts window there, with its “Drag and drop to install” instruction. Arguably this is exactly the same at using Control Panel > Fonts. But IMO it’s less work and more fun to use. At least it worked quite well for me.

What Came Out of My Visit to Fonts

Thanks to all the files in my personal account folders and their auto-backup to OneDrive, when I set up a new PC with the same MSA, it inherits all that stuff. So as soon as I visited Nerd Fonts, downloaded CakaydiaCove NF, and installed OhMyPosh on the P16, this is what Windows Terminal looks like (it’s using Jan De Dobbeleer’s eponymous theme named “JanDeDobbeleer” in its config file).

Font Handling Works Through Settings.winfetch

Windows Terminal showing winfetch and OhMyPosh at work, overlaid atop the Nerd Fonts download page. [Click image for full-size view.]

FWIW, I use the various Caskaydia Cove NF (Nerd Font) variants in Windows Terminal because they look great with OhMyPosh. But it’s both worthwhile and fun to poke around that collection to find something that you like and looks as good or better.

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

WinGet Source Hiccup Self-Repair

Leave a comment

I saw a new WinGet error message yesterday. In attempting a “blanket update” PowerShell showed a “Failed when opening source(s)…” error instead (see intro graphic above). That same error also suggested its own fix via WinGet source reset. I didn’t read carefully enough to see that the –force option was also required. But my next upgrade attempt succeeded anyway. There was apparently a WinGet Source hiccup self-repair at work. What happened?

OK, Why Did WinGet Source Hiccup Self-Repair?

I can only speculate that there was a transient communications glitch between my test PC and the URLs associated with the Microsoft Store and WinGet itself. To me, this dual drop most likely indicates an interruption of service at the ISP level. Both domains have vastly different IP addresses so it’s unlikely to have been something at their end. Hence my best guess that something affected the lookups from my end through my ISP,  Spectrum.com.

It’s amusing that I discovered this hiccup simply by entering another command (albeit an incorrect one). Upon re-entering the original blanket update:

winget upgrade –all — include-unknown

Everything went through as expected on the second try. Through well-cultivated habits, in fact, my first impulse with Windows when things don’t work as expected is simply to try again and see what happens. In this fragile world of ours (including Windows-World) what doesn’t work at first often succeeds on a subsequent attempt.

Had it turned out otherwise, I’d be showing a different screencap, and telling a different story. This time, second try was the charm!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, Updates, WED Blog

Busy Week Brings 9 WinGet Updates

Leave a comment

It’s been a busy week, so I’ve been doing stuff more, and playing less with Windows. How do I know? I just ran WinGet on my production desktop and it tossed up a new personal high. That’s right: my busy week brings 9 WinGet updates to my Windows Terminal PowerShell session. You can see the intro part in the lead-in graphic. Wow!

When Busy Week Brings 9 WinGet Updates, Install Them

So that’s what I’m doing right now, as I write this blog post. The whole 9 items took about 2 minutes to complete. It brought 8 successes and one failure. Because I have numerous M365 components open right now, the M365 Apps for Enterprise install failed. That’s probably because I’m using a different subscription version tied to a different MSA. The one I’m using cheerfully reports itself all caught up.

It’s the one I’m NOT using that reports itself out-of-date (which is perfectly OK, because I’m not using it. Maybe I should remove it?) Isn’t it funny how using multiple MSAs in a Windows PC can occasionally make life interesting when you login with one such account, and use assets tied to another such account?

It’s All Part of Windows’ Inestimable Charms…

Learning where the eccentricities reside or potholes lie, and steering around them, gives me countless opportunities for learning and enjoyment when it comes to working with Windows. But less so than usual this week: I’m busy. In fact, I need to go do some paying work as soon as I’m done here. Cheers!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Updates, WED Blog

PowerShell Install Goes Cancelled to Abandoned

Leave a comment

Here’s a good one. Take a look near the bottom of the lead-in graphic. It shows what happens at the end of a WinGet upgrade sequence with the PowerShell installer. But whereas that installer used to say “Installation cancelled” it now says “Installation abandoned.” Hence my assertion: PowerShell Install Goes Cancelled to Abandoned. In truth, this simply means the Windows Terminal window must be closed and re-opened for a new PowerShell version to take effect.

What PowerShell Install Goes Cancelled to Abandoned Means

Things get interesting when a program that’s currently running gets updated. Generally, for the code to take over from the old, the old must first stop. Then, the new must start up and run, so it can use all of its newly-minted capabilities and capacities. The “cancelled” and “abandoned” stuff is text for an error message that indicates the installer itself had to terminate in some kind of unexpected, unusual, or surprising way.

Look at what comes up when I close Windows Terminal, and then re-open it. Just for grins, I add WinGet list microsoft.PowerShell and another WinGet upgrade … check. The former shows the new version 7.4.2.0 is present (as does the lead-in prompt above it). The latter shows that a new WinGet check no longer reports that PowerShell needs an upgrade. Case closed!

PowerShell Install Goes Cancelled to Abandoned.follow-up

The new PowerShell version is running so it no longer generates an update notification. [Click image full full-size view.]

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

WingetUI Announces UnigetUI Name Change

Leave a comment

Though you can use it nicely with the Windows Package Manager, aka WinGet, WingetUI also works with other package managers. As you can see on its GitHub page, WingetUI also works with Scoop, Chocolatey, Pip, Npm, .NET Tool and the PowerShell Gallery. That’s a whole heap of package managers, and helps to explain why WingetUI announces UnigetUI name change in the app right now (see the lead-in graphic for same).

How WingetUI Announces UnigetUI Name Change

When I fired up WingetUI yesterday — for the first time in a couple of weeks, I cheerfully confess — the lead-in graphic popped up on my upstairs Windows 11 test PC (Asrock B550 mobo, Ryzen 5800 CPU, 64 GB RAM, Nvidia 1070TX GPU, etc.). In that little explainer, Marti Climent makes it clear that while WingetUI was initially designed to work only with Winget, it now covers numerous other package managers as well. Hence, the name change.

Of those other package managers, I’ve messed with Scoop and Chocolately. I’ve also turned to PowerShell Gallery on many occasions (though I’d call it a package repository more than a package manager, even though WingetUI/UnigetUI has worked with it for some while now).

WinGet CLI vs. WingetUI/UnigetUI

When I first discovered WingetUI I found it compelling and interesting because I was still learning the intricacies of WinGet commands and their sometimes convoluted syntax. But these days, I’m pretty darn comfortable with WinGet. Thus, I don’t find myself using WingetUI as much as I once did. Nevertheless, it’s a worthwhile tool that’s worth getting to know.

Indeed, I wrote a story about WingetUI for TekkiGurus last August (part of a 4-part Winget series). If you’re curious to learn more about either or both of these topics (Winget and WingetUI/UnigetUI) be sure to check them out. [Note: you’ll find links to the other 3 elements of the WinGet series if you visit the WingetUI story linked above.] Cheers!

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

KB50001716 Is Puzzling

Leave a comment

OK, then. I was reading Martin Brinkmann’s post to gHacks this morning. It’s entitled “Microsoft’s sneaky KB5001716 Windows 10 update pushes Windows 11.” I don’t think my production PC qualifies, because its Intel SkyLake i7-6700 falls outside the range of supported CPUs. So I went looking for it, and learned some useful things. Let me share them with you…

Why KB50001716 Is Puzzling

First off I went to look at WU Update History to see if KB5001716 was present (or absent). I quickly realized that reading the whole WU history was more than a little taxing on a machine that’s been running Windows 10 since 2016.

So I turned to PowerShell where some operating on the Get-WUHistory command seemed like a good idea. When I figured out my Update History had 528 entries, that idea seemed even better. You can view the update history by creating a variable named $history, like so

$history = Get-WUHistory -last 1000

This grabs up to the last 1000 entries in the history records and assigns them to the variable $history. If you look at that output it’s kind of hard to ingest from Windows Terminal. It makes more visual sense if you look at it this way:

$history | sort date -desc | Format-Table Date,KB,@{l=’Category’;e={[string]$_.Categories[0].Name}},Title

[Note the preceding lines are a single PowerShell command string. If you want to try it, cut’n’paste into a text editor and make sure it’s a “one liner” before pasting into PowerShell. This produces output that looks like this:

KB50001716 Is Puzzling.table-output

Table format is more readable, but still too much to take in.
[Click image for full-size view.]

So I changed up the command string to write it to a file. That required appending the following string:

> i7wuhist.txt

The > symbol redirects the output, and the filename resides in folder context in which PS runs. Working with a file I was able to figure out the following:

1. I had no instances of KB5001716 in there anywhere
2. There were a total of 528 entries in that file.

I also concluded that my PC’s failure to meet Windows 11 hardware requirements probably meant that the upgrade offer (and indeed KB5001716 itself) were not forthcoming. Good to know, and I learned some interesting stuff along the way.

Facebooklinkedin
Facebooklinkedin
Cool Tools, PowerShell, Recent Activity, WED Blog

WingetUI Throws Bogus Update Notification

2 Comments

Alas, all tools have their little quirks. I’ve noticed recently that WingetUI is telling me to update CredentialManager (CM) from version 2.0 to version 2.0.0. They’re the same thing! Even more interesting when I tried running the Update-Module cmdlet manually, it told me CM wasn’t even installed on the target PC. So I used Install-Module to get it installed. You can see what happened next when I re-ran WingetUI in the lead-in graphic. Sigh.

Why Say: WingetUI Throws Bogus Update Notification?

What else should I say when WingetUI tells me to update something that’s not installed? And then, once installed it finds version mismatch from a “2.0” label from the developer versus aninternal Winget “2.0.0” label? Sigh again. I remember this kind of thing happening from time to time as I ran the old Software Update Monitor (SUMo), now out of action.

Look what happens when I click my way into “Package details” for CredentialManager inside WinGetUI and then click the update button for that package:

WingetUI Throws Bogus Update Notification.no update found

When it actually goes to look, it finds no update.

My best guess is there’s something in the CM manifest in the PS Gallery that’s presenting the version number as 2.0, and something going on with Winget that changes the value to 2.0.0. And indeed, if I look at get-installedmodule data again it shows the CM version number as 2.0. I’m hoping Demitrius Nelon and the winget team will check this out, and share their findings. Also filing a bug report via GitHub at the WingetUI pages.

Should be interesting to see what kind of response comes up. Cheers!

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

CNF Conundrum Gets Some Love

Leave a comment

OK, then. I’ve been trying to figure out why, on some of my test PCs, I get an error message when PowerShell loads my profile and tries to import the PowerToys WingetCommandNotFound (CNF) module. You can see that error message in the lead-in graphic above (from my ThinkPad P16 Mobile workstation). Thanks to some fiddling around, this CNF conundrum gets some love — finally!

I haven’t figured out how to fix the problem properly just yet. But for the nonce, if I go into PowerToys, visit CNF, uninstall and then resinstall same, it returns to work. This happens every time I open a fresh PowerShell session, so it’s at least mildly bothersome. But I’m starting to make progress on figuring things out.

How CNF Conundrum Gets Some Love

The error message keeps changing on me as I add things to the folder where the profile resides — namely %user%\documents\PowerShell. First, it complains about not being able  to find the module itself. I copy it into that folder. Then it complains about a .DLL. I copy that, too. Finally, it complains about an error handler not being able to field a thrown exception.

It’s not fixed yet, but I now know that this issue comes from my PowerShell modules path set-up. Something is wonky between those search paths (there’s one for the system, and one for my login account) and PowerToys. This happens for one of my Microsoft Accounts (MSAs)  every time I use it to log into Windows, because this information is shared across those instances through OneDrive.

What’s Next?

I’ve got to research how I should be setting things up in the OneDrive environment to get PowerShell and PowerToys to get along with each other properly. I’ll be contacting the WinGet crew (Demitrius Nelon’s team at MS) to request additional info and guidance. That’s because my online searches have only clued me into what’s going on, but not how to fix it properly.

Stay tuned: I’ll keep this one up-to-date. And I’ll probably post again, when a resolution is formulated. This just in: OneDrive is reporting multiple copies of the PS profile in its file store. Could this be related? I have to think so. Again: stay tuned…

Facebooklinkedin
Facebooklinkedin