Secure Boot certificates and Hyper-V: why your Gen 2 VMs are not updating, and what breaks in 2026
A question keeps surfacing on Reddit and in the field: does a Hyper-V host need updated firmware and hardware Secure Boot enabled before its Generation 2 VMs can receive the 2023 Secure Boot certificates? The answer is no. The host hardware has nothing to do with it. But the question is worth taking seriously, because the assumption behind it is hiding a problem that most Windows Server estates have not yet noticed, and that has a clear deadline attached.
The Microsoft Secure Boot certificates issued in 2011 begin expiring in June 2026. Most coverage frames this as a desktop and laptop story driven by automatic Windows 11 servicing. On Windows Server, and therefore inside your Gen 2 virtual machines, the behaviour is different, the update is not automatic, and on existing VMs it frequently fails without any obvious sign. This article explains where the dependency really lives, why existing VMs and templates do not take the new certificates, the exact failure to look for, and the remediation sequence that works in a clustered environment. There is still time to do this properly. The point of the article is to make sure it lands on your plan with the right priority rather than drifting until it becomes an incident.
- The host firmware question, and where the dependency really lives
- The certificate stores, and the 2011 to 2023 mapping
- What the 2026 and 2027 deadlines actually break
- Why Windows Server does not behave like Windows 11
- The trap: existing Gen 2 VMs fail the KEK update with Event ID 1795
- Diagnosing the real state across a cluster
- Remediation: the template toggle, the opt-in, the verification
- The vTPM caveat and the DBX revocation trap
- Templates, golden images, and version-specific behaviour
1. The host firmware question
A Generation 2 VM's Secure Boot is fully virtualised. Hyper-V provides each Gen 2 VM with its own virtual UEFI firmware, and Microsoft is explicit that this firmware is independent of what is on the physical host. Secure Boot and UEFI firmware are not required on the host itself. The VM's key stores live in the VM's own NVRAM, which is part of the VM configuration, not on the physical motherboard, and not shared with any other VM.
Two consequences follow, and they are the reason for this whole topic.
First, the physical host does not need hardware Secure Boot enabled, and does not need a BIOS or system firmware update, for its guests to receive the 2023 certificates. A host running old system firmware with hardware Secure Boot switched off can still present and update current certificates to its Gen 2 guests. State this the other way round, because it is the part people get wrong: a Gen 2 VM with Secure Boot enabled is fully in scope for the 2023 certificate work even when the host has Secure Boot disabled or unsupported. The host's own posture neither protects the VM nor excuses it. If you have been assuming that hosts without Secure Boot put their VMs out of scope, the opposite is true.
Second, because every VM carries its own independent NVRAM, no single action on the host fixes all guests at once. Patching the host does not reach into a running VM's NVRAM. Every guest, and every template, is a separate certificate store that can be in a different state and must be checked on its own.
So the two questions that get mixed up are unrelated:
- Host hardware Secure Boot and system firmware: irrelevant to whether guests can take the 2023 certificates.
- Host OS patch level, guest OS patch level, and per-VM NVRAM state: this is the entire problem.
The dependency is software, all the way down, and it is per-VM.
2. The certificate stores, and the 2011 to 2023 mapping
Secure Boot keeps its trust in four UEFI variables, and the event-log messages make no sense until you know what each one is.
PK, the Platform Key, is the single root key that authorises changes to the KEK list. KEK, the Key Exchange Key, holds the keys that are allowed to update the two signature databases below it. DB is the database of allowed signatures, the certificates a boot component must be signed against to be permitted to run. DBX is the opposite, the forbidden database, a revocation list of signatures that must be refused even if otherwise valid.
The replacement is not a clean one-to-one swap, which is why the output looks busy. In the KEK, Microsoft Corporation KEK CA 2011 is succeeded by Microsoft Corporation KEK 2K CA 2023. This one key is the gate: without the 2023 KEK in place, the guest cannot authorise the DB updates that follow. In the DB, the third-party Microsoft Corporation UEFI CA 2011 is replaced by two 2023 certificates, Windows UEFI CA 2023 and Microsoft UEFI CA 2023, the latter covering option ROMs, and the Windows Boot Manager signer Microsoft Windows Production PCA 2011 moves to the 2023 boot path.
The practical takeaway is short: the boot-critical certificate to confirm is Windows UEFI CA 2023 in the DB, and it is gated by KEK 2K CA 2023 in the KEK. If the 2023 KEK is missing, nothing downstream lands no matter what you set inside the guest.
3. What the 2026 and 2027 deadlines actually break
Be precise here, because the headlines overstate the immediate impact and understate the eventual one, and the truth is what lets you plan rather than panic.
A VM that still trusts only the 2011 certificates after June 2026 does not stop booting on that date. It continues to start and run normally, and ordinary Windows updates continue to install. Nothing fails on the day.
What it loses is the early-boot security pipeline: updates to the Windows Boot Manager, Secure Boot DB updates, DBX revocation-list updates, and mitigations for future boot-level vulnerabilities of the BlackLotus class (CVE-2023-24932). The system is pinned at its current boot-path security posture with no way to advance it.
The consequences are staged, which is the good news for planning. Microsoft has indicated that security fixes for the Windows Boot Manager stop reaching systems on the old certificate by October 2026, and the Windows Production PCA 2011 expiry follows in 2027. The forward-looking risk that matters most is boot media: an OS image, WinPE build, or recovery medium signed only against the 2023 certificates will not boot on a VM whose DB never received them. That is the scenario that turns a deferred housekeeping item into a Sev-1 during a recovery, precisely when you reach for media that a stranded VM refuses to trust.
None of these dates are this week. All of them are close enough that a clustered estate with hundreds of guests should be inventorying now and remediating over the next maintenance windows, not in May 2026. Treat it as scheduled work with a real end date, not as an emergency and not as something optional.
Most Windows Server estates have not noticed this yet. A CloudLabs Hyper-V Cluster Health Check inventories Secure Boot state across every Gen 2 guest and template, identifies the 1795 trap, and delivers a severity-ranked remediation plan.
Schedule a Health Check intro call →4. Why Windows Server does not behave like Windows 11
This is the single most important operational difference, and it is where general guidance fails server operators.
On Windows 11, the 2023 certificates are increasingly delivered and applied automatically through servicing. On Windows Server, and therefore on your Gen 2 Windows Server guests, they ship inside the cumulative updates from 2024 onward but are not applied automatically. Server requires an explicit opt-in, because applying certificate changes unattended on server and virtual workloads carries a boot-risk that Microsoft chose not to take on your behalf. The conservative default is deliberate, and it means nothing happens until you act inside each guest.
The opt-in is a single registry value that tells Windows to deploy the 2023 certificates and update the boot manager to the 2023-signed version, while leaving the old 2011 certificate in place rather than revoking it. Leaving 2011 in place is exactly what you want at this stage.
# Inside the guest. Opt in to Secure Boot certificate deployment.
# This adds the 2023 certificates and updates the boot manager.
# It does NOT revoke the 2011 certificate (revocation is a later step).
$p = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
Set-ItemProperty -Path $p -Name AvailableUpdates -Value 0x5944 -Type DWordA background scheduled task processes the change on its own cycle. Trigger it rather than wait:
# Inside the guest. Run the servicing task that applies the update now.
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"A reboot is then required for the boot manager to switch to the 2023-signed version. All of this runs inside each guest. None of it is done for you by patching the host.
5. The trap: existing Gen 2 VMs fail the KEK update with Event ID 1795
This is the part that is genuinely under-reported, and the reason this article exists.
New VMs created on a fully patched host, Windows Server 2025 or a current Windows 11 Hyper-V host, are initialised at creation with both the 2011 and 2023 certificates, including the 2023 KEK. They are in good shape from day one.
Existing VMs are not updated when you patch the host, because their certificate state lives in their own NVRAM. So you do the sensible thing, set the registry opt-in inside the guest exactly as you would on physical hardware, run the task, reboot, and on a large proportion of existing Server 2019 and Server 2022 Gen 2 VMs it fails.
The signature is Event ID 1795 in the guest System log, with wording to the effect that the system firmware returned an error, the media is write protected, when attempting to update a Secure Boot variable KEK 2023. The virtual UEFI is refusing the KEK write. Because the 2023 KEK is the gate for the DB updates, the entire chain stalls. The opt-in looks configured, the task runs, and yet Windows UEFI CA 2023 never appears in the DB.
What makes this risky is that nothing is broken at the time. The VM boots and runs. You will not notice unless you go looking, or until a post-deadline failure forces the issue. An entire cluster can sit in this state, opt-in set, certificates not actually applied, and look completely healthy on every dashboard you have.
6. Diagnosing the real state across a cluster
Check this programmatically from your management server, the box that already has WMI access to every cluster node, such as your VMM server. This works cleanly for the host-side enumeration below. The per-guest checks are a different matter: reading a guest's firmware variables means remoting into the guest, so run those guest-local where you can, or through your existing configuration-management channel, rather than fanning them out over nested remoting. Driving management server to host to guest in one hop runs into Kerberos double-hop and credential-delegation limits that most estates have not configured for ad-hoc work, and it tends to fail quietly. Do not walk the VMs one at a time in the GUI, and do not trust the registry value as proof, since it records only intent.
First, from the management server, enumerate which VMs are in scope across all nodes. Only Gen 2 VMs have UEFI and Secure Boot; Gen 1 VMs are out of scope entirely.
# From the management server. Gen 2 VMs and their Secure Boot state, all nodes.
Get-ClusterNode -Cluster "HVCLUSTER01" | ForEach-Object {
Get-VM -ComputerName $_.Name |
Where-Object Generation -eq 2 |
Get-VMFirmware |
Select-Object @{n='Node';e={$_.ComputerName}}, VMName, SecureBoot, SecureBootTemplate
}The authoritative check has to run inside the guest, because the host cannot see into the VM's applied DB and KEK. Confirm both the boot-critical DB certificate and the KEK gate in one pass:
# Inside the guest. True/True means on track. A False KEK is the 1795 signature.
$db = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
$kek = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes)
[pscustomobject]@{
DB_2023 = $db -match 'Windows UEFI CA 2023'
KEK_2023 = $kek -match 'KEK 2K CA 2023'
}Run that check guest-local across the estate, gathering the results centrally, so you get one table instead of a manual tour. If you do reach in with Invoke-Command, mind the double-hop limit noted above. The VMs where KEK_2023 is false are your remediation targets. Where you want the cause confirmed rather than inferred, pull the event directly:
# Inside the guest. Surface the write-protected KEK failure if present.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1795} -MaxEvents 5 -EA SilentlyContinue |
Select-Object TimeCreated, Message7. Remediation: the template toggle, the opt-in, the verification
When a guest hits the 1795 write-protected failure, the fix is not inside the guest. It is a Secure Boot template toggle performed on the host, which resets the VM's UEFI key store to the template defaults. On a current host those defaults include the 2023 certificates, which clears the stuck KEK store.
With the VM shut down, run this against the owning node:
# On the owning node. Reset the Secure Boot key store via template defaults.
# Toggle to the open CA template, then straight back to the Windows template.
Stop-VM -Name "VM01"
Set-VMFirmware -VMName "VM01" -SecureBootTemplate MicrosoftUEFICertificateAuthority
Set-VMFirmware -VMName "VM01" -SecureBootTemplate MicrosoftWindows
Start-VM -Name "VM01"The full sequence that works reliably on existing Server 2019 and 2022 Gen 2 VMs is: shut down the VM, toggle the template on the host, start the VM, set the registry opt-in inside the guest if it is not already there, run the Secure-Boot-Update task, reboot the guest, then verify with the section 6 check. KEK_2023 should now return true and DB_2023 should follow. Skipping the host-side template toggle is exactly why the in-guest-only approach fails on these VMs.
8. The vTPM caveat and the DBX revocation trap
Two warnings that will save a bad afternoon, possibly a bad quarter.
First, virtual TPM. If a Gen 2 VM uses a vTPM, you cannot update its certificates in place. The TPM measurements taken during boot incorporate the certificate state, so changing the certificates invalidates those measurements, with direct consequences for BitLocker and any attestation that relies on them. These VMs must be reprovisioned onto a current image rather than toggled. Identify them at inventory time, because reprovisioning is a planned activity involving data and key-protector handling, not a five-minute task. In a clustered estate this is usually the largest single line item in the remediation plan, which is another reason to start inventory early.
Second, do not rush the DBX revocation. Microsoft documents a manual procedure that revokes the old 2011 certificate by adding it to the DBX, the forbidden database. Do not apply that revocation as part of this exercise. Revoking 2011 prematurely can render existing boot media, WinPE images, recovery drives, and provisioning targets unbootable, because they are still signed against 2011. The safe order is strict: add the 2023 certificates, validate that everything boots from both the OS and your recovery media, and leave revocation to a much later, deliberate phase once the entire estate and all media are confirmed on 2023. Adding trust is reversible and safe. Removing it is where estates brick themselves.
9. Templates, golden images, and version-specific behaviour
The highest-leverage single action is to fix your templates and golden images before you touch another running VM. An unpatched template spawns new VMs that are already behind, so the problem regenerates faster than you can remediate it.
Bring every template to a current patch level, apply the template-toggle and opt-in treatment if it is Server 2019 or 2022, confirm Windows UEFI CA 2023 is present in its DB with the section 6 check, then re-seal and resume deploying from it.
Behaviour by version, briefly. Windows Server 2025 hosts initialise new VMs with both certificate sets at creation, so freshly built VMs are clean, but existing VMs migrated onto 2025 hosts are not retroactively fixed and still need the per-guest work. Windows Server 2022 and 2019 carry the certificates in cumulative updates from 2024 onward, apply nothing automatically, require the opt-in, and are the versions most prone to the 1795 KEK failure on existing VMs. Windows Server 2016 is the weakest position, with the thinnest tooling and servicing support for this transition, so treat any 2016 Gen 2 VM as requiring individual validation and, where you can, fold it into a migration plan rather than a certificate fix. Generation 1 VMs of any version are unaffected, without exception.
The pattern behind the list
This is a familiar shape. A long-lived cryptographic artefact, issued and forgotten in 2011, quietly reaches the end of its life and turns into a fleet-wide operational deadline. Nothing is on fire today, which is what makes it easy to defer: the cost of inaction stays invisible right up to the moment a VM will not boot from new media, or a boot-path vulnerability lands with no patch path on a fleet that can no longer take the fix.
The host firmware question compounds it, because it sends people to inspect the motherboard when the answer lives in patch parity and per-VM NVRAM state. In a clustered Hyper-V estate that is dozens or hundreds of independent certificate stores, each able to fail quietly with the opt-in set and the certificates still absent. The work is methodical rather than heroic, and there is time to do it methodically: inventory every Gen 2 guest and template from your management server, verify the actual DB and KEK state rather than trusting the registry, remediate existing VMs with the template toggle, plan the vTPM reprovisioning as its own stream, and leave the DBX revocation for last.
Plan a Hyper-V Cluster Health Check introduction →
Frequently asked questions
No. Microsoft provides each Gen 2 VM with virtual UEFI firmware that is independent of the host, and Secure Boot is not required on the host at all. A Gen 2 VM with Secure Boot enabled is in scope for the 2023 certificate work regardless of the host's hardware Secure Boot state. The host OS patch level matters; the host's hardware Secure Boot does not.
Not on that date. They keep running on the 2011 certificates and ordinary updates keep installing. What they lose is the ability to receive boot-path security updates, and eventually the ability to boot media signed only with the 2023 certificates. The boot-failure risk is downstream, and there is time to prevent it if you start now.
On existing Server 2019 and 2022 Gen 2 VMs the KEK update often fails with Event ID 1795, media write protected. Because the 2023 KEK gates the DB updates, nothing lands. Toggle the Secure Boot template on the host with the VM shut down, then re-apply the opt-in inside the guest and verify the DB and KEK.
Inside the guest, read the DB and KEK variables and match for Windows UEFI CA 2023 and KEK 2K CA 2023. The registry value records only intent; the key stores record what actually applied.
They cannot be updated in place, because the TPM boot measurements include the certificate state, which also affects BitLocker. They must be reprovisioned onto a current image. Identify them early.
No. Gen 1 VMs have no UEFI and no Secure Boot, so they are entirely unaffected.
A CloudLabs Hyper-V Cluster Health Check runs over two days and is read-only during assessment. Diagnosis uses non-disruptive PowerShell; remediation is delivered as a severity-ranked runbook you apply in your own maintenance window.
Secure Boot-certificaten en Hyper-V: waarom je Gen 2-VM's niet bijwerken, en wat er in 2026 stukgaat
Een vraag blijft terugkomen op Reddit en in de praktijk: heeft een Hyper-V-host bijgewerkte firmware en hardware Secure Boot nodig voordat de Generation 2-VM's de Secure Boot-certificaten van 2023 kunnen ontvangen? Het antwoord is nee. De hosthardware heeft hier niets mee te maken. Toch is het de moeite waard de vraag serieus te nemen, want de aanname erachter verbergt een probleem dat de meeste Windows Server-omgevingen nog niet hebben opgemerkt, met een harde deadline eraan vast.
De Microsoft Secure Boot-certificaten uit 2011 beginnen in juni 2026 te verlopen. De meeste berichtgeving brengt dit als een verhaal over desktops en laptops, aangejaagd door automatische Windows 11-servicing. Op Windows Server, en dus binnen je Gen 2-VM's, is het gedrag anders: de update gaat niet automatisch, en op bestaande VM's mislukt hij vaak zonder enig zichtbaar teken. Dit artikel legt uit waar de afhankelijkheid werkelijk zit, waarom bestaande VM's en templates de nieuwe certificaten niet opnemen, welke storing je precies moet zoeken, en welke herstelvolgorde werkt in een geclusterde omgeving. Er is nog tijd om dit goed te doen. Het doel van dit artikel is dat het met de juiste prioriteit op je planning komt, in plaats van te blijven liggen tot het een incident wordt.
- De vraag over hostfirmware, en waar de afhankelijkheid werkelijk zit
- De certificaatopslagplaatsen, en de overgang van 2011 naar 2023
- Wat de deadlines van 2026 en 2027 daadwerkelijk stukmaken
- Waarom Windows Server zich niet gedraagt als Windows 11
- De valkuil: bestaande Gen 2-VM's laten de KEK-update mislukken met Event ID 1795
- De werkelijke status in kaart brengen over een cluster
- Herstel: de template-toggle, de opt-in, de verificatie
- De vTPM-kanttekening en de DBX-intrekvalkuil
- Templates, golden images, en versiespecifiek gedrag
1. De vraag over hostfirmware
De Secure Boot van een Generation 2-VM is volledig gevirtualiseerd. Hyper-V voorziet elke Gen 2-VM van zijn eigen virtuele UEFI-firmware, en Microsoft is er duidelijk over dat deze firmware losstaat van wat er op de fysieke host draait. Secure Boot en UEFI-firmware zijn op de host zelf niet vereist. De key stores van de VM zitten in de eigen NVRAM van de VM, die deel uitmaakt van de VM-configuratie, niet op het fysieke moederbord, en niet gedeeld met enige andere VM.
Twee gevolgen volgen hieruit, en zij zijn de reden voor dit hele onderwerp.
Ten eerste heeft de fysieke host geen hardware Secure Boot nodig, en geen BIOS- of systeemfirmware-update, om zijn guests de certificaten van 2023 te laten ontvangen. Een host met oude systeemfirmware en hardware Secure Boot uitgeschakeld kan zijn Gen 2-guests nog steeds van actuele certificaten voorzien en die bijwerken. Zeg het ook andersom, want dat is het stuk dat mensen verkeerd inschatten: een Gen 2-VM met Secure Boot ingeschakeld valt volledig binnen de scope van het 2023-certificaatwerk, zelfs wanneer de host Secure Boot uitgeschakeld of niet ondersteund heeft. De toestand van de host beschermt de VM niet en verontschuldigt hem evenmin. Als je hebt aangenomen dat hosts zonder Secure Boot hun VM's buiten scope plaatsen, dan is het tegendeel waar.
Ten tweede, omdat elke VM zijn eigen onafhankelijke NVRAM draagt, lost geen enkele actie op de host alle guests in één keer op. De host patchen reikt niet tot in de NVRAM van een draaiende VM. Elke guest, en elke template, is een aparte certificaatopslag die zich in een andere staat kan bevinden en die afzonderlijk gecontroleerd moet worden.
De twee vragen die door elkaar worden gehaald staan dus los van elkaar:
- Hardware Secure Boot en systeemfirmware van de host: irrelevant voor de vraag of guests de 2023-certificaten kunnen opnemen.
- Patchniveau van de host-OS, patchniveau van de guest-OS, en de NVRAM-status per VM: dat is het hele probleem.
De afhankelijkheid is software, op elk niveau, en zij is per VM.
2. De certificaatopslagplaatsen, en de overgang van 2011 naar 2023
Secure Boot bewaart zijn vertrouwen in vier UEFI-variabelen, en de meldingen in het event log slaan nergens op tot je weet wat elk ervan is.
PK, de Platform Key, is de enige rootsleutel die wijzigingen aan de KEK-lijst autoriseert. KEK, de Key Exchange Key, bevat de sleutels die de twee onderliggende signature-databases mogen bijwerken. DB is de database van toegestane handtekeningen, de certificaten waartegen een boot-component ondertekend moet zijn om te mogen draaien. DBX is het tegenovergestelde, de verboden database, een intrekkingslijst van handtekeningen die geweigerd moeten worden, ook als ze verder geldig zijn.
De vervanging is geen schone één-op-één-wissel, en daarom oogt de uitvoer druk. In de KEK wordt Microsoft Corporation KEK CA 2011 opgevolgd door Microsoft Corporation KEK 2K CA 2023. Deze ene sleutel is de poort: zonder de 2023-KEK op zijn plaats kan de guest de DB-updates die erna komen niet autoriseren. In de DB wordt de third-party Microsoft Corporation UEFI CA 2011 vervangen door twee 2023-certificaten, Windows UEFI CA 2023 en Microsoft UEFI CA 2023, waarbij de laatste de option ROMs dekt, en de ondertekenaar van de Windows Boot Manager, Microsoft Windows Production PCA 2011, verschuift naar het 2023-bootpad.
De praktische conclusie is kort: het boot-kritieke certificaat dat je moet bevestigen is Windows UEFI CA 2023 in de DB, en dat wordt afgeschermd door KEK 2K CA 2023 in de KEK. Als de 2023-KEK ontbreekt, landt er stroomafwaarts niets, ongeacht wat je binnen de guest instelt.
3. Wat de deadlines van 2026 en 2027 daadwerkelijk stukmaken
Wees hier precies, want de koppen overdrijven de directe impact en onderschatten de uiteindelijke, en juist de nuance laat je plannen in plaats van panikeren.
Een VM die na juni 2026 nog uitsluitend de 2011-certificaten vertrouwt, stopt op die datum niet met booten. Hij blijft normaal starten en draaien, en gewone Windows-updates blijven installeren. Op de dag zelf faalt er niets.
Wat hij verliest is de beveiligingsketen voor de vroege bootfase: updates voor de Windows Boot Manager, Secure Boot DB-updates, DBX-intrekkingslijst-updates, en mitigaties voor toekomstige boot-niveaukwetsbaarheden van de BlackLotus-klasse (CVE-2023-24932). Het systeem zit vast op zijn huidige bootpad-beveiligingsniveau, zonder manier om dat te verhogen.
De gevolgen zijn gefaseerd, en dat is het goede nieuws voor de planning. Microsoft heeft aangegeven dat beveiligingsupdates voor de Windows Boot Manager rond oktober 2026 stoppen met landen op systemen met het oude certificaat, en dat het verlopen van Windows Production PCA 2011 in 2027 volgt. Het toekomstgerichte risico dat het meeste telt is bootmedia: een OS-image, WinPE-build of herstelmedium dat uitsluitend tegen de 2023-certificaten is ondertekend, boot niet op een VM waarvan de DB die nooit heeft ontvangen. Dat is het scenario dat een uitgesteld klusje verandert in een Sev-1 tijdens een herstelactie, precies op het moment dat je grijpt naar media die een vastgelopen VM weigert te vertrouwen.
Geen van deze datums is deze week. Ze liggen allemaal dicht genoeg bij dat een geclusterde omgeving met honderden guests nu zou moeten inventariseren en in de komende onderhoudsvensters zou moeten herstellen, niet pas in mei 2026. Behandel het als gepland werk met een echte einddatum, niet als een noodgeval en niet als iets optioneels.
De meeste Windows Server-omgevingen hebben dit nog niet opgemerkt. Een CloudLabs Hyper-V Cluster Health Check inventariseert de Secure Boot-status over elke Gen 2-guest en template, identificeert de 1795-valkuil, en levert een op severity gerangschikt herstelplan.
Plan een kennismaking voor een Health Check →4. Waarom Windows Server zich niet gedraagt als Windows 11
Dit is het belangrijkste operationele verschil, en het is waar algemene richtlijnen serverbeheerders in de steek laten.
Op Windows 11 worden de 2023-certificaten in toenemende mate automatisch geleverd en toegepast via servicing. Op Windows Server, en dus op je Gen 2 Windows Server-guests, zitten ze vanaf 2024 in de cumulatieve updates maar worden ze niet automatisch toegepast. Server vereist een expliciete opt-in, omdat het onbeheerd toepassen van certificaatwijzigingen op server- en virtuele workloads een boot-risico met zich meebrengt dat Microsoft niet namens jou wilde nemen. De behoudende standaardinstelling is een bewuste keuze, en betekent dat er niets gebeurt tot je binnen elke guest in actie komt.
De opt-in is één registerwaarde die Windows opdraagt de 2023-certificaten uit te rollen en de boot manager bij te werken naar de 2023-ondertekende versie, terwijl het oude 2011-certificaat blijft staan in plaats van te worden ingetrokken. Het 2011-certificaat laten staan is precies wat je in dit stadium wilt.
# Inside the guest. Opt in to Secure Boot certificate deployment.
# This adds the 2023 certificates and updates the boot manager.
# It does NOT revoke the 2011 certificate (revocation is a later step).
$p = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot"
Set-ItemProperty -Path $p -Name AvailableUpdates -Value 0x5944 -Type DWordEen achtergrondtaak verwerkt de wijziging op zijn eigen cyclus. Trigger hem in plaats van te wachten:
# Inside the guest. Run the servicing task that applies the update now.
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"Daarna is een herstart vereist om de boot manager te laten overschakelen naar de 2023-ondertekende versie. Dit alles draait binnen elke guest. Niets ervan wordt voor je gedaan door de host te patchen.
5. De valkuil: bestaande Gen 2-VM's laten de KEK-update mislukken met Event ID 1795
Dit is het stuk dat echt onderbelicht is, en de reden dat dit artikel bestaat.
Nieuwe VM's die worden aangemaakt op een volledig gepatchte host, Windows Server 2025 of een actuele Windows 11 Hyper-V-host, worden bij het aanmaken geïnitialiseerd met zowel de 2011- als de 2023-certificaten, inclusief de 2023-KEK. Zij zijn vanaf dag één in orde.
Bestaande VM's worden niet bijgewerkt wanneer je de host patcht, omdat hun certificaatstatus in hun eigen NVRAM zit. Dus doe je het verstandige: je zet de register-opt-in binnen de guest, precies zoals je dat op fysieke hardware zou doen, draait de taak, herstart, en op een groot deel van de bestaande Server 2019- en Server 2022 Gen 2-VM's mislukt het.
Het kenmerk is Event ID 1795 in het System-log van de guest, met een strekking als: de systeemfirmware gaf een fout terug, de media is schrijfbeveiligd, bij een poging een Secure Boot-variabele KEK 2023 bij te werken. De virtuele UEFI weigert de KEK-schrijfactie. Omdat de 2023-KEK de poort is voor de DB-updates, loopt de hele keten vast. De opt-in lijkt geconfigureerd, de taak draait, en toch verschijnt Windows UEFI CA 2023 nooit in de DB.
Wat dit riskant maakt, is dat er op dat moment niets stuk is. De VM boot en draait. Je merkt het niet tenzij je gaat kijken, of tot een storing na de deadline de zaak afdwingt. Een heel cluster kan in deze staat zitten, opt-in gezet, certificaten niet daadwerkelijk toegepast, en er volledig gezond uitzien op elk dashboard dat je hebt.
6. De werkelijke status in kaart brengen over een cluster
Controleer dit programmatisch vanaf je beheerserver, de machine die al WMI-toegang heeft tot elke clusternode, zoals je VMM-server. Voor de host-zijdige enumeratie hieronder werkt dat schoon. De controles per guest liggen anders: het uitlezen van de firmware-variabelen van een guest vereist remoting naar de guest, dus draai die guest-lokaal waar het kan, of via je bestaande configuratiebeheerkanaal, in plaats van ze uit te waaieren over geneste remoting. Beheerserver naar host naar guest in één hop loopt tegen de Kerberos double-hop- en credential-delegatiegrenzen aan die de meeste omgevingen niet voor ad-hocwerk hebben ingericht, en het faalt doorgaans stilletjes. Loop de VM's niet één voor één na in de GUI, en vertrouw de registerwaarde niet als bewijs, want die legt alleen de intentie vast.
Inventariseer eerst, vanaf de beheerserver, welke VM's binnen scope vallen over alle nodes. Alleen Gen 2-VM's hebben UEFI en Secure Boot; Gen 1-VM's vallen volledig buiten scope.
# From the management server. Gen 2 VMs and their Secure Boot state, all nodes.
Get-ClusterNode -Cluster "HVCLUSTER01" | ForEach-Object {
Get-VM -ComputerName $_.Name |
Where-Object Generation -eq 2 |
Get-VMFirmware |
Select-Object @{n='Node';e={$_.ComputerName}}, VMName, SecureBoot, SecureBootTemplate
}De gezaghebbende controle moet binnen de guest draaien, omdat de host niet in de toegepaste DB en KEK van de VM kan kijken. Bevestig in één keer zowel het boot-kritieke DB-certificaat als de KEK-poort:
# Inside the guest. True/True means on track. A False KEK is the 1795 signature.
$db = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
$kek = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes)
[pscustomobject]@{
DB_2023 = $db -match 'Windows UEFI CA 2023'
KEK_2023 = $kek -match 'KEK 2K CA 2023'
}Draai die controle guest-lokaal over de omgeving, met de resultaten centraal verzameld, zodat je één tabel krijgt in plaats van een handmatige rondgang. Als je toch met Invoke-Command naar binnen reikt, houd dan rekening met de double-hop-grens die hierboven is genoemd. De VM's waar KEK_2023 op false staat zijn je hersteldoelen. Waar je de oorzaak bevestigd wilt zien in plaats van afgeleid, haal de gebeurtenis dan direct op:
# Inside the guest. Surface the write-protected KEK failure if present.
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1795} -MaxEvents 5 -EA SilentlyContinue |
Select-Object TimeCreated, Message7. Herstel: de template-toggle, de opt-in, de verificatie
Wanneer een guest tegen de 1795-schrijfbeveiligingsfout aanloopt, zit de oplossing niet binnen de guest. Het is een Secure Boot-template-toggle die op de host wordt uitgevoerd en die de key store van de VM terugzet naar de template-standaarden. Op een actuele host bevatten die standaarden de 2023-certificaten, waarmee de vastgelopen KEK-store wordt vlotgetrokken.
Draai dit met de VM uitgeschakeld, tegen de eigenaarsnode:
# On the owning node. Reset the Secure Boot key store via template defaults.
# Toggle to the open CA template, then straight back to the Windows template.
Stop-VM -Name "VM01"
Set-VMFirmware -VMName "VM01" -SecureBootTemplate MicrosoftUEFICertificateAuthority
Set-VMFirmware -VMName "VM01" -SecureBootTemplate MicrosoftWindows
Start-VM -Name "VM01"De volledige volgorde die betrouwbaar werkt op bestaande Server 2019- en 2022 Gen 2-VM's is: schakel de VM uit, toggle de template op de host, start de VM, zet de register-opt-in binnen de guest als die er nog niet is, draai de Secure-Boot-Update-taak, herstart de guest, en verifieer dan met de controle uit sectie 6. KEK_2023 zou nu true moeten teruggeven en DB_2023 zou moeten volgen. Het overslaan van de host-zijdige template-toggle is precies waarom de aanpak van alleen binnen de guest op deze VM's faalt.
8. De vTPM-kanttekening en de DBX-intrekvalkuil
Twee waarschuwingen die je een vervelende middag besparen, mogelijk een vervelend kwartaal.
Ten eerste, virtuele TPM. Als een Gen 2-VM een vTPM gebruikt, kun je de certificaten niet ter plekke bijwerken. De TPM-metingen die tijdens de boot worden gedaan nemen de certificaatstatus mee, dus het wijzigen van de certificaten maakt die metingen ongeldig, met directe gevolgen voor BitLocker en elke attestatie die erop steunt. Deze VM's moeten worden geherprovisioneerd naar een actuele image in plaats van getoggled. Identificeer ze op het moment van inventarisatie, want herprovisioning is een geplande activiteit met afhandeling van data en key protectors, geen klusje van vijf minuten. In een geclusterde omgeving is dit doorgaans de grootste afzonderlijke post in het herstelplan, een reden te meer om vroeg met inventarisatie te beginnen.
Ten tweede, haast je niet met de DBX-intrekking. Microsoft documenteert een handmatige procedure die het oude 2011-certificaat intrekt door het toe te voegen aan de DBX, de verboden database. Voer die intrekking niet uit als onderdeel van deze oefening. 2011 voortijdig intrekken kan bestaande bootmedia, WinPE-images, herstelschijven en provisioning-targets onbootbaar maken, omdat die nog tegen 2011 zijn ondertekend. De veilige volgorde is strikt: voeg de 2023-certificaten toe, valideer dat alles boot vanaf zowel de OS als je herstelmedia, en laat de intrekking over aan een veel latere, bewuste fase, zodra de hele omgeving en alle media bevestigd op 2023 zitten. Vertrouwen toevoegen is omkeerbaar en veilig. Het weghalen is waar omgevingen zichzelf onbruikbaar maken.
9. Templates, golden images, en versiespecifiek gedrag
De enkele actie met de meeste hefboomwerking is je templates en golden images herstellen voordat je nog een draaiende VM aanraakt. Een ongepatchte template brengt nieuwe VM's voort die al achterlopen, zodat het probleem zich sneller reproduceert dan je het kunt herstellen.
Breng elke template op een actueel patchniveau, pas de template-toggle- en opt-in-behandeling toe als het Server 2019 of 2022 betreft, bevestig dat Windows UEFI CA 2023 aanwezig is in de DB met de controle uit sectie 6, en re-seal dan en hervat het uitrollen ervan.
Gedrag per versie, in het kort. Windows Server 2025-hosts initialiseren nieuwe VM's bij het aanmaken met beide certificaatsets, dus vers gebouwde VM's zijn schoon, maar bestaande VM's die naar 2025-hosts zijn gemigreerd worden niet met terugwerkende kracht hersteld en hebben nog steeds het werk per guest nodig. Windows Server 2022 en 2019 dragen de certificaten vanaf 2024 in de cumulatieve updates, passen niets automatisch toe, vereisen de opt-in, en zijn de versies die het meest vatbaar zijn voor de 1795-KEK-storing op bestaande VM's. Windows Server 2016 staat er het zwakst voor, met de dunste tooling- en servicingondersteuning voor deze overgang, dus behandel elke 2016 Gen 2-VM als iets dat individuele validatie vereist en, waar het kan, onderdeel van een migratieplan in plaats van een certificaatfix. Generation 1-VM's van welke versie dan ook zijn niet geraakt, zonder uitzondering.
Het patroon achter de lijst
Dit is een bekende vorm. Een langlevend cryptografisch artefact, uitgegeven en vergeten in 2011, bereikt stilletjes het einde van zijn leven en verandert in een omgevingsbrede operationele deadline. Vandaag staat er niets in brand, en juist dat maakt het makkelijk om uit te stellen: de kosten van niets doen blijven onzichtbaar tot precies het moment waarop een VM niet vanaf nieuwe media wil booten, of een bootpad-kwetsbaarheid landt zonder patchpad op een omgeving die de fix niet meer kan opnemen.
De vraag over hostfirmware versterkt het, want die stuurt mensen naar het moederbord terwijl het antwoord zit in patchpariteit en NVRAM-status per VM. In een geclusterde Hyper-V-omgeving zijn dat tientallen of honderden onafhankelijke certificaatopslagplaatsen, die elk stilletjes kunnen falen met de opt-in gezet en de certificaten nog afwezig. Het werk is methodisch in plaats van heldhaftig, en er is tijd om het methodisch te doen: inventariseer elke Gen 2-guest en template vanaf je beheerserver, verifieer de werkelijke DB- en KEK-status in plaats van het register te vertrouwen, herstel bestaande VM's met de template-toggle, plan de vTPM-herprovisioning als een eigen stroom, en laat de DBX-intrekking voor het laatst.
Plan een kennismaking voor een Hyper-V Cluster Health Check →
Veelgestelde vragen
Nee. Microsoft voorziet elke Gen 2-VM van virtuele UEFI-firmware die losstaat van de host, en Secure Boot is op de host helemaal niet vereist. Een Gen 2-VM met Secure Boot ingeschakeld valt binnen de scope van het 2023-certificaatwerk, ongeacht de hardware Secure Boot-status van de host. Het patchniveau van de host-OS telt; de hardware Secure Boot van de host niet.
Niet op die datum. Ze blijven draaien op de 2011-certificaten en gewone updates blijven installeren. Wat ze verliezen is het vermogen om bootpad-beveiligingsupdates te ontvangen, en uiteindelijk het vermogen om media te booten die uitsluitend met de 2023-certificaten zijn ondertekend. Het boot-faalrisico ligt stroomafwaarts, en er is tijd om het te voorkomen als je nu begint.
Op bestaande Server 2019- en 2022 Gen 2-VM's mislukt de KEK-update vaak met Event ID 1795, media schrijfbeveiligd. Omdat de 2023-KEK de poort is voor de DB-updates, landt er niets. Toggle de Secure Boot-template op de host met de VM uitgeschakeld, zet daarna de opt-in binnen de guest opnieuw en verifieer de DB en KEK.
Lees binnen de guest de DB- en KEK-variabelen en match op Windows UEFI CA 2023 en KEK 2K CA 2023. De registerwaarde legt alleen de intentie vast; de key stores leggen vast wat daadwerkelijk is toegepast.
Die kunnen niet ter plekke worden bijgewerkt, omdat de TPM-bootmetingen de certificaatstatus meenemen, wat ook BitLocker raakt. Ze moeten worden geherprovisioneerd naar een actuele image. Identificeer ze vroeg.
Nee. Gen 1-VM's hebben geen UEFI en geen Secure Boot, dus ze zijn volledig niet geraakt.
Een CloudLabs Hyper-V Cluster Health Check loopt over twee dagen en is read-only tijdens de beoordeling. De diagnose gebruikt niet-verstorende PowerShell; het herstel wordt geleverd als een op severity gerangschikt runbook dat je in je eigen onderhoudsvenster toepast.