Can AI Be a System Administrator? Fixing a Stuck Windows 11 Upgrade

If you're not using AI in your system administration work, you might be missing out on a lot. But you can't just trust whatever it spits out, even from the big frontier models.

To put that to the test, I took a real problem from my home lab: a Windows 11 Pro VM stuck on 21H2, which hit end of life in June 2023 and stopped receiving updates. Windows Update just won't budge. So I put three AIs on the case:

• Qwen3 14B running locally in LM Studio
• Qwen3 27B running in VS Code
• Google Gemini (cloud/frontier model)

I wanted to see how each one approached the problem and whether their answers held up. Here's what happened.

Full video

Setting up the AI lineup

I gave all three AIs the same starting prompt, a short "you are an expert system administrator" setup, so everyone was on the same playing field.

One catch right away: the local 14B model doesn't support images. I could paste screenshots of the Windows Update screen straight into Gemini and VS Code, but for LM Studio I had to describe the screenshot in text instead.

Also useful: telling them to stop being verbose. A quick "short answer only" instruction got the 27B and Gemini to cut the chatty diagnostics down to something usable.

The AIs disagree

With the problem described, I asked all three: "I need to upgrade to the latest version of Windows 11. It's stuck on 21H2."

• Qwen3 27B and Gemini both suspected a TPM issue
• Qwen3 14B went off in a completely different direction and suggested Hyper-V checks — which was off base, since this VM isn't even on Hyper-V

Two out of three agreeing isn't proof, but it's worth a check.

Verifying the TPM diagnosis

You verify AI answers the same way you'd verify a coworker's. I opened Computer Management → Device Manager and confirmed the VM does have TPM 2.0. Then I fed that result back to all three AIs.

The 27B kept pushing update drivers and other fixes, but Gemini's response was the one that landed: the upgrade was blocked because of the CPU, not the TPM. That matched my own suspicion. The VM's Proxmox CPU type was the problem.

The real culprit: Proxmox CPU type

In Proxmox, the VM's CPU type was set to an older default, and Windows 11's upgrade checks reject it. The fix:

1. Shut down the VM
2. In Proxmox, change the CPU Type on the VM's hardware settings (I went one version back first, then moved forward when that worked)
3. Boot it back up and confirm the new CPU shows up in Windows. Device Manager now reported a virtual CPU 2.5+

With the CPU fixed, those blockers were gone. But Windows Update still offered nothing, so it was time for the manual route.

Downloading and mounting the Windows 11 ISO

The reliable way to force this upgrade:

1. Download the Windows 11 ISO from Microsoft
2. Mount it in the VM (on my machine it showed up as the F: drive)
3. Run setup.exe from the mounted drive

Because I was working in PowerShell, I used the .\setup.exe form. PowerShell wants the explicit path qualifier for the current directory.

The upgrade kicked off. Windows logo, "Preparing," and we're finally off 21H2.

Takeaways

• AI is a good sysadmin copilot, not an autopilot. The local 14B model was confidently wrong. Even the frontier model needed a nudge toward the real root cause.
• Verify everything. Checking Device Manager for TPM 2.0 took two minutes and ruled out two of the three diagnoses.
• Local models have real limits. No image support on the 14B meant extra work describing screens. It still runs entirely on my own hardware, though.
• The classic fixes still apply. Sometimes the answer is just "mount the ISO and run setup."

SUPPORT MY WORK

Hire US

Buy Me a Coffee