[English]VMware by Broadcom hat wohl vor einigen Tagen die neue VMware Workstation Version 17.6 veröffentlicht. Nutzer, die ein nicht englisches Windows als Betriebssystem verwenden, sollten aber mit "Installationsversuchen" abwarten. Die VMware Workstation Version 17.6 lässt sich nicht installieren, weil vom Installer erwartete englischsprachige Gruppennamen nicht vorhanden sind.
Anzeige
Seit Broadcom VMware übernommen hat, geht da einiges den Bach runter. Im Mai 2024 wurde VMware Workstation Version 17.5 zwar für "Personal Use" freigegeben, d.h. private Nutzer dürfen das Produkt kostenfrei einsetzen (siehe VMware Workstation/Fusion Personal Use-Mode bestätigt, Schwachstellen vorhanden, fehlende Lizenzen im Broadcom-Portal). Mir ist es aber noch nicht mal gelungen, ein Benutzerkonto bei Broadcom einzurichten, um mir diese Version zum Test mal anzuschauen.
VMware Workstation Version 17.6
Über "Kollegen" habe ich doch noch eine Version zur Evaluierung erhalten und wunderte mich, als ich diese am Sonntag nach längerer Abstinenz mal wieder startete, dass VMware Workstation Version 17.6 beworben wird.
Um diese Version zu erhalten, muss man auf Get More Information klicken, um zum Broadcom-Portal zu wechseln. Dort wird einem die Workstation Pro App für 120 Dollar pro Jahr angedient. Um diese Version zu bekommen, muss man sich am Portal an seinem Benutzerkonto anmelden.
Anzeige
Installationsprobleme bei nicht englischem Windows
Es gibt Käufer der VMware Workstation Pro, die schnell auf die neue Version wechseln wollen. Aktuell kann man nur raten, mit dem Upgrade zu warten. VMware by Broadcom hat es nämlich vermurkst – die neue VMware Workstation Pro 17.6 lässt sich nicht installieren, wenn man kein englischsprachiges Betriebssystem verwendet.
Blog-Leser Hartmut hat mich zum 5. Oktober 2024 per Mail kontaktiert und auf Probleme hingewiesen (danke dafür). Er schrieb, dass die Entwickler Murks in Bezug auf die aktuelle VMware Workstation Pro Version 17.6 abgeliefert haben. Diese Version lässt nicht auf nicht englischsprachigen Windows-Systemen installieren. Nutzer eines deutschen, französischen, italienischen Windows etc. scheitern bei der Installation, "da Gruppen fehlen". Zudem hat VMware wohl die Unity-Funktion in der Version 17.6 gestrichen.
Diskussion auf Dr. Windows
Hartmut hat mir den Link auf die am 28. September 2024 gestartete Diskussion VMware Workstation pro – Update bei Dr. Windows geschickt. Dort beschwert sich jemand, der die VMware Workstation Version 17.5 gekauft hat, dass das Upgrade auf die Version 17.6 scheitert.
Diskussion im Broadcom-Forum
Im Broadcom-Forum gibt es den Thread I cannot upgrade to ,or install, VMware Workstation 17.6 Pro for Windows, wo mehr Details zu finden sind. Ein Nutzer, der upgraden wollte, erhielt in einem Popup den Installationsfehler:
An error occurred while applying security setting. Users is not a valid user or group.
Es könnte ein Problem mit dem zu installierenden Paket, dem Domain-Controller im Netzwerk oder der Netzwerk-Verbindung sein, wird im Popup angegeben. Das ist aber falsch, denn die Ursache liegt an anderer Stelle.
In VMware Workstation 17.6 gibt es einen Fehler, der die Installation auf einem nicht-englischen Windows scheitern lässt. Der Installer erwartet nämlich eine Gruppe "Authenticated Users", sowie die Gruppe "Users" die es in diesen Windows-Versionen nicht gibt. Als Workaround könnte man eine administrative Eingabeaufforderung öffnen und folgende Befehle eingeben.
net localgroup /add "Users" net localgroup /add "Authenticated Users"
Die Befehle legen die benötigten Gruppen mit den englischsprachigen Namen an, so dass der Installer durchlaufen sollte. Broadcom ist sich der Problematik bewusst und arbeitet an der Behebung des Problems. Aktuell wird empfohlen, bei VMware Workstation Pro Version bei 17.5.2 zu bleiben, bis der Fehler behoben ist.
Anzeige
Ich empfehle sowieso immer Windows in Englisch + Landessprache zu installieren… VMware ist da nämlich nicht der Einzige der pfuscht! Somit kann man sprachtechnische Fehler gekonnt vermeiden.
Es schadet nicht und der zusätzliche Speicherplatz der dadurch belegt wird frisst heute kein Brot mehr.
ja absolut. mir aber eigentlich ein rätsel warum die lokalisierung, also von internen ressourcen nie rückgängig gemacht wurde.
weil es das nicht benötigt. ihr habt das Konzept der Wellknown SID nicht verstanden.
VMware leider auch nicht … das System benötigt benötigt keine Namen. Die ACLs und SDDL sind sprachunabhängig, bzw verwenden festgelegte Abkürzungen
schlechte Entwickler benutzen den Namen
Das Konzept ist so wellknown dass nur MS es benutzt. nirgendswo anders macht man es so. klar jetzt bei user und gruppen im ad kannste dich drauf berufen, ich habe mich aber eher auf dateipfade etc bezogen, da wo es keine darüberliegende meta ebene gibt. da helfen auch keine junctions und ausgeblendete ordner
Als Anwender ist es völlig egal, was die technische Ursache ist und ob Microsoft, Broadcom oder der heilige Sankt Sonstwer da was verbockt hat. Es zeigt einmal mehr die komplette Arroganz, Ignoranz und Inkompetenz der IT-Branche. Wie lange muss noch gebettelt werden, bis es endlich ein Haftungsrecht in der IT-Branche gibt, wie es überall anders völlig selbstverständlich ist?
Wie heißt Linus Torvalds Biographie so schön: "Just for Fun" – das drückt eigentlich alles aus, wie diese Branche denkt und arbeitet – Lokalisierung scheint eben kein "Fun" zu sein!
Muss ich als User auch nicht! Sondern darf zurecht davon ausgehen das der Entwickler seinen Job beherrscht.
Nur das in der Software/IT Branche ja keine Haftung gibt darf ich als User eben die Fehler ausbügeln indem ich irgendwelche Workaround
nutzen muss.
AMEN!
Wer SDDLs oder SIDs unter den Rock gucken will: https://skanthak.hier-im-netz.de/tidbits.html#sddl, https://skanthak.hier-im-netz.de/tidbits.html#sidereal und https://skanthak.hier-im-netz.de/tidbits.html#security sowie https://skanthak.hier-im-netz.de/download/SDDL.INF
Eigentlich liegt der Pfusch wie so oft bei MS.
Wer kommt denn bitte auf die depperte Idee, interne Bezeichner zu lokalisieren?
Nur doof, dass in diesem speziellen Fall Microsoft mal nicht der Schuldige ist. Bei den Gruppennamen handelt es sich mitnichten um einen internen Bezeichner, der interne Bezeichner wäre die SID und die ist sprachunabhängig.
Und die Doku dazu ist natürlich präzise und eindeutig? Oder eher ein halbgar gefrickelter Bockmist, so dass selbst große Partner wie VMware nicht mehr durchblicken?
Leider hilft das Anlagen der Gruppen nicht wirklich. Die Installation klappt dann zwar, aber Workstation Pro läßt sich dennoch nicht starten. Auch Mist, daß ein Downgrade nicht möglich ist. Da hilft nur Deinstallieren und 17.5 wieder neu installieren. War denn nach der Übernahme durch Broadcomm eine Verbesserung zu erwarten? Notabene ist es mir nicht gelungen bei Broadcom ein Support Ticket aufzumachen, trotz aktivem Supportvertrag. Ich kann nur jeden vor diesem Unternehmen warnen.
Das ist (vermutlich) nicht das einzige Problem. Ich hatte vor zwei Tagen das Upgrade auf 17.6 installiert (mit anlegen der Gruppen), danach ist aber mein Arbeits-VM in unregelmäßigen Abständen "eingefroren" und es half nur noch VM runterfahren.
Möglich dass das bei mir ein Einzelfall ist, ich glaube aber nicht dran…
War mir zu blöd, habe 17.6 wieder deinstalliert und 17.5 installiert.
Da müssen absolute Amateure am Werk sein. Wer Gruppen in kompilierten Programmen ernsthaft über den Namen anspricht hat wirklich keine Ahnung. Das ist bodenlos peinlich. Gerade Systemgruppen haben doch nicht umsonst einheitliche SIDs.
Das gleiche beim Player 17.6, den ich mir gestern heruntergeladen hatte zum Testen.
Dein Artikel passt wieder perfekt, damit ich jetzt nicht den Fehler bei mir suche!
Siehe auch:
VMware Workstation Pro und Player 17.6 mit Sicherheitskorrekturen und unterstützt Windows Server 2025 [Workaround zum Fehler]
—
GB: Danke für den Link – den Artikel der Kollegen von deskmodder.de hatte ich übersehen.
Für alle die vielleicht schon länger überlegen zu Linux zu wechseln (pssst: VMware Workstation Personal läuft auch super unter Linux :-) )
Unter Linux (Pop!_OS) lief das Update auf die neue Version sauber durch.
Wenn man die Meldung bestätigt hat, öffnet sich ein weiteres Fenster in dem der komplette Patchingvorgang von statten geht.
Sobald das sauber erledigt war, muss man leider (immer noch) alternative host-modules von Hand installieren. Dafür gibt es Abhilfe –> hXXps://github.com/mkubecek/vmware-host-modules
Ein kleines Howto wie man auf der Broadcom Seite bis zum Download navigiert ist hier – hXXps://www.mikeroysoft.com/post/download-fusion-ws/
have fun!
Die 17.6 ist seit einem Monat offiziell erhältlich. Der Fehler relativ zeitnah bei VMware by broadcom im Forum bekannt und es gibt keine Korrektur des fehlerhaften setup?
Traurig
Vermutlich wurde bei der Personalanpassung von über 1200 Menschen nicht nur im Vertrieb massiver Stellenabbau betrieben um die sinnlose Gier zu befriedigen.
VMware by broadcom wird von uns gemieden nach der angepassten Lizenzpolitik.
Wir haben die Alternativen wieder belebt und unterstützen VMware by broadcom in keinster Weise mehr.
Ich empfehle jedem sowieso auf 17.6 zu verzichten und bei… 17.5.1/17.5.2 zu bleiben.
VMware hat nämlich bei 17.6 die Funktionalität soweit heruntergeschraubt (End Of Life von wichtigen Kernfunkionen, Entfernung von legacy VMTools Image aus dem Installer) dass die weitere Benutzung bald nicht zumutbar und empfehlenswert wird.
Die 17.5.1 braucht noch die Seriennummer, die 17.5.2 nicht mehr.
Einfach die ISO-Images aus dem Installationsordner in einen eigenen Ordner kopieren.
So hab ich das auch gemacht. Nutze eine eigene Festplatte für die VMs und dort hab ich dann auch die Daten für den allgemeinen Austausch, Daten für VMs selbst (Wallpaper, Profilbilder Testdokumente, etc.) und eben nun auch die Images der LegacyTools liegen.