[German]VMWare by Broadcom released a security update for VMware Tools to version 12.5.1 at the end of March 2025 to close a vulnerability. A blog reader contacted me the other day because he was running into massive problems with the network and AD service accounts with this version of VMware Tools under VMware ESXi.
VMware Tools 12.5.1 closes CVE-2025-22230
An Authentication Bypass vulnerability (CVE-2025-22230) exists in VMware Tools for Windows in older versions prior to 12.5.1. An attacker with non-administrative privileges on a guest VM can bypass authentication due to insufficient access control and gain the ability to perform certain high-privilege operations within that VM.
Broadcom had published the security advisor VMSA-2025-0005: VMware Tools for Windows update addresses an authentication bypass vulnerability (CVE-2025-22230) on March 25, 2025 and offers the VMware Tools for Windows 12.5.1 with a fix. I had mentioned this in the German blog post Warnungen vor Schwachstellen in Software (26. März 2025).
VMWare by Broadcom released a security update for VMware Tools to version 12.5.1 at the end of March 2025 to close a vulnerability. A blog reader contacted me the other day because he was running into massive problems with the network and AD service accounts with this version of VMware Tools under VMware Workstation.
Issues with network and AD service accounts
On April 15, 2025, German blog reader Heiko H. contacted me by e-mail because he was expecting help or confirmation from the readership. He wrote to me that he had updated the VMware Tools in his department to version 12.5.1 last weekend, as this version closes vulnerabilities in the VMware Tools for Windows in older versions before 12.5.1.
Just one of the reader's systems is affected
There are probably several hundred Windows servers in the reader`s enterprise environment and only one Windows server the reader is responsible for, causing massive issues with the updated VMware Tools 12.5.1. The symptoms are: The network is working too late and therefore the domain is not reachable in time. As a result, all services running under domain/GMSA accounts do not start.
More details on the error pattern
Blog reader Heiko H. wrote that with VMware Tools 12.5.1 installed, the affected system gets a delayed connection to the network every time the virtualized Windows server is restarted. This applies if you do not use static IPs but have activated DHCP. Normally this should not be a problem, because if DHCP is active, Windows waits for the DHCP address before continuing and searching for the domain, loading services with domain account, loading GPOs, etc.
Ist dagegen eine statische Adresse in Windows hinterlegt ist, geht das Betriebssystem wohl (zu früh) davon aus, dass es 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 gibt 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 schreit, 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?
