After recent updates to Office on Windows 10 and 11, AI support shows up in Task Manager. It’s in a process named “ai.exe” of which you can see four instances in the lead-in graphic. That comes from my Windows 10 production desktop, but you can also see this running in Windows 11 versions as well.

That said, this facility comes from Office, not OS, upgrades. That means it won’t show up on PCs that aren’t running Office 365 or newer standalone versions. Nevertheless, I find it interesting that MS is moving AI into its own processing environment away from the executables for individual office components (e.g. Word, PowerPoint, Excel, Outlook, Teams and so forth). In fact, I’m guessing that the reason I see four instances in Task Manager reflect recent use of all four of those components recently on this very PC.

What AI Support Shows Up in Task Manager Says…

It tells me that MS is really getting serious about supporting AI throughout its application stack. I have to presume that support in the OS itself won’t be too far behind. Yesterday’s announcement that new Surface devices will support Neural Processing Units (NPUs) to speed AI workloads therefore comes as additional confirmation. To me,  this represents a shift in the kinds of things that OSes and apps can do, and handle, as part of normal operations. AI is here, and it’s not going away.

Read more about what’s going on here in this Windows Latest story dated April 10. It’s got much more detail about the processes, folders, and executables that have recently popped up in Windows 10 and 11. Personally, I find it fascinating, and hope to see tangible impacts in my work with Office apps soon. So far, after a six-day stretch during which I’ve worked in Word all day long (8 hrs +) I haven’t really noticed anything… But here’s hopin’, right?

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!

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.