Category Archives: Updates

Teams App vs. Application Update Conundrum

I’m chuckling as I report this. Right now many people — including me — run both the app and the application version of Microsoft Teams on their Windows 10 and/or 11 PCs. I’ve been sussing out another update mystery in keeping Teams current, and have finally figured it out . . . I think. It seems there’s an easily overlooked Teams app vs application update conundrum in play. The Microsoft Store keeps the app version current on its own; regular applications often require human intervention for updates.  And to make things more interesting, this is apparently a case where WinGet isn’t always equipped with pointers to the latest, greatest update packages. Sigh.

One more thing: Because the Teams application runs as part of the Office (365 or 2019 or later “dated versions”) running update in Outlook, Word, PowerPoint and so on also takes care of the Teams application update. Good to know!

Solving the Teams App vs. Application Update Conundrum

I started twigging to my issue when I saw two entries for Microsoft Teams in my update scanner SUMo. Winget told me one of those instances was an application (ID: Microsoft.Teams; version 1.6.00.12455 was most current, but I was still running 1.6.00.6754). The other one was an app (ID: MicrosoftTeams_8wekyb3d8bbwe; version 23134.300.2089.5908; the _*weky… string in the ID is what tells you it’s an app, BTW).

That led to my “Aha!” moment. Microsoft Store keeps apps up to date pretty darn well without requiring human intervention. Regular applications, not so much. So I had to fire up the application, log in, navigate into Settings, and tell it to “Check for updates.” That did the trick, after which Teams was finally up-to-date. Amusingly it’s now running version 1.6.0.16322 — a higher version number than the SUMo recommendation that twigged me to this interesting issue in the first place. Go figure!

Keeping Windows apps and applications up-to-date is always interesting. In cases like this one, in fact, it may even be a little too interesting. But it’s always fun to figure things out.

Facebooklinkedin
Facebooklinkedin

Post-Update Cleanup Causes DISM Loop

I’m not sure what’s causing a fascinating Windows 11 issue. But you can see what it looks like in the lead-in graphic for this blog post. Basically, post-update cleanup causes DISM loop, whereby cleanup keeps repeating 100% completion, until I forcibly stop it with Ctrl-C. Weird!

I’ve never seen anything like this before. It occurred on Windows 11 Canary Build 25387.1200, after applying KB5027120 “2023-06 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Windows Version Next for x64.” This comes in the wake of KB5027849, released June 7, that takes the build to minor release number 1200. Again: Weird!

When Post-Update Cleanup Causes DISM Loop, What Now?

The traditional “next move” when something odd and extraordinary occurs in Windows is to reboot, and try again. So that’s what I did. The affected PC — a Lenovo ThinkPad X380 Yoga — came back up without any obvious signs of distress or damage. I was able to remote in without issues, either. And on a retry of the DISM… /startcomponentcleanup command it ran through to completion without further issues.

There’s a known oddity that this DISM command causes a weird doubling of the progress bar if (a) a CU is applied to a Windows 10 or 11 PC and (b) the command is run before the target system is rebooted for a second time. I can only speculate this oddity has been somehow exacerbated in this version of Windows 11.

Be that as it may, the old standby troubleshooting technique — reboot, and try again — seems to do the trick. Once again, the old “three-fingered salute” comes to the rescue. Go figure!

Facebooklinkedin
Facebooklinkedin

Tracking Minor Updates Poses Diminishing Returns

Here’s a question whose best practices answer may save admins time and effort. While indeed many developers now push regular updates for their software, not all are equally urgent. Why? Because whereas some updates add valuable new functionality or plug serious security gaps, others may not introduce much of note. That’s why, IMO, tracking minor updates poses diminishing returns against the time and effort required to find, download, and install them.

A case in point appears in the lead-in graphic. Antibody’s WizTree is a tree graph oriented disk space layout visualization and management tool. You’ll notice that winget doesn’t track release numbers past the first sub version level (e.g. 4.14 is what its “show” sub-command displays, and what its “list” sub-command finds on the target PC).

Why Say: Tracking Minor Updates Poses Diminishing Returns?

Simply put, if winget doesn’t track it and package labels don’t include it, not even the developer thinks it’s noteworthy. I’ve had other development teams confirm this approach to me. Thus, for example, when I contacted IObit to ask about minor revisions to their Driver Booster tool (example version number 10.4.0.127) they’ve told me that they don’t advise users to update unless something new or security-related is changed in a new version. If so, their policy is to increment version numbers more significantly, and to use the tool’s auto-update function to recommend and flog the update process forward.

Long story short: if the developer doesn’t recommend installing every minor update that comes along, I can’t do otherwise. For one thing: life’s too short to keep up with absolutely everything. For another, working toward scheduled update windows for most corporate software means choosing only “worthwhile updates” for inclusion. This reduces the amount of change — and its attendant risk — during such windows, and keeps the time and effort required to survive them as manageable as possible.

The old saw: “If it ain’t broke, don’t fix it” somehow seems apt. Don’t let OCD tendencies to keep up with all change put you in a bind. Relax, and watch the blinking lights instead…

 

Facebooklinkedin
Facebooklinkedin

Winget Upgrade May Require Cleanup

OK, then: yesterday dev lead Demetrius Nelson and his Winget team pushed an upgrade to winget. This comes courtesy of the Microsoft Store, and shows up as part of the App Installer and/or Windows Terminal packages. I noticed also that winget would occasionally throw the error “Failed in attempting to update the source: winget” as you can see in the lead-in screencap. What made it interesting was that it happens on some, but not all, of my Windows PCs. Now, let me explain why this post says that the “Winget upgrade may require cleanup.”

Why Say: Winget Upgrade May Require Cleanup?

When I saw this pop up in the wake of the new release, I figured the changes involved in pushing it out the door might have been involved. So I contacted Mr. Nelson and sent him (among other info) the screencap that leads this piece off. He responded this morning and explained how I could fix the issue, using the commands:

winget uninstall Microsoft.Winget.Source_8wekyb3d8bbwe
winget source reset --force

The first string removes the winget package from the PC. The second resets the winget environment, which is why the user must agree to Terms again before winget will run. After that it shows no upgrades are available (“No installed package found matching input criteria” with no accompanying error message (“Failed in attempting to update the source: winget”).

Problem solved; case closed. It’s always good to get the fix right from the source. Had to laugh about the “It won’t break while the engineer is watching” comment he sent me, too. Isn’t that just the way things go in Windows-World (and elsewhere in life)? LOL

See the whole thing here:

The fix is in — and working! Good stuff…

Facebooklinkedin
Facebooklinkedin

Updating Intel Processor ID Utility

Hmmmm. Here’s an interesting one. SUMo just told me that the Intel Processor Identification Utility (Legacy Model) needs an update. Poking around on the Intel site, I found a download page that covers Intel processors by generation: the new one goes Gen 12 and up; the old one Gen 11 and down. The old one appears beneath the new in the lead-in graphic, so it’s the one I downloaded and installed. That got me through Updating Intel Processor ID Utility on my i7 Skylake.

Why Bother Updating Intel Processor ID Utility?

The latest version of the new utility is 5/22/2023. The legacy one that works for my i7 Skylake shows a date of 5/17/2023 on the General Properties tab for the ProcID.exe file. That means it’s the latest and greatest of such files. I’m not aware of any security or other issues that the new version fixes. I’m just in the habit of updating as new versions come out. It runs just fine on the production PC. Here, for example, is the “CPU Technologies” info from that tool:

Updating Intel Processor ID Utility.CPU-tech

CPU Technologies show instructions, virtualization, sleep and other state info support (or not).

Intel Always Makes Updates Interesting

I feel lucky this morning that the landing page for Processor ID Utility took me to the update I needed. Sometimes, they don’t make it totally easy or simple to find the latest versions. Indeed, searching on version number (6.10.29.0517) didn’t work all that well for me. But this tool has an “Update” button subordinate to its Help menu. Now that I know this is an option, I bet it will work immediately next time around. That’s what makes updates interesting in general (and Intel in particular): there’s almost always a way to get a boost from the developer, if you know where and how to look for same. Sigh.

Facebooklinkedin
Facebooklinkedin

Winget Just Keeps Chugging Along

I’ve started a new writing and editing gig with TekkiGurus.com. I’m contributing 3-4 articles a month on Windows 10 and 11 topics, and providing input and feedback on their overall desktop OS coverage. Just recently, I started a series of stories for them on the Winget package manager for Windows. I’ve been using it daily for about a year now, and  I have to observe that Winget just keeps chugging along — and getting better all the time.

What Winget Just Keeps Chugging Along Means

Take a look at this morning’s results on my Windows 10 production PC (see lead-in graphic above). It just updated VS Enterprise 2022, TeamViewer, and Chrome, in under 2 minutes with only minimal effort from yours truly. I seldom encounter winget issues — and when I do, they’re nearly always easily resolved.

What continually suprises me is that using winget for updates is often faster than the in-app (or in-application) update facility itself. Visual Studio 2022 made an interesting case in point just now, when it updated that hefty environment (nearly 400 MB to start it going, and over 150 packages as the process worked to completion). It finished in well under 2 minutes on this aging desktop PC (i7 SkyLake, 32 GB RAM, 500 GB Gen 2 PCIe SSD).

Where Winget Falls Short Is Not Its Problem

I do still use other tools to keep my apps and applications updated. But that’s not winget’s fault. As I discuss in my March 17 post here, winget relies on developers to provide package manifests for their software so that it can do its install/update/query/uninstall things.

The list of items for which I have to use other tools includes some apps or applications that seldom get packages (Kindle, Zoom, Box, Dropbox, and others) or that have none (AFAICT). I encourage all developers who don’t already update winget manifests as they push updates to get in that habit.  (See this MS Learn item “Create your package manifest” to dig into that semi-automated YAML and PowerShell-based process.) It will make everybody’s lives easier in the Windows admin world — including mine! ‘Nuff said…

Facebooklinkedin
Facebooklinkedin

Pet Peeve: Upgrade Walls Around Free Versions

I was checking upgrades over the weekend (part of my daily routine, in fact). I found myself having to search for a specific version of a favorite app. Why? Because the developer erected upgrade walls around free versions of the app. It’s just a “little reminder,” I guess, that users should support developers by paying for what they use.

Why Put Upgrade Walls Around Free Versions?

Basically, the developer steered its “manual update” capability into the purchase dialog for the same program’s for-a-fee version. I have the paid-for version on my production PC, in fact. But I don’t pay for the instances I run on my test PCs (which vastly outnumber my home desktop and traveling “work laptop” — by 5 to 1). It just ticks me off when the developer leads users down a road with no obvious access to downloading the free version through the application’s own built-in update facility. Am I wrong to feel that way?

I don’t think so. But in this case, I had to remember that the name of the free version includes “lite” in its name (cute). Then, I had to Google the name of the application with that string in its name to get to the right download page. Not too challenging, but at least mildly vexatious, IMO.

The Pecuniary Imperative

Sure, developers need income to justify their time and effort spent in creating and maintaining their offerings. But do users need to be reminded that they could pay for the for-a-fee version each time they update (or upgrade) its free counterpart? Depends on who you ask: some developers obviously feel that the answer to that question is “Hell, yeah!” As for me, I just find it somewhat annoying.

Sigh. That’s just the way things go in Windows-World sometimes. Thanks for letting me vent…

Facebooklinkedin
Facebooklinkedin

Intel DSA Version Confusion

OK then, I’m back in the office after a 10-day hiatus. Natch, after meeting today’s writing deadlines, I started updating all 11 of my Windows PCs. Along the way, I found myself caught up in Intel DSA version confusion for that company’s Driver & Support Assistant software.

Look at the lead-in screencap. The Intel download page shows version 23.2.17.8 is the latest and greatest version. Yet the details for the download file show it as version 23.1.9.7. And indeed, when you install or repair DSA using the file the lower-numbered version is what’s installed. Go figure!

Overcoming Intel DSA Version Confusion

After handling over 100 updates, the Patch Tuesday and incidental WU stuff, I didn’t want to find myself troubleshooting a bogus update problem. But that’s what I’ve got going on. Until Intel puts the update for version 23.2.17.8 in the “Latest” position on its download center, there’s not much I can do to fix this.

C’mon Intel: please fix this issue so OCD updaters — like yours truly — can get caught up. I’ve already got 23.1.9.7 (the version that actually appears in the Properties window for the 23.2.17.8 download) installed. I can’t catch up until the right file gets posted to the download center.

It’s Always Something, Right?

Just goes to show you that here in Windows-World there’s always some kind of gotcha lurking to make life more interesting. In some cases, my issues are of my own making. In this particular case, it looks like something odd is up with the Intel download page itself.

Just for grins, I went to an alternate download source. Much to my surprise, that installer shows the correct version number for this file, to wit:

Intel DSA Version Confusion.alt-source

An “alternate download source” DOES have the right file.
Go figure again!

I wish I knew how the other source got the right file, when I couldn’t grab it myself directly. As Mr. Churchill said of Russia, that makes this “a riddle, wrapped in a mystery, inside an enigma.” I don’t know whether to laugh, or cry.

Facebooklinkedin
Facebooklinkedin

Winget Discord Update Trick

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…

Facebooklinkedin
Facebooklinkedin

The Never-ending Windows Update Story Carries On

Back on March 6, I posted an item about Windows Application Update Rhythms. This offered a snapshot for a week’s update activities across my various PCs. Since then, of course, the updates have continued as the never-ending Windows Update story carries on. I’ve made some interesting observations since then, too.

The lead-in graphic above shows one such data point. I’ve begun to notice that sometimes Winget will update Chrome, and sometimes it won’t. It seems to be related to whether or not the app is open at the moment (yes if closed; no if open).

Never-ending Windows Update Story Keeps Going…

The same thing appears to be true for PowerShell as well, as you can see in this next screencap. Amusingly, the app itself is PowerShell so indeed it’s obviously running too. But there are ways to force a PS upgrade within the app, so this default behavior can be over-ridden. The second post in this SuperUser thread explains how to do just that. It grabs and uses the PS install MSI from GitHub to make that happen.

Never-ending Windows Update Story.update-PS

Winget updates neither Chrome nor PowerShell here.

What’s Behind the Apparent No-Upgrade Behavior?

In various discussions online as to what’s at work here, I learned (or re-learned) a few things. When installer formats change (MSIX to MSI, MSI to EXE, and so forth) Winget won’t perform the update. Indeed, I’ve seen explicit messages to this effect in Winget output from time to time. This Answers.Microsoft.com thread explains how to grab, then use, the download URL for the Chrome installer to bypass the failed (and silent, error-message-wise) Winget update. Likewise interesting!

The more I work with Winget, the more I learn about its various hiccups and gotchas. But the tool continues to impress because there’s nearly always a clever workaround to get things done. It’s definitely made the various installments of the never-ending Windows Update story around Chez Tittel shorter and more entertaining. What more could a Windows-head like me want?

Facebooklinkedin
Facebooklinkedin