Having returned a couple of loaner units to Lenovo, I recently decided to enroll the  Lenovo ThinkStation P3 Ultra — a beast of a workstation — in the Windows Insider Program to start testing preview builds. The machine was running Windows 11 Pro, TPM 2.0 was enabled, Secure Boot was on, and I had a personal Microsoft account linked. By every measure, this machine should have sailed right through that process. But alas, P3 Ultra Insider enrollment falters, and thereby hangs this tale.

Why P3 Ultra Insider Enrollment Falters

Enrollment hung. Indeed, I hit a brick wall: an eligibility error that blocked enrollment dead in its tracks. I got no clear explanation, no obvious next steps. Just a vague message and a dead end. If you’re in the same boat, you’re not alone, and there’s an easy fix. Here’s exactly what I did to get it working.

What This Error REALLY Means

The error Windows surfaces during Insider enrollment is frustratingly generic. Depending on your exact configuration, you might see language about the device not being “eligible,” a “policy restriction” preventing enrollment, or a note about account requirements — sometimes all three in the same dialog. There’s rarely a useful error code attached.

What makes this especially maddening on a machine like the P3 Ultra is that the hardware is fully compliant. TPM 2.0? Check. Secure Boot? Check. Windows 11 Pro? Absolutely check. The error fires anyway, leaving you staring at a dialog that tells you almost nothing useful about where the actual blocker is hiding.

There’s Something About the (Original) MSA

I can’t figure out what it is, but there’s something about my primary MSA that stymied the enrollment. As soon as I switched to a backup MSA and authenticated (using the MS Authenticator app on my iPhone), the process went through correctly. After a reboot, the Insider update showed up and downloaded (as you can see, it’s installing right now):

Troubleshooting Tips for Insider Enrollment

If a change of MSA doesn’t fix your issues, try looking for Group Policy that blocks preview build enrollment, or check to see if diagnostic data level is too low. Additional deets follow.

Fix the Diagnostic Data level

Navigate to Settings > Privacy & Security > Diagnostics & feedback and make sure “Diagnostic data” is set to Optional — or at minimum confirm it isn’t being suppressed or overridden by a policy. Without this, enrollment may silently fail even if everything else is correct. If the toggle is greyed out, a Group Policy or MDM policy is controlling it, and you’ll need to address that first via gpedit.msc or your MDM console.

Reset the “Manage preview builds” Group Policy

Open gpedit.msc (run as Administrator), then navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Update > Windows Update for Business. Find the policy named “Manage preview builds” and set it to Not Configured or, if you prefer explicit control, set it to Enabled with the sub-option that allows preview builds. Once done, open an elevated Command Prompt and run gpupdate /force to apply the change immediately without waiting for the next Group Policy refresh cycle.

Try a Personal MSA

MSAs can be of type “Work or School” or “personal.” The Insider program wants one that’s strictly personal. If all else fails, you can use a gmail, yahoo or icloud email address. MS free options include Outlook.com (though existing hotmail and live.com addresses still work, no new signups for those domains are allowed).

Insider Enrollment Issue Takeaways

Insider Program enrollment errors on modern workstation-class hardware almost always come down to one of three things: the diagnostic data level is too low, Group Policy is actively blocking preview build enrollment, or there’s an account type mismatch — a work or school identity where a personal MSA is needed. It is almost never the hardware itself.

The ThinkStation P3 Ultra is a fully Insider-capable machine. It meets every technical requirement Microsoft publishes. The blocker, in my experience and in most reported cases, is configuration — either something an IT department put in place, or a default that Windows didn’t surface clearly during setup.

Work through the three steps above in order, and there’s a very good chance you’ll be selecting your Insider channel within a few minutes. And if you hit a variant of this error that the steps above didn’t resolve, drop the details in the comments below — include the exact error message text, whether the machine is domain- or Entra-joined, and what your gpresult output shows for the Windows Update for Business policies. The more detail you share, the faster we can help narrow it down.

Here’s something interesting and mildly mystifying. If you use Reliability Monitor to keep tabs on Windows stability, you may have spotted old_mscopilot_proxy.exe as a problem item — I certainly have. My most recent entry occurred July 6, 2026, at 12:02 PM. That naturally sent me hunting for the file so I could understand what it was doing and if I could delete it safely. What I found — or rather, what I didn’t find — tells a nifty story about how Reliability Monitor actually works. Despite throwing error, old_mscopilot_proxy.exe is MIA when I try to search (and perhaps root) it out.

Despite Throwing Error, Old_mscopilot_proxy.exe Is MIA

Take a look at the lead-in graphic. It shows the error details from Reliability Monitor. Basically, it’s saying that the app has quit working. To be more specific, it says the program has “stopped interacting with Windows and was closed.” The version number provided — 149.0.4022.80 — follows a Chromium-based versioning scheme Microsoft adopted for its Copilot app. That’s an important and concrete clue about the file’s true origin.

Key factoid: the old_ prefix is a standard artifact of Microsoft’s in-place updater for Copilot. Before dropping a new executable, the updater renames the currently running binary to old_[filename].exe as a rollback maneuver. Once the new version installs successfully, that old_ file should be cleaned up automatically. In practice, that cleanup step fails silently with some regularity, leaving an orphaned executable on disk — and a crash record in the event log when the system subsequently tries to invoke it.

Seeking Old Copilot Files/Versions

Knowing where the file should be is not the same as finding it. I ran Get-ChildItem searches against C:\Windows, LocalAppData, Program Files, and the notoriously ACL-locked C:\Program Files\WindowsApps folder — all with -ErrorAction SilentlyContinue to suppress access-denied noise. Every search returned immediately with no output. I then queried the Windows Error Reporting archive and queue folders using Select-String to look for any .wer report referencing the file. Nothing there either. Finally, I launched Voidtools Everything as administrator, triggered a full C: rescan, and searched again. The file is completely absent, gone MIA.

Why Does ReliMon Report This Error?

Here’s the part that catches people off-guard, including your humble author. Reliability Monitor does not verify live disk state before displaying an error entry. It reads the Windows Application Event Log — specifically Event ID 1000 Application Error records. These persist independently of whether or not the executable they name still resides on disk. Such log entries cannot be selectively deleted in Windows, either. You’d have to clear the whole Application log to remove them, which is far too blunt an instrument for this situation.

When in Doubt, Do No Harm (Nothing)

There’s really no need to do anything about this error, except to recognize its (in)significance. The file is gone, the Windows Error Reporting reports are gone, and the Application event log entry from July 6 will age out of Reliability Monitor’s 28-day display window naturally — in my case, by August 3, 2026. If you want to confirm that the event log is the sole remaining source of the entry, run this command string in an elevated PowerShell session:

Get-WinEvent -LogName Application | Where-Object { $_.Message -like "*mscopilot_proxy*" } | Select-Object TimeCreated, Id, Message | Format-List

When I run it, I get hits from 7/6, but also 6/19, 6/12, 5/28, and then weekly back to 4/14. This, apparently, is a pretty constant (if bogus) error on the Flo6 system. Indeed, Copilot tells me “the ghost error pattern — where a file that no longer exists keeps appearing in Reliability Monitor — is surprisingly common and poorly documented.”

But once you understand that Reliability Monitor reads historical event log records rather than interrogating live disk state, these apparent mysteries resolve themselves. The file is gone, the risk is zero, and the entry will vanish from ReliMon on its own (though it remains in the error log). Sometimes the best fix is no fix at all, particularly when there’s nothing wrong, nor anything to repair. Here in Windows-World, doing nothing can come as a welcome relief. That’s my take, anywho…

Normally, when you open the Windows Security app, there’s a brief pause during which the app window is blank (1-2 seconds is normal). But sometimes, that window remains empty. This morning, it popped up on my second Ryzen 7 5800X desktop. In turn, that had me seeking out ways for fixing Windows Security stays blank. Turns out there are two extremely easy fixes, though one takes longer and is more disruptive than the other. Here goes…

Note: the intro screencap shows mockups of the blank Windows Security window (light theme at left, dark theme at right). The key point is “Nothing to see here!” That’s a problem that turns out to be relatively easy to fix.

How-To: Fixing Windows Security Stays Blank

The quick and easy way is to use the app menu a little differently. On the affected machine, I observed that picking any subsystem inside Windows Security will cause it to open, after which “going home” inside the app works like a champ. Since I wanted to check “Device Security” anyway, I went straight there.

Instead of clicking the icon at top center, I clicked on “Device Security” (3rd from bottom in preceding screencap). It came right up and I saw what I needed to see (checking Secure Boot status info).

Another Fix: Reboot, Try Again

I also observed that a reboot brought Windows Security back to a normal, predictable state. Indeed, this is a workable technique to undo lots of everyday wonkiness in Windows, as many readers will know and appreciate. This has been a staple early stage activity in Windows troubleshooting as far back as I can remember (1991, 35 years ago).

Why Does This Happen?

Copilot attributes this reasonably common behavior to an outcome from its design as a UWP shell atop a set of back-end Windows services. It says “When the shell launches faster than its backend services are ready to respond — a classic race condition — the shell renders the window frame but has nothing to populate it with, so you get a blank canvas.” Sounds about right to me, especially noticing a slight delay between launch and population on other PCs I just checked (including the 2018 vintage ThinkPad Yoga X380, the 2022 vintage ThinkPad X16, and the 2020 vintage ThinkPad X12 Detachable Tablet).

Here in Windows-World thinks going wonky is part of the daily round. It’s nice to find a minor glitch that’s quick and easy to diagnose, and fix. I’ll take those wins where I can find them!