I’m flummoxed. I just upgraded PowerShell from version 7.3.3.0 to 7.3.4.0. It’s the latest stable version, as you can plainly see at GitHub. But even after updating, that preceding version still shows up using winget list powershell. An explicit uninstall request reports “No installed package found matching input criteria.” Hmm; WTF? I can only call this a PowerShell update oddity version confusion problem!

If you look at the left-hand tab in the lead-in graphic, you’ll see two versions of Powershell, one numbered 7.3.3.0 and the other 7.3.4.0. But when I try to uninstall the older one, winget can’t find it. And indeed when I try to open it in the right-hand tab, it comes up at the current (latest) version. I’ve seen something like this before, so I start thinking about causes and workarounds. Read on to see how I resolved this one…

Resolving PowerShell Update Oddity Version Confusion

I’m of the school that says if you can’t do it one way in Windows, you can almost always find another. If I poke around in my file system searching on “pwsh.exe” (the name of the powershell executable file), I see an app-based instance of the 7.3.3.0 version in ProgramFiles\WindowsApps. And sure enough, inside Settings → Apps, I find three (count ’em) versions of PowerShell. Here’s a snap:
AFAIK, I only need the middle one, so I right-click to uninstall the other two. When I’m done, I check Windows Terminal, and it tells me I need to reset my default profile. I do, and choose version 7.3.4.0. When I open a new Terminal window and run winget list powershell again, it shows only a single (and correct) version. Problem solved!

Now, all I have to do is figure out why the winget uninstall didn’t work, but a manual uninstall inside the Apps widget in Settings did the trick. I’m gonna have to think about that for a while… Stay tuned!

I read, with some amusement and a sense of inevitability this morning  about a new Windows 11 feature. The latest Windows 11 Beta release (Build 22624.1610) supports presence sensing. Of course, special PC hardware augments are required. Apparently I have no PC new or advanced enough for this. Alas, no Windows 11 presence sensing for me!

What No Windows 11 Presence Sensing Means

If I remember correctly the notion of “presence” comes from computer telephony. It means the user is present and in front of the device (PC, in this case). Presence data helps guide whether or not requests and data go to users who’ve registered for specific conferences, events, and so forth. If they’re present, they’re included; if not, they’re not. And also, presence detection can work with Windows Hello (via IR camera sensing) to determine if a user is in front of the PC, to handle login and access.

My Lenovo P16 Mobile Workstation is pretty good at visual recognition. It’s also a mid-to-late 2021 vintage PC. Thus, I’m surprised that it apparently does not support Windows Presence. How do I know? There’s no “Presence sensing” entry in Settings → Privacy & Security → entry on that PC (or any of my other machines). Sigh. Why is that when MS announces a new Windows feature, I either don’t have it in the build, or it’s not supported on my PC? I guess it’s just a consistent turn of (ill) fate for yours truly.

I’ll see if I can remember to ask Lenovo to make sure this feature is present (pun intended) on my next eval unit. If so, I can check it out. If not, I don’t think it will kill me.

And so it sometimes (or often) goes, here in Windows-World. Stay tuned for news about other new stuff I don’t (or can’t) have. I’ll keep you posted.

In dealing with the never-ending story of Windows OS and app/application updates, I sometimes marvel at the obvious and visible role that certain installers play in that process. Fortunately, some tools — like PatchMyPc — make a virtue out of “silently installing” such things, too. The arrival of a new Intel Bluetooth driver this morning on some of my PCs prompted the observation that installing updates silently (or not) has real value. For me, at least… (see lead-in graphic for my inspiration).

Why Installing Updates Silently (or Not) Matters

It’s all about the user interactions. Some installers demand that users respond to their requests for permission and acknowledgement before they’ll proceed. This morning’s Bluetooth item, for example, required no less than four mouse clicks to go through its paces.

This matters because it makes life interesting for admins who have to automate updates via scripting and automation. It also explains the broad appeal of a product like RoboTask and AutoHotKey (see this Windows Report story for some useful coverage of this topic). Capturing mouse movement and clicks and replaying them becomes a vital ingredient in turning something done “by user, by hand” into something that can run as part of a general scheduled update process. But in general, such things are best avoided if possible.

Going Down the Rabbit Hole…

Switching over to silent updates can be challenging, though. Take a look at this Spiceworks forum thread that walks readers through the requirements involved in working with Chrome templates and Group Policy Objects (GPOs). It’s kind of scary, but also pretty fascinating. There’s a lot of research and, sometimes, effort involved in putting complete update packages together for automated deployment. That’s the kind of stuff I like to observe, and learn from, when I have the chance.