How to Fix “Hyper-V Virtual Machine Summary State Unsupported” After Windows 11 23H2 Update

Opened Hyper-V Manager after a 23H2 update rolled through and one of my VMs just sat there with “Unsupported” in the State column on the Summary tab. Not stopped, not running, not even the usual “Critical” flag — just Unsupported, like the VM had failed some kind of exam. This one isn’t as widely documented as the classic “stuck at 10%” issue, so here’s what I found digging through it.

Quick Answer

• This almost always comes down to a VM configuration version mismatch between the VM and the updated Hyper-V host
• Run Get-VM | Select Name, Version in PowerShell to check which VMs are on an outdated configuration version
• Use Update-VMVersion to bring the VM’s configuration version in line with what the host now supports
• The VM must be fully powered off before you can upgrade its configuration version — this isn’t reversible once done
• If Update-VMVersion isn’t available or fails, exporting and reimporting the VM is the reliable fallback

Why It Fails

Hyper-V VMs carry a configuration version number separate from the Windows version of the host. That version number determines what features the VM’s .vmcx file can describe and which the host’s hypervisor schema recognizes. When you update Windows — a feature update like 23H2 counts here — the host’s hypervisor and management stack can move to a newer supported version range, and any VM still sitting on an old configuration version becomes something the updated Hyper-V Manager can’t fully summarize anymore, which is what triggers “Unsupported” in that Summary tab specifically rather than a more descriptive error.

A few specific things cause this in practice:

1. VM configuration version never got upgraded after a previous host update. This is the most common one, from what I’ve seen. Windows doesn’t automatically bump the VM’s config version during a feature update — that step is manual, and it’s easy to forget it exists at all if you’ve never had to touch it before.
2. A VM imported or restored from a much older host. If you exported a VM from an older Windows Server or Windows 10 Hyper-V host and imported it fresh onto a 23H2 machine, the imported VM can retain its original configuration version rather than adopting the host’s current one.
3. Integration Services version mismatch inside the guest. Less common, but if the guest OS is running an old version of Hyper-V Integration Services that predates the host’s current build, the Summary tab can misreport state info even when the VM technically still starts.
4. Partial or interrupted feature update. If 23H2 installed in a way that left the Hyper-V management components and the underlying hypervisor platform out of sync (this happens more than Microsoft’s documentation really acknowledges), Hyper-V Manager can misread perfectly normal VMs as unsupported until the mismatch resolves itself, usually via a reboot or component repair.

Technical Comparison

Step-by-Step Fixes

Step 1: Check the VM’s Current Configuration Version

Open PowerShell as Administrator:

Get-VM | Select-Object Name, Version, State

Compare the version numbers against what your current Hyper-V host supports. If you’re not sure what the host’s max supported version is, check:

Get-VMHostSupportedVersion

Anything below the highest listed supported version is a candidate for the fix below.

Step 2: Shut the VM Down Completely

This step matters — the version upgrade can’t run on a VM that’s running, saved, or paused. Make sure it’s fully Off, not just Saved State.

Stop-VM -Name "YourVMName" -Force

Step 3: Back Up First

Before touching configuration version — this operation is one-directional. Once upgraded, a VM’s configuration version can’t be downgraded back to run on an older host. If there’s any chance you’ll need to move this VM back to an older Hyper-V host later, export it first:

Export-VM -Name "YourVMName" -Path "D:\VM-Backups"

Step 4: Upgrade the Configuration Version

Update-VMVersion -Name "YourVMName"

For multiple VMs at once:

Get-VM | Update-VMVersion

You’ll get a confirmation prompt since this is irreversible — read it before accepting, especially in a shared or clustered environment.

Step 5: Start the VM and Recheck the Summary Tab

Open Hyper-V Manager, select the VM, and check the Summary tab. The State field should now show a normal status instead of Unsupported.

Step 6: If Update-VMVersion Fails or Isn’t Available

Some very old configuration versions can’t jump straight to the current one in a single step, and occasionally the cmdlet itself throws an error rather than doing the upgrade. In that case:

1. Export the VM (if you haven’t already)
2. Delete the VM entry from Hyper-V Manager (this doesn’t touch the exported files)
3. Reimport using Copy the virtual machine (create a new unique ID) rather than Register — this rebuilds the VM against the current host’s configuration version cleanly

What Actually Worked For Me

My case turned out to be the imported-VM scenario. I’d moved a dev VM over from an older Windows 10 Hyper-V host a while back using an export/import, and it had apparently been sitting on its original configuration version this whole time without me noticing — it ran fine, so I never had a reason to check.

First thing I tried was just rebooting the host, on the theory that maybe the 23H2 update just hadn’t fully settled yet. That’s usually my go-to first move for weird Hyper-V Manager display glitches, and sometimes it’s genuinely all it takes. Didn’t fix it this time, though.

So I ran Get-VM | Select Name, Version and sure enough, that one VM was sitting two versions behind what Get-VMHostSupportedVersion reported as the host max. Backed it up with Export-VM out of caution, shut it down fully, and ran Update-VMVersion. Took maybe ten seconds, and the Summary tab went back to showing a normal state immediately after starting it back up. Genuinely one of the more painless Hyper-V fixes I’ve run into — the annoying part was just figuring out that the configuration version was the actual issue in the first place, since the “Unsupported” label in Hyper-V Manager doesn’t tell you that directly.

Advanced Fixes and Edge Cases

Checking Event Viewer for the actual mismatch details. Under Applications and Services Logs → Microsoft → Windows → Hyper-V-VMMS Admin, look for events referencing configuration version or schema mismatches around the time the update installed. These often give a more specific error than what Hyper-V Manager’s Summary tab shows.

Clustered environments. If this VM is part of a Failover Cluster, don’t run Update-VMVersion casually — all nodes in the cluster need to support the target configuration version, or the VM becomes unable to fail over to older nodes. Check cluster node versions first with Cluster Validation before upgrading any clustered VM’s configuration.

Repairing a partially applied feature update. If several unrelated VMs all started showing this at once right after installing 23H2, that points more toward an incomplete update than individual VM version issues. Run:

sfc /scannow
dism /online /cleanup-image /restorehealth

then reboot and recheck before touching individual VM configuration versions.

WMI repository corruption. In rarer cases, a corrupted WMI repository on the host can cause Hyper-V Manager to misreport VM states across the board, not just this one. If DISM and SFC come back clean but the issue persists across most or all VMs, checking WMI repository health is worth doing before assuming it’s a per-VM configuration version problem.

What Rarely Works

Just restarting the VM itself almost never fixes this one — the issue lives at the configuration version level, not in the VM’s running state, so restarting doesn’t touch the actual mismatch. Similarly, reinstalling the Hyper-V role entirely is overkill here; it’s disruptive to every other VM on the host and doesn’t address a per-VM version discrepancy at all.

Prevention Tips

• After any major Windows feature update, run Get-VM | Select Name, Version as a quick health check before assuming everything’s fine
• When importing a VM from an older host, upgrade its configuration version immediately rather than leaving it for later
• Keep Integration Services updated inside guest OSes, especially after host-side updates
• Document your host’s supported version range if you manage multiple Hyper-V hosts at different update levels, so you’re not caught off guard moving VMs between them

FAQ

Will upgrading the configuration version affect my VM’s data or settings? No, it only affects the VM’s configuration schema — VHDX contents and guest OS data aren’t touched.

Can I move the VM back to an older host after upgrading its version? Not without exporting from a backup taken before the upgrade. Once a VM’s configuration version is upgraded, it can’t run on a host that only supports the older version.

Why didn’t this happen right when I installed 23H2, but only weeks later? The Summary tab reflects state each time you open Hyper-V Manager or interact with the VM — if you didn’t check on that VM right after the update, the mismatch could’ve been sitting there unnoticed the whole time.

Is this the same thing as the VM being marked “Critical” in Failover Cluster Manager? No, those are different indicators. Critical in cluster manager usually points to a resource health issue, not a configuration version mismatch.

Editor’s Opinion

this one’s kind of an annoying error because “unsupported” tells you almost nothing on its own. once you know its a config version thing its a two minute fix, but getting there took actual digging since hyper-v manager just doesnt explain itself here. worth checking Get-VM version numbers as a habit after any feature update honestly, would’ve saved me the guessing