Windows Server 2022: Februar 2023-Patchday und das ESXi VM-Secure Boot-Problem

Sicherheit (Pexels, allgemeine Nutzung)[English]Das am 14. Februar 2023 für Windows Server 2022 veröffentlichte Sicherheitsupdate KB5022842 löst einen Kollateralschaden aus. Virtuelle Maschinen unter ESXi können anschließend nach einem Reboot nicht mehr starten und finden entweder ihre Systemlaufwerke nicht mehr oder lösen einen Secure Boot-Fehler aus. Abschalten des Secure Boot hilft – Microsoft und VMware haben inzwischen diesen Fehler bestätigt. Ergänzung: Es gibt einen Patch von VMware.


Anzeige

Boot-Probleme bei VMs

Ich hatte das für Windows Server 2022 veröffentlichte Sicherheitsupdate KB5022842 im Blog-Beitrag Patchday: Windows 11/Server 2022-Updates (14. Februar 2023) vorgestellt. Kurz nach Veröffentlichung des Beitrags meldeten sich bereits Nutzer, die über Probleme berichteten.

User #1:  Meine Vorlage Win 2022 VM fährt nach dem Update nicht mehr hoch, wenn man diese einmal ausgeschaltet hat.

User #2: Windows Server 2022 mit aktiviertem Secure Boot / VBS in der VMware machen nach dem Feb. Update Probleme und lassen sich nicht mehr starten.

Erst kommt: Windows Boot Manager… Security Violation
Danach Windows Boot Manager… unsuccessful

Kann das jemand bestätigen?

User #3: Gleiches Problem, ESXi 7.0.3
Nach Update läuft der Server, nach weiterem Boot
kommt "Security Violation"
Deaktivieren des Secure Boot löst das Problem

User #4: Selbiges Problem bei unseren Win 2022 Server VMs. Durch Deaktivierung von VBS und Secure Boot fährt die VM wieder hoch. (ESXi 7.0.3 Umgebung)

Dennis C. hat mich ebenfalls per E-Mail kontaktiert und berichtete den Fehler beim VMs:

Sehr geehrter Herr Born!

Vorab: Vielen Dank für Ihre Website, sie hat mir schon einige Male geholfen.

Ich weiß nicht, ob wir ein Einzelfall sind, aber seit heute haben wir ein Problem, welches ich gerne mit Ihnen teilen möchte. Vielleicht können Sie es ja verifizieren und veröffentlichen:

Ich habe bei einem Kunden folgendes Problem (Server 2022): Ist eine VM in der Version 19 vorhanden, der Server Member eine Domäne und erhält das Februarupdate (KB5022842), überlebt der Server den nächsten Neustart nicht.

Über die Konsole kann man noch folgendes sehen, bevor in die Boot-Optionen gewechselt wird:

VMware Seciroty Violation message

Wenn ich nun in den VM-Optionen das Security-Boot deaktiviere, startet der Server wieder wie gewohnt:

ESXi-Settings

Interessanterweise mussten bei mir die 3 Voraussetzungen zusammentreffen. Ein Server in der VM-Version 16 war nicht betroffen, dort gab es die Secure-Boot-Option nicht.

Habe Dennis dann auf die Diskussion im Blog hingewiesen. Auch auf patchlist.org wird das Thema diskutiert:

So far this is isolated to a single VM on VMware ESXI, but we have a server 2022, new install from about 2 weeks ago, installed updated Ok, rebooted OK.

Just rebooted again and it's got a "security violation."

Turning off VBS and secure boot seems to have fixed it for now.

Dort kam der Hinweis, dass auf reddit.com im Patchday-Superthread sowie hier der Fehler ebenfalls gemeldet wurde. Martin merkte auf Facebook in einer Admin-Gruppe zu meinem Post noch an:

Wichtig ist sicherlich auch der Sachverhalt, dass der erste Restart funktioniert. Also der Server läuft nach den Updates erstmal. Erst nach dem nächsten regulären Neustart tritt das Problem dann auf. Nur mal als Info für alle die sich vielleicht sicher fühlen, dass es bei Ihnen nicht ist.

Es sind wohl alles Fälle, in denen VMware ESCi zur Virtualisierung verwendet wird. Die Deinstallation von KB5022842 behebt das Problem laut Simon nicht, weil die EFI Dateien in der neuen Version zu verbleiben scheinen.

In diesem Kommentar bezieht sich einer auf Probleme bei Windows Server 2019 und Hyper-V, was von einem zweiten Nutzer bestätigt wird, aber mit obigen Beschreibungen nicht wirklich korrespondiert. Und dieser Kommentar berichtet, dass Citrix PVS vdisks/Maschinen nach dem Update nicht mehr starten.


Anzeige

VMware bestätigt den Bug

Andi hat sich bereits im Blog mit diesem Kommentar gemeldet (danke dafür) und berichtet, das ein Kollege einen Support-Case bei Microsoft eröffnet habe:

Ein Kollege hat bei MS einen A Call aufgemacht.
MS ist der Fehler bekannt, liegt am ESXI
ESXI 8.0 hat das Problem nicht.
Entweder kommt Patch von MS oder von VMWare

Inzwischen hat VMware den Support-Beitrag Virtual Machine with Windows Server 2022 KB5022842 (OS Build 20348.1547) configured with secure boot enabled not booting up (90947) dazu veröffentlicht – danke an Michael und weitere Blog-Leser auf Facebook für den Hinweis. In diesem reddit.com Post wird der Fehler nochmals zusammen gefasst und der Hinweis auf den Support-Beitrag von VMware geliefert. Im VMware-Supportbeitrag wird der Fehler beschrieben und es heißt:

Currently there is no resolution for virtual machines running on vSphere ESXi 6.7 U2/U3 and vSphere ESXi 7.0.x. However the issue doesn't exist with virtual machines running on vSphere ESXi 8.0.x. vSphere ESXi 6.7 is End of general Support.

Uninstalling the KB5022842 patch will not resolve the issue. If the Virtual machine has already been updated, then the only available options are:

  1. Upgrade the ESXi Host where the virtual machine in question is running to vSphere ESXi 8.0
  2. Disable "Secure Boot" on the VMs.

Im Supportbeitrag ist dann ein Upgrade auf vSphere ESXi 8.0 sowie Secure Boot in den VMs deaktivieren genannt. VMware warnt vor der Istallation des Updates KB5022842 auf einer virtuellen Maschine mit Windows 2022 Server, bis das Problem behoben ist. Von Microsoft gibt es inzwischen den Beitrag Windows Server 2022 might not start up im Windows Server 2022 Health Status-Bereich unter Known Issues.

After installing KB5022842 on guest virtual machines (VMs) running Windows Server 2022 on some versions of VMware ESXi, Windows Server 2022 might not start up. Only Windows Server 2022 VMs with Secure Boot enabled are affected by this issue. Affected versions of VMware ESXi are versions vSphere ESXi 7.0.x and below.

Es wird auf den obigen VMware-Support-Beitrag verwiesen. Microsoft und VMware untersuchen dieses Problem und werden weitere Informationen bereitstellen, sobald diese verfügbar sind.

Ergänzende Anmerkung: Das ist erneut ein Fall für eine Entwicklung, die ich bereits seit Jahren beobachte. Die Drittanbieter Virtualisierungslösungen kollidieren mit Windows as a Service. Bereits bei VMware Workstation hatte ich das Problem, dass Windows 10 Funktionsupdates mit dem Hypervisor kollidierten. Es wurden Updates von VMware Workstation fällig, die irgendwann recht spät kamen. Und bei jedem Versionssprung hieß es zahlen. Aktuell habe ich daher Hyper-V auf einer Maschine unter Windows 10 22H2 Pro laufen. Ist zwar eine Gurke, was die Handhabung betrifft. Aber zumindest lässt sich Windows 10 da problemlos installieren. Im Feld werden daher mehr und mehr Administratoren, sofern möglich, von VMware ESXi o.ä. zu Hyper-V wechseln. Und wieder ein Monopol mehr.

Ergänzung: Das Problem weitet sich auf Windows Server 2022-Installationen auf Bare Metal aus, siehe meinen Folgebeitrag Windows Server 2022 Feb. 2023 Patchday: Secure Boot-Problem auch auf Bare-Metal-Systemen!.

Ergänzung 2: Wie bereits in nachfolgenden Kommentaren erwähnt, hat VMware am 21. Februar 2023 einen Patch für ESXi 7.0 veröffentlicht. Details finden sich im Blog-Beitrag Windows Server 2022: VMware-Patch für Secure Boot-Problem (Feb. 2023). Hilft aber nicht bei ESXi 6.x und bei Bare Metal-Systemen.

Ähnliche Artikel:
Microsoft Security Update Summary (14. Februar 2023)
Patchday: Windows 10-Updates (14. Februar 2023)
Patchday: Windows 11/Server 2022-Updates (14. Februar 2023)
Windows 7/Server 2008 R2; Server 2012 R2: Updates (14. Februar 2023)
Patchday: Microsoft Office Updates (14. Februar 2023)
Exchange Server Sicherheitsupdates (14. Februar 2023)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Update, Virtualisierung, Windows Server abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

23 Antworten zu Windows Server 2022: Februar 2023-Patchday und das ESXi VM-Secure Boot-Problem

  1. Singlethreaded sagt:

    Bei uns meldete das vCenter 7.0.3 – 20990077 gestern ein Update. Komischer Weise wurde ein Upgrade auf den letzten Build von vCenter 8.0.0 – 21216066 vorgeschlagen, obwohl die Baseline gar nicht für Upgrades konfiguriert wurde. Am 14.02.2023 kam wohl ein Patch für die Version 8.0.0 von vCenter auf die Version 8.0b. Hat VMware da was falsch klassifiziert? Kann jemand das Verhalten bestätigen?

  2. Singlethreaded sagt:

    @Bernd, LaRs:
    Danke für die Rückmeldungen! Sieht ja doch arg nach einem Bug / Fehler von VMware aus. Werde erstmal warten, ob sich das wieder so verzieht wie es erscheinen ist, nämlich von alleine. 😉

  3. Timeless sagt:

    Die Deaktivierung von Secure Boot über vCenter auf einem Testserver auf einem unserer VMware ESXi, 7.0.3, 20842708 hat geholfen.
    Der ESXi muss also nicht zwingend auf ESXi 8.0 sein.

  4. tineidae sagt:

    Windows 2022 mit Secure Boot und aktivem VBS. ESXI auf Version 7.0 Update 3j, keine Probleme mit dem starten von VMs.

  5. Andi sagt:

    Kann das Problem ebenfalls bestätigen. Man installiert das Update und startet neu, die Maschine kommt wieder hoch. Beim nächsten Boot hängt es dann. Erst wenn Secureboot deaktiviert wurde, startet die Maschine wieder.

  6. Steven sagt:

    Ich muss mal sagen:
    Was für eine krude Anmerkung am Ende des Textes.
    Natürlich werden nun deswegen mehr Administratoren auf Hyper-V wechseln, da der Prozess ja auch einfach und ohne Business-Impact geht [/sarcasm].

    Es ist immer eine Option den Hypervisor zu wechseln, klar und es ist auch sehr einfach gesagt. Man sollte sich in dem Fall aber erstmal belesen/auffrischen was das heißt.
    Backupprodukte haben gewisse Abhängigkeiten zum Hypervisor, dies geht dann weiter auf den Storage, den man betreibt und auch die viele Optimierung in dem Bereich, die bei VMware durch VAAI zu Tragen kommt.
    Das sind teilweise technische Voraussetzungen, die ein Hyper-V gar nicht erfüllen kann mit der ODX Implementierung. Des Weiteren bewegt sich MS mit der Cloudstrategie gar nicht in die Richtung eines in 2023 potenziellen On-Premise Anbieters für Virtualisierung.
    Der Business Impact, dass jede VM offline konvertiert werden muss ist wohl dabei einfach nur noch die Kirsche auf der Sahne.

    Es spricht sich leicht aus, den Hersteller zu wechseln und in kleineren Umgebungen ist das auch machbar, aber bitte beachtet halt einfach alle Aspekte oder denkt über den MS-Tellerrand hinaus.

    • Günter Born sagt:

      Kann ich alles stehen lassen – noch cooler wäre gewesen, wenn Du das Thema "Neuer Eigentümer von VMware" (Broadcom) thematisiert hättest. Da denken einige Kunden drüber nach, zu wechseln bzw. hegen ihre Befürchtungen. Wenn Micrsoft nicht in Richtung "On-Premises Anbieter für Virtualisierung" geht, ist doch alles gut. Mal schauen, was wir da so die kommenden Jahre erleben ;-).

      • Kurt sagt:

        Gehen sie doch schon.. Stichwort Azure Stack HCI

      • Steven sagt:

        Klar kannst du das stehen lassen, ist ja schließlich deine Meinung.

        Ich behaupte auch nur, sie ist nicht genug in die Tiefe gedacht.

        Vom VMware Kauf durch Broadcom ist wohl niemand (außer Broadcom selbst) begeistert, aktuell bleibt jedoch abzuwarten wie sich das auf den Kunden auswirkt…. Und deshalb sämtliche technologische Aspekte auszublenden finde ich ein wenig übertrieben.
        Btw. ist wohl der aufsteigende Star am Virtualisierungshimmel wohl eher Proxmox und auch in vielen Belangen sehr atttraktiv.

  7. 1ST1 sagt:

    Im Laufe des heutigen Tages habe ich irgendwo auch einen Hinweis darauf gefunden, dass auch Server 2022 basierte Citrix-Terminalserver, die auf dem Citrix Hypervisor (ehemals XenServer) provisioniert mit aktiviertem Secure Boot mit der gleichen Fehlermeldung auf die Schnauze fallen.

    Den Secureboot-Ball muss man wohl Microsoft in die Schuhe schieben!

  8. E. aus E. sagt:

    In der letzten Woche hörte ich , dass Microsoft die "On Premise" Umgebungen nun nur noch "Pre Cloud" Umgebungen nennt. Mir stellt sich nun, nach dem katastrophalen November Update, und dem ebenfalls katastrophalen Februar Update, die Frage, ob Microsoft die On Premise Server Kunden so schneller in die Cloud treiben möchte, oder ob die Qualitätssicherung von Microsoft wirklich so unterirdisch ist. Beides scheint realistisch.
    Ich für meinen Teil arbeite seit über 30 Jahren mit Microsoft Windows Server Umgebungen, allerdings glaube ich langsam dass die "Post Cloud" Phase selbst für mich "Linux Server" oder "Clear OS Server" heißen könnte.

  9. Curtis Newton sagt:

    Bei Wechsel auf VMWare 8 muss ggf. Hardware getauscht werden. Hatte selber 10 Jahre alte Kisten.
    6.7 ging noch, 8 ging nicht.

    Wenn VMWare das für 6.7 nicht fixt, wäre das heftig. Auch wenn EoL (erst seit Dez.22(!) soweit in Erinnerung).

  10. Fritz sagt:

    Bevor ich Updates unternehmensweit freigebe schaue ich auch immer auf die Empfehlungsseite der Datev, um quasi eine "zweite Meinung" zu bekommen.

    Spannenderweise fand ich dort heute in der Abschlußbeurteilung einen Querverweis auf genau diesen Beitrag hier 😉

    Die Welt ist klein.

    • Günter Born sagt:

      Ist doch schön – entwickelt sich borncity.com mit dem Blog zur "Single Source" ;-)

      • Fritz sagt:

        Hmmm, Du weißt welche Verfügbarkeitsanforderungen an eine "Single Source" gestellt werden?
        Hatten wir gerade bei den "Luftikussen".

        Wie groß ist denn Dein Blog-Team, gibt es 24/7 Bereitschaft sowie Vertretungen für Urlaub und Krankheit?
        Seid Ihr geographisch weit genug aufgestellt um auch bei einem Erdbeben weitermachen u können?
        Macht Ihr regelmäßige Katastrophentests und protokolliert diese?

        Natürlich nur Spaß, aber einen Teil dieses Fragenkataloges darf sich unsere IT-Leitung im jährlichen Audit der Wirtschaftsprüfer schon anhören. 😁

        • Günter Born sagt:

          mein Gynäkologe sagt, ich bin nicht schwanger, dat Attest reicht doch sicher, um Borns Kritis weiter zu betreiben …

          Kritis = kritischer Blog ;-)

          mit dem richtigen Paper darfst Du in Deutschland alles – und wenn es schief geht, kann auf MS Answers spekuliert werden, was bloß los sei – hatten wir ja schon Mal …

          Und ich kann später 'war ein riesen und ausgefeilter Angriff…,', 'Mc Murphy hat zugeschlagen, konnte ja keiner ahnen', oder "war ein Genickbruch …" als argumentive Begründung für den Ausfall hier rein schreiben – hatten wir ja auch schon Mal… – und die Leserschaft so "mit Cloud wär das nix passiert …"

          Immerhin, wenn Borns Blogs hustet, haben die Admins in DACH Grippe. Ein Teil, weil er sich langweilt und nichts zu tun hat (meint die GF), der andere Teil, weil er dem Zwang, hier lesen und sich dann in gewohnter Weise zu ärgern zu müssen, verlustig geht, und der Rest, weil er sich nicht mehr arbeitsfähig glaubt.

          A kleines bisserl stolz bin ich schon, dass als Einzeltäter geschafft zu haben … aber ich glaube, ich lass das mit dem Single Ding (bin ja fast ein halbes Jahrhundert verheiratet) und mach bald auf Rente ;-)

          PS: Der letzte Wirtschaftsprüfer ist verlustig gegangen, man munkelt, Wirecard hätte ihm das Genick gebrochen … (ups, falsche Schublade EY hatte ich nie drin, Arthur Anderson war glaube ich schon mal für was im internationalen Steuerrecht von MS beauftragt) wenn mir jemand 1969 als kleiner Lehrling die Story erzählt hätte, wie es mit mir sehr viel später (nach 54 Jährchen) danieder geht, ich glaube, ich hätte gefragt "was hast Du gerade für Zeugs geraucht" …

  11. Christoph von Wittich sagt:

    This issue is resolved in VMware ESXi 7.0 U3k, released on February 21st 2023.

Schreibe einen Kommentar

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

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.