Insider stuff, Recent Activity, Remote Desktop (RDP), WED Blog, Windows 11

Remote Connection Name Cache Cleanup

Leave a comment

Take a look at the lead-in graphic. It shows the start menu entries that appear when I enter “rem” to fire off the Remote Desktop Connection app (mstsc.exe). Most of the items that appear therein are current and correct, but some are not (two of the machine names, and all of the IP-based connections). That led me to ask Copilot to lead me though remote connection cache name cleanup. I basically wiped the cache and wound up with this:

Why Do a Remote Connection Name Cache Cleanup?

Short answer: because it points only at useful entries. Longer answer: because I got tired of looking at names for PCs I’d returned to their makers in late 2025 and early 2026. So I decided to ask Copilot to tell me how to clear the stale entries. Boy, howdy,  did THAT turn out to be an adventure. Why? Because there are many different things to clean, and many ways to clean them. Here’s a quick recitation of the various steps I took along my path.

Step 1 — Polite Approach: Delete Single Entries

Before you reach for a registry editor or fire up PowerShell, give the built-in method a shot. Open Remote Desktop Connection (mstsc.exe), click the drop-down arrow next to the Computer field, hover over the offending entry, and press the Delete key. Windows will ask you to confirm, you click Yes, and that hostname is gone. Clean, simple, no collateral damage.

Under the hood, all this does is remove a single string value — MRU0, MRU1, or whichever slot held that entry — from HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default. It doesn’t touch your saved credentials, your default connection settings, or anything else. Surgical, even.

Here’s the problem: this works beautifully when you have two or three stale entries. If you’re staring at a list of twenty-plus hostnames and you need to kill most of them, the one-at-a-time approach will age you visibly. There’s no “select all and delete,” no batch operation — just you, your Delete key, and an ever-dwindling reservoir of patience. Time to escalate.

Step 2 — Targeting MRU Registry Keys Directly

Open Registry Editor (regedit.exe, run as your normal user — no elevation needed for HKCU), and navigate to:

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default

In the right-hand pane you’ll see the MRU entries spelled out plainly: MRU0, MRU1, MRU2, and so on, each containing a hostname or IP string. You can click any entry and hit Delete, or — and here’s where it gets slightly more satisfying — hold Ctrl and click multiple entries to select a batch, then delete the whole lot in one go.

While you’re in the neighborhood, don’t overlook the Servers subkey:

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers

Each child key here is named after a machine you’ve connected to, and it stores credential hints — typically the username Windows offered when you last connected. Deleting a machine’s subkey here removes that saved username data, which matters if you’re handing the machine to someone else or just want a clean security posture.

⚠ Caution: Regedit is unforgiving. There is no Undo. Work carefully, and if you’re nervous, export the Terminal Server Client key first (File > Export) so you have a fallback. It takes ten seconds and has saved many an afternoon.

Registry surgery is great for targeted removal — ripping out specific machines while leaving others intact. But it’s still a manual process, and if your list is long, you’ll find yourself in exactly the same situation as Step 1, just with a slightly scarier interface.

Step 3 — Scripted PowerShell Cleanup

This is where most IT pros should start. Two lines of PowerShell. No GUI fumbling, no click-by-click tedium, and — crucially — repeatable. Drop it in a script, assign it to a shortcut, paste it into a runbook. It doesn’t care how many MRU entries you’ve accumulated.

Open PowerShell (no elevation required — we’re working in HKCU) and run the following:

Remove-ItemProperty -Path “HKCU:\Software\Microsoft\Terminal Server Client\Default” -Name * -ErrorAction SilentlyContinue
Get-ChildItem “HKCU:\Software\Microsoft\Terminal Server Client\Servers” | Remove-Item -Recurse -ErrorAction SilentlyContinue

Here’s what each line actually does:

  • Line 1 uses Remove-ItemProperty with the wildcard -Name * to delete every value (every MRU entry) inside the Default key in one shot. The -ErrorAction SilentlyContinue keeps things tidy if the key happens to be empty or the path doesn’t exist yet — no red error text, no drama.
  • Line 2 pipes all child keys under Servers through Remove-Item -Recurse, which deletes each per-machine subkey and its contents. Again, SilentlyContinue means it won’t throw a tantrum if the Servers key is already empty.
💡 Pro Tip: Note that neither line deletes the Default or Servers keys themselves — it only removes their contents. That means mstsc.exe finds the parent keys intact and doesn’t need to re-create them, which keeps things clean on the filesystem side.

The PowerShell approach is the sweet spot for most users and administrators: fast, repeatable, easy to verify, and infinitely less error-prone than clicking around regedit under time pressure. Run it once and you’re done. Or add it to an off-boarding script and never think about it again.

 

Step 4 — Wipe the Terminal Server Client Hive

Sometimes the PowerShell approach still leaves you with artifacts — corrupted entries, unexpected subkeys, or settings that mstsc.exe seems to be reading from somewhere you can’t quite pin down. For those moments, there’s one final escalation: delete the entire Terminal Server Client key wholesale.

In regedit, navigate up one level to HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client, right-click the key, and choose Delete. Or from PowerShell:

Remove-Item -Path “HKCU:\Software\Microsoft\Terminal Server Client” -Recurse -ErrorAction SilentlyContinue

Windows will re-create the entire key structure fresh the next time you launch mstsc.exe. This gives you a genuinely clean slate. Because it got rid of entries whose source I couldn’t identify (but were still producing entries in the Start menu “Recent” list), this is what I decided to do.

⚠ Important Warning: This wipes everything — not just the MRU name cache, but also any default settings you’ve configured in the RDP client (default screen resolution, audio settings, drive redirection preferences, and so on). It’s the right call when decommissioning a workstation, preparing a machine for a new user, or resolving a genuinely corrupted configuration. For routine cache cleanup on your own machine, the PowerShell two-liner in Step 3 is the better choice.

Keeping A Tidy Registry

So there you have it — a clean escalation ladder for taming the RDP name cache, matched to whatever level of mess you’re facing. One or two stale entries? Hit Delete in the client and move on with your life. A sprawling graveyard of defunct hostnames? The PowerShell two-liner clears it in seconds. Truly cursed configuration? Nuke the whole hive and let mstsc.exe start fresh.

Each approach is appropriate to its context, and none of them require third-party tools, elevated privileges, or any particularly heroic effort. The registry isn’t as scary as it looks — as long as you back it up before you go excavating and resist the urge to poke at things you don’t recognize. Keep your tools sharp, your connections list short, and your registry cleaner than you found it. Future-you will be grateful.

What I Did Next, and Where It Took Me

After nuking my name cache completely (option 4) I then remoted into each of the PCs currently on hand here at Chez Tittel. That updated the recents list so it shows ONLY those PCs I might actually remote into. IMO that means “Case closed.” I’m glad it’s over!

Here in Windows-World, the desire to clean up can be overtopped by the difficulties involved. This time, I powered through and got things where I wanted them. I plan to enjoy that while it lasts…

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Secure Boot, Troubleshooting, Uncategorized, WED Blog, Windows 11

Two Reboots ARE Better Than One

Leave a comment

During the repair process for the X12 Hybrid Tablet (see Friday’s blog for details), I got to the point where I was ready to reboot after a couple of repairs. Those involved (1) running bcdboot to rebuild my boot files from scratch, and (2) telling Garlin’s update_UEFI... script to emplace SkuSiPolicy.P7b. After a first reboot, the boot screen showed red error text for a Secure Boot mismatch error (reporting that what’s in firmware differs from what wants to run). After a second reboot, the system came up clean with no errors at all. Indeed, that’s what’s supposed to happen and why I claim that two reboots are better than one!

To begin, it’s worth noting what those two steps actually do. Running bcdboot rebuilt the EFI System Partition boot files and restored a working Windows Boot Manager entry. The Garlin script then installed the production-variant SkuSiPolicy.p7b, which writes itself as a UEFI firmware variable enforcing production-level Secure Boot signing rules — rules stricter than the defaults many machines ship with. Consequently, the UEFI firmware suddenly had new staged SVN values sitting alongside the existing committed values in NVRAM. The first reboot is, therefore, where things got genuinely interesting.

Exploring Why Two Reboots ARE Better Than One: First Reboot

When the X12 attempted its first boot after the script ran, the firmware compared the newly staged SVN (Security Version Number) values against whatever was already written into UEFI NVRAM. Naturally, they didn’t match — because the new policy was not yet committed. That mismatch triggered the Secure Boot error you see mocked up as the lead-in graphic. However, and this is the critical part, that same first boot is exactly when Windows Boot Manager wrote the new SVN values out to the UEFI NVRAM, permanently committing the production policy into the chip’s non-volatile storage. The error, in other words, was not a failure. In fact, it was the system doing its job exactly as designed. The Secure Boot commit phase looks alarming on the surface; nonetheless, it is entirely intentional behavior.

Microsoft engineered this two-phase mechanism deliberately so that a mid-commit crash or power loss cannot brick the machine. Old NVRAM values stay valid until the new ones are fully written and confirmed. As a result, if the lights go out halfway through the commit, the firmware simply falls back to the previous known-good state. It is a genuinely elegant safety net (one that I have come to deeply appreciate after years of watching less careful UEFI implementations leave machines unbootable).

Reboot Two: Verifying a Clean Bill of Health

Furthermore, once the X12 had committed the new values on reboot one, the second reboot was simply the verification phase. With the NVRAM now holding the freshly committed data, the firmware ran its Secure Boot checks again. This time, FirmwareSVN, BootManagerSVN, and StagedSVN all agreed — and the machine booted clean, no error, no complaint. Running Get-SecureBootSVN from an elevated PowerShell prompt confirmed the result:

At this time, in fact, 9.0 is the current maximum enforced SVN — so this is a perfect result, not merely a passing grade. All three values align, and the ComplianceStatus line says exactly what you want it to say. The Secure Boot commit phase had done its work on reboot one; verification simply confirmed it on reboot two. The X12 was, in every sense, fully compliant with proper Secure Boot policy.

Two Reboots Makes a Pattern…

Moreover, this two-reboot pattern is not unique to my ThinkPad X12 repair scenario. It is the same deliberate mechanism Windows uses for DBX enforcement updates such as KB5012170. Microsoft designed it this way intentionally — if the machine loses power or crashes mid-commit, the old NVRAM values remain valid until the new ones are fully written and confirmed by a clean second boot.

IMO, the mismatch error on reboot one is a feature, not a bug. The Secure Boot commit phase genuinely requires two boots to complete safelyIndeed, that’s by design, not by accident. So next time you see a Secure Boot mismatch error on the first reboot after a repair or a policy update — don’t panic, don’t reach for the BIOS reset jumper, and definitely don’t call Microsoft support just yet. Just reboot again. Chances are, you’ll be greeted by a perfectly clean boot and Secure Boot status check outputs that make you smile.

Here in Windows-World, we take those smiles as we can get them, cheerfully and with good humor. Once the panic subsides, that is…

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11

X12 Runs Production Win11 After Boot Repair

Leave a comment

Here’s an odd one. I just  fixed a broken boot environment on my ThinkPad X12 (Gen 1) Hybrid Tablet. Oddly enough, Winver is now showing Windows 25H2 Build 26200.8737. What makes that odd? Prior to the fix, I’d been running the Beta release, Build 26220.8370. Hence my conclusion that the X12 runs production Win11 after boot repair. All I can say is: WTF?@*

Why X12 Runs Production Win11 After Boot Repair?

That’s the question I asked Copilot right away once I figured things out. Here’s what it said (bold emphasis mine):

bcdboot reconstructed the EFI boot environment from the on-disk Windows 25H2 partition, laying down a clean, production-signed bootloader baseline with no awareness of the machine’s prior Beta channel enrollment. The Garlin script then installed the production-variant SkuSiPolicy.p7b, which writes itself as a UEFI firmware variable and enforces production-level Secure Boot signing rules. This blocked the pre-release trust chain that Beta channel builds rely on, so Windows Update classified the device as a retail endpoint. It then served it the latest production-signed CU, build 26200.8737, not a Beta flight.

Whoa! Who knew that could happen? But sure enough when I visit Settings > Windows Update > Windows Insider Program on the X12, it tells me to “Join the Windows Insider Program.” This PC is clearly unenrolled and running a production build. Amazing!

Plus ça change…

Here in Windows-World, strange is just part of the day-to-day game. This latest little wrinkle, however, ranks pretty high on my own Strange-O-Meter. But as long as the laptop is working and doing what it should, I’m happy. In fact, I’m bemused because the official word is you can’t leave the Insider Builds unless you do so at a precise moment when it’s allowed, or perform a clean install. Seems like — at this moment, at least — here’s another way!

 

Facebooklinkedin
Facebooklinkedin
Backup/Restore, Insider stuff, Recent Activity, Secure Boot, Troubleshooting, WED Blog, Windows 11

USB-C UFD Restores X12 Boot

2 Comments

I wasn’t sure Copilot was right. Even some of my regular commenters here at edtittel.com were sure Copilot was wrong. Fact is, I couldn’t get into WinRE to repair my damaged BCD until I inserted a brand-new USB-C based Kingston Data Traveler 70 (US$28) into the X12 Hybrid Tablet (Gen 1). Now it’s working. More explicitly using the USB-C UFD restores X12 boot capability.

Before that, I had tried known, good working USB-A UFDs via a USBA2C adapter. I’d also tried native USB-C NVMe SSDs as well. Apparently — as Copilot averred and my experience shows — it will only boot to a real USB-C UFD. Same format, same files, same creation approach on the other devices just didn’t result in a boot into WinRE for on-disk boot repairs to the C: drive. That much of the travail, at least, is now over…

After USB-C UFD Restores X12 Boot, Then?

Now I need to fix Secure Boot (SB), which is what got me in trouble in the first place. Right now, the unit boots fine with SB disabled. I’ve run the Garlin check script and have installed SkuSiPolicy.P7b. But still, I get the red text “Secure Boot mismatch” error info when I try to book with SB turned on. I’m going to reset the keys to factory default, and pick up from there to see what happens next.

But first, after I rebooted again on the X12 without making any changes, it took me to the Windows 11 lock screen. Windows Security gives the system its blessing (green checkmark on the Secure boot entry). So I may already be over the hump, because of the second reboot.

If at First You Don’t Succeed, Reboot Again…

On a third reboot, I get the spinning circles while the OS loads and get right to the Windows 11 lock screen. No more boot issues, no more “boot mismatch” refusals. I seem to have things working again.

As the old saying goes “Get the right tool for the job.” In my case I had to learn the hard way that I MUST use a USB-C UFD to boot the X12 into anything. Now I know. It’s in my little plastic bin of UFDs and I guess I know how to use it. Case closed, I hope!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows 10, Windows 11

GnuGB Properties Window Explains WinGet Pin

Leave a comment

The old saying goes “There’s one in every crowd.” One of what? In this case, an app for which WinGet handles packages that doesn’t play by the rules. That’s OK in this case: the app is Gnu Backgammon (aka GnuBG, runs as “gnubg.exe”). I’m willing to forgive these foibles because it’s the  best-ever digital version of Backgammon around. It’s so good, in fact, I have to turn down its capabilities or it will beat me 9 games out of 10. That said, a quick look at the Gnubg Properties windows explains winget pin on this executable.

How GnuGB Properties Window Explains WinGet Pin

WinGet handles GNU Backgammon under the ID GNU.gnubg, But as a quick look at the properties window for gnugb.exe shows, it doesn’t self-report file version, product name or product version info (see lead-in graphic up top). That last item is an important part of what WinGet uses to figure out if updates apply to one of the packages in its custody. Indeed, this appears at the head of the next screencap, which shows output from two WinGet commands: pin list and show GNU.gnubg.

In particular, it’s noteworthy that Version info for GNU.gnubg shows up as “Unknown.” That reports the missing properties info obliquely, and explains why WinGet always attempts to upgrade that program unless I pin it up out of the way.

Indeed, that’s one of the main points of the WinGet pin command. And it works to prevent the package manager from trying to update something for which no update is available. It’s only because the app doesn’t self-report a version number that an issue presents. Pin provides the fix, and I’m glad.

Here in Windows-World, one must take one’s jollies when one can. I choose to be amused and entertained in this case. But I’m glad the WinGet team had the forethought to anticipate and fend off this kind of thing. ‘Nuff said.

Facebooklinkedin
Facebooklinkedin
Backup/Restore, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

X12 Boot Fix on Hold

4 Comments

Boy, howdy. I just spent the best part of a day figuring out I can’t fix a boot problem on one of my laptops. The Lenovo ThinkPad X12 Hybrid is a capable and compact Windows device, but its UEFI firmware has strict requirements for external boot media. After extensive troubleshooting, it’s clear that continuing repair attempts without a native USB-C flash drive won’t work. This post explains why that process must pause until the correct media shows up. Until it does, I’ve put the X12 boot fix on hold. Let me explain…

Why Put the X12 Boot Fix on Hold?

The X12 Hybrid’s UEFI boot environment is designed to recognize and boot only from a narrow set of external devices. Specifically, it supports:

  • Native USB-C flash drives
  • Native USB-A flash drives (when connected directly to a built-in USB-A port; my X12 has only two USB-C ports & no USB-A ports)
  • SD cards (on models equipped with an SD slot)

Alas, I’ve confirmed by experiment that it does not boot from:

  • NVMe enclosures
  • SATA enclosures
  • USB-A drives connected through USB-A-to-USB-C adapters
  • USB hubs or multiport dongles

Even when such devices appear in the boot menu, the firmware rejects them during handoff to the bootloader. My problem right now is that I don’t own a USB-C flash drive.

Why the Current Media Fails

During troubleshooting, multiple external boot media were tested:

  • USB-A flash drives: Not recognized as bootable when connected through an adapter.
  • Modern NVMe enclosures: Enumerated in the boot menu but immediately returned to the boot selector when chosen.
  • Older NVMe enclosures: Presented themselves correctly as USB Mass Storage devices but were still rejected by the firmware.

These behaviors indicate that the X12 Hybrid’s boot ROM enforces strict transport and device-class requirements. Only a native USB-C flash drive meets all these constraints. Sigh: I’ve got a US$28 Kingston DataTraveler 70 on order from Amazon (delivery : 7/1).

Why a USB-C Flash Drive Is Required

A native USB-C flash drive provides:

  • Direct USB-C connectivity without adapters or bridges
  • USB Mass Storage Class (BOT) compatibility
  • Reliable FAT32 formatting for UEFI boot
  • Full compatibility with Windows installation media

This combination ensures that the X12 Hybrid’s firmware can properly read and execute the Windows bootloader.

The Practical Decision: Pause and Wait

Given the firmware limitations and the consistent rejection of all other media, I can do no further troubleshooting until a USB-C flash drive appears. Once in hand, the following steps will occur:

  1. Format the USB-C drive as GPT + FAT32
  2. Rebuild the Windows installation media
  3. Boot the X12 Hybrid from the new drive
  4. Repair or rebuild the EFI System Partition (ESP)

Pausing now avoids wasted effort and boosts the odds that my next troubleshooting step will help.

Still Waiting…

The troubleshooting process for the X12 Hybrid now sits where the correct hardware is needed. A native USB-C flash drive is the only reliable path forward for UEFI boot and system repair. Once it arrives, the repair process can continue with confidence. Or so I hope: here in Windows-World there’s always the chance that a (nearly) sure thing turns out otherwise. Sigh again: I’ll be finding out!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, Updates, WED Blog, Windows 11

WinGet Upgrade Knows More Than It Says

Leave a comment

In running through my usual morning Winget Upgrade drill, I noticed that it found 3 upgrades, but applied only 2. As you can see in the lead-in screencap, it concluded its efforts with a line that reads “1 package(s) have upgrades blocked because newer versions use a different install technology…” To me, this means that WinGet Upgrade knows more than it says, because process of elimination reveals that Microsoft Edge is the missing item.

Why Say: WinGet Upgrade Knows More Than It Says

Microsoft Edge is deeply embedded into the Windows 11 OS.  Indeed, Windows 11 uses WebView 2 as a system component. That also powers the Settings app, widgets, Copilot, Teams, Outlook (new), the MS Store, and more. That’s why Edge usually updates more easily from within its own UI anyway.

In this particular case, something about the install technology changed moving from Version 149.0.4022.96 to Version 149.0.4022.98. That forces WinGet to keep its mitts off, unless users uninstall the old and then install the new in two separate operations.

I elected to jump into the app, do the upgrade, then returned to Windows Terminal to run WinGet Upgrade –all –include-unknown again. As you can see in the lead-in graphic (if you right-click that image to display it in its own browser tab), with Edge manually updated already beforehand, the next check returns “No installed package found matching input criteria.” In WinGet parlance that means “no items need updating here.”

In Windows-World, what you see can sometimes tell you more than what your app or tool output tells you. This is a definite illustration, and explains why I assert that the Windows package manager (i.e. WinGet) and its upgrade facility knows more than it says. Cheers!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Thoughts & concerns, WED Blog, Windows 10, Windows 11

Windows 10 ESU Gets Another Year

Leave a comment

Microsoft has added a year to the expiration date for its Windows 10 Extended Security Updates (ESU) program. This gives consumers, businesses and organizations another year of critical security patches on their Windows 10 devices. In turn, that provides much-needed breathing room for transitioning to Windows 11 or newer platforms, ensuring users remain protected against emerging threats. As Windows 10 ESU gets another year of life, those running Windows 10 get another year to figure out “What’s next?”

The lead-in graphic for this post shows the MS ESU Explainer that pops up inside that OS when you visit Settings > Update & Security, then click the link that reads “Learn more about Extended Security Updates.” As far as I can tell, MS just extended that date this week. FWIW, other published sources (e.g. WinAero, Windows Latest, Windows Central, etc.) agree.

What Windows 10 ESU Gets Another Year Means

Extended Security Updates (ESU) is a program Microsoft offers to organizations that need to keep Windows 10 systems secure beyond the official end-of-support date. Officially, Windows 10 support ended on October 14, 2025. Even so, ESU allows customers to receive critical and important security updates for some time after that date. This “expiration date” just got extended, as you can see in the lead-in screencap.

This program is especially valuable for businesses with legacy applications or hardware that are not yet compatible with Windows 11. It helps them avoid security risks while they plan and execute their migration strategies.

Why the Extension Matters

The extension of Windows 10 ESU for another year reflects the reality that many organizations face challenges upgrading their infrastructure. Whether due to budget constraints, application compatibility issues, or operational complexities, migrating to a new operating system is rarely straightforward.

By extending ESU, Microsoft acknowledges these hurdles and offers a safety net. This additional year of support means organizations can continue receiving vital security patches, reducing the risk of vulnerabilities that could be exploited by cyber attackers.

What’s Included in the Extended Support?

The ESU program focuses on delivering security updates classified as critical or important by Microsoft. These updates address vulnerabilities that could allow remote code execution, privilege escalation, or denial of service attacks.

However, ESU does not include feature updates or non-security fixes. Organizations still need to plan for a full upgrade to a supported operating system to benefit from new features and improvements.

How to Get Windows 10 ESU

Eligible customers can purchase ESU licenses through Microsoft’s Volume Licensing programs or authorized resellers. The pricing typically increases each year, reflecting the diminishing support window. Individual users may also qualify for ESU, either by activating Windows Backup to sync files and settings via OneDrive, or by redeeming 1,000 MS Reward points.

To activate ESU, organizations must install specific activation keys and ensure their systems are up to date with the latest servicing stack updates. Microsoft provides detailed guidance and tools to help with this process. Individual users typically upgrade directly through WU, without having to reactivate Windows 10 licenses.

Planning Your Migration

While the ESU extension offers more time, it’s not a permanent solution. Users should use this period to accelerate their migration plans to Windows 11 or other supported platforms.

For IT-driven organizations, key steps include:

  • Assessing Compatibility: Evaluate applications and hardware for Windows 11 readiness.
  • Testing: Pilot Windows 11 deployments in controlled environments.
  • Training: Prepare IT staff and end-users for the new operating system.
  • Deployment: Roll out Windows 11 in phases to minimize disruption.

For SOHO and individual users, migration will usually mean disposing of older PCs not able to meet Windows 11 hardware requirements. Replacing those typically involves purchasing a new or used PC or laptop with Windows 11 pre-installed. Optionally, they may (or may not) use a program such as PC Mover to transfer their apps, files, and settings to the new OS.

One Year Adds Time, But Cures No Ills

The additional year for Windows 10 ESU is a welcome relief for many organizations still navigating the complexities of OS migration. It ensures continued protection against security threats while providing a buffer to plan and execute a smooth transition.

However, relying on ESU indefinitely is not advisable. The best strategy is to leverage this extension as a bridge toward a fully supported and modern operating system environment.

By staying informed and proactive, IT teams can safeguard their infrastructure and keep their organizations secure in an ever-evolving threat landscape. Individual consumers gain time to save up for a new PC or laptop, and plan their migration strategy, too.

Facebooklinkedin
Facebooklinkedin
Backup/Restore, Insider stuff, Recent Activity, WED Blog, Windows 11, Windows Update

Nearly Perfect PITR Makes Windows 11 Debut

Leave a comment

Point-in-Time Restore (PITR) is one of the most interesting recovery features Microsoft has added to Windows 11 in recent memory. It arrived quietly through cumulative update KB5095093 in June 2026. Yet it brings a welcome new option for users who want a fast way to roll back their systems. PITR works by capturing snapshots of key system areas. These snapshots let you return your PC to an earlier state when something goes wrong. The idea is simple, and the execution is surprisingly smooth. In fact, I’d say MS has delivered a nearly perfect PITR to the OS.

What Makes It Nearly Perfect PITR, and Nor More or Less?

PITR creates restore points that include system files, settings, and some application data. These snapshots live on the local drive. They also tie into Microsoft’s cloud services when available. This hybrid approach gives PITR more flexibility than older tools like System Restore. It also makes the feature more resilient when local files become damaged. With the release of KB5095093, PITR gained a major upgrade: it now appears directly inside WinRE. That means you can access PITR even when Windows won’t boot. You can see it as a Troubleshoot option in WinRE in the lead-in graphic.

Seeing PITR listed in the WinRE Troubleshoot menu feels like a big step forward. It signals that Microsoft wants PITR to serve as a real recovery tool. You can boot into WinRE, choose Point-in-Time Restore, and pick a snapshot to roll back to. The process is quick and clear. It also avoids the complexity that sometimes comes with older recovery methods. For many users, this will be enough to fix common problems.

What Limits Warrant a “Nearly Perfect” Label?

Still, PITR is not a full replacement for image-based backup solutions. Tools like Macrium Reflect and Hasleo Backup Suite offer deeper protection. They create complete disk images that capture every sector of a drive. These images can be mounted like virtual disks. That means you can browse them, copy files out of them, and inspect their contents. PITR cannot do that. Its snapshots are not mountable. They do not support file-by-file access. They also do not cover the entire disk.

This difference matters when you need more than a simple rollback. If a drive fails, PITR cannot help. If you need to recover a single file from a past state, PITR cannot help there either. Image backups shine in these situations. They give you full control over your data. They also let you restore a system even when the internal drive is gone. PITR is faster and easier, but it is not as complete.

Even so, PITR fills an important gap. It offers a middle ground between System Restore and full image backups. It is quick, lightweight, and built into Windows. The addition of WinRE support makes it far more useful. You can now rely on PITR when Windows refuses to load. That alone makes it worth enabling.

Worth Enabling, But Not A Panacea

In the end, PITR is a welcome addition to Windows 11. It is not perfect, but it is close. For everyday problems, it may be all you need. For deeper issues, image backups remain essential. The best approach is to use both. PITR gives you speed. Image backups give you safety. Together, they create a strong recovery strategy for any Windows system.

To check PITR and it settings visit, Settings > System > Recovery > Point-in-time restore. On my systems it’s enabled by default with a single PITR restore point every 24 hours, 72 hour retention, and a space ceiling 2.0% of disk capacity. YMMV. Check it out: seems like a nearly perfect addition to Windows 11’s recovery capabilities.

To learn more about PITR, read this June 23 Windows IT Pro blog post “Point-in-time restore for Windows 11 is now generally available.” Lots of good stuff in there!

Facebooklinkedin
Facebooklinkedin
Uncategorized

Hyper-V Hangs Up Intel DSA

Leave a comment

Yesterday, I launched Intel Driver & Support Assistant (aka Intel DSA) on my Lenovo ThinkStation P3 Ultra Gen 3. Then I watched it sit there, seemingly forever, with Intel DSA hanging at “Scanning your system…” interminably. The spinner spun. And spun. And kept right on spinning.

First, I did what any reasonable Windows veteran does: I refreshed the browser tab. Then I restarted Intel DSA. Then I cleared the browser cache. Then — because hope springs eternal — I uninstalled and reinstalled the whole tool. Nothing worked.

Finally, after roughly 20 minutes of increasingly creative nattering about, I decided to actually dig in and find the culprit. Ultimately, I was able to determine that Hyper-V hangs up Intel DSA. When Hyper-V is running (with one or more VMs in tow), DSA gets stuck. When Hyper-V is off and its VMs shut down, DSA does its thing.

Discovering That Hyper-V Hangs Up Intel DSA

My first instinct was Task Manager. I scanned the process list for anything suspicious chewing up CPU or disk I/O. Nothing obvious jumped out — DSAService.exe was running, but it was barely registering any activity. Interesting.

Next, I pulled up Windows Services and confirmed that the Intel DSA Service was running and set to automatic. So the service itself wasn’t the issue. I then checked Event Viewer, hoping for a clear error message. However, Event Viewer offered nothing but a wall of routine informational noise. As helpful as usual (not much).

Then I glanced over at my taskbar — and something caught my eye. Hyper-V Manager was open. And sitting right there in the Virtual Machines list was my Windows 10 ESU VM, happily showing a Running state. I hadn’t touched it in days. I’d simply forgotten to shut it down.

That was my “aha” moment. I had a hunch. It was time to test it.

The Fix Is In — and Dead Easy, Too

I right-clicked the running VM in Hyper-V Manager and chose Shut Down — not Pause, not Save State, but a full, clean shutdown. Note state showing “Off” in the lead-in graphic: that’s what you want. Then I closed Hyper-V Manager entirely. Finally, I switched back to my browser and relaunched Intel DSA. The scan completed in about four seconds. Four seconds. After sitting frozen for half an hour!

So why does this happen? Here’s the short version. Intel DSA’s local service performs low-level hardware enumeration — it interrogates drivers, firmware, and system components directly. However, when Hyper-V has an active virtual machine running, the hypervisor layer sits between the operating system and the physical hardware. It intercepts certain hardware queries to protect the VM’s virtualized environment. As a result, Intel DSA’s scan requests can stall waiting for responses that never arrive. The tool doesn’t time out gracefully — it just hangs there, looking busy while doing absolutely nothing.

What to Do If Intel DSA Hangs on Your PC

If you’re seeing Intel DSA hanging at “Scanning your system…” with no end in sight, work through this list before you do anything drastic.

  1. Check Hyper-V Manager for running VMs. Open Hyper-V Manager and look at the State column. If anything shows “Running,” that’s your prime suspect.
  2. Shut down — don’t just pause — any running VMs. Right-click the VM and select Shut Down. Wait for the state to change to “Off” before moving on.
  3. Close Hyper-V Manager entirely. Don’t just minimize it. Close the window completely so the management layer releases its handles.
  4. Relaunch Intel DSA in your browser. Navigate back to the Intel DSA page and let it load fresh. The scan should complete within seconds.
  5. If it still hangs, try the IP listen fix. Open an elevated Command Prompt and run: netsh http add iplisten 127.0.0.1 Then, restart the DSAService via Services or with net stop DSAService && net start DSAService. This resolves a separate but related port-binding conflict that can also cause Intel DSA to freeze.

With luck, DSA will get unstuck for you, too. It worked for me. Here in Windows-World that may not guarantee it will work for you to. But at least, it’s worth a try. Give it a shot!

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness