Category Archives: Insider stuff

AI, Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows 11

When Copilot Goes Bye-Bye, Local LLM Takes Over

Leave a comment

Yesterday, Thursday, November 12, I got an unexpected lesson in AI continuity planning. Around lunchtime here in Central Texas, Microsoft 365 Copilot became unavailable to me. Outlook, Teams and other Microsoft 365 services were also caught up in a widespread service disruption. At the time I could only say to myself: “I wonder how Copilot goes bye-bye in this day and age?”

Why (and for How Long)
Copilot Goes Bye-Bye

Microsoft tracked the broader event as MO1550821. Reporting based on Microsoft’s service updates says that incident began at 1:26 PM Eastern, or 12:26 PM Central. The trouble was not a sudden flood of users. Microsoft said a number of servers unexpectedly became unavailable, putting extra strain on the infrastructure still standing. Automated health-check failures and an overwhelmed core process complicated recovery. The outage continued for many hours and into November 13 for some users.

In my case, that meant Copilot was essentially gone from noon through the end of my workday. The timing was especially inconvenient because I had four roughly 1,000-word pieces to produce for a hurry-up project (submissions starting NOW). Their themes were modernization, hybrid IT strategy, securing infrastructure for AI, and managing growing IT estates without growing budgets apace.

Necessity being the mother of invention, I decided this was a fine time to find out whether the Lenovo ThinkStation P3 Ultra could become its own AI writing workbench. Google AI helped me get there. By the end of the exercise, I had a local LLM workflow and all four articles completed. Sometimes an outage provides motivation that a normal workday does not.

Ollama Provides the Local AI Engine

The foundation is Ollama, which runs open models locally on Windows. I installed the Windows build and confirmed that its local API was available at http://127.0.0.1:11434. Ollama’s Windows documentation says the application runs in the background after installation and makes the ollama command available in PowerShell and other terminals.

My first check was simple: ollama list. There were no models aboard yet. I then pulled qwen3.6 and wound up using qwen3.6:latest as the model behind this writing experiment. Once downloaded, that model could run on the P3 Ultra instead of depending on somebody else’s cloud staying healthy and accessible.

Ollama for Windows: https://ollama.com/download/windows

AnythingLLM Turns Model Into Workspace

Ollama supplied the engine, but I needed a practical document-oriented front end. AnythingLLM Desktop filled that role. Its workspace approach let me collect source material for the  project, embed it, retrieve relevant files, and converse with the model around a defined body of documents.

Installation presented one Windows-like speed bump. Smart App Control blocked AnythingLLM from launching on this particular PC. I chose to disable SAC in Windows Security so I could proceed. That is a consequential security setting, not a step I recommend taking casually. Here, it was a calculated tradeoff on a machine I manage.

There was another wrinkle. AnythingLLM now includes its own local model runner, but I specifically wanted Ollama. In Settings, under AI Providers and LLM, I selected Ollama and pointed the base URL at http://127.0.0.1:11434. I also expanded the model context window to 32,768 tokens so larger source collections had useful breathing room. I was a bit non-plussed running out of tokens in AnythingLLM’s default workspace, let me tell you!

AnythingLLM Desktop: https://anythingllm.com/download

Blank Model Setting Throws a Curveball

My most interesting configuration glitch produced a wonderfully terse error: “model is required.” AnythingLLM’s newer interface auto-saves selections, so there was no missing Save button to blame. Instead, I discovered that my workspace had been created before I pulled qwen3.6. It had retained a blank model override.

Opening the workspace’s Chat Settings and explicitly choosing Ollama plus qwen3.6:latest cleared the problem. A fresh chat then caused Ollama to load the model into memory. That was the moment the collection of installers, settings and URLs turned into a functioning system.

From Experiment to 4 Finished Articles

For the actual writing job, I loaded the project’s text sources into the AnythingLLM workspace and used Save and Embed. Rather than pinning a huge pile of material into every prompt, I let retrieval do the heavy lifting. Then I worked through the articles section by section, keeping each piece focused on its assigned IT theme.

The result surprised me. This was not merely a laboratory demo showing that a local model could answer a prompt. The P3 Ultra became a useful production tool. In one afternoon, the local Ollama/AnythingLLM combination helped me finish four substantial articles while my normal cloud assistant was unavailable.

I am not giving up Copilot. Far from it. But yesterday changed my view of local AI. The lesson is less about replacing one assistant with another than eliminating a single point of failure. Cloud AI is convenient and powerful right up until the cloud goes away. Now, when that happens, the P3 Ultra has another answer: keep the sources local, load the model, and keep writing.

Here in Windows-World, it’s best to be ready for anything and everything. Sooner or later, that readiness will pay off. Long live local LLMs!

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

Dueling PowerShell Updates: WU vs. WinGet

Leave a comment

Usually, I think of an LTS release as the conservative choice: solid, supported and deliberately behind the leading edge. Thus I had to laugh when Windows Update (WU) brought one PowerShell branch forward, while WinGet immediately pointed to something newer. What looked like a routine update turned into a useful lesson about PowerShell packaging. For a moment, though, it looked very much like a case of dueling PowerShell updates. Cue the banjos!

Why Say Dueling PowerShell Updates?

On the one hand, after WU did its thing, my working PowerShell landed at 7.6.10. That is the shell reached through C:\Program Files\PowerShell\7\pwsh.exe. And indeed, it remains first in the $PATH variable. A quick $PSVersionTable.PSVersion confirmed 7.6.10 was running.

On the other hand, winget list –id Microsoft.PowerShell –exact showed PowerShell 7.6.10 with 7.7.0 available right after that upgrade. PowerShell 7.7 reached GA on November 10, 2026. Microsoft calls it the next Standard Term Support, or STS, release, and it moves PowerShell onto .NET 11. Curiously enough, it too shows a release date of November 10, 2026 at GitHub.

WTF? Two PowerShell updates on the same day, different versions and — as it turns out — different lineages.

When An Upgrade Is More Than That…

Here’s where things get interesting. WinGet did not upgrade my installed 7.6.10 copy. Instead, it reported that the newer version uses a different install technology. Microsoft’s current installation documentation explains the reason. Beginning with PowerShell 7.6, WinGet uses MSIX by default. Beginning with PowerShell 7.7.0, there is no MSI package at all. WinGet installs only MSIX.

I checked the Microsoft Store, but 7.7.0 failed to appear there as an update to my existing installation. WinGet itself supplied a better clue. That is winget show –id Microsoft.PowerShell –exact identified 7.7.0 as an MSIX installer and pointed to the official PowerShell 7.7.0 MSIX bundle on GitHub.

Install Succeeds Where Upgrade Fails

Rather than downloading the bundle manually, I stayed with WinGet. From a normal, non-elevated PowerShell session I ran the user-scoped install shown below. That succeeded. The important distinction is that WinGet could not convert my existing installation in place, but it could install the new MSIX package separately.

winget install --id Microsoft.PowerShell --exact --source winget --scope user

3 Powershells Walk Into a PC…

Afterward, winget list showed three entries: PowerShell 7.7.0, PowerShell 7.6.10 and an older 7.6.9 installation (see lead-in graphic). That sounds messier than it is. Typing pwsh still resolves first to the 7.6.10 executable under Program Files. The 7.7.0 MSIX exposes an application execution alias under my WindowsApps path. So, if I want to run 7.7.0, I must launch it inside 7.6.10 using the PS command string:
& "$env:LOCALAPPDATA\Microsoft\WindowsApps\pwsh.exe".

Here, I’m using the explicit, complete path to the executable to call it directly (that decodes to C:\Users\ed\AppData\Local\Microsoft\
WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe as far as I can tell).

Launching that alias explicitly started PowerShell 7.7.0 inside the same Windows Terminal pane. $PSVersionTable reported 7.7.0, while Get-Process showed the executable running inside the afore-mentioned directory path. In other words, both branches are installed and usable, while 7.6.10 remains my default.

Lessons Learned

The useful lesson is that WinGet can know a newer package exists without being able to upgrade the installation already present. Here, “different install technology” was literal: the path forward crossed from the older installer world into MSIX-only PowerShell 7.7.

For now, keeping 7.6.10 LTS as my default and launching 7.7.0 STS separately provides a usable way to test the new release without disturbing the known-good shell. Sometimes an update failure is not really a failure. Here in Windows-World, this time it’s informing you that the packaging rules for PowerShell have changed. As I mess around with both versions, I’ll get a feel for other changes that might impact my work habits and flow. Stay tuned!

Further Reading

Microsoft Learn, “Install PowerShell 7 on Windows”; PowerShell Team, “Announcing PowerShell 7.7 GA Release” (November 10, 2026).

NeoWin, “PowerShell 7.7 Built on .NET 11 is now generally available” (November 11, 2026).

Microsoft Learn, “What’s New in PowerShell 7.7?” (September 22, 2026).

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

Secure Boot Values Vary By Version

Leave a comment

The most recent Patch Tuesday brought an interesting Secure Boot wrinkle to my Windows 11 test fleet. Production and Insider Preview systems now report different component versions, even though both appear fully updated. That sounds contradictory at first. A closer look says otherwise, even as Secure Boot values vary by version.

What’s Involved When Secure Boot Values Vary By Version?

On my production Windows 11 26H2 PCs, Garlin’s Secure Boot check reports SVN 12.0 and SkuSiPolicy version 3.0.0.20. My Insider Preview systems remain on Windows 11 25H2. There, the tool reports SVN 12.0 as well, but with a different associated file version and SkuSiPolicy 3.0.0.19.

The temptation is to assume that .19 is behind .20 and therefore needs fixing. Garlin says not. On both groups of systems, its final verdict is the same: “SUCCESS: UPDATES ARE FINISHED.”

Secure Boot State Matters More than Version Numbers

That result is the key to understanding what’s happening. Secure Boot servicing does not require every supported Windows branch to carry identical files. Microsoft says Windows 11 versions 24H2, 25H2 and 26H2 share a common servicing foundation. Version 26H2 can be enabled on eligible systems through an enablement package.

At the same time, Microsoft’s November 10, 2026 security update continues the Secure Boot certificate transition. Microsoft says the update adds more high-confidence device targeting data, expanding the population eligible to receive newer Secure Boot certificates automatically through Windows Update.

Windows release identity, individual Secure Boot component versions and Secure Boot remediation state are related. But they are not the same measurement, and they need not line up in synch.

SVN 12.0 Is Reassuring

For me, the most important common value is SVN 12.0. Both Production and Insider Preview have reached that security version number even though their SkuSiPolicy revisions differ.

That makes the .19 versus .20 split look like a branch-specific payload distinction rather than an incomplete update. I have found no Microsoft documentation that says SkuSiPolicy 3.0.0.20 is mandatory before Secure Boot remediation is considered complete.

Garlin’s identical success result reinforces that take. The tool sees both configurations as having completed the applicable Secure Boot update sequence.

Insider Doesn’t Mean Every File Is Newer

There’s another useful lesson here. We often think of Windows Insider Preview as automatically ahead of Production. That is true for many operating-system changes, but it does not mean every individual serviced component must carry a higher version number.

Right now my Production systems have moved to the Windows 11 26H2 designation, while my Insider Preview installations still identify as 25H2. Production also happens to have a newer SkuSiPolicy revision.

If It Ain’t Broke…

I won’t copy SkuSiPolicy 3.0.0.20 from Production to those Insider machines merely to force congruence. Secure Boot is specifically intended to maintain a trusted boot chain. Manually transplanting policy files because one version number looks newer would substitute my judgment for Windows servicing.

For now, the practical rule is simple. Check the security state, not just individual file versions. If SVN is current, Secure Boot is operating normally, and Garlin reports “UPDATES ARE FINISHED,” differing payload revisions can still describe fully serviced Windows installations. Here in Windows-World that means Secure Boot is A-OK. Good!

One More Thing…

After the Production update, I DID have to run Update_UEFI-CA2023.ps1 -SkuSiPolicy and reboot my production machines. That’s what took that value from 3.0.0.19 to 3.0.0.20 on those machines. After that Garlin’s check tool reports complete success as shown in the right-side half of the lead-in graphic. This is becoming a “thing to check” for Windows admins after applying Windows Update packages, especially Patch Tuesday CUs.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, Recent Activity, Security, Troubleshooting, WED Blog

Iphone SMS Failure 2FA Cascade

Leave a comment

Recently, my iPhone 12 developed a particularly inconvenient communications problem. SMS messages from multiple online services simply stopped showing up. Ordinary phone use looked normal, but two-factor authentication (2FA) did not. When a site wanted to send me a one-time code by SMS, that code often went MIA. That turned routine account maintenance into an obstacle course, and provoked an iPhone SMS failure 2FA cascade. Let me explain…

Finding & Fixing Iphone SMS Failure 2FA Cascade

After doing the usual checking, I called Spectrum, my wireless provider. That turned into a surprisingly positive support encounter. The network support representative worked the carrier side while I worked on the iPhone.

The prescription was straightforward. I reset the iPhone’s network settings (item 2 in lead-in graphic) while Spectrum reset and resynchronized things on its end. Apple’s documentation confirms that Reset Network Settings removes saved network settings, including Wi-Fi networks and passwords, cellular settings, and VPN and APN settings. It does not amount to erasing the phone.

Once both sides had been refreshed, SMS delivery returned to normal. Verification codes started arriving again. That’s the outcome that matters most. Whatever had become unsynchronized between handset and network was apparently cleared by rebuilding the relationship from both ends. I’m not sure what caused this, but it started happening aftera recent iOS update (26.7.2) on October 26.

Next Comes Account Cleanup…Sigh

Restoring SMS did not magically undo everything that happened while those messages were missing. Now I’m going through affected online accounts to make sure authentication, billing, and other notices are behaving normally.

That exercise immediately produced an unwelcome surprise at Box.com. I discovered a $500-plus invoice for online file-exchange service. The subscription covers three seats even though I’m using none (and don’t really need the subscription anymore).

Getting Outside the Box

I started investigating how to reduce that bill. Box’s published support information says paid accounts subject to its seat-reduction policy have a three-seat minimum. It also says seat decreases can be processed only at the end of the account term. Removing users by itself does not reduce subscription charges.

Refund language isn’t particularly comforting, either. Box says services are prepaid and generally non-refundable, including renewed accounts. Its support material does allow eligible customers to request a refund for a renewal charge through Billing, but that is a request, not a promise.

Those rules may make contractual sense from Box’s point of view. From where I sit, though, paying more than $500 for three seats when I’m using none makes little sense. If I cannot unwind a freshly discovered renewal, this may end a very long business relationship.

A Bigger Lesson For Yours Truly

The episode started as an iPhone messaging problem and turned into an account audit. That’s probably a useful takeaway. When SMS-based 2FA stops working across multiple unrelated services, don’t assume every account has suddenly broken. The common dependency may be the phone or carrier connection.

In my case, resetting network settings while Spectrum refreshed its side fixed my immediate SMS problem. The follow-on work is less pleasant, but perhaps equally valuable. I’m now checking the accounts that depend on those messages, fixing what needs fixing, and reconsidering services whose billing arrangements fall outside my pain threshold. Sometimes a communications failure tells you more than you expected to learn. Here in Windows-World, that means “It’s Tuesday.”

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

Repair Install Requires Local Logins for Working RDP

Leave a comment

Here’s an interesting Windows 11 gotcha I ran into after a recent repair install on RyzenOfc. Remote Desktop worked perfectly with a local administrator account, but my usual Microsoft account refused a known-good password. The eventual fix was surprisingly simple: I had to log into RyzenOfc locally with that Microsoft account and its password once. Hence this post’s title: repair install requires local logins for working RDP.

That local login triggered the familiar “Setting a few things up…” sequence. After Windows finished its abbreviated OOBE-style setup, the same Microsoft account immediately worked for RDP from Flo6. Along the way, PowerShell provided some useful clues about what had survived the repair install and what had not.

Why Repair Install Requires Local Logins

From the get-go, I could RDP from Flo6 into RyzenOfc using the local administrator account LocalU. That eliminated a long list of suspects. The network path worked, Remote Desktop was enabled, and the target system was accepting RDP connections. Indeed, the failure was specific to my Microsoft account.

Windows returned the wonderfully nonspecific message “Your credentials did not work.” I knew the password was correct, so I started by examining the accounts RyzenOfc knew about.

PowerShell Exposes 2 MSAs

This command listed the local account records and their origins:

Get-CimInstance Win32_UserAccount -Filter "LocalAccount=True" |
Select-Object Name, Caption, SID, Disabled

The interesting entries were ed and etitt. Both showed up as MicrosoftAccount identities (aka MSAs). I already knew etitt belonged to an old, obsolete  Microsoft account. That made ed, with SID ending in -1002, the account of interest. In fact, that’s my current go-to user account.

Next I checked RDP and administrator group membership:

Get-LocalGroupMember -Group "Remote Desktop Users"
Get-LocalGroupMember -Group “Administrators”

That produced another important clue. RYZENOFC\ed was already a member of Remote Desktop Users. RYZENOFC\etitt and LocalU were administrators. Thus the ed account did not lack RDP permission. Adding it to Administrators would have treated the symptom as a permissions problem when the evidence pointed elsewhere.

Missing Profile = Smoking Gun

I then looked at the account objects more closely:

Get-LocalUser |
Select-Object Name, SID, PrincipalSource, Enabled, LastLogon

Both ed and etitt were enabled and identified as MicrosoftAccount principals. But a query for their Windows profiles changed the picture:

Get-CimInstance Win32_UserProfile |
Where-Object SID -in @(
‘S-1-5-21-144170778-2336474949-3120614169-1001’,
‘S-1-5-21-144170778-2336474949-3120614169-1002’) |
Select-Object LocalPath, SID, Loaded, LastUseTime

Only the old etitt identity appeared, mapped to C:\Users\etitt. There was no Win32_UserProfile entry for ed. RyzenOfc knew that ed existed and even knew it was allowed to use Remote Desktop, but Windows had not yet initialized that user environment following the repair install.

Local Login Closes the Loop

That observation reminded me of something important: I had not logged into RyzenOfc with the ed@edtittel.com/password combination since performing a repair install a couple of weeks earlier. I had been relying on Windows Hello rather than forcing a conventional password login.

So I did exactly that at RyzenOfc. I selected the ed account, chose password sign-in, and supplied the known-good Microsoft account password. Windows responded with “Setting a few things up…” and went through the familiar first-login setup sequence.

That message explained a lot. The Microsoft account registration had survived, but Windows still needed to finish initializing the user’s post-repair environment. The password-based sign-in also gave Windows a fresh interactive authentication event for that Microsoft account on the target PC.

THEN, RDP Gets to Workin’

Windows Hello and a Microsoft account password are related to the same identity, but they are not interchangeable credentials. A Hello PIN is tied to the device and protected through Windows Hello mechanisms. An ordinary RDP connection using a Microsoft account password needs the target Windows installation to be able to validate that password-based identity.

Microsoft documentation describes Windows Hello as using cryptographic keys, while Microsoft community reports describe RDP failures after setup when password-based sign-in has not been established locally. Those reports also describe a successful local password login as restoring RDP password authentication.

That matches my RyzenOfc experience. Once the local login completed account and profile setup, I returned to Flo6 and connected using the ed Microsoft account. This time RDP accepted the same password it had rejected before.

Here Cometh the Lesson

The practical takeaway is straightforward. After a Windows repair install, don’t assume a preserved Microsoft account is fully ready for every authentication path just because Windows still lists it.

If RDP works with a local administrator but rejects a known-good Microsoft account password, check the account source, Remote Desktop Users membership, and Win32_UserProfile state before changing security policy. If the Microsoft-account profile has not been initialized, perform one local interactive login using the actual password rather than the PIN.

In my case, that little “Setting a few things up…” message told the story. Windows was finishing work the repair install had left pending. Once it completed, RDP was back in business. Here in Windows-World, I count that as a win!

Facebooklinkedin
Facebooklinkedin
AI, Insider stuff, Networking, PowerShell, Recent Activity, WED Blog, Windows 11

Quick WLAN Profile Cleanup

Leave a comment

I’ve known for a long, long time that the netsh wlan show profiles command lists known Wi-Fi networks on suitably equipped Windows PCs. Until now, I’ve periodically used that command to check how many I’ve got and how many I don’t really need. Now, thanks to Copilot’s “script on demand” abilities, I’ve got a script that walks me through the list. It offers a quick WLAN profile cleanup, so I can keep the ones I use, and deep-six the ones I don’t.

PowerShell For Quick WLAN Profile Cleanup

The screencap starts with the list of 7 known wi-fi networks on the Lenovo ThinkPad X380 Yoga. Of the 7 networks shown, I only need 2 of them.

The script (named wifiprofcln.ps1) walks through all known WLAN profiles for Wi-Fi networks, then asks whether to keep or delete each one. As you can see in the screencap, I deleted 5 and kept 2 of the 7 I started out with. Some were from hotels, others from offices, others from my cellphone provider’s hotspot network.

The Real Beauty of On-Demand Scripting

This is just a simple bit of throwaway PowerShell. The script is 40 lines long. It took Copilot less time to build it than it took me to tell it what I wanted the script to do. At one time, I would’ve been inclined to deliver this info as a recipe with the proper way to structure commands and let readers DIY their way through it. Now, I can put together and share a quickie one-off tool in minutes.

Say what you want about the evils of AI, the perils of hallucination or misalignment, or even existential threats. This kind of simple, straightforward use is easy, fast and pretty darn useful. Within scope and with a tight focus, it’s a complete boon to getting things done here in Windows-World. Use it carefully, to be sure, but use it you must!

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

More Discord Follies: Unactivated Download

Leave a comment

Sometimes an update problem gets more interesting after the obvious fix succeeds. That just happened to me with Discord on Windows. WinGet insisted version 1.0.9267 was available, while my PC remained on 1.0.9266. Even stranger, forcing the upgrade did not change the reported installed version.

I tried WinGet, UniGetUI and Discord’s in-app updater. Nothing moved the needle. Eventually I performed a clean uninstall and reinstall. That exercise exposed what was really happening: version 1.0.9267 had downloaded, but Discord was still running 1.0.9266. That’s how I found myself engaged in more Discord Follies: unactivated download is present, but inert. WTF?

Unpacking More Discord Follies: Unactivated Download

The basic inventory command showed the mismatch clearly:
winget list --id Discord.Discord --exact --scope user

It reported 1.0.9266 installed and 1.0.9267 available. Discord was installed at user scope, which also produced an instructive side trip. An elevated WinGet session refused to uninstall the per-user package. Switching to a normal Windows Terminal session fixed that.

winget uninstall --id Discord.Discord --exact --scope user

After the uninstall succeeded, I checked for leftovers:

Test-Path "$env:APPDATA\Discord"
Test-Path "$env:LOCALAPPDATA\Discord"

Both returned True. With no Discord processes still running, I removed those directories and verified that both paths returned False. That gave me the clean slate I wanted.

The Clean Install Surprise!

Next came an explicit installation of the supposedly newer release:

winget install --id Discord.Discord --exact --version 1.0.9267 --scope user

WinGet found 1.0.9267, verified its installer hash and reported a successful installation. Yet another winget list still showed 1.0.9266 installed, with 1.0.9267 available. At first glance, that looked impossible.

The file system told a better story. I enumerated Discord’s version directories:

Get-ChildItem "$env:LOCALAPPDATA\Discord" -Directory -Filter "app-*" | Select-Object Name, FullName

There were two of them: app-1.0.9266 and app-1.0.9267. Checking the Discord.exe files confirmed that each directory contained the version its name advertised. Again: WTF?

Installed Is Not Activated, Apparently

The decisive check was to examine the running processes instead of trusting package inventory alone:

Get-Process Discord | Select-Object Id, Path,
@{N='FileVersion';E={$_.MainModule.FileVersionInfo.FileVersion}}

Every running Discord process came from app-1.0.9266. I then checked the per-user uninstall registration:

Get-ItemProperty HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
Where-Object DisplayName -eq 'Discord' |
Select-Object DisplayName, DisplayVersion, InstallLocation, UninstallString

Windows likewise registered Discord as version 1.0.9266. In other words, WinGet was not hallucinating. Version 1.0.9267 really existed on disk, but 1.0.9266 remained the registered and active release.

The Nub of This Discord Folly Is…

Discord’s current generic stable update manifest identifies 1.0.9267 as the host version. I also found installation-specific manifest results that still identify 1.0.9266. That makes staged update selection a plausible explanation for this split state, though the local evidence alone doesn’t completely illuminate  Discord’s rollout policy.

Here, the important lesson is more general. When an updater says success but inventory disagrees, inspect three layers: package registration, files on disk and the executable that’s actually running. Those views might disagree: here they did so spectacularly.

For now, I’m leaving both Discord directories alone. Manually deleting the active release or rewriting its registration would create more, not less

Discord’s current generic stable update manifest identifies 1.0.9267 as the host version. We also found installation-specific manifest results that still identify 1.0.9266. That makes staged update selection a plausible explanation for the split state, although the local evidence alone cannot prove Discord’s rollout policy.

The important lesson is more general. When an updater says success but inventory disagrees, inspect three layers: package registration, files on disk and the executable actually running. Those views can disagree, and here they did spectacularly.

For now, I am leaving both Discord directories alone. Manually deleting the active release or rewriting its registration would create more, not less uncertainty. Here in Windows-World, sometimes the best troubleshooting means knowing exactly why you should stop troubleshooting. I’m done for now, and will wait to see what Discord does next. Sigh.

Further Reading

Discord stable Windows x64 update manifest

Discord Support, Windows Corrupt Installation

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11, Windows Update

Checking Hotfix Can Beat Package Check

Leave a comment

After reading about KB5127936 and its Cloud Rebuild facility recently, I wondered how many of my production level PCs already sported this Preview CU. So I asked Copilot to craft me some PowerShell to check. Along the way, I learned that: (a) some methods are better than others, and (b) that there are many ways to request such information. It’s also how I learned that checking hofix can beat package check info, depending on what you need.

My first query looked perfectly reasonable:
Get-WindowsPackage -Online | Where-Object PackageName -match '5127936'
Alas, that request returned no output. Such a result could tempt an administrator to conclude that the update was absent. Here, that conclusion would be wrong.

Why Checking Hofix Can Beat Package Check

Turns out the afore-cited PowerShell command (which uses DISM under the hood) assumes that the string  “KB5127936” appears in the package metadata. It does not, as it turns out.

However, this simpler command
Get-HotFix -Id KB5127936
produces a direct hit. You can see the outcomes of both commands in the lead-in screencap. After Get-Hotfix, P16 reported KB5127936 as Update, installed by NT AUTHORITY\SYSTEM on October 29, 2026. For the question I was asking, that was exactly the information I needed.

Why the difference? Microsoft documents Get-HotFix as a cmdlet for retrieving installed hotfixes. It uses  Win32_QuickFixEngineering WMI class, whose -Id parameter accepts a hotfix ID. Microsoft even provides an example specifically for verifying whether an update is installed.

In other words, if I start with a KB number, Get-HotFix gives me a KB-oriented lookup. Good stuff!

Get-WindowsPackage Asks Something Different

Get-WindowsPackage is not broken, nor did DISM somehow miss the operating system update. Microsoft describes this cmdlet as a way to obtain information about packages in a Windows image. With -Online, that targets the running Windows installation.

The distinction matters because PackageName is the name of a servicing package inside the image. It is not promised to be the public KB identifier with which its labeled. Microsoft also notes that Get-WindowsPackage cannot provide detailed package information for .msu files, only .cab files. And KB5127936 arrives in .msu form.

Thus my pipeline was really asking, “Does any returned package name contain the characters 5127936?” The empty result answered that narrow question. It did not establish that KB5127936 was missing. And that’s because the package data omits that string. Sigh.

Match the Cmdlet to the Question

This suggests a useful rule of thumb. When somebody hands you a KB number and asks whether that update is installed, try Get-HotFix first:  Get-HotFix -Id KB5127936

For scripts, I like a quiet Boolean-style test:
if (Get-HotFix -Id KB5127936 -ErrorAction SilentlyContinue) { 'INSTALLED' } else { 'NOT FOUND BY GET-HOTFIX' }
That wording is deliberately cautious. Get-HotFix is not a universal inventory of everything Windows Update has ever installed, either. Microsoft defines its scope through QuickFixEngineering. Absence from that view should trigger another check, not a final verdict.

Package Checks Retain Their Value

When I am servicing an online or mounted Windows image, inspecting package identities, or working with CAB-based packages, Get-WindowsPackage remains the right tool. It answers a package-servicing question rather than a KB-history question.

That P16 session reinforced an old Windows lesson: command output only makes sense in the context of the question asked. Here, Get-WindowsPackage told me there was no package name matching my KB string. Get-HotFix told me the update associated with that KB was installed.

Sometimes the simpler check really is the better check. On P16, it certainly was. Here in Windows-World simple is not only faster and easier; it’s a minor but useful labor-saving device!

Further Reading

Microsoft Learn: Get-HotFix (Microsoft.PowerShell.Management)

Microsoft Learn: Get-WindowsPackage (Dism)

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

Revoking P16 CA-2011 Breaks Secure Boot Stalemate

3 Comments

For several days, my Lenovo ThinkPad P16 seemed stuck halfway through Microsoft’s Secure Boot certificate transition. The new 2023 certificates were present, but the Secure-Boot-Update task would not finish the job. Then I revoked the old Microsoft Windows Production PCA 2011 certificate. Finally, it looks like revoking P16 CA-2011 breaks Secure Boot stalemate!

The resulting Garlin check_UEFI-CA2023 audit is the kind of output Windows admins like to see, including yours truly. Every check passes. The Windows UEFI CA 2023 trust chain is active, the newer Boot Manager is in use, and the old PCA 2011 path is revoked.

What changed, and why did revocation apparently matter? That question is worth examining because this 2011-to-2023 transition is becoming increasingly important for Windows PCs.

P16 Breaks Secure Boot Stalemate

Before the final change, this P16 was not exactly broken. Secure Boot was on. Windows booted normally. The 2023 certificates had made their way into the firmware databases. Yet the overall migration remained incomplete.

Repeated efforts to trigger the Microsoft Secure-Boot-Update scheduled task did not transition to the expected state. The task sat at Ready, and Garlin’s checks continued to show that more work remained.

That distinction is useful. A system can remain operational while sitting between the old and new Secure Boot states. Seeing a scheduled task at Ready also does not prove that the complete certificate transition has occurred.

Microsoft Makes It a Staged Transition

Microsoft’s documentation helps explain why. Moving from the 2011 Secure Boot certificates to their 2023 replacements involves more than dropping a certificate into firmware. Microsoft says the change includes new Secure Boot certificates and a Windows Boot Manager signed by the updated trust. All those pieces work together as an explicit design.

Microsoft also treats revocation carefully. Its CVE-2023-24932 guidance warns that Secure Boot revocations can have persistent consequences. Once applied, they cannot simply be undone while Secure Boot remains in use. That’s a real reason why Microsoft has rolled related mitigations out in stages rather than treating them like an ordinary monthly update.

Enterprise guidance makes another dependency explicit. Adding Windows UEFI CA 2023 and untrusting Microsoft Windows Production PCA 2011 requires cooperation from device firmware. Differences among hardware and firmware therefore matter.

Revocation Supplies the Missing Shove

On my P16, requesting the PCA 2011 revocation was the move that finally altered the outcome. I would not claim that revoking PCA 2011 repaired a defective scheduled task. I cannot see enough of the task’s internal decision-making to verify that.

Nevertheless, the observable evidence supports a narrower and more useful conclusion. The machine had reached an intermediate Secure Boot state. Applying the revocation caused Windows and the firmware to complete the remaining transition work. Only then did the audit report the Secure Boot state as functionally complete and up-to-date.

That’s an important troubleshooting insight. When Secure-Boot-Update appears intransigent, the visible task state may be a symptom rather than the underlying cause. Certificate state, firmware state, Boot Manager signing and revocation state all need inspection.

Confirmation: (Mostly) Clean Garlin Check UEFI Results

That said, Garlin still reports two missing certificates.

These missing certificates serve different purposes from Windows UEFI CA 2023:

  • Microsoft UEFI CA 2023 signs third-party UEFI boot loaders and EFI applications.
  • Microsoft Option ROM UEFI CA 2023 signs third-party option ROMs.

They replace broader third-party trust previously supplied by the 2011 Microsoft UEFI certificate. Microsoft split the replacement into two certificates for finer control over third-party boot loaders and option ROMs.

Questioning the Final Garlin Repairs

However, the P16’s DB listing does not contain the old Microsoft Corporation UEFI CA 2011 certificate. Microsoft says the update task adds those two replacement certificates if the old Microsoft Corporation UEFI CA 2011 certificate exists in DB. It doesn’t so neither do they. Garlin’s script accurately observes that these two third-party certs are missing, but they don’t seem to interfere with proper boot behavior.

The decisive lines appear in the lead-in graphic as:

Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
Registry: "WindowsUEFICA2023Capable" = 2
Registry: "UEFICA2023Status" = Updated
Windows BootMgr SVN 12.0
SkuSiPolicy.p7b is CURRENT.

The next screencap shows the tail-end of the Garlin check script results. I’ve run this repair three or more times and it never makes an impact on P16. That’s why I think it’s done, even though the check script still calls for those certs. Copilot says the 0x5800 modifier has a special meaning — namely:

  • 0x0800 requests installation of Microsoft Option ROM UEFI CA 2023 into DB.
  • 0x1000 requests installation of Microsoft UEFI CA 2023 into DB.
  • 0x4000 is a conditional modifier. It tells Windows to install those two certificates only if DB already contains the old Microsoft Corporation UEFI CA 2011 certificate.

Add ’em all together and  you get — wait for it — 0x5800. ‘Nuff said.

As far as I’m concerned, the P16 is fully updated and compliant. I had to do some learning to understand why. I did, and now I’m satisfied.

Further Reading

Microsoft Support, “How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932” (KB5025885).
Microsoft Support, “Enterprise Deployment Guidance for CVE-2023-24932” (KB5053946).
Microsoft Support, “Updating Windows bootable media to use the PCA2023 signed boot manager” (KB5053484).
Microsoft Support, “When Secure Boot certificates expire on Windows devices” (KB5079373).

Facebooklinkedin
Facebooklinkedin
Hardware Reviews, Insider stuff, Recent Activity, WED Blog, Windows 11

Benefits of Inventory Timing

Leave a comment

I had a real “How in the heck did they DO that?” moment this morning, reading over recent Tweaktown coverage.In this case (pun intended) PC pricing induces a self-builder (like your humble correspondent) to stop and check the numbers. This $2,430 Skytech gaming desktop at Walmart pairs an AMD Ryzen 7 9800X3D with an NVIDIA GeForce RTX 5070 Ti, 32GB of DDR5-6000, a 2TB NVMe SSD, a 360mm AIO and an 850W Gold power supply. “Hmmm,” I said to myself, “is this exploiting the benefits of inventory timing?”

By way of comparison, I priced a broadly comparable do-it-yourself configuration using recognizable retail components. Those parts came to $2,973.84 before tax. That puts the Walmart machine $543.84 below the DIY total, about 18 percent cheaper. Even removing the $139.99 Windows 11 Home license leaves DIY at $2,833.85. The prebuilt still leads by more than $400. Amazing!

Comparison Shows Possible Benefits of Inventory Timing

Here’s the comparison that caught my eye. The CPU, graphics card and memory alone total $2,013.90 at today’s prices: that leaves only $416.10 between those three retail parts and Walmart’s price for the whole shebang. Here’s a priced-out build list with today’s per-item “best cost” selections.

DIY PC vs. Walmart Skytech
Component DIY selection Price
CPU AMD Ryzen 7 9800X3D $444.00
GPU ASUS Prime RTX 5070 Ti 16GB $1,119.99
Motherboard ASUS TUF Gaming B850-Plus Wi-Fi $216.99
Memory 32GB DDR5-6000 CL30 $449.91
SSD Crucial E100 2TB Gen4 NVMe $249.99
CPU cooler Arctic Liquid Freezer III Pro 360 A-RGB $129.99
Case Lian Li Lancool 207 $82.99
Power supply Corsair RM850x 850W Gold ATX 3.1 $139.99
Operating system Windows 11 Home $139.99
DIY TOTAL $2,973.84
Walmart Skytech $2,430.00
PREBUILT ADVANTAGE $543.84

Why Say: Inventory Timing May Be at Work?

My best explanation for this sizable gap is inventory timing. Skytech may be building these systems from CPUs, memory, graphics cards and other components they acquired earlier. I assume that means at significantly lower costs than today’s per-item retail prices. Bulk purchasing could widen that gap.

That’s a premise rather than something documented. I don’t know Skytech’s acquisition cost or when its inventory was purchased. But the retail comparison makes this idea plausible. A system builder does not necessarily face the same replacement cost that confronts somebody ordering nine separate parts today.

That distinction matters especially around the holidays. A manufacturer with favorable inventory costs can turn older purchasing decisions into a current sales weapon. Instead of simply protecting margin, the vendor can pass some of the advantage along and produce a price that DIY buyers have difficulty matching.

Does DIY Even Compete/Compute Here?

The case for building your own PC isn’t entirely nixed. A self-build lets one choose the exact motherboard, SSD, power supply, cooler and graphics card. With the Skytech system, several of those specific makes and models are unspecified or may vary (and may not be to your liking). Component control has real value, particularly for buyers who care about firmware, expansion, acoustics or long-term serviceability.

A Deal Worth Considering

Still, $544 buys lots of component preference. At $2,430, I would have trouble justifying an equivalent self-build strictly on price. The Walmart system arrives assembled, includes Windows and carries a system warranty.

That makes this a useful lesson in PC purchasing. Current retail component prices don’t always dictate price for a prebuilt PC. Inventory has history. When a manufacturer bought well, and decides to turn that advantage into aggressive holiday pricing, yesterday’s inventory can become today’s bargain.

I’ve got to admit this is a good enough deal that I’m actually thinking it over. But with at least 4 strong, decently-equipped PCs here at Chez Tittel, I’ll probably have trouble selling to “The Boss.” But here in Windows-World, I can always dream about my next PC, knowing it’s a matter of “when,” not “if.”

Facebooklinkedin
Facebooklinkedin