Category Archives: Windows 10

RDC vs. Remote Desktop

I make remote connections to Windows PCs all the time, every day. I often switch between the Remote Desktop  Connection (RDC, aka mstsc.exe) and the Remote Desktop app (9WZDNCRFJ3PS in the MS Store). Lately, I’ve noticed that the .exe is prey to a hiccup to which the app is not — namely, RDC will often hang at the lock screen with spinning balls frozen when I start a remote session. Remote Desktop never does this. Because I know RDC better than Remote Desktop I used to prefer it. Because I favor speedy in-and-out over redoing my link I’m now leaning toward the latter. Thus, in my recent estimation of RDC vs. Remote Desktop, the app is gaining favor.

More Differences in RDC vs. Remote Desktop

This got me to wondering about other differences between the older exe and the newer UWP app. Looks like Remote Desktop can do other stuff that RDC cannot, too, including:

  • Auto updates through the MS Store (Winget handles mstsc.exe)
  • Modern UWP app interface with thumbnails and minimal controls (Full-Screen and Disconnect only)
  • Access a complete remote desktop or access one remote app without running a complete remote desktop
  • Works across MacOS, iOS/iPadOS, Android, Chrome and Web browsers (IDKICDT)
  • Multi-monitor support lets Remote Desktop map multiple monitors from remote client to host desktop
  • Works with Azure Virtual Desktop and Windows 365 Cloud

In some situations, I can see where single-app remoting could be good. I also like support for multiple client OSes and monitors. I wish I had the ability to try out the cloud capabilities, too. Sounds like fun.

Maybe It’s Time to Join the 21st Century?

I’m thinking I should be using Remote Desktop more than RDC. I think I’ll try it for a while and see how it goes. It could be that some of my issues with VMs might also be MIA in the newer app. Let’s find out!

Facebooklinkedin
Facebooklinkedin

Windows.old Required For Uninstall Window Access

Here’s an interesting Windows gotcha that affects both Windows 10 and 11. There’s an interval setting value in these OSes that controls how long Windows.old stays on your system disk before it gets deleted. It’s called the “OS uninstall window” and it’s set to 10 days by default, though any value from 2 through 60 (days) is legal. That said, you can only see and manipulate this value if Windows.old is present on the target system. That’s what the title means when it says “Windows.old required for uninstall window access.”

Why Is Windows.old Required For Uninstall Window Access?

God only knows (and possibly a few Microsoft OS engineers). That’s just the way it works. Indeed the relevant MS Learn article doesn’t comment on the why; it only documents the how. I had to go to Google to get an explanation for what you see in the lead-in graphic — namely, that when you run the DISM command that tells you the current uninstall window value for Windows.old, it throws an error if there’s no Windows.old present on your system for it to inspect. Weird.

The best explanation I found is at SuperUser.com. The short answer to “Why an error and not a number?” reads simply “No, you are too late.” That is, once Windows.old is removed, the command no longer works the way one might presume it should. In short, if no Windows.old is present, the OSUninstallWindow value is not available, nor can it be reset. Again: Weird.

Even weirder: you’d think there would be a registry value to control this. But alas, as Copilot informs me and my truth-check research confirms “There isn’t a specific registry value in Windows 10 or 11 that directly controls the OSUninstallWindow value.” It’s just another Windows oddity for the ages. Now I know (and now, you do, too). Cheers!

Facebooklinkedin
Facebooklinkedin

DevHome App Faces May Retirement

It was both fascinating and a little disheartening to learn yesterday that the Microsoft DevHome app faces May retirement. I have come to really, really appreciate DevHome for two reasons — namely:

1. It supports easy creation and management of ReFS drives in both Windows 10 and 11.
2. It demonstrates that MS can indeed fully automate the creation of Windows Hyper-V VMs, even though Hyper-V Manager still includes glitches one must work around to bring up such VMs manually.

Initially, I learned about this yesterday from long-time Window developer and watchdog Rafael Rivera via X (@WithinRafael). But this morning, Sergey Tkachenko posted an item at WinAero that shows a DevHome notification to the same effect.

Decoding What DevHome App Faces May Retirement Means

I’ll be darned if I can find the notification that Sergey displays in the WinAero post (and which Rafael included in his initial X info). I made sure Microsoft.DevHome (the app’s WinGet ID) was up-to-date. As you can see in the lead-in graphic, I even uninstalled, then reinstalled DevHome using WinGet just to make sure I wasn’t missing something. No dice.

All this said, I’m guessing that the various extensions and utilities that DevHome makes available, and its ReFS and Hyper-V VM capabilities,  will show up in other parts of Windows 11 around May as well. Sounds like a pretty good platform for 25H1 updates, in fact. What I can’t say because I don’t know is if MS will decide to do likewise for Windows 10, which currently supports DevHome (via the MS Store; it’s pre-installed in Windows 11 starting with 23H1 and thereafter).

I guess it will be interesting to see what happens with these various bits and pieces, several of which have garnered my appreciation. Plea to MS: please, please, please fix Hyper-V Manager so that it will do what DevHome currently does with panache — that is, automate VM install with the added capability to point to on-disk images or ISOs. If you want to understand how things work now, and what workarounds are necessary to bring a VM in Hyper-V Manager, see my September 24, 2024 ComputerWorld story How to set up Windows 11 Hyper-V virtual machines. It’s kind of a mess, frankly…

Facebooklinkedin
Facebooklinkedin

WinGet Boosts Chrome Update Capability

Here’s an interesting item. Previously, WinGet wouldn’t update Chrome on Windows PCs where it was running. Now it will, because WinGet boosts Chrome update capability. It now runs the installer with admin privileges to overcome the maxim “don’t mess with running processes.” You can see it working in the lead-in graphic, where the text reads (in yellow):

The installer will request to run as administrator, expect a prompt.

If WinGet Boosts Chrome Update Capability, Users Benefit

This means users must still Relaunch Chrome to get the update to take, though WinGet applies the update. Previously, WinGet would just skip the whole thing. Now, the next time users open that browser, the new update will take over (or, they can manually use the Relaunch button themselves).

After WinGet does its thing, Relaunch remains required to leave running processes undisturbed.

Will Other Browser Makers Follow Suit?

Here’s a shout out to the dev teams for Edge, Mozilla/Firefox (and variations), Opera, and others. Take heed of this Chrome action and do likewise. Your users — including your truly, most fervently — will thank you.

It’s just another small step for WinGet. But it translates into a big boost for the Windows user base. Keep up the good work, people!

New PowerShell Version Out, Too…

While I’ve got your eye, a new PowerShell version — v7.5.0 — is out. It’s still new enough that WinGet won’t install it yet. If you, like me, are OCD enough to want to run it before it gets into the pipeline, download it from the assets on the Release v7.5.0 page.

Note added 15 minutes later: Nevermind, it’s already showing up in WinGet. I should’ve known @Denelon and the team wouldn’t sit on their hands here. Another attaboy for that group and the PowerShell team. Good-oh.

Here, you can see the old 7.4.6 windows left, and a new 7.5.0 window right. God: I *LOVE* Windows Terminal.

Facebooklinkedin
Facebooklinkedin

UniGetUI Beta Previews Advanced Features

Yesterday, Marti Climent — the lead developer for UniGetUI (formerly known as WinGetUI) — dropped a new beta version (3.1.6-Beta2) of the program into GitHub. This UniGetUI Beta previews advanced features planned for the next official release, when it transitions into production. Right now, it may be worth downloading and playing with to see what it can do (IMO). But the developer’s “Caution” on this release reads “Prerelease builds can be unstable and should not be used on a production environment.” There: you’ve been warned.

Exploring UniGetUI Beta Previews Advanced Features

A good way to understand what’s in 3.1.6-beta2 is to visit its release page at GitHub. There you’ll see that info listed under “General Changes.” Minutae appear in the detailed changelog (summarized under “What’s Changed” on the GitHub page). Highlights:

  • Downloads provide more detailed status info, including download and install phases
  • Multiple downloads can now proceed in parallel
  • Immediate package download triggers upon right-click of any item in the update list

I’m especially intrigued to see that UniGetUI will soon gain parallel download capability. It already launches a separate process for each download/install session but does them in series. In the next release, it will do them in bunches, instead of one at a time. Good-oh!

Production Release 3.1.5 Also Worth Trying

For those seeking a good alternative to WinGet (and 9 other package managers, including Scoop, Chocolatey, NPM, PIP, and more) UniGetUI is worth checking out in its own right. The lead-in graphic shows a recent download session on my production Windows 10 PC. There, it’s ready to download and install 6 packages (Dropbox, Chrome, Java SE SDK, PS 5.x and 7.x PSGalleries, and Snagit 2024). The whole process takes less than 10 minutes to complete.

UniGetUI should be of especial interest to organizations and development teams that use sources not available to WinGet but readily available to some or all of the other package managers mentioned in the preceding paragraph). Indeed, UniGetUI finds and updates items that WinGet at the command line does not, because of that wider range of available update sources, even on plain-vanilla Windows 10 or 11 PCs.

If you like what you see in version 3.1.15, keep your eyes out for the final cut of 3.1.16. It promises to be faster and more capable than the current production version. One more thing: if you’d rather let UniGetUI do its thing without bothering you try this super-silent command line invocation:

UniGetUI.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /NoAutoStart

This suppresses interactions and messages, and puts off any restarts that might otherwise be initiated if working UniGetUI through its actual UI. Works like a charm, in total stealth mode. Good stuff!

 

Facebooklinkedin
Facebooklinkedin

Weird Win10 Insider Mismatch

When I report a Windows puzzle, I usually like to provide a solution. But I just noticed something odd I may not have time to solve today. It looks to me like a weird Win10 Insider mismatch. Let me explain: my production PC is signed up for the Beta Channel, as you can see in the lead-in graphic. But a quick Winver run shows that PC running version 19045.5371 (see below). Alas, the current Beta Channel Insider Preview Build is 19045.5194. And there’s the mismatch in plain sight!

The Build number on this supposed Beta Channel PC corresponds to the current public/production release.

Fixing Weird Win10 Insider Mismatch

Upon closer examination, the Beta build is lower than the current production build. Looks like I want to switch to the Release Preview channel at Build 19045.5435 instead. Let me try that… No joy.

So then, I do some more poking around online, turns out I need to re-select the Beta Channel item (see lead-in graphic) and open its subsidiary window. That lets me switch to the Release Preview channel. Then when I pop back up two levels to re-run an update check, I get what I want:

Turns out my problem is an error in understanding how to switch from Beta to Insider Preview channel: problem solved!

Looks like the download and install are working. I’ll be rebooting soon: installing has reached 100% but not yet flipped over to “Restart pending…” Now it’s installing again … 20% … taking much longer … 45% … 73% … 88% … done. Restarting now… AAAAND winver now shows 19045.5435.

Turns out it wasn’t a channel mismatch: I was on the wrong channel FWIW, Copilot tells me that MS is shutting down Beta Channel, but is continuing to release into the RP (Release Preview) Channel. Hence, my need to change channels to get to the right build level. Apparently, I missed that memo. All fixed now!

As always here in Windows-World, fixing things is easy when one knows what to do. This time, it took me a while — and some new info — to figure out what that was. Go figure!

Facebooklinkedin
Facebooklinkedin

OhMyPosh Auto Update Hangover Fixed

Here’s an interesting one. Indeed one can configure or enable the excellent OhMyPosh prompt tweaking tool  (aka OMP) to update itself. But there’s a trick involved in getting WinGet to recognize an update has occurred. I call it an “update hangover.” Apparently the local copy of the WinGet source list itself needs a reset before it catches up with what’s happened. (That list provides the basis from which it decides what’s fresh and what needs updating.) Let me explain — and show — how I got this OhMyPosh auto update hangover fixed.

Getting OhMyPosh Auto Update Hangover Fixed

Take a look at the screencap in the lead-in graphic. Before this sequence occurred, OMP told me as the PowerShell session started up that it was updating itself to version 24.18.1. You’ll notice that selfsame “Available” version according to WinGet upgrade output right at the head of that PowerShell command sequence.

Keep reading. Note that the output for oh-my-posh –version also reads 24.18.1. Thus, OMP is already upgraded and already current. But after I complete the valid remaining upgrade manually (for Microsoft.WindowsADK), another simple upgrade check shows that WinGet thinks OMP still needs that upgrade.

What to do? I try basic winget source reset — which attempts a reset for the winget and msstore sources — but the command output tells me the directive requires the –force option to work. So that’s what I try next:

winget source reset –name winget –force

As you can see when I do the next upgrade check after that, WinGet now reports “No installed package found matching input criteria.” That means it no longer sees OMP as a legit update target. Fixed!

Now, I wonder if Jan DeDobbeleer can figure out a way to reset the local list of packages for comparison to the WinGet source as part of his auto-update function. Probably not: knowing his thorough and deliberate approach to this package, he’d have done it already were that possible.

 

Facebooklinkedin
Facebooklinkedin

New OhMyPosh Version Highlights Auto-Update

As the world returned to a more normal work rhythm yesterday, I found myself fielding various new software updates. Among them, a bump to OhMyPosh version 24.18.0. It wouldn’t work via WinGet because — as you can see in the lead-in graphic — it introduces a “newer version” for its “install technology.” Thus, this new OhMyPosh version highlights auto-update gotcha. I’d already used the oh-my-posh enable upgrade command to automate that process. A new install wipes out that directive.

If New OhMyPosh Version Highlights Auto-Update, Then What?

This got me looking at ways to embed the same information in the omp.json file that drives OhMyPosh configurations. Turns out when a reinstall happens, default configurations are rewritten from scratch. Thus, adding commands to

“auto_upgrade”: true,
“disable_notice”: true,

likewise got wiped from my chosen JanDeDobbelleer.omp.json config file as well. (Add them to the end of that file and you’ll need to drop the second comma, in fact.) What to do?

Turns out a custom config file is left alone when you have to shift from an older install technology to a newer one. Renaming the default config file, adding customizations, and referencing that new name in the invocation for OMP will do the trick. Way to learn, I guess!

Best Gets Better, After Sussing Out the Wrinkles

My fervent thanks to Jan DeDobbelleer, the OMP developer and chief steward. There’s seldom anything that goes off with OMP that isn’t addressed in his copious documentation and online interactions with other users. It sometimes takes a little while — about half an hour for this set-to, for example — but I have always been able to figure out and fix whatever gets hinky with OMP. That’s quite a testament to the tool and its builder. Thanks again for everything, Jan!

Facebooklinkedin
Facebooklinkedin

2025 Is PC Refresh Year

I’m not sure what to make of Microsoft’s blog post for CES 2024, entitled “The Year of the Windows 11 PC Refresh.” According to StatCounter, as of December 2024, Windows 11 holds a 34.11% market share, as compared to Windows 10 at 62.7%. That puts 11 at around 55% of 10 by those numbers. If indeed 2024 is PC refresh year for Windows 11, as MS says, it’s got a lot of ground to make up.

Why Say: 2025 Is PC Refresh Year?

Indeed, MS concludes the afore-cited blog post with these concluding words:

…we believe that one of the most important pieces of technology people will look to refresh in 2025 isn’t the refrigerator, the television or their mobile phone. It will be their Windows 10 PC, and they will move forward with Windows 11.

The impetus, of course, from the MS POV is that Windows 11 running on a Copilot+ PC provides significant new capabilities in the areas of security and AI-driven content creation, bolstered by faster, more powerful hardware with longer battery life. Given such a compelling combination of features and functions, the case for refresh is too strong for any other outcome to be likely.

Impending End of Service for Windows 10

October 14, 2025 remains the end of the officially supported road for Windows 10, with subsequent yearly payments for extended service after the cut-off date. MS will bump costs annually for up to three years after that time, to allow laggards to pay for the privilege of postponing refreshes instead.

Does this all translate into 2025 as a notable refresh year? It could, provided that consumers and businesses buy into the notion that what Windows 11 24H2 brings to the party is worth the time, cost and effort to push a refresh through sooner rather than later.

IMO, what’s more compelling to consumers and businesses is the age of their PC fleets, and how long it might be until a refresh occurs as per normal 3-5 year cycles. Looking at my modest collection of a dozen units or so, 3 of them date from 2018, and another three pre-date 2022. That would argue for a 60% refresh rate here at Chez Tittel. I suspect many small to mid-size businesses, and even enterprises, are in a similar boat.

Could 2025 be a big year for PC refreshes? Possibly. Will that actually happen? It depends on how appetites for new technology match up with the will and the wherewithal to acquire Copilot+ PCs. I suspect 2025 will see more refresh activity that 2024 did. But I’ll be surprised if Window 10 and 11 marketshare flip-flops — that is, 30-40% Windows 10 versus 50-60% for Windows 11 by the end of the year. That said, stranger things have happened.

My own best guess is that Windows 10 and 11 might reach parity — which currently calculates to ~48% each — by 12/31/2025. But I see that as a stretch target based on current numbers and prior version histories. Of course, only time will tell… Stay tuned!

Facebooklinkedin
Facebooklinkedin

Avoid Mystery Pop-up Windows

It’s now a truism that one should NEVER click links in email from unknown or untrusted sources. This morning, I was reminded the same is true inside a browser. There, one should avoid mystery pop-up windows with equal attention and suspicion. Indeed, this happened as I visited one of my daily Windows-related news and info sites, much to my alarm and dismay.

Why Avoid Mystery Pop-Up Windows?

Any time you’re presented with a link you don’t recognize, didn’t ask for — and probably also, don’t want —  leave it alone. In my case, I clicked CTRL-Shift-ESC to launch Task Manager. Then, I killed all related browser processes. After that, I restarted Firefox anew. It’s never smart to take any such bait, nor to let it linger on your desktop.

Indeed, Task Manager might have refused to kill one or more Firefox processes. Then,  my next step would be: restart my PC, then run an immediate virus scan. As it was, an immediate follow-up scan showed Defender still on the job. It revealed neither lurking threats nor suspicious files. Good-oh!

You’ve Been Pwned!

Right here at edtittel.com, I fought off a series of WordPress-induced injection attacks last year. I ended up having to buy into a security service that prevented hijackers from altering URLs published into social media sites (e.g. X, Facebook and LinkedIn). These redirected would-be blog post visitors to certain potentially unsavory stop-offs en route to my daily posts. It now costs me $300 a year to protect website visitors from such stuff and nonsense.

I say this to explain that such things can happen to almost any website, at any time, as unpatched vulnerabilities get exploited. Knowing that this is always a possibility, savvy users recognize that mystery pop-ups hide much more malice and potential for harm than sources for wonder and beauty. Avoid them at all costs, is received security wisdom — and my best advice as well. That goes double if they come bearing offers that seem too good to be true…

Facebooklinkedin
Facebooklinkedin