Category Archives: PowerShell

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

Working with WinFetch

October 24, 2022 Ed Tittel Leave a comment

WinFetch is a windows-focused knock-off of another well-known shell tool named NeoFetch. Each is written to show useful and informative data about systems from within a command-line shell environment. NeoFetch is built atop bash; WinFetch atop PowerShell. IMO, that makes WinFetch more suited for use with Powershell. I’ve been working with WinFetch a lot lately, learning how to use it to help me see what I’m doing with Windows Terminal and PowerShell customizations. Indeed, it’s pretty helpful. But I’ve also been learning some lessons the hard way as I go. Let me explain…

Why Working with WinFetch Takes Some Effort

The documentation on WinFetch is kind of sparse. In fact, I’m starting to think I should spend my time reading the NeoFetch stuff, because it may shed more light on the inner workings of WinFetch. Straight from its GitHub home, there’s precious little info available about its details and settings. Sigh.

So far, the lessons I’ve learned the hard way include:
1. You must save the config.ps1 file that governs WinFetch behavior for its changes to take effect.
2. Sometimes, a reboot is required, above and beyond a simple save. I can’t tell why, but I found myself stuck a couple of times on this hump. If you make a change, save the config file and it has no impact on the WinFetch output, try a reboot. It may do the trick.
3. Customizing the WinFetch config is totally a trial-and-error exercise. Be prepared to spend lots of time tweaking and checking, then repeating ad infinitum. Sigh again.

Customizing for Winget Package Mgr

It took me a while — including plenty of the aforementioned trial and error, but I got WinFetch to look at and report on Winget packages. Here’s the syntax, straight from the config.ps1 file that makes WinFetch work:

$CustomPkgs = @(“winget”)
function info_pkg_winget {
return ((winget list | measure-object).count)
}

What you’re doing is telling winget to list all the packages it knows about, then piping that input into the measure-object cmdlet. Using its count attribute you simply show the overall package count. Sublime!

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

Get-Hotfix Shows What WU Sometimes Cannot

October 18, 2022 Ed Tittel Leave a comment

When MS lifted the safeguard hold on my Lenovo P16 Mobile Workstation, I upgraded it to Windows 11 22H2. Naturally, my first thought thereafter was to check on status of recent updates and fixes. That’s when I figured out that KB5018427 was included in the 22H2 version installed. Seems that Get-Hotfix shows what WU sometimes cannot — at least as far as Update History goes.

It’s all apparent in the lead-in graphic for this story. In case it’s not legible enough, right-click on that image and select “Open image in new tab” (Chrome, Firefox, Edge, etc.). That should show it at original resolution. If necessary, you can use the browser’s Zoom controls to magnify the text.

How Get-Hotfix Shows What WU Sometimes Cannot

Update history shows only user-alllied updates. It does not show updates that — like KB5018427–get rolled up into the windows image file (WIM) used to install a version upgrade. That’s what makes the PowerShell Get-Hotfix command so useful. Its image analysis tool tells it what’s there, whether the user applied it directly, or whether it’s already “in there” as is the case here.

An important clue appears in the “Installed on” date shown in the output of Get-Hotfix. Although the KB item itself is dated 10/11/2022, it didn’t get rolled into the WIM until 10/14/2022.

What Led Me Down This Trail?

I read the Windows Latest story about KB5018427. Naturally, I wanted to check on its status in the upgraded 22H2 version. When I didn’t see it in Update History, I visited the Microsoft Catalog and downloaded the 64-bit MSU file. Upon attempting its installation, it searched the updates already installed on the PC. That produced the following status message:

That made me understand the KB had been included in the WIM file I’d already installed. A search on “use PowerShell to show updates installed” led me to the Get-Hotfix command.

As the afore-cited PowerShell docs states:

The Get-Hotfix cmdlet gets hotfixes, or updates, that are installed on the local computer or specified remote computers. The updates can be installed by Windows Update, Microsoft Update, Windows Server Update Services, or manually installed.

Thus Get-Hotfix can catch patches and fixes no matter how they get included in the image it checks and reports upon. The rest, as they say (drum roll, please)… is history!

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

Exploit Winget Include Unknown Syntax

August 22, 2022 Ed Tittel Leave a comment

For the past couple of years I’ve been learning — and using — the Microsoft package manager, Winget, It helps me keep my PC apps updated. Just recently, I’ve learned to exploit Winget include unknown syntax to broaden its coverage. Basically, this will “upgrade packages even if their current version cannot be determined.” That quote comes from the upgrade command section of the MS Winget documentation.

How to Exploit Winget Include Unknown Syntax

First, that syntax couldn’t be simpler: just add the string
--include-unknown
to the usual invocation for winget . For the record that’s
winget upgrade --all
. This tells the program to apply upgrades for all packages with known versions. You can see this at work in the lead-in graphic for this story, in fact. Chrome shows up when unknowns are included, but not otherwise. (Compare top and bottom sections, or view the image full sized by clicking the following thumbnail.)

The difference between the unadorned “all” version of Winget upgrade and the one with unknowns included applies in large part to applications like Kindle, Chrome, Firefox, and more, which apparently do not report their current version numbers either consistently or well to Winget during its initial survey phase.

This addition to the command finds those things and attempts to upgrade them. Certain apps — most notably Teams — will not work with this tool because of version mismatches (and the prudent decision not to overwrite versions outside the same version tree). But this does improve its overall coverage. That lowers the number of apps and applications I must update manually. To me — and to you, too, I bet — that’s a good thing!

Note: Winget works in PowerShell with equal facility for both Windows 10 and Windows 11. It’s become one of my go-to tools for keeping my small fleet of PCs (currently numbered 12, with 2 going off to college with my son soon) up to date.

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

Windows Terminal PowerShell Selection

July 12, 2022 Ed Tittel Leave a comment

I have to laugh. Yesterday, I noticed version 5 of PowerShell running inside Windows Terminal. So I naturally wondered: “How do I upgrade this?” Turns out, in fact, that no upgrade is needed. It all comes down to the current Windows Terminal PowerShell selection. I’ll explain shortly, but first: look at the window in the lead-in graphic.

Managing Windows Terminal PowerShell Selection

By default, version 5.1.xxx… appears when you open Windows Terminal. But it’s easy to get to a newer PowerShell version. No upgrading is necessary: you need only know how to do this. If you click on the down-caret at the far right of the title bar, a menu appears, like this:

The down-caret menu lets you choose among shells you can run in a Windows Terminal tab. [Click image for full-sized view.]

The trick — if you can call it that — is to choose the right version of PowerShell (and corresponding default) to run. The top item in the menu corresponds to version 5.1.xxx. The fourth item down brings up the latest 7.x PowerShell version (specifically, 7.2.5). If you click Settings, you can also choose this version as the “Default Profile” which makes the new version (rather than the 5.1.xxx version) appear whenever you open Windows Terminal, or click the “Plus” sign to open a new default Terminal tab.

As with many other things in Windows World, foreknowledge and understanding are key to doing things right. In my case, I had no need to update PowerShell. I only needed to pick the right version to run inside Windows Terminal. Now I know how. If you didn’t know how already, this should make things equally simple for you. Cheers!

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

WingetUI Offers Useful Update Capability

June 16, 2022 Ed Tittel Leave a comment

Lately, I’ve been using the Winget PowerShell applet to assist with updating my Windows 10 and 11 PCs. Thanks to Martin Brinkmann at Ghacks, I’ve found a GUI front end for that tool. Indeed, the aptly-named WingetUI offers useful update capability.

Winget.UI does other things, too. It let you explore all 3460 packages under its purview (“Discover Software” tab). It also shows a complete list of all packages already installed on your PC (“Installed applications”). On first blush, Winget.UI looks like a good tool. Its GitHub page provides the lead-in graphic for this story.

“Available updates” quickly identifies and provides ready access to item-by-item update launch. [Click image for full-size view.]

What WingetUI Offers Useful Update Capability Means

To update an item from the Software Updates tab in Winget.UI (shown above), simply double-click its corresponding Winget entry under the “Installation source” heading. Personally, I find this prefereable to the winget upgrade --all command. Why? Because it provides item-by-item control. That lets me skip elements (such as MS Teams), which experience has taught me isn’t really amenable to winget updates.

The double-clicking takes a little getting used to, but by and large the update function works well. It worked well for third-party packages, including Kindle, Python 2, and Revo Uninstaller. It hit errors on some built-in MS components, such as the WADK and Edge Runtime. Based on prior history, I didn’t even try the Teams components.

Good, But Not Perfect

I’ll need to spend more time with WingetUI to fully understand and appreciate its foibles and strengths. For now, it’s much like other update tools I use: good — indeed, pretty helpful — but by no means either great or perfect. Perhaps that’s just the way that update tools work here in Windows World!

[Note: Nochmals Danke schoen to Mr. Brinkmann for an interesting find.]

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

Checking Windows DotNET Versions Installed

May 5, 2022 Ed Tittel Leave a comment

A recent Windows news story reports that “KB5012643 for Windows 11 breaks .NET Framework 3.5 apps” (WindowsReport). This raises some interesting questions for Windows 11 users. For some, it apparently renders certain apps inoperable. Indeed, the bug highlights the value of checking Windows DotNET versions installed on a given PC.

So I did a little research, and learned there are at least two methods to run this info down. In fact, MS offers a multi-page Docs item that explains how to do it using PowerShell. Belgian-based software developer (and former MVP) Nick Asseloos’ ASoft company goes another way. It offers a free download named .NET Version Detector. Its output provides the lead-in graphic for this story.

What Checking Windows DotNET Versions Installed Tells You

As you can see by examining the lead-in graphic. the detector provides information of several kinds, conveniently listed in order from top to bottom by row:

Row1: Versions of the MIcrosoft .NET Framework Installed. In my example, it shows older versions to the left (2.0, 3.0, and 3.5, with SP levels),and current versions to the right (4.8, with latest update level).

Row2: Extra Details show the folder locations for the various frameworks installed. It also shows names and levels for frameworks installed as well (mostly relevant to 4.x versions), plus languages and updates (mostly a bunch of KB article identifiers).

Row3: .NET Core versions installed for 64-bit (left) and 32-bit (right) enviornments. Given my machines all run Windows 10 or 11, 32-bit is mostly MIA.

How ‘Bout Going the Other Way ‘Round?

OK, we know now how to determine what .NET versions are installed on a Windows PC. What about figuring out which applications use some specific .NET framework? That’s a bit trickier. The only sure-fire method I could find was to fire up SysInternals Process Explorer. There’s a tab named “.NET Assemblies” that shows up whenever a process that includes same gets highlighted.

This means you can find out which .NET versions are in use primarily by observation and inspection. Stack Overflow has an article that explains how to automate this process for managed processes using C# or PowerShell. I’ll leave that as an “exercise for the reader” for those inclined to work out to that extent!

[Note: this story gives a shout out to the redoubtable Martin Brinkmann at Ghacks, whose 2014 story (updated 2018) introduced me to ASoft .NET Version Detector. Nochmals vielen Dank! (Thanks very much again!)]

Insider stuff, PowerShell, Tips, Tricks and Tweaks, WED Blog, Windows 11

Windows 11 Says Sayonara WMIC

October 25, 2021 Ed Tittel Leave a comment

Because it was announced in Windows 10 21H1, it was just a matter of time. The Windows Management Interface Command-Line utility, aka WMIC, is deprecated. No longer simply slated for oblivion, WMIC is missing from the Dev Channel version of Windows 11. The lead-in graphic shows what (doesn’t) come up in cmd.exe for Build 22483 and higher. Hence my title: Windows 11 says Sayonara WMIC. For the record, it’s still in production Windows 11 versions but reads “WMIC is deprecated.” in red.

Notice the red text at top of help response. It’s MIA In Dev Channel versions now.[Click image for full-sized view.]

Though Windows 11 Says Sayonara WMIC, WMI Remains Around

Microsoft has good advice for would-be WMIC users. They should use PowerShell replacement cmdlets instead. Turns out that the Windows Management Interface (WMI) remains alive and well. In a story about this change-over, WinAero.com suggests using a specific PowerShell command to learn more:

Get-Command -Noun WMI*

For the record, that string produces the following output that shows this is just the beginning of a sizable set of cmdlet documentation.

The 5 cmdlet WMI facilities: Get, Invoke, Register, Remove and Set.
[Click image for full-sized view.]

Each of these five facilities has its own muti-level help files. Looks like the switch-over is supported. That said, it requires climbing a new learning curve to bring users under the PowerShell umbrella.
Cheers!