Category Archives: PowerShell

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

Command Palette Brings WinGet Wrinkles

Leave a comment

OK, then. I’m having an absolute ball running the new v0.90 PowerToys Command Palette for all my everyday Windows tasks and upkeep. This morning, it’s a quick hop into CmdPal (as it’s commonly abbreviated in Windows Terminal or PowerShell discussions or documentation) to see how WinGet behaves. It works just fine, but Command Palette brings WinGet wrinkles that I had to experience to understand. Let me explain…

What Command Palette Brings WinGet Wrinkles Means

I’m used to running WinGet inside PowerShell. That means I get a lot of support from its inbuilt facilities, as well as those from the surrounding Windows Terminal environment. As far as I can tell right now, running WinGet from CmdPal lacks that support.

Thus, for example, when I type winget up, the command shell is smart enough to know that I’m probably going to want to run my all-time favorite winget upgrade command — namely:

winget upgrade –all –include-unknown

Indeed you can see that from the auto-complete function in PowerShell in lighter text if you examine the following screencap carefully. Note the cursor sits just to the right of “up” in that string. If I strike the right-arrow key it will enter the rest of the line for me.

When I enter strings into CmdPal, I don’t get the auto-complete function automatically. It may remember over time, but I’m just starting to use it so it has nothing to remember right now.

Also, when I hit the Enter key after typing out the full string shown above manually, it runs inside of the Command Prompt shell, not PowerShell. That means I have to approve installers via UAC (User Account Control) so they can run with a mouse click. Inside PowerShell, those installers run without requiring UAC approvals.

Right Now, I Prefer WinTerm/PS to CmdPal

I’m not yet aware if I can customize CmdPal to run commands in PowerShell rather than Command Prompt by default. Part of my confusion stems from CmdPal as a Windows Terminal facility that precedes the introduction of the utility of the same name via PowerToys. But hey, anything new comes with little wrinkles and niggling details in need of working out and understanding more fully.

But again, it’s a gas to use CmdPal. And I am having great fun working my way into what promises to be a terrific and capable tool. I just need to learn how to use it properly, and well.

 

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

Unintended OneDrive Consequences

Leave a comment

I have  to chuckle. Working on a Windows 11 revision to a data recovery  story yesterday, I ran into “the law of unintended consequences.” In this case, I switched OneDrive backup on to test the Windows Backup app. In so doing, I picked up some unintended OneDrive consequences. You can see them in the lead-in screenshot.

Overcoming Unintended OneDrive Consequences

Blithely, I started using files for my primary MSA from OneDrive on that test PC. (I chose the snappy and powerful ThinkStation P360 Ultra.) Immediately, it picked up Windows Terminal environment settings from the cloud, not the local PC.

Check the lead-in graphic. The error results from running the cloud-based PowerShell profile. It references supporting infrastructure for the WinGet.CommandNotFound capability. This allows WinGet to suggest a source to install a command that

(a) PowerShell sees as undefined
(b) WinGet recognizes
(c) knows where to find
(d) can install on the user’s behalf

Read the error message beneath the failed import command at Line 8 in that output stream. You’ll see the module named Microsoft.WinGet.Client is not loaded. Translation: that module IS squared away on PC from which  OneDrive supplies shared files.If it gets loaded on this machine, the error won’t recur.

Putting the (Right) Pieces in Place

The next screencap shows what I did to fix this. I looked up the instructions to get Microsoft.Winget.Client loaded. It requires two back-to-back PowerShell commands. The first handles install, the the second import:

Install-Module -Name Microsoft.WinGet.Client
Import-Module -Name Microsoft.WinGet.Client

I ran those commands  on the P350 Ultra. Where requested, I provided permission to access the module gallery for the client module. Next, PowerShell said”Restart Windows Terminal.” After I did that everything worked OK. Here’s visual proof:

What you see is that PowerShell opens normally, with no error messages. Next, you see NeoFetch which shows system and OS info for some nice eye candy. But that last part is proof that unknown command handling is working as it should. I typed ‘vim‘ in at the command line (it’s a well-known text editor popular in UNIX and Linux circles, not installed by default in PowerShell). And you see the results of the Microsoft.CommandNotFound module suggesting WinGet syntax for how to install this tool if wanted.

Problem solved!

 

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

Remove Package Kills Spurious Reclaimables

Leave a comment

Over the past year or so, I’ve blogged 7 times about “spurious reclaimables” in Windows 11. They persist in the component store even after DISM /StartComponentCleanup. You can see this in the lead-in graphic. Right now, in fact, the current Beta and GA releases show this behavior. Indeed, it comes from older packages that the preceding DISM command can’t (or won’t) clean out. Reading the CBS.log carefully, someone at ElevenForum  figured out that a single remove package kills spurious reclaimables dead.

Running Remove Package Kills Spurious Reclaimables

A line in the CBS log file that caught long-time member and guru @Bree‘s eye. It showed up in the CBS.log via DISM … /AnalyzeComponentStore. It reads (in part):

Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10] is a top-level package and is deeply superseded

In the component store, a top-level package is a primary package. It contains all the bit and pieces — namely files, resources, and instructions — to install or enable some specific Windows update or feature. It’s called top-level because it may contain (or be a parent to, in hierarchical terms) other, related packages and features.

What caught Bree’s attention was the “deeply superseded” phrase in the descriptive text. Normally, DISM /StartComponentCleanup doesn’t remove top-level packages from WinSxS. “What if,” he reasoned, “this were removed because of its obsolete status?” And indeed, it turns out that removing this package also removes a child package as well. And these two nogoodniks turn out to be the very same two packages that show up as spurious reclaimables when running DISM /AnalyzeComponentStore.

Doing Away With Deeply Superseded Package

If your Windows 11 still shows 2 reclaimable packages after a successful  DISM /StartComponentCleanup operation, try this DISM command to remove the deeply superseded package (if it’s not the cause, this command will simply fail but won’t harm the component store):

dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10

It worked on all the Windows 11 systems I tried it on, including current Beta and GA releases (5 in all). You can also regain about 1.2-1.3GB of space in the component store by following up with a DISM /StartComponentCleanup command. Cheers!

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

Extirpating WinGetUI Requires Registry Cleanup

Leave a comment

Here’s an odd one. A few months back, I tried out a pre-release version of UniGetUI that still fell under the WinGetUI umbrella. The package info involved — as you can see in the lead-in graphic — was ID=MartiCliment.UniGetUI.Pre-Release Version=1.5.2. I thought I’d deleted same, and it showed up in none of Programs and Features, Settings > Apps, or Revo Uninstaller. Yet it kept showing up in WinGet‘s upgrade and list commands anyway. TLDR; extirpating WinGetUI requires registry cleanup to “make it go away.” Sigh.

Why Extirpating WinGetUI Requires Registry Cleanup

Apparently, adding packages to Windows leaves all kinds of traces in the file structure, as well as settings and pointers that get instantiated in the registry. Furthermore, it looks like WinGet relies what it finds in the registry to create its view of what’s installed on a Windows PC. Thus, I had to remove all registry entries that included the string “WinGetUI” and/or “UniGetUI” (except for stuff not related to the application or its package info, such as pointers to Word files I’d written about those tools).

And indeed, that did the trick. Neither WinGet Upgrade nor WinGet List Marti.Climent.UniGetUI,Pre-Release posits pointers to something I know isn’t there. The next screengrab provides visual proof. Good-oh!

After removing all WinGetUI references in the registry, WinGet no longer sees the older package.

It just goes to show that some uninstall facilities work better than others. For all its good features, it appears that WinGetUI/UniGetUI does not clean the registry upon uninstall deeply enough to tell WinGet that it’s gone, gone, gone. You’d think that wouldn’t happen with a WinGet-related and -focused follow-on tool. But here’s a counter-example that says otherwise.

That’s the way things go here in Windows-World, where not all is as it seems, not always works exactly the way it should. Sigh. When that happens, we clean up manually and keep on truckin’…

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

PowerShell-Based Defender Commands

2 Comments

The other day, my Canary Channel X380 Yoga hung up on Windows Update. In other words, after  some kind of WU download difficulty, it wouldn’t download from those servers. There are lots of ways to unstick WU, but one of the easiest is to get Windows Defender to update. Personally, I prefer to use a single PowerShell command with no arguments or parameters, rather than navigating into Windows Security to see if that might help. Indeed, there is a plethora of Defender controls in PowerShell. The one I used is just a single instance in a collection of over a dozen items.

Finding PowerShell-Based Defender Commands

You can see the command I used to ask PowerShell to update Defender in the lead-in graphic. It’s named Update-MpSignature, and it takes no mandatory arguments or parameters. What you’re looking at there, in fact, is the general PowerShell Module Browser at MS Learn. It’s dialed into Defender commands, shown in the breadcrumbs up top: Learn/Windows/PowerShell/Defender. As you will soon find out, there is a baker’s dozen of such things there under this heading.

Other Defender Commands get their own listings, but also appear in a handy-dandy table (simplified contents reproduced verbatim below). Indeed, each one also has its individual command reference, for which you find links in said table.

 

Add-MpPreference
Get-MpComputerStatus Gets the status of antimalware software on the computer.
Get-MpPreference Gets preferences for the Windows Defender scans and updates.
Get-MpThreat Gets the history of threats detected on the computer.
Get-MpThreatCatalog Gets known threats from the definitions catalog.
Get-MpThreatDetection Gets active and past malware threats that Windows Defender detected.
Remove-MpPreference Removes exclusions or default actions.
Remove-MpThreat Removes active threats from a computer.
Set-MpPreference Configures preferences for Windows Defender scans and updates.
Start-MpScan Starts a scan on a computer.
Start-MpWDOScan Starts a Windows Defender offline scan.
Update-MpSignature Updates the antimalware definitions on a computer.

As you can see there are lots of interesting and sometimes useful ways to interact with Defender in PowerShell. They’re worth exploring and getting to know. I used a simple one to unstick WU this week, but there are lots of other tools here, ready to help you manipulate Defender in Windows Terminal or via automation scripts. Have at it!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, WED Blog, Windows tools

Bringing Neofetch Aboard via WinGet

Leave a comment

I knew there had to be a way. I just couldn’t find it or figure it out on my own. The venerable old OS info command line tool Neofetch (best known to UNIX and Linux users) works at the Windows command line, too. But I struggled with Chocolatey and Scoop to get it installed without liking the results. This morning Eleven Forum user Lance1 posted a terrific WinGet-based install/update tool from Chris Titus with an understated title “You may find this handy.” Indeed I did — and I also successfully tried bringing Neofetch aboard via WinGet on my production PC. You can see it running in the lead-in screengrab.

What’s Behind Bringing Neofetch Aboard via WinGet?

Running the command from Lance1’s post — namely

iwr -useb https://christitus.com/win | iex

absolutely did the trick for me.

Here’s how Copilot breaks this command string down (all six numbered items are quoted verbatim therefrom):

  1. iwr: This is an alias for the Invoke-WebRequest cmdlet. It sends an HTTP request to a web server and retrieves the response.
  2. -useb: This parameter tells Invoke-WebRequest to automatically unblock the downloaded file, which is useful when downloading scripts from the internet.
  3. https://christitus.com/win: This is the URL of the file you’re downloading. In this case, it’s a script hosted on Chris Titus’s website.
  4. |: This is the pipeline operator, which passes the output of one cmdlet to another cmdlet.
  5. iex: This is an alias for the Invoke-Expression cmdlet. It runs a script or command that is passed to it as input.

In summary, says Copilot: “this command downloads a script from https://Christitus.com/win and then executes it immediately on your system.” It’s what pops up the partial console that includes a checkbox for Neofetch, like so:

And when I clicked on Install/upgrade selected in the console pop-up window, it showed the following output as it used WinGet to handle the Neofetch install:

I’m jazzed. I need to spend more time with this Chis Titus tool and see what ELSE it can do. Lance1 was certainly right in his low-key estimation of its utility. I’ve already found it handy, so to speak. Cheers!

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

WinTerm Multi-Line Paste Flag Is Helpful

Leave a comment

Way to go, Windows Terminal (WinTerm) development team. I just accidentally hit Paste (Ctrl-V) inside that application, and it posted the warning you can see in the lead-in graphic. I saved myself unnecessary error messages — and the app saved itself from associated error handling — by warning me I was about to do something possibly stupid. Indeed I was, as you can see from the clipboard contents info in the screencap. Hence my considered judgement: the WinTerm multi-line paste flag is helpful.

Obviously, WinTerm Multi-Line Paste Flag Is Helpful

Shoot! Given how often, and in how many ways I use the paste buffer, there could be just about ANYTHING in there. That includes all kinds of text and even images. I use cut’n’paste all the time while writing, especially when updating older stories from Windows 10 to 11 coverage. I’ve done that dozens of times in the past couple of years for ComputerWorld, Tom’s Hardware and TechTarget. Plus, I often use cut’n’paste to drop screencaps into social media posts as I’m commenting on Windows news and observations. None of that stuff works in PowerShell, folks!

It’s a good thing when application designers and developers recognize human frailty, and take steps to protect users from themselves. It’s particularly good, IMO, when that user is me!

Windows Terminal Keeps Getting Better and Better

From its own self-update behavior, to various UI and Settings improvements, to PowerToys add-ins (Think: “Command Not Found”), Windows Terminal has just kept steadily improving over the past 2-3 years. The more I use it, the more I’ve come to like it. And now, with Copilot to assist me in writing PowerShell scripts, I’ve become better able to take advantage of that ever-increasing goodness. You should, too.

Facebooklinkedin
Facebooklinkedin
Cool Tools, PowerShell, WED Blog, Windows 10, Windows 11

OhMyPosh Auto Update Hangover Fixed

3 Comments

Here’s an interesting one. Indeed one can configure or enable the excellent OhMyPosh prompt tweaking tool  (aka OMP) to update itself. But there’s a trick involved in getting WinGet to recognize an update has occurred. I call it an “update hangover.” Apparently the local copy of the WinGet source list itself needs a reset before it catches up with what’s happened. (That list provides the basis from which it decides what’s fresh and what needs updating.) Let me explain — and show — how I got this OhMyPosh auto update hangover fixed.

Getting OhMyPosh Auto Update Hangover Fixed

Take a look at the screencap in the lead-in graphic. Before this sequence occurred, OMP told me as the PowerShell session started up that it was updating itself to version 24.18.1. You’ll notice that selfsame “Available” version according to WinGet upgrade output right at the head of that PowerShell command sequence.

Keep reading. Note that the output for oh-my-posh –version also reads 24.18.1. Thus, OMP is already upgraded and already current. But after I complete the valid remaining upgrade manually (for Microsoft.WindowsADK), another simple upgrade check shows that WinGet thinks OMP still needs that upgrade.

What to do? I try basic winget source reset — which attempts a reset for the winget and msstore sources — but the command output tells me the directive requires the –force option to work. So that’s what I try next:

winget source reset –name winget –force

As you can see when I do the next upgrade check after that, WinGet now reports “No installed package found matching input criteria.” That means it no longer sees OMP as a legit update target. Fixed!

Now, I wonder if Jan DeDobbeleer can figure out a way to reset the local list of packages for comparison to the WinGet source as part of his auto-update function. Probably not: knowing his thorough and deliberate approach to this package, he’d have done it already were that possible.

 

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

New OhMyPosh Version Highlights Auto-Update

Leave a comment

As the world returned to a more normal work rhythm yesterday, I found myself fielding various new software updates. Among them, a bump to OhMyPosh version 24.18.0. It wouldn’t work via WinGet because — as you can see in the lead-in graphic — it introduces a “newer version” for its “install technology.” Thus, this new OhMyPosh version highlights auto-update gotcha. I’d already used the oh-my-posh enable upgrade command to automate that process. A new install wipes out that directive.

If New OhMyPosh Version Highlights Auto-Update, Then What?

This got me looking at ways to embed the same information in the omp.json file that drives OhMyPosh configurations. Turns out when a reinstall happens, default configurations are rewritten from scratch. Thus, adding commands to

“auto_upgrade”: true,
“disable_notice”: true,

likewise got wiped from my chosen JanDeDobbelleer.omp.json config file as well. (Add them to the end of that file and you’ll need to drop the second comma, in fact.) What to do?

Turns out a custom config file is left alone when you have to shift from an older install technology to a newer one. Renaming the default config file, adding customizations, and referencing that new name in the invocation for OMP will do the trick. Way to learn, I guess!

Best Gets Better, After Sussing Out the Wrinkles

My fervent thanks to Jan DeDobbelleer, the OMP developer and chief steward. There’s seldom anything that goes off with OMP that isn’t addressed in his copious documentation and online interactions with other users. It sometimes takes a little while — about half an hour for this set-to, for example — but I have always been able to figure out and fix whatever gets hinky with OMP. That’s quite a testament to the tool and its builder. Thanks again for everything, Jan!

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

OMP Changes Update Handling

Leave a comment

I should have seen this one coming. Jan De Dobbeleer’s excellent Oh My Posh (OMP) prompt glyph handling (for PowerShell on Windows Terminal in my case) is going through lots of changes lately. Among those is an “upgrade” option in its configuration file. I’d seen prompts about it awhile back (September, perhaps?) but hadn’t take the time to investigate. But when OMP changes updated handling, I did so. Turns out it’s dead easy and I should’ve done it right away. Live and learn, right? The lead-in graphic shows how easy: a one-liner OMP instruction: oh-my-posh enable upgrade. Done!

Avoiding How OMP Changes Update Handling Brings Trouble

The next screencap shows the pickle I put myself in yesterday. The latest OMG update (v24.12.0) uses a different install technology from the previous version, so handling it via WinGet meant an uninstall/install manuever. You can see what happened when I did that.

After uninstalling OMP, the Terminal startup can’t initialize it.

After uninstalling OMP, Windows Terminal can’t execute its initialization (’cause there’s nothing to initialize). And when I install it, it won’t run in that Terminal window (or pane). It must be invoked. That’s why I opened a second terminal session (right-hand pane) so OMP would actually load and run. Simply enabling OMP to update itself via the aforementioned command is a heck of a lot easier, and far less disconcerting.

Now, I need to go through and do this on all of my Windows PCs with OMP installed (the vast majority, in fact). Again: I should’ve done it right away. Maybe that’s the moral of the story…

Facebooklinkedin
Facebooklinkedin