Category Archives: PowerShell

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

1 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
Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog

Identify Spurious Windows Reclaimables

Leave a comment

OK, then: thanks to some excellent detective work by ElevenForum stalwart @Bree, it looks like DISM can tell curious Windows users which packages are “stuck.” That is, you run the DISM command sequence: Analyze-Clean-Analyze, with a positive number of reclaimable packages still showing. (You can find all the details in my 11/2023 blog post on this topic.) This time around, I’ll show you how to list out the actual items that identify spurious Windows reclaimables. Warning: some PowerShell hacking is involved!

How-to: Identify Spurious Windows Reclaimables

@Bree shows the source for the data needed to identify these strange offenders. It’s based on analyzing data within a DISM generated text file. Here’s the specific command that creates that data:

DISM /ONLINE /GET-PACKAGES /FORMAT:TABLE > KB.txt

What this does is to inspect the current running Windows image (/online), grab all packages it finds with some related data (/get-packages),  and format it into a table (/format:table). That last bit (> KB.txt) redirects command output into that named file. The column headings in that output read: Package Identity, State, Release Type, and Install Time with vertical bars (‘|’) used to separate entries.

Bree’s analysis concurs with my own prior inspection of this same kind of output. We both agree that only lines with the strings “Staged” and “Feature Pack” in them point to spurious Windows packages. His analysis depends on sucking the output into a text file, converting to Excel format, sorting by State, and counting groups of lines to match the spurious reclaimable count to what’s reported by DISM /AnalyzeCompontentStore. Remember: those are packages that stay in the component store even after a DISM /cleanup-image operation has completed successfully. I simply write the output from the /Get-Packages DISM command to a file named KB.txt and filter its results.

Automating Analysis of KB.txt Contents

Next, my PowerShell script comes into play (such as it is, it’s pretty primitive). Unzip kbfilt.zip and then move kbfilt.ps1 to the directory where you created kb.txt (to run this file type .\kbfilt.ps1 inside an administrative PS Terminal window: screenshot follows later).

# Path to the input text file
$inputFilePath = "kb.txt"

# Path to the output text file
$outputFilePath = "kbfilt.txt"

# Read the file line by line and filter the lines
Get-Content $inputFilePath | ForEach-Object {
# Check if the line contains both "Staged" and "Feature Pack"
if ($_ -match "Staged" -and $_ -match "Feature Pack") {
# Output the line to the output file
$_ | Out-File -FilePath $outputFilePath -Append}}

# Confirm the script has finished
Write-Host "Lines w/ 'Staged' and 'Feature Pack' written to $outputFilePath"
Write-Host "Remember to delete kb.txt, kbfilt.txt before next use"

I used the -Append directive for Out-file which means the script appends text to the file and doesn’t over-write (“clobber” in PS-speak) other content. That’s why you’ll want to delete these files if you want to run the script again.

My Copilot+ PC (an Intel Aura Yoga Slim 7 model from Lenovo), running Windows 11 24H2 Build 26100.2134, has 2 spurious packages as shown here:

2 packages with LONG names (typical for Windows)
[Click image to view full-sized.]

This investigation is simply to show you which packages are stuck. You can get rid ofthem with DISM /Remove-Package. But if you do, they’ll most likely pop back up again after you install the next Cumulative Update (CU). Windows images are funny that way. But at least, now you can identify the packages involved.

Facebooklinkedin
Facebooklinkedin