[English]VMWare by Broadcom hat Ende März 2025 ein Sicherheitsupdate für die VMware Tools auf die Version 12.5.1 veröffentlicht, um eine Schwachstelle zu schließen. Ein Blog-Leser hat mich die Tage kontaktiert, weil er mit dieser Version der VMware Tools unter VMware ESXi in massive Probleme mit dem Netzwerk und AD-Dienstkonten läuft.
VMware Tools 12.5.1 schließen CVE-2025-22230
In den VMware Tools für Windows gibt es in älteren Versionen vor 12.5.1 eine Authentication Bypass-Schwachstelle (CVE-2025-22230). Ein Angreifer mit nicht-administrativen Rechten auf einer Gast-VM kann die Authentifizierung aufgrund einer unzureichenden Zugriffskontrolle umgehen und die Fähigkeit erlangen, bestimmte Operationen mit hohen Rechten innerhalb dieser VM durchzuführen.
Broadcom hatte zum 25. März 2025 den Sicherheitshinweis VMSA-2025-0005: VMware Tools for Windows update addresses an authentication bypass vulnerability (CVE-2025-22230) dazu veröffentlich und bietet die VMware Tools für Windows 12.5.1 mit einem Fix an. Ich hatte dies im Beitrag Warnungen vor Schwachstellen in Software (26. März 2025) erwähnt.
Probleme mit Netzwerk- und AD-Dienstkonten
Zum 15. April 2025 hat sich Blog-Leser Heiko H. bei mir direkt per E-Mail gemeldet, weil er sich Hilfe oder Bestätigung aus der Leserschaft erwartet. Er schrieb mir, dass er voriges Wochenende die VMware Tools im Unternehmen auf die Version 12.5.1 aktualisiert habe, da diese Version ja Sicherheitslücken schließt.
Ein System beim Leser betroffen
In der Unternehmensumgebung werden wohl einige Hundert Windows Server betrieben und ausgerechnet der Windows Server im Zuständigkeitsbereich des Lesers macht (als einziger) mit den aktualisierten VMware Tools 12.5.1 massive Probleme. Die Symptome sind: Das Netzwerk ist zu spät funktionsfähig und somit ist die Domäne nicht rechtzeitig verfügbar. Daher starten dann alle Dienste nicht, die unter Domänen-/GMSA-Konten laufen.
Mehr Details zum Fehlerbild
Blog-Leser Heiko H. schrieb, dass bei installierten VMware Tools 12.5.1 das betroffene System bei jedem Neustart des virtualisierten Windows Server ein verzögerte Verbindung zum Netzwerk bekommt. Dies gelte, sofern man statische IPs benutzt und keinen DHCP aktiviert hat. Bei aktivem DHCP gibt es keine Probleme, denn dann wartet Windows auf die DHCP-Adresse, bevor es weitermacht und die Domäne sucht, Dienste mit Domänen-Konto lädt, GPOs lädt, etc.
Ist dagegen eine statische Adresse in Windows hinterlegt, geht das Betriebssystem wohl (zu früh) davon aus, dass eine funktionierende Netzwerkverbindung besteht. Dann läuft das System in Probleme, da die Domäne nicht verfügbar/erreichbar ist. In Folge kann Windows dann die Dienste nicht starten, da die Konten/Passwörter ohne erreichbaren Domain Controller (DC) nicht validierbar sind.
Im Debug-Log für den netlogon-Dienst stehen dann Fehler für DNS, Domänen-Suche und so weiter. Auch das Event-Log enthält Meldungen für die fehlende Domäne und die fehlgeschlagenen Dienststarts.
Zum konkreten System schrieb der Leser, dass es sich um einen Windows Server 2022 mit statischer IP handelt, der in ESXi 7.x virtualisiert wurde. In der Vergangenheit erfolgte ein Upgrade von Windows Server 2016 zu Windows Server 2022. DHCP zu aktivieren ist in dieser Umgebung und bei diesem System für den Leser leider keine Option. Andere virtualisierte Windows Server in der Unternehmensumgebung des Betroffenen arbeiten auch mit statischen IP-Adressen und bereiten keine Probleme.
Der Blog-Leser schreibt, dass die IT das obige Problem eindeutig auf die Installation der VMware Tools 12.5.1 zurückführen könne, da nach dem Einspielen eines Backups und anschließendem Update der VMware Tools der Fehler erneut aufgetreten ist. Der Leser hat im Anschluss noch Folgendes (leider ohne dauerhaften Erfolg) probiert hat:
- Die Netzwerkverbindungseinstellungen wurden an die eines funktionierenden Servers angeglichen,
- Die Netzwerk(karte) zurückgesetzt, und diverse Netzwerkfunktionen (Proxy, VPN-Einstellungen) wurden in Windows aktiviert/deaktiviert,
- weiterhin wurde die GPO „Beim Anmelden auf Netzwerk warten aktiviert“.
Als Workaround läuft jetzt beim Systemstart ein Task mit 30 Sekunden Verzögerung, der per PowerShell die Dienste der Anwendung auf dem Server startet. Der Leser schloss seine Mail mit dem Hinweis, dass er mit aktuellem Stand als finale Lösung noch zwei Optionen sieht (die er nach seinem Urlaub testen/umsetzen kann, wenn auch nur ungern):
- Die VM-Hülle/-Konfiguration in VMware neu erstellen und den vorhandenen Server in einer neuen VM-Hülle booten.
- Den kompletten Server neu installieren und einrichten. Das hat den Nachteil, dass dies mindestens einen Tag Produktionsausfall bedeuten.
Der Leser bat darum, das Thema im Blog einzustellen, in der Hoffnung auf einen Tipp aus der Blog-Leserschaft. Denn er sei nach 1,5 Tagen testen mit seinem Latein am Ende, und auch ein testweises Abschalten aller Profile in der Windows Firewall hat nichts gebracht.
Weitere Berichte zum Problem
Der Leser hatte Bedenken, der berühmte „Einzelfall zu sein“, da nur einer der vielen Server bei ihm im Unternehmen betroffen ist. Der Fehler scheint wohl nicht breit aufzutreten, denn es gibt nicht allzu viele Fundstellen im Internet.
Ein Thread auf reddit.com
Auf reddit.com gibt es den Thread Network not ready at startup with VMware tools 12.5.1 on Windows Server, wo das Problem ebenfalls beschrieben wird. Der Betroffene hat vor einigen Tagen das VMware-Tools-Update auf Version 12.5.1 durchgeführt, indem er eine Baseline erstellt, die ESXi-Hosts aktualisiert und dann die entsprechenden virtuellen Maschinen (hauptsächlich mit Windows Server 2019) aktualisiert hat.
Doch dann meldete die eingerichtete Überwachung einige Dienste, die automatisch starten sollten, dies aber nicht taten. Dieses Problem trat nach dem Neustart der Windows Server in den VMs auf.
Der Betroffene hat das Problem dann untersucht und herausgefunden, dass alle Dienste, die im Kontext von Domänendienstbenutzern laufen, beim Booten nicht starten können. (also genau das von Heiko weiter oben beschriebene Problem). In der Ereignisanzeige findet sich ein Eintrag mit der Ereignis-ID 7000. Der Eintrag gibt an, dass das vom Dienst verwendete Konto entweder nicht existiert oder das Kennwort falsch sei. Ein manueller Start des Dienstes funktioniert jedoch einwandfrei, also kann das Konto nicht so kaputt sein.
Bei der weiteren Analyse hat der Betroffene herausgefunden, dass seit dem VMware-Tools Update auf die 12.5.1 jeder Windows Server nach einem Neustart die Ereignis-ID 5719 von NETLOGON anzeigt. Das Problem seit neu und trat vorher nicht auf, schrieb der Nutzer und sieht dies als einen Hinweis auf die Ursache des Problems.
Er vermutet, dass die Dienste auf den virtualisierten Windows Server 2019-Systemen starten, bevor das Netzwerk tatsächlich bereit ist. Das ist ein paar Tage lang unbemerkt geblieben, weil die Netlogon-Sache keine allzu großen Probleme verursacht, aber die anderen Dienste machen dem Betroffenen jetzt zu schaffen.
Der Betroffene merkt an, dass es bereits 2011 ein solches Problem mit Windows Server 2008 R2 SP1 gegeben habe, was seinerzeit im VMware-Forum im Beitrag Windows NETLOGON 5719 at Startup diskutiert wurde. Das hilft aktuell aber nicht weiter.
Im reddit.com-Thread bestätigen andere Betroffene, u.a. mit virtualisierten Windows Server 2022-Installationen ebenfalls das Problem. Ein Poster schlug vor, per GPO die „machine identity isolation configuration“ zu deaktivieren. Es sieht mir aber nicht so aus, als ob das die Lösung für einen der Betroffenen darstellt.
Erwähnung bei deskmodder.de
Bei deskmodder.de gibt es diesen Kommentar, wo ein weiterer Betroffener schreibt, dass man mit dem Update der VMware Tools 12.5.1 das Problem habe, dass nach dem Start das Netzwerk nicht bereit ist, wenn fest IP-Adressen verwendet werden. Dann lässt sich keine sichere Verbindung zum Domain Controller herstellen.
Probleme mit Sage-Backup
In der Sage-Community gibt es den Beitrag Issues backing up within Sage after upgrading file server to VMWare Tools 12.5.1, wo jemand Probleme mit der Datensicherung von einer Netzwerkinstallation von Sage beklagt, nachdem er einen Dateiserver auf die neueste Version von VMWare Tools aktualisiert hat.
Nachdem der Windows Server, auf dem die Sage-Daten und -Dienste liegen, auf die VMware Tools 12.5.1 aktualisiert wurde, fror Sage sofort ein, falls jemand versuchte, seine Daten zu sichern. Nach dem Zurücksetzen auf die VMware Tools 12.5.0 funktioniert alles wieder.
Ähnliche Artikel:
VMware Tools 12.5.0 veröffentlicht
Windows 11 24H2: VMware Workstation Pro 17.x extrem langsam
VMware Workstation: Auto-Updates kaputt, werfen Zertifikatsfehler
VMware Workstation 17.6: Installationsproblem auf nicht englischem WindowsVMware Workstation bald auch für Business-User gratis?
Wir haben das Update zeitnah gemacht. Gute 40 VMs mit Windows Server 2016 und Windows Server 2022. Es sind keinerlei Probleme mit dem Update aufgetreten. Wir migrieren auch von 2016 -> 2022, allerdings ohne Inplace-Upgrade. Solche Fälle kennen wir in der IT alle. Eigentlich ist alles gleich, standardisiert und dann ist da einer der aus der Reihe tanzt. Häufig versenkt man viel Zeit in die Fehlersuche und macht am Ende doch alles neu.
Mal versucht die Netzwerkkarte aus dem Geräte Manager inkl. Treiber zu löschen? Dann den Server abschalten und den NIC aus der Konfig der VM nehmen. Server hochfahren und wieder runterfahren. Dann die NIC dort neu einbauen. Ich denke es wird VMXNET3 sein. Server starten und die VMware Tools nochmal installieren.
der Netzwerk Treiber in den 12.5.1 Tools ist gleich jenen der 12.5 Tools. Broadcom hat aber Updates über Windows Update verteilen lassen. Den aktuellen vmxnet3 Treiber bekommt man über Windows Update
Wie hatten das Problem auf einem unserer Anwendungsserver (seltsamerweise nicht auf allen, nicht mal auf allen mit der gleichen Anwendung) und ein einfacher Workaround war den Dienst auf diesem Server verzögert zu starten.
Eine Beobachtung:
Mit der Installation des CU 04/2025 auf einem Window Server 2022 21H2 wurde am 10.04.2025 ein Treiber-Update „Broadcom Inc. – Net 1.9.20.0“ angeboten und installiert.
Heute, 19.04.2025, wird auf der gleichen Maschine ein Treiber-Update für „Broadcom Inc. – System 9.8.30.0“ angeboten.
Habe dann zuerst die VMWare-Tools 12.5.1 installiert und das System neu gestartet.
Das Treiber-Update „Broadcom Inc. – System 9.8.30.0“ wurde immer noch angeboten, habe ich dann auch installiert. Der Server startet ohne Probleme, hat aber auch keine Domänen-Konti in den Diensten. Statische IP und ESXi 7.x passen jedoch zum Problembeschrieb.
Möglicherweise wurde da von Seiten Broadcom nochmal was gefixt und nach dem 10.04.2025 für Windows-Update freigegeben. Und diese Komponente wird nicht mit den VMware-Tools 12.5.1 aktualisiert. Vielleicht sollte man bei den Servern mit Problemen nochmals prüfen ob da noch das „Broadcom Inc. – System 9.8.30.0“ – Update ein Rolle spielt und das Problem zwischenzeitlich behoben wurde.
Nachtrag:
Broadcom hat am 01.04.2025 den Article ID: 313145 „VMware Tools drivers published To windows update“ aktualisiert. Warum wurde der vmci-Treiber 9.8.30.0 am 10.04.2025 nicht im Windows Update angeboten? Der vmxnet-Treiber 1.9.20.0 war zu diesem Datum in Windows Update schon vorhanden.
https://knowledge.broadcom.com/external/article/313145/vmware-tools-drivers-published-to-window.html
Nachtrag 2:
Wer aufmerksam liest ist besser informiert. Gilt auch für mich. :‑)
Im Artikel von Broadcom steht unten im Abschnitt „Known Issues“ unter Punkt 2: „VMware will publish the latest driver to Windows Update on each release, but due to the Microsoft gradual rollout, the driver will not show in the search result until the gradual rollout is completed. Due to the limited release period, a Windows VM may have a delay before receiving the driver update“
Dieses „Delay“ ist wohl die Erklärung warum die Updates im Einzelsprung den Weg zu unseren VMs finden. Wünsche allen schöne Ostern!
An den Problemmelder, folgendes ist wilde Spekulation und mir ist bewusst, dass die E1000E nicht so performant ist:
Vielleicht hilft es, bei diesem Fehlerbild auf die E1000E zu wechseln und dann in Windows in den erweiterten Treiberoptionen des Intel Standardtreibers die Einstellung „Wait for Link“ zu aktivieren.
(Hintergrund: In meiner Umgebung ist die E1000E Standard und erhält keine Besonderen Treiber, macht auch keine Probleme. Bei wenigen stark IO-fordernden Systemen ist selten vmxnet konfiguriert, da kann ich nicht mitreden. Vor einiger Zeit (vielleicht bis heute) verpassten diverse Windows Clients standardmäßig ihre Group Policy Startskripte, weil MS besonders schnell aufs Desktop kommen wollte, obwohl man die GPO „Wait für Network“ gesetzt hatte.
Die tatsächliche Lösung dagegen war bei Systemen mit Intel Karten die Einstellung „Wait For Link“, so dass der Treiber nicht zu früh behauptet, es sei bereit und damit auch schon das Netz…)
Bei Erfolg bitte Rückmeldung…
Zur Ereignis-ID 5719,NETLOGON – diese gibt es bei uns auf einem Windows Server 2019 in der Domäne mit VMXNET3 regelmässig. Probleme macht der Server aber nicht, fährt sehr schnell hoch und alles funktioniert wie erwartet. Anmelden mit einem Domänenkonto am Server ist sofort möglich. Auf Grund des Kommentar von „js“ habe ich versucht, das Problem mir der GPO „Wait for Network“ zu beheben. Das funktionierte in diesem Fall nicht.
Was mir beim Testen aufgefallen ist, der Fehler steht nur in etwa 6 von 10 Neustarts im der Ereignisanzeige. Es muss da um Millisekunden gehen.
Anschliessend die VMWare Tools 12.5.1 installiert. Es funktioniert weiterhin alles genau gleich vorher (einwandfrei, aber mit Netlogon-5719 Meldung).
Hi ChristophH, nur aus Vorsicht zur Nachklärung:
Meine Geschichte betraf Admins, denen schmerzhaft auffiel, dass das System ungeordnet startete und die sich eine geordnete GPO Verarbeitung via „Always wait for the network at computer startup and logon“ GPO wünschten.
Dabei trat das Wunschverhalten NUR ein wenn:
A) Der Startprozess gelegentlich durch Windows Updates verzögert wurde
B) Vielleicht(?) DHCP statt Static IPs für Geduld sorgten
C) Garantiert(!) bei einer Intel Netzwerkkarte auch „Wait for Link“ von „Auto“ auf „On“ eingestellt wurde.
Ich kann mir gut vorstellen, dass Betroffene bei der Sache von dem Treibersetting nutznießen könnten, ob die GPO nötig ist, weiss nicht, aber wenn ich betroffen wäre würde ich die in zweiter Instanz auch mit probieren…