Secure Boot 2026: Warum es Provisioning-Umgebungen härter trifft

Wer Citrix Provisioning betreibt, kennt die Arbeitsteilung: Das Werkzeug erstellt die vDisk — aber die saubere Bereitstellung der Umgebung drumherum liegt beim Kunden. Und genau dort lauern gerade Fallen, die nicht jeder Administrator auf dem Zettel hat. Die aktuellste heißt Secure Boot, und sie hat ein Ablaufdatum.

Die Secure-Boot-Zertifikate von 2011 laufen ab

Microsoft tauscht 2026 die komplette Secure-Boot-Zertifikatskette aus. Zwei der drei Zertifikate aus dem Jahr 2011 sind bereits abgelaufen: die KEK CA am 24. Juni, die UEFI CA am 27. Juni 2026. Das dritte, die Windows Production PCA 2011, folgt am 19. Oktober 2026. Der Ersatz ist die 2023er-Generation, die per Windows Update in die UEFI-Firmware jeder einzelnen Maschine gelangen muss.

Für klassische PCs ist das ein Rollout wie jeder andere. Für Provisioning-Umgebungen ist es eine Falle mit Ansage — so sehr, dass Citrix dazu gleich zwei eigene Known-Issue-Artikel veröffentlicht hat (CTX696455 für VMware und XenServer, CTX696473 für Hyper-V). Der Kern beider: PVS-Targets mit Secure Boot booten nicht mehr, nachdem Windows-Updates in die vDisk eingespielt wurden.

Warum es Provisioning besonders trifft

Der Mechanismus dahinter ist schnell erklärt — und typisch PVS. Das Windows-Update legt einen mit der 2023-CA signierten Bootmanager ins Master-Image, und damit in die vDisk. Diese vDisk wird an Dutzende oder Hunderte Target-VMs gestreamt. Jede dieser VMs prüft den Bootmanager gegen die Zertifikate in ihrer eigenen UEFI-Firmware — und die stammt aus einem Template von vorgestern. Kennt sie die 2023-CA nicht, bootet sie nicht. Die Farm steht.

Ein einzelner PC repariert sich per Windows Update selbst. Eine provisionierte Farm nicht — denn das Image ist eingefroren, und die Firmware liegt pro VM beim Hypervisor. Genau diese Schere zwischen „einem Image“ und „hundert Firmware-Zuständen“ macht das Thema für PVS-Umgebungen so gefährlich.

Ehrlich gesagt: Das ist kein PVS Forge-Problem

Und hier sind wir wieder bei der Arbeitsteilung. Ein Imaging-Werkzeug erstellt aus dem Master Target eine saubere vDisk — das gelingt auch mit Secure Boot einwandfrei. Die Firmware der Target-VMs, die Hypervisor-Version, die VM-Templates: All das liegt beim Kunden und seinem Hypervisor-Hersteller. Darauf hat kein Imaging-Werkzeug der Welt Einfluss.

Aber: Wer, wenn nicht das Werkzeug, das vor jedem Imaging ohnehin auf dem Master arbeitet, sollte den Administrator rechtzeitig warnen?

Prüfen, warnen, beheben

Genau das ist die Haltung von PVS Forge — bei jedem Imaging-Start, für jedes Master Target, ohne Konfiguration.

Prüfen heißt: Läuft der Master überhaupt mit Secure Boot? Stecken die 2023-Zertifikate bereits in seiner Firmware-Datenbank, und im KEK? Systeme ohne UEFI oder ohne Secure Boot werden still übersprungen — kein falscher Alarm.

Warnen heißt: Fehlen die Zertifikate, erscheint ein verständlicher Hinweis mit Erklärung, den Citrix-Artikelnummern und einer Kopiervorlage für die manuelle Behebung.

Und differenzieren heißt: unterscheiden, was wirklich Sache ist. Fehlt die 2023-CA in der Datenbank, droht das Boot-Szenario — harte Warnung. Fehlt nur der KEK, sind künftige Zertifikats-Updates blockiert — Hinweis. Und wenn die Firmware das Update schlicht verweigert sagt PVS Forge klar: Das ist Hypervisor-Seite, hier hilft nur ein Hypervisor-Update, keine Software im Gast.

Der Ein-Checkbox-Fix

Wer es bequemer mag, aktiviert eine einzige Option: „Fix Secure Boot Certificates (2023-Rollout)„. Dann setzt das PVS Forge vor dem Imaging den offiziellen Microsoft-Opt-in auf dem Master und stößt den Windows-eigenen Update-Task an und startet das Master Target neu. Windows wendet die Zertifikate anschließend an, wo die Plattform es zulässt — und weil der Auslöser mit in die vDisk wandert, können auch die gestreamten Devices die Zertifikate beim Boot in ihre eigene Firmware übernehmen, sofern der Hypervisor das unterstützt.

Wichtig dabei: Der Fix nutzt ausschließlich den dokumentierten Microsoft-Mechanismus, ist wiederholbar und greift nur, wenn tatsächlich etwas fehlt. Selbst der Fall, dass die Hypervisor-Firmware nicht mitspielt, ist harmlos — dann passiert nichts Schlimmes, und der Hinweis benennt die Ursache.

Die Grenzen — und warum man sie benennen sollte

PVS Forge kann viel, aber nicht alles, und es ist seriöser, das auszusprechen. Der Hypervisor muss die 2023-Kette können (etwa VMware vSphere 8.0 U3h oder neuer, XenServer 8.4, aktuelles Hyper-V auf Windows Server 2019 oder neuer). Ältere Stände verweigern das Beschreiben der Firmware — das kann keine Gast-Software umgehen. Die VM-Firmware bestehender Targets zu aktualisieren ist eine Hypervisor-Aufgabe. Und auch Citrix Provisioning selbst braucht für die neue Kette eine aktuelle Version.

Ein gutes Werkzeug warnt rechtzeitig, behebt, was im Gast behebbar ist, und zeigt mit dem Finger auf die richtige Stelle, wenn es woanders klemmt. Mehr kann und soll ein Imaging-Werkzeug nicht versprechen.

Nebenbei: dasselbe Prinzip bei DNS und DHCP

Secure Boot ist nur das aktuellste Beispiel für diese Philosophie. Ein zweites kennt jeder PVS-Administrator, oft ohne die Ursache zu kennen: Gestreamte Devices tragen die DNS- und DHCP-Identität des Master Targets im Image — und löschen beim Boot schon mal den DNS-Eintrag des Masters oder fragen dessen alten DHCP-Lease an. Der saubere Umgang damit ist, diesen Registrierungs-State unmittelbar vor dem Sealing zu bereinigen: die DNS-Bereinigung risikolos standardmäßig, weil Windows den Zustand ohnehin neu aufbaut; die DHCP-Bereinigung als bewusste Option gegen Adresskonflikte nach dem Rollout.

Fazit

Die Secure-Boot-Umstellung 2026 ist keine Theorie. Zwei Zertifikate sind abgelaufen, das dritte folgt im Oktober, und Citrix hat die Boot-Ausfälle bereits dokumentiert. Provisionierte Umgebungen sind strukturell im Nachteil, weil ein Image auf viele Firmware-Zustände trifft.

PVS Forge macht daraus das, was es tun sollte: Es prüft bei jeder Gelegenheit, warnt verständlich, behebt per Checkbox, was behebbar ist — und ist ehrlich über den Rest. Der Secure-Boot-Check ist dabei kein Sonderfall, sondern eines von vielen Beispielen. Es sind all die eingebauten Kleinigkeiten, vom DNS/DHCP-Aufräumen bis zur Zertifikats-Warnung, die dem Administrator das Leben von Haus aus leichter machen.


PVS Forge prüft die Secure-Boot-Zertifikatskette bei jedem Imaging out-of-the-box, warnt mit Kopiervorlage und behebt per Checkbox den Microsoft-Opt-in, wo die Plattform es zulässt — und benennt klar, wenn die Ursache beim Hypervisor liegt. Praxiswissen, eingebaut ins Produkt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen