Category Archives: PowerShell

Windows 10 Phone Link Eliminated

Dang! After messing about with PowerShell unsuccessfully, I turned to long-time fave 3rd-party tool Revo Uninstaller Free. Seems that Windows 10 doesn’t allow the Phone Link app to be uninstalled anymore. Sadly, the Uninstall option is greyed out in Settings. Likewise, I couldn’t get PowerShell Get-AppxPackage | Remove-AppxPackage to work, either. But if you turn to Revo Uninstaller, it delivers the goods: Windows 10 Phone Link eliminated.

Why I Want Windows 10 Phone Link Eliminated

Two reasons:

1. Phone Link only works with Android phones and I have iOS. Don’t use it, ever.
2. Update failed, then app “stopped working, around recent Store revisions.

If I can’t use an app AND it causes errors, I don’t need it. Thus, I want it gone!

Look at the lead-in graphic. I’ve put a red box around the listing item for the Phone Link app on my Windows 10 production desktop. Right-click on that item, and the first menu option is “Uninstall.” Pick that. Revo asks you to confirm that choice, as follows:

Windows 10 Phone Link Eliminated.confirm

Alas, PS does NOT show the command details it uses to pull this off. Sigh.

Revo Unsintaller works some PowerShell magic around the following text I copied:

Deployment operation progress: Microsoft.YourPhone_1.22092.211.0_x64__8wekyb3d8bbwe

After removing the app, I used the Revo Uninstaller Scan functions to remove all leftovers from the Registry. It no longer shows up on my Windows 10 PCs — all both of them. I will be on the lookout for reappearances after CUs and feature upgrades, based on what I read online about how Phone Link keeps showing back up.

When it comes to “Windows pest removal” sometimes, repeated treatments may be required. LOL!

Facebooklinkedin
Facebooklinkedin

Repair Upgrades PowerShell

Here’s something I didn’t know before. Or at least, I never tried it. Just recently (November 8) MS released a new 7.3.0 version of PowerShell to GitHub. I’ve been upgrading my various systems since, slowly but surely. This morning I learned that opting for Repair upgrades PowerShell. Let me show you what that means.

Showing How Repair Upgrades PowerShell

On some PCs, winget upgrade may not show the new PowerShell as an option. (I’ll use my Lenovo Yoga 7i as an illustration because it manifests such behavior.) You can see it’s running version 7.2.7 and that PowerShell does not show up in the output from winget upgrade below:


If that’s the case, here are the steps to using repair to upgrade PowerShell on such PCs:

1. CTRL-Click on the link that reads https://aka.ms/powershell. This opens the MS PowerShell Documentation page.
2. Click on the “Download PowerShell” button at the upper right. This takes you to the GitHub Latest release page for PowerShell (7.3.0, as I write this, but updated as new versions emerge). Then close all open PowerShell sessions.
3. Scroll down to assets and download the installer file for your PC (for most readers the 64-bit MSI is the right choice: PowerShell-7.3.0-win-x64.msi)
4. Run the microsoft self-installing (MSI) file to start PowerShell installation. Step through all the installer prompts. If the Repair option comes up, select it (shown in the lead-in graphic for this story). It will run and “fix” the current installation.

At the end of this process, you’ll have a working upgrade to version 7.3.0. Cheers!

What About Winget Upgrade Microsoft.Powershell?

Gosh! That works too but finishes strange. Let me show you, in the following screencap (click on image to view full-sized):

The output doesn’t actually confirm a successful install of PowerShell 3.7.0. It shows a progress bar, and a status of “Starting package install…” Then it transitions to a command prompt. In the background, the new version is installed and running. But because you’ve got a 7.2.7 window open, you don’t see the 7.3.0 label until you close the old window and open a new one.

It’s always something, right?

Facebooklinkedin
Facebooklinkedin

Further Kindle Update Follies

Yesterday I worked through my blog post from earlier in the week on yet another PC. As it happens, the initial step — using winget to uninstall the outdated Kindle version — was highly fortuitous. Even though the subsequent winget install Amazon.Kindle brought in the wrong version (because of the package definition), removing the old version is a good way to start the upgrade process. In my further Kindle Update follies follow-up, not uninstalling left the old version behind alongside the new. Wait! It gets even more interesting…

What Happened with Further Kindle Update Follies?

When I found I had two side-by-side versions, I ran Revo Uninstall to try to take out the old one. That left me with no Kindle at all (even though I didn’t do the post uninstall cleanup that Revo does itself). So, I got to install the correct version again. That worked!

Here’s my new recipe for manual Kindle updates.

  1. Grab the latest version from the Kindle download page.
  2. Run winget uninstall Amazon.Kindle in an admin PowerShell (or Windows Terminal) session
  3. Run the downloaded Kindle installer (as I write this, that filename is KindleForPC-installer-1.39.65323.exe, but that will change)

One more thing: before you follow this recipe, try opening the Kindle app. Sometimes — and I stress this word, “sometimes” — it will actually update itself as part of its launch process. Because I haven’t been able to figure out why it works sometimes and not others, the recipe serves as a follow-up should it not auto-update itself.

This is kind of whacko. I repeat an earlier plea to the Amazon developers: please add an update function to the Kindle for PC software. Or, have the installer clean up the old version after it brings in the new one. It’s just too tricky to find and manage updates for ordinary users right now. IMO, that definitely needs fixing …

Note Added November 7

I’ve been working through updates on a bunch of PCs today. Many (most) have needed a Kindle update. I can now conclusively confirm that my foregoing recipe works to update Kindle without apparent issues. Consider it a validation, of sorts…

Facebooklinkedin
Facebooklinkedin

Using Winget For 4 Ways To Update

I’ve been researching an upcoming ComputerWorld story about the terrific and powerful PowerShell based Windows packager: Winget. It’s a peach! I mostly use it for keeping applications and supporting elements current. Lately,  I’m  using Winget for 4 ways to update my apps. Let me explain…

How-to: Using Winget for 4 Ways to Update

Way 1: Check Pending /Available Upgrades

By itself, the command winget upgrade simply shows what’s ready to upgrade. It doesn’t actually do any upgrades. Thus, it offers a quick easy way to see what upgrades are available. That’s why it appears as the lead-in graphic for this story.

Ways 2 & 3: Perform Blanket Upgrades

In fact, two different command strings provide varying degrees of upgrade capability

  1. winget upgrade –all
  2. winget upgrade –all –include-unknown

By default winget only upgrades to a new version when it recognizes the current version. Then, if the current installed version is lower-numbered than the pending one, the upgrade goes ahead. Some-times, for whatever reason, winget can’t find the current running version into. In such cases, the upgrade –all variant skips them. Thankfully, adding –include-unknown to the string tells winget to upgrade those anyway. Consequently, I use that more inclusive variant because there’s less follow-up needed.

To illustrate, the next screencap shows winget upgrade –all –include-unknown output on the PC that produced the lead-in snap. Notice please: 5 items found, 5 items upgraded. Good-oh!

The –all –include-unknown variant of winget upgrade covers the most possibilities. On this PC, all 5 candidates upgrade.
[Click image for full-sized view.]

Way 4: Targeted Winget Upgrades

Examined closely, both preceding screencaps shows an ID column. Indeed, that information provides a “package name” for its associated application. Thus, you can always upgrade a single package at time using this syntax:

winget upgrade <package-name>

For example, names shown in the screencaps include Mozilla.Firefox, TeamViewer.Teamviewer, AntibodySoftware.Wiztree, Google.Chrome and Microsoft.WindowsSDK. That follows a mostly predictable structure: builder-name.package-name. For speed, I like to use it when winget presents only a single option, or when a winget blanket command fails.  I’m learning that happens sometimes, for various odd reasons.

There are many ways to work with winget I haven’t yet mentioned. These could appear in future posts here. Certainly, they’ll definitely be covered in my upcoming ComputerWorld piece. Right now, that’s scheduled to appear online before month’s end. Hopefully, you’ll get a chance to catch that during the busy holiday season.

 

Facebooklinkedin
Facebooklinkedin

Winget Updates PowerShell 7.2.7

Here’s something new in my personal experience. I ran Winget on one of my Dev Channel test PCs this morning. The latest version of PowerShell came up as an upgrade option. So I exercised it, and indeed the PowerShell version incremented from 7.2.6 to 7.2.7. Hence my claim that now, Winget updates PowerShell 7.2.7. You can see the process underway in the lead-in graphic for this story.

What Happens When Winget Updates PowerShell 7.2.7?

Things get a little weird along the way. Notice that after Winget starts the package install for PowerShell, it shows a “Cancelled” notification at the lower left corner of the Terminal session window. At the same time, the PowerShell installer (small pane at lower right) reports ongoing progress in removing the old version, then installing and configuring the new version.

When the progress bar goes all the way to the right, it simply disappears with no further communication from the installer. On a whim, I closed the open Terminal session window. When I opened a fresh one, here’s what I saw:

Winget Updates PowerShell 7.2.7.new-window

Once the progress bar completes, the installer goes silent. But if you close the open Terminal session, then open a new one, you’ll see it’s indeed been updated to 7.2.7.

I’m not sure how it’s supposed to behave because I’ve never seen winget upgrade PowerShell before. Normally, a full installer window opens with the masked PowerShell avatar (see below). Then, one steps through the typical standalone installation sequence. This time, with PowerShell running things it worked differently. A bit disconcertingly, too. But it’s installed now and works as expected. So I guess, all’s well that ends well. Cheers!

Winget Updates PowerShell 7.2.7.avatar

I guess I’ll miss the avatar going forward, but I do appreciate the convenience of upgrading inside PowerShell.

Facebooklinkedin
Facebooklinkedin

Working with WinFetch

WinFetch is a windows-focused knock-off of another well-known shell tool named NeoFetch. Each is written to show useful and informative data about systems from within a command-line shell environment. NeoFetch is built atop bash; WinFetch atop PowerShell. IMO, that makes WinFetch more suited for use with Powershell. I’ve been working with WinFetch a lot lately, learning how to use it to help me see what I’m doing with Windows Terminal and PowerShell customizations. Indeed, it’s pretty helpful. But I’ve also been learning some lessons the hard way as I go. Let me explain…

Why Working with WinFetch Takes Some Effort

The documentation on WinFetch is kind of sparse. In fact, I’m starting to think I should spend my time reading the NeoFetch stuff, because it may shed more light on the inner workings of WinFetch. Straight from its GitHub home, there’s precious little info available about its details and settings. Sigh.

So far, the lessons I’ve learned the hard way include:
1. You must save the config.ps1 file that governs WinFetch behavior for its changes to take effect.
2. Sometimes, a reboot is required, above and beyond a simple save. I can’t tell why, but I found myself stuck a couple of times on this hump. If you make a change, save the config file and it has no impact on the WinFetch output, try a reboot. It may do the trick.
3. Customizing the WinFetch config is totally a trial-and-error exercise. Be prepared to spend lots of time tweaking and checking, then repeating ad infinitum. Sigh again.

Customizing for Winget Package Mgr

It took me a while — including plenty of the aforementioned trial and error, but I got WinFetch to look at and report on Winget packages. Here’s the syntax, straight from the config.ps1 file that makes WinFetch work:

$CustomPkgs = @(“winget”)
function info_pkg_winget {
return ((winget list | measure-object).count)
}

What you’re doing is telling winget to list all the packages it knows about, then piping that input into the measure-object cmdlet. Using its count attribute you simply show the overall package count. Sublime!

Facebooklinkedin
Facebooklinkedin

Get-Hotfix Shows What WU Sometimes Cannot

When MS lifted the safeguard hold on  my Lenovo P16 Mobile Workstation, I upgraded it to Windows 11 22H2. Naturally, my first thought thereafter was to check on status of recent updates and fixes. That’s when I figured out that KB5018427 was included in the 22H2 version installed. Seems that Get-Hotfix shows what WU sometimes cannot — at least as far as Update History goes.

It’s all apparent in the lead-in graphic for this story. In case it’s not legible enough, right-click on that image and select “Open image in new tab” (Chrome, Firefox, Edge, etc.). That should show it at original resolution. If necessary, you can use the browser’s Zoom controls to magnify the text.

How Get-Hotfix Shows What WU Sometimes Cannot

Update history shows only user-alllied updates. It does not show updates that — like KB5018427–get rolled up into the windows image file (WIM) used to install a version upgrade. That’s what makes the PowerShell Get-Hotfix command so useful. Its image analysis tool tells it what’s there, whether the user applied it directly, or whether it’s already “in there” as is the case here.

An important clue appears in the “Installed on” date shown in the output of Get-Hotfix. Although the KB item itself is dated 10/11/2022, it didn’t get rolled into the WIM until 10/14/2022.

What Led Me Down This Trail?

I read the Windows Latest story about KB5018427. Naturally, I wanted to check on its status in the upgraded 22H2 version. When I didn’t see it in Update History, I visited the Microsoft Catalog and downloaded the 64-bit MSU file. Upon attempting its installation, it searched the updates already installed on the PC. That produced the following status message:

That made me understand the KB had been included in the WIM file I’d already installed. A search on “use PowerShell to show updates installed” led me to the Get-Hotfix command.

As the afore-cited PowerShell docs states:

The Get-Hotfix cmdlet gets hotfixes, or updates, that are installed on the local computer or specified remote computers. The updates can be installed by Windows Update, Microsoft Update, Windows Server Update Services, or manually installed.

Thus Get-Hotfix can catch patches and fixes no matter how they get included in the image it checks and reports upon. The rest, as they say (drum roll, please)… is history!

 

Facebooklinkedin
Facebooklinkedin

Exploit Winget Include Unknown Syntax

For the past couple of years I’ve been learning — and using — the Microsoft package manager, Winget, It helps me keep my PC apps updated. Just recently, I’ve learned to exploit Winget include unknown syntax to broaden its coverage. Basically, this will “upgrade packages even if their current version cannot be determined.” That quote comes from the upgrade command section of the MS Winget documentation.

How to Exploit Winget Include Unknown Syntax

First, that syntax couldn’t be simpler: just add the string
--include-unknown
to the usual invocation for winget . For the record that’s
winget upgrade --all
. This tells the program to apply upgrades for all packages with known versions. You can see this at work in the lead-in graphic for this story, in fact. Chrome shows up when unknowns are included, but not otherwise. (Compare top and bottom sections, or view the image full sized by clicking the following thumbnail.)

Exploit Winget Include Unknown Syntax
Exploit Winget Include Unknown Syntax

The difference between the unadorned “all” version of Winget upgrade and the one with unknowns included applies in large part to applications like Kindle, Chrome, Firefox, and more, which apparently do not report their current version numbers either consistently or well to Winget during its initial survey phase.

This addition to the command finds those things and attempts to upgrade them. Certain apps — most notably Teams — will not work with this tool because of version mismatches (and the prudent decision not to overwrite versions outside the same version tree). But this does improve its overall coverage. That lowers the number of apps and applications I must update manually. To me — and to you, too, I bet — that’s a good thing!

Note: Winget works in PowerShell with equal facility for both Windows 10 and Windows 11. It’s become one of my go-to tools for keeping my small fleet of PCs (currently numbered 12, with 2 going off to college with my son soon) up to date.

Facebooklinkedin
Facebooklinkedin

Windows Terminal PowerShell Selection

I have to laugh. Yesterday, I noticed version 5 of PowerShell  running inside Windows Terminal. So I naturally wondered: “How do I upgrade this?” Turns out, in fact, that no upgrade is needed. It all comes down to the current Windows Terminal PowerShell selection. I’ll explain shortly, but first: look at the window in the lead-in graphic.

Managing Windows Terminal PowerShell Selection

By default, version 5.1.xxx… appears when you open Windows Terminal. But it’s easy to get to a newer PowerShell version. No upgrading is necessary: you need only know how to do this. If you click on the down-caret at the far right of the title bar, a menu appears, like this:

Windows Terminal PowerShell Selection.choose shell

The down-caret menu lets you choose among shells you can run in a Windows Terminal tab. [Click image for full-sized view.]

The trick — if you can call it that — is to choose the right version of PowerShell (and corresponding default) to run. The top item in the menu corresponds to version 5.1.xxx. The fourth item down brings up the latest 7.x PowerShell version (specifically, 7.2.5). If you click Settings, you can also choose this version as the “Default Profile” which makes the new version (rather than the 5.1.xxx version) appear whenever you open Windows Terminal, or click the “Plus” sign to open a new default Terminal tab.

As with many other things in Windows World, foreknowledge and understanding are key to doing things right. In my case, I had no need to update PowerShell. I only needed to pick the right version to run inside Windows Terminal. Now I know how. If you didn’t know how already, this should make things equally simple for you. Cheers!

Facebooklinkedin
Facebooklinkedin

WingetUI Offers Useful Update Capability

Lately, I’ve been using the Winget PowerShell applet to assist with updating my Windows 10 and 11 PCs. Thanks to Martin Brinkmann at Ghacks, I’ve found a GUI front end for that tool. Indeed, the aptly-named WingetUI offers useful update capability.

Winget.UI does other things, too. It let you explore all 3460 packages under its purview (“Discover Software” tab). It also shows a complete list of all packages already installed on your PC (“Installed applications”). On first blush, Winget.UI looks like a good tool. Its GitHub page provides the lead-in graphic for this story.

Winget.UI Offers Useful Update Capability.updates

“Available updates” quickly identifies and provides ready access to item-by-item update launch. [Click image for full-size view.]

What WingetUI Offers Useful Update Capability Means

To update an item from the Software Updates tab in Winget.UI (shown above), simply double-click its corresponding Winget entry under the “Installation source” heading. Personally, I find this prefereable to the winget upgrade --all command. Why? Because it provides item-by-item control. That lets me skip elements (such as MS Teams), which experience has taught me isn’t really amenable to winget updates.

The double-clicking takes a little getting used to, but by and large the update function works well. It worked well for third-party packages, including Kindle, Python 2, and Revo Uninstaller. It hit errors on some built-in MS components, such as the WADK and Edge Runtime. Based on prior history, I didn’t even try the Teams components.

Good, But Not Perfect

I’ll need to spend more time with WingetUI to fully understand and appreciate its foibles and strengths. For now, it’s much like other update tools I use: good — indeed, pretty helpful — but by no means either great or perfect. Perhaps that’s just the way that update tools work here in Windows World!

[Note: Nochmals Danke schoen to Mr. Brinkmann for an interesting find.]

Facebooklinkedin
Facebooklinkedin