Category Archives: PowerShell

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

MS Defender Update Targets Deployment Images

June 7, 2023 Ed Tittel Leave a comment

If you can trust the header data in this MS Support note (I do) it was updated on June 5, 2023. The item is entitled “Windows Defender update for Windows Operating system installation. It describes how to imbue offline Windows images with the latest and greatest Defender capabilities. In fact, that article includes a warning not to apply them to live images. Thus, it’s clear that this MS Defender update targets deployment images.

I got my date information about the article from its HTML meta-data:

<meta name="lastPublishedDate" content="2023-06-05">
<meta name="firstPublishedDate" content="2020-12-04">

How MS Defender Update Targets Deployment Images

Pre-requisites to run the updates — for WIM and VHD files — include:

Works on OS install images for 64-bit Windows 10 and 11, and Windows Server 2016 and 2019
OS environment must include PowerShell version 5.1 or newer (current production version is 7.3.4 as I write this)
Microsoft.Powershell.Security and DISM modules installed
The PowerShell session for the script <code>DefenderUpdateWinImage.ps1</code> runs with admin privileges. (“Run as administrator” or equivalent.)

The script provides switches to apply, remove or roll back, and list details for the installed update. Useful for those who maintain Windows images and want their security levels up to current snuff.

Find all the details in the MS Support article previously named. Do this before your next scheduled update window, for sure. Of course, this means you’re using Windows Defender as part of your security infrastructure.

MS Is BIG in Security

I just worked on a promotional piece for a joint Rubrik and MIcrosoft security webinar (YouTube video). Amazingly, MS describes itself as “the biggest cyber security company in the world” and did over US$20B in such business in 2022. I guess they do have some legs to stand on in this arena. And indeed, they’re doing all kinds of fascinating stuff with AI and ML to improve their security posture and incident response capabilities. Great stuff!

Cool Tools, PowerShell, Recent Activity, WED Blog

Deciphering PowerShell History Commands

May 22, 2023 Ed Tittel Leave a comment

Whoa! I just spent an enjoyable half-hour learning about the various PowerShell command line history viewing and editing tools. This comes courtesy of OhMyPosh creator Jan De Dobbeleer (@jandedobbeleer) on Twitter. Deciphering PowerShell history commands, in my case, involved a fair amount of interesting play and learning in a Terminal session. As you can see from the lead-in graphic, I had fun manipulating my command history (and then, updated OhMyPosh to catch up my test system).

When Deciphering PowerShell History Commands, Do This…

The operative way to understand PS history management is as a series of prefixes to “-history” at the command line — namely:

get: shows current PS command line history as stored for display
clear: clears current PS command line history
add: allows you to import a predefined command history from a file

There’s a lot more to managing history than you might think, as described in this MS Learn reference on the Clear-History command. Indeed you can tailor the history based on commands by number (from top or bottom of the history list, using -Count and other options) or by content (using the -CommandLine option and string-matching facilities).

Wait! There’s an Add-History, Too

You can save a representative command history by piping get-history into a CSV file. Later on, Add-History lets you import that file’s contents to imbue the current command history into your current PowerShell context. See this reference for more info.

Working with PowerShell history commands is great fun, actually. I’d suggest visiting the afore-linked references to take things for a spin. I find it useful to clear the history after such learning adventures (or after making mistakes at the command line that I’d just as soon forget…).

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

Another Interesting PowerShell Clean-up

April 28, 2023 Ed Tittel Leave a comment

Wow! What a ride… I was working on my Lenovo P16 Mobile Workstation this morning. Winget kept finding two versions of PowerShell — namely 7.3.8.0 and 7.3.4.0 — when I ran an open-ended upgrade command. That said, I couldn’t find the older version anywhere. Ultimately, this would lead me to another interesting PowerShell cleanup. Let me walk you through what I had to do to come clean, as ’twere…

Starting Another Interesting PowerShell Clean-up

I’ll begin by explaining where I started from. I was running the Preview version of PowerShell. The complete name string (FQDN equivalent): Microsoft.Powershell.Preview. The list command for that string was showing two versions in winget output, as described above. Upgrade attempts had no effect on the older version, despite reporting success. Sigh…

Also, when I searched all the folders where the software should be lurking (from the PowerShell environment variable), I found it nowhere. Likewise, my usual fallback trick — searching for filename pwsh.exe (the PowerShell executable) — showed only one instance.

Frustrating!

Ending the Clean-up Conclusively

When all else fails, remove/replace still does the trick. I ran the following commands to fix things so that only one version shows as in the lead-in graphic for this story:

1. winget uninstall -q Microsoft.PowerShell.Preview -v 7.3.8.0
2. winget uninstall -q Microsoft.PowerShell.Preview -v 7.4.0.3
2. winget install –id Microsoft.Powershell –source winget

That replaced the Preview with the Production version, and did away with the elusive (unfindable, even) older Preview version. Problem solved. Sheesh!

Note: Here’s a handy article from MS Learn “Installing PowerShell on Windows” that supplied me with number 3 above. Works well, but I did have to close my open PowerShell window for the install process to complete. Can’t have the old stepping on the new again, can we? Sigh again…

PowerShell, Recent Activity, Troubleshooting, Uncategorized, WED Blog, Windows 10, Windows 11

Windows 10 Dual Progress Bars Mystery

April 20, 2023 Ed Tittel Leave a comment

Back in November 2017, I posted the item shown in the lead-in graphic to Windows TenForums.com. I get two progress bars when running DISM ... /StartComponentCleanup on my Windows 10 PCs. The thread is interesting to read, and offers a good explanation in item#4 for what’s happening: a spurious line feed somewhere in the DISM routines that handle this task. Just this morning, I noticed that this Windows 10 dual progress bars mystery persists to this day. But I’ve figured out more…

More Data for Windows 10 Dual Progress Bars Mystery

This doesn’t happen every time I run DISM ... /StartComponentCleanup on my Windows 10 PCs. It happens only if I’ve just applied a Cumulative Update to that machine, and I haven’t rebooted the machine a second time after the post-update reboot. And, in fact, I just replicated this very same issue on one of my Windows 11 22H2 PCs as well in those same circumstances.

I’m still wondering about why this happens. I take it as ongoing proof that problems do make themselves visible in Windows (10 and 11) occasionally. Ditto for the observation that some glitches are more important than others.

This particular glitch, while interesting, is benign. It’s just a hiccup in the DISM output. Everything works as it’s supposed to, except for the dual progress bars (or appearance thereof if my TenForums informant is correct about the “spurious linefeed” theory). But here is the error in Windows 11 as well. Note: the build number shown, 22621, identifies this OS as Windows 11 22H2 even though the “Major” OS version reads “10.”

I love a good mystery. I hope someday to see this fixed, though…

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

Winget Discord Update Trick

April 11, 2023 Ed Tittel 2 Comments

I’ve got a new PC waiting in the wings to take over for my aging production PC. Right now, it’s ensconced in my son’s bedroom, where I use it as a test machine. He also games on it when he comes around. As a Discord user, he checks in on that app daily when he’s here. One of his tools pinned that app, so Winget can’t upgrade it through normal means (e.g. Winget upgrade –all or some equivalent). But I’ve discovered a Winget Discord update trick that works nonetheless.

Pinning Requires Winget Discord Update Trick

For some time now (as described in this July 2020 GitHub thread) users and programs can “pin” packages for Winget. This explicitly holds Discord to some specific version (or range of version numbers). It also means that unless Winget upgrade is targeted with a specific Discord version, it doesn’t perform the upgrade.

The trick to a successful upgrade is to use the –version parameter with Winget upgrade to explicitly specify the upgrade target. For example, I successfully upgraded the upstairs PC with this command:

winget upgrade Discord.Discord –version 1.0.9012

Note: I had to use the “full package name” for the Discord app (“Discord.Discord”). I also had to provide the complete version number (1.0.9012) following the –version parameter. After jumping through those hoops, the pinned version allowed the update. One presumes that the same approach will work for other pinned apps and applications with Winget as well.

It may take some squinting, but you can see Discord’s version info in the lead-in graphic at the far right. It reads “Host 1.0.9012 (30921).” To the left is a Terminal window that shows a successful targeted upgrade (update, actually) of the Discord app itself. It’s easy — if you know how. Those are the deets! And now, it’s all good…

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

Strange wt.exe Windows Terminal Behavior

February 28, 2023 Ed Tittel Leave a comment

I’ve got to admit I love nothing better than a good Windows mystery. And right now: I seem to have a doozy on my hands. Here’s the deal: if I open Windows Terminal on my production Windows 10 PC, it won’t run another terminal instance (wt.exe) either in PowerShell or in a Command Prompt pane. You can see this in the lead-in graphic above. The PowerShell error message also provides profound guidance on what’s going on here with this strange wt.exe Windows Terminal behavior. Can you see it, too?

Why Get Strange wt.exe Windows Terminal Behavior?

The clue is in the error message text where it shows the path for the version of wt.exe that PowerShell or Command Prompt tries to run. It’s the Preview version, which I have installed alongside the production version on this — and only this — PC here at Chez Tittel. By no coincidence, it’s also the only machine here that’s having this problem.

That said: I’ve also found various workarounds that bypass this issue:

1. Providing the complete path spec for the non-preview version launches a new Terminal window from Command Prompt. The complete path spec for the preview version still provokes “access denied.” It sits there and does nothing inside PowerShell.
2. Opening Voidtools Search Everything, right-clicking and selecting “Run as administrator” launches a new Terminal window for either version. The same approach works in File Explorer, too. Ditto for Start menu access (but only for the production version, which is the only one that has a Start menu entry).

Version Confusion Path Dynamics

To me, this problem seems obviously path related. And indeed, the first entry in the PATH variable on the affected PC reads:

C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_ 1.17.10234.0_x64__8wekyb3d8bbwe;

That explains why the shell tries to run the Preview version in the first place when it’s called at the command line. It’s very likely a side-effect of the Terminal Preview installation process. I didn’t edit PATH to include it, that’s for sure.

And it turns out that when wt.exe runs, it adds itself to the PATH. This raises the question of why, even when I launch the production version, the Preview is the version added to the PATH. Interesting!

Workarounds Will Cover My Needs

For the time being I can get Terminal to do what I need it to do without completely figuring out this strange path dynamic that’s at work. I imagine that I could simply uninstall the Preview version and my issue would disappear. I’ll think about and fool around with this for a while yet, and see if I can figure another solution. For further discussion of what turns out to be a bigger mystery than I was expecting see this github issues thread: Windows terminal path is different if launched with wt.exe. This one appears to possess Dantean qualities (“Abandon all hope, ye who enter here…).

Let me be clear about this, though. This happens only on one of my near-dozen Windows PCs. And it’s the only one with both Preview and Production versions of Windows Terminal running side-by-side. It’s definitely a tempest of sorts, but one in a pretty small teapot.

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

Updating WingetUI Brings Follow-On

January 31, 2023 Ed Tittel Leave a comment

I have to laugh. When I wrote yesterday about Winget moving up to version 1.4, I should’ve known it would carry items in its wake. Hence my update to the GUI front-end for Winget this morning — namely, the Github project known as WingetUI. I might have guessed, but did not, that updating WingetUI brings follow-on packages in its wake.

Instead I simply fired off the update process for WingetUI this morning, and moved onto another open window. I was happily surfing some traffic at ElevenForum.com when outta nowhere an install window for the Microsoft Visual C++ 2015-2022 Redistributable popped up on my screen. You can see the trace it left behind in “Programs and Features” (dated 1/31/2023) in the screencap above.

If Updating WingetUI Brings Follow-On, Then What?

I guess it makes sense that if Winget is updated, WingetUI should follow suit. I’m not sure if the new C++ Redistributable is a natural consequence of the update, or just a coincidence. But gosh! I’m of the opinion that if one program needs to install other stuff so it can work, it should at least notify you beforehand. Or even, ask permission.

But what do I know? Thus, I was a bit taken aback when the install window for the C++ Redistributable popped up today. It seemed kind of random and unexpected to me. Maybe it’s my fault for covering up the WingetUI install window with something else. Maybe it’s just one of those things that sometimes happens when you update software here in Windows-World. You tell me!

Cool Tools, PowerShell, Recent Activity, WED Blog, Windows 10, Windows 11

Obtaining Winget Version Info

January 30, 2023 Ed Tittel Leave a comment

A couple of weeks ago, a new version of Winget popped up on Github. Pretty much since then, I’ve been slowly but surely making sure all 11 of my Windows PCs are running this latest and greatest version (e.g. 1.4.10173). For me that naturally raised the question: How does one go about obtaining Winget version info? That led me back into the MS Learn documentation, about which I’ll now report.

Obtaining Winget Version Info Is Dead Easy

Turns out that winget is just another package, like all the others that the tool can download, install, upgrade, delete and otherwise manage. Thus a simple and basic winget command told me what I wanted to know:

winget –info winget

The lead-in graphic for this story shows this command and its resulting output. Note the first line after the command reads:

Windows Package Manager v1.4.10173

That matches the “Latest” version number at Github, so it’s the most current version around AFAIK (not counting previews). And indeed, I’m pleased to report that using standard winget upgrade commands has ensured that winget is current on all my PCs.

More than One Path to Enlightenment

I also noticed that winget syntax errors will report the version running before conveying its error message info. Thus, omitting the dashes before “info” in the preceding command will also tell you its version number (after which a pageful of syntax guidance follows). I guess you could deliberately mistype a command to produce the version number. But heck, I’d rather do it the right way if I can remember how.

One More Thing: Winget -v

Turns out that Winget -v (or -version) will produce just the info needed in compact readable form. Thanks to Demetrius Nelson (@DenelonMs) for pointing this out to me on Twitter! Why didn’t I think of that… Here ’tis:

Hmmm. It doesn’t get any easier than this.
Moral: RTFM (with more care)!

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

Winget Install Technology Hiccup

January 25, 2023 Ed Tittel 2 Comments

When I ran Winget to check for updates on the Lenovo P16 Workstation yesterday, something interesting happened. As you can see in the lead-in graphic, Winget found 2 packages in need of update. But it installed only one of them upon command. I discovered why when I attempted to force install the missing item. Indeed it produced what I’m calling a Winget install technology hiccup. Let me explain…

Overcoming the Winget Install Technology Hiccup Is Easy

The error message that resulted when I tried to force install RingCentral told me everything I needed to know. It reads:

A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version.

So that’s exactly what I did in the next two commands shown–namely:

winget uninstall ringcentral

winget install ringcentral

Luckily for me, the simple name “ringcentral” is sufficient to identify the unique and actual package name (“RingCentral.RingCentral”). Otherwise, I’d have been compelled to use that full, complete nomenclature to pull off the remove/replace maneuver that saw the hiccup overcome. That happens when multiple packages share common nomenclature, and a unique string for the desired package must be fully specified.

In this case, everything was easy-peasey. Just the way I like it: hiccup fixed!

Device drivers, Insider stuff, PowerShell, Troubleshooting, WED Blog, Windows 11

Windows 11 Power Options Oddity

January 19, 2023 Ed Tittel Leave a comment

OK, here’s one for the “Stranger Things” file. I was checking Power Options on a test laptop yesterday. In fact, it’s one of a pair of nearly identical machines: both are Lenovo ThinkPad X380 Yogas that differ only in SSD brand and OS variant (this one runs Beta Channel, the other one Dev). Yet this machine will show only two power plans under Power Options (see lead-in graphic). The other one shows all default items just as it should, and then some (see below) .

The Dev Channel X380 lets me view or hide additional plans; the Beta Channel X380 does not. What gives?
[Click image for full-sized view.]

Working Around Windows 11 Power Options Oddity

To attempt to fix the issue, I worked my way through the various — and terrific — Power Options tutorials over at ElevenForum.com. These include the following items:

Of those items, the first put the X380 in a state where I could restore missing power plans. The GUIDs for other plans remained available, but I couldn’t get the utility to offer an “Unhide” option so it would only show two Power Plans at any given moment. That said, having made other Power Plans accessible that workaround proved good enough for me.

Even the Master Remains Baffled

I exchanged a series of private messages with Shawn Brink, fellow WIMVP and a primary operator and tutorial writer at Eleven Forum on this mystery. We ended up concluding that a Lenovo OEM power management driver might be impacting the built-in Power Options control panel widget. I found and installed a new (Nov 29, 2022) Lenovo Power Management Driver for Windows 11.

At first, it made no difference in Power Options behavior. Following a reboot, though, while I still could not unhide other power plans in the initial Power Options pane shown as the lead-in graphic, when I click “Create a power plan,” it now shows all three default items correctly — namely Balanced, Power Saver and High Performance.

Here’s progress, of a sort. All the defaults show up when creating a custom plan. [Click image for full-sized view.]

I still have to work around the lack of an unhide capability to access invisible power plans using PowerShell. But at least I can now access and use all such power plans. This time, close enough is also good enough. Sigh. And that’s how things sometimes go, here in Windows-World.

Note Added January 23

I built an ISO to match the currently running beta image (22623.1180) from UUPDump.net. Then, I performed an in-place repair upgrade. I’d hoped this would fix the Power Options oddities. No dice: apparently, this is among the few problems that a prair install won’t fix. Sigh again.