[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!
Na nun lehn Dich mal nicht so weit aus dem Kellerfenster :)
Ich und die Leute um mich herum kennen und nutzen wo sie können in sprachübergreifenden Systemskripten lieber die SIDs.
Was ist denn die "Meta-Ebene" für Dich? Nicht etwa dieses lokalisierende desktop.ini-Gezauber an das sich nur der explorer.exe hält?
Was für ein Stuss das ist, sollte man eigentlich erkennen, wenn man weiß, das Microsoft so gar ein walisisch/gälisches Windows liefern kann. Da sitzt tatsächlich eine einzelne Muttersprachelerin in ihrem Einöd-Hof und finanziert sich so ihr Leben…
@caligula
> Das Konzept ist so wellknown dass nur MS es benutzt. nirgendswo anders macht man es so […]
wir reden aber nun Mal von Windows und wie es funktioniert. wer mit Windows arbeitet und sich in dem Ökosystem bewegt sollte verstanden haben, das er die Grundregeln beherrschen muss.
VMware hat den Namen verwendet, nicht die SID. das war der Fehler und das Problem liegt nicht bei Microsoft, sondern beim Partner, der nicht weiß, wie es funktioniert
apropos Dateipfade, Variablen existieren, man muss die nur benutzen
"apropos Dateipfade, Variablen existieren, man muss die nur benutzen"
Ich argwöhne, dass Du mit "Variablen" Umgebungsvariablen meinst. Falls ja: AUTSCH!
Umgebungsvariablen kann der Benutzer/Aufrufer jederzeit ändern und damit auch ausführbare Dateien von beliebigen, unter seiner Kontrolle stehenden (externen) Pfaden laden!
Siehe https://cwe.mitre.org/data/definitions/73.html" "CWE-73: External Control of File Name or Path"
Das Win32-API hat dafür die Funktionen GetAllUsersProfileDirectory, GetCurrentDirectory, GetDefaultUserProfileDirectory, GetProfilesDirectory, GetSystemDirectory, GetSystemWindowsDirectory, GetSystemWow64Directory, GetUserProfileDirectory, GetWindowsDirectory, SHGetFolderPath und SHGetKnownFolderPath
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
Die Webseiten lassen sich mit Chromium nicht öffnen (Einstellung: Standardschutz).
Fehlermeldung:
Dies ist keine sichere Verbindung
NET::ERR_CERT_AUTHORITY_INVALID
Mit Firefox funktioniert es hingegen problemlos.
Kann ich hier nicht bestätigen – es dauert bzw. ich muss refreshen. Hier ist der Defender unter Windows aber die Ursache, der den Zugriff wegen des Eicar-Testvirus blockiert.
ESET blockiert die Seite auch mit der Meldung :
Potenzieller Phishing-Versuch
Diese Webseite versucht, ihren Besuchern vertrauliche Informationen wie z. B. Anmeldedaten oder Kreditkartennummern zu entlocken.
Das Zertifikat der Seite läuft in 3 Tagen, am 11.10.2024 ab.
Nach einem Refresh geht es jetzt aber auch mit Chromium.
Hi,
der eine oder andere AV springt auf die Seite an.
Windows Defender ebenfalls.
VT: https://www.virustotal.com/gui/url/26b97fc6f54e304a25ca6d316ebe360a4094fb6c1ac73f0021c7a3fb32be32cf
Nur kurz als Hinweis.
gruß
Steffen
Der Hinweis nützt nichts – Stefan Kanthak hat die Angewohnheit, eine Signatur des Eicar-Test-Virus in eine Data-Struktur seiner HTML-Seiten einzubinden, um zu schauen, wie clever Sicherheitslösungen sind.
Steckt in einer Meta-Anweisung als preload Daten-Sequenz. Solange eine Eicar-Signatur nur in einer Data-Struktur als Meta-Daten vorliegt, wird sie nicht verwendet und eine Sicherheitslösung sollte sie nicht bemängeln. Die meisten Virenscanner springen dann aber an …
Gut, dann muss ich da nicht drauf!
Auch eine Methode die Leute fern zu halten!
Man kann es auch direkt bei MS nachschlagen:
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers#well-known-sids
https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids
Wobei ein Virus mit der Struktur von Eicar auf aktuellen Systemen nicht mehr startfähig ist.
Er eignet sich dennoch als vollkommen ungefährlicher Test, ob der Virenscanner aktiv ist, und nicht ungewollt deaktiviert wurde (weil Microsoft die .exe umbenannt hatte. BTST)
Was das den Author der Webseite angeht erschließt sich mir nicht.
Per Definition kann Eicar auch mit Notepad und der Tastatur eingetippt werden und als .txt gespeichert werden.
Es bleibt weiterhin ein Test-Pattern.
Ich erwarte eigentlich, das ein Virenscanner mir Anwender das sagt, das er die Signatur gefunden hat.
Ich könnte latürnich auch einen richtigen Schädling, den das von Ahnungslosen noch immer missbrauchte und im Ernstfall unwirksame Schlangenöl nicht erkennt, so einbauen, dass der (sofort oder irgendwann später) wirksam wird.
Wer spielen will kann harmlose URLs wie ldap://localhost oder mailto:? in die Adresszeile des WWW-Browsers oder bei Start->Ausführen eingeben.
Danach (oder davor) im Kommandoprozessor noch FTYPE ldap und FTYPE mailto ausführen: die ausgegebenen Kommandozeilen zeigen nur 2 von ca. zwanzigtausend Instanzen der als CWE-73 wohlbekannten Schwachstelle, die die Redmonder Frickler vor 30 (in Worten: DREISSIG) Jahren eingebaut haben.
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?
Bei dem Preis der von VMware aufgerufen wird, erwarte ich als Kunde, dass auch die schlechteste Doku befolgt wird. Außerdem haben solche großen Softwareanbieter doch sicher ganz andere Möglichkeiten bei Microsoft als irgendein Hobby-Coder, da kann man doch auch mal nachfragen. Nochmal bei dem Preis, erwarte ich das auch.
ja, aber das hilft aber hier nichts, weil diese Anfänger vermutlich die Gruppe "Administrators" suchen, die im Deutschen halt "Administratoren" heißt…
Das ist ein typischer Anfängerfehler, nicht nur durch den beschränkten Horizont das es auch andere Sprachen in der Welt gibt, zu begründen, sondern auch durch fehlendendes Auditing…
Man könnte mit den international gleich SIDs arbeiten. Das jetzt nachträglich reinzubastelmln kann dauern.
(Es gab früher immer mal wieder Programmierer, die erwarteten das der User mit der Funktion Administrddminiator, als Display Name Administrator trägt. Da hat MS immer die Notbremse gezogen…)
Aber wie man seine Kunden zu höheren Preisen nötigt wissen sie…
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.
Hast Du tatsächlich einen "aktiven Supportvertrag"?
Ich bin damit nämlich auf die Nase gefallen.
Im April ein Upgrade von Workstation Pro 15 auf Version 17 gekauft und anschließend 17.5.2 installiert.
Als 17.6 herauskam habe ich versucht, es bei Broadcom herunterzuladen. Es tauchte aber in meinem Account unter "My Entitlements" nicht auf.
Also am 20.09.2024 ein Support-Ticket geöffnet. Und dann gewartet. Und gewartet.
Vorgestern (7.10.2024) dann ein Anruf von Broadcom (laut Landesvorwahl aus den USA). Der durchaus nette, deutschsprechende Herr hat dann geprüft und mir mitgeteilt, dass ich korrekterweise keinen Zugriff auf das Update habe, weil mein Support ausgelaufen ist.
Ich: Kann doch nicht sein, ist doch noch kein halbes Jahr alt
Er: Doch, im Kaufvertrag steht "Support term: 30 days"
Und das steht da tatsächlich im Kleingedruckten. Hatte ich nicht gesehen.
Das Broadcom der Meinung ist, dass nach Ablauf des Supportzeitraums auch keine Updates innerhalb der gekauften Hauptversion (Hier Version 17) zur Verfügung gestellt werden, das steht auf einem anderen Blatt. Fühle mich an dieser Stelle leicht verar…t
Zum letzten Satz: Im Jahr 2001 kam mein Titel VMware Workstation Praxisführer bei SuSE Press für SuSE Linux heraus. Damals war ich bereits unter Windows auf VMware Workstation. Seit dieser Zeit lief das Produkt hier bei mir unter Windows. Manchmal habe ich eine Presselizenz bekommen, aber auch immer mal wieder eine Lizenz gekauft. Als es dann anfing, dass so einen oder zwei Monate nach Kauf einer Lizenz eine neue Hauptversion herauskam, die dann aber nicht Upgrade-berechtigt war, bin ich ausgestiegen.
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.
Hallo Marco,
das ist kein Einzelfall; habe das auch ein Paar Male gehabt: das GUI der VM friert ein bzw. man kann in die VM nicht reinklicken und sie bedienen. Die VM an sich läuft und kann z.B. per RDP erreicht werden – wenn es denn in der VM aktiviert ist. Ansonsten nur per 'vmrun' herunterfahren.
Ich habe das mit Workstation und mit Player 17.6 beobachtet, auf Windows 11 Host.
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!
Bei Linux ist ja auch kein zugekloster Marketingler auf die hirntote Idee gekommen, "root" auf "Wurzel" umzubenennen um das Betriebssystem einzudeutschen.
Microsoft lebt in seiner eigenen Welt und singt wie Pippi Langstrumpf.
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.
Bei openSUSE kann man unter System -> Yast -> Virtualisierung -> KVM und Tools (oder XEN und Tools) installieren und die im Kernel eingebaute VM kostenlos benutzen.
Da braucht man kein vmWare, kein VirtualBox und kein Proxmox.
Warum sollte man sich also mit vmWare herumärgern?
Ist ein Argument – wollte Sonntag zwei ältere Notebooks mal mit Mint bzw. Q4OS bestücken – um auch mal zu sehen, ob KVM da drauf läuft. Aber welch Pleite: Als ich die beiden Notebooks aus der Ecke gegriffen habe, wiesen beide einen Displayschaden auf (muss wohl mal was drauf gestellt worden sein, wenn ich das auch nicht erinnere). Der Monitor im VGA-Adapter, den ich beim Test verwendet habe, half auch nicht, da der Linux-Fenstermanager entweder nur ein blaues Bild spiegelte oder es sonst ein Problem gab. Werde jetzt wohl die beiden Uralt-Notebooks entsorgen (einer ist ein schwachbrüstiges Netbook mit 32-Bit-Atom-CPU) und nach einem günstigen Refurbished Notebook von Dell Ausschau halten, um eine Linux-Maschine zu bekommen.
"ob KVM da drauf läuft"
KVM läuft schon seit über 10 Jahren in jedem Linux-Kernel. Das ist da fest integriert.
Man muss es lediglich benutzen.
Zur leichteren Benutzung gibt es den QEMU (Gui für KVM) oder die KVM-Tools von SUSE.
In dem Windows-Gast muss man noch die virtIO-Treiber installieren.
naja, VMware ist aber doch ein bisschen mehr als nur eine Virtuelle Maschine.
So mit einem Klick eine VM auf eine andere Hardware moven geht das mit KVM auch?
Das wird gerne übersehen. Wir nutzen Vmware WS lokal im Zusammenspiel mit Vshpere Umgebungen je nach Aufgabenstellung.
Und ja: Die ersten Proxmox-Cluster stehen auch schon.
Gruß
Ist letztlich auch nur Software. ™ (r) (pat.pend.)
Achtung!!
Es reicht nicht die Gruppen nur anzulegen.
Man muss entweder den eigenen User in die neue Gruppe users packen oder aber die security setting anpassen und die entsprechende User Gruppe der Sprache in dem vmware Verzeichnis im Programm files packen. Sonst geht der Start der Anwendung nicht.
Wenn man den Taskmanager gegen den Prozess-Monitor austauscht findet man ein solches Problem sehr schnell, ohne viele Experimente…
Aber der Hinweis wird inzwischen wohl als Spam gewertet und ist geshadowed?
17.6.1 ist erschienen
https://www.deskmodder.de/blog/2024/10/10/vmware-workstation-17-6-1-korrigiert-setup-problem-und-mehr/
Evtl auch für den ein oder anderen relevant:
Ab der 17.6.0 wurde ein Performance Bug gefixed. Im Zusammenhang mit den neuen Intel CPUs haben wir eine drastische Leistungsverschlechterung festgestellt. Wenn man VMWare Workstation als lokaler Admin gestartet hat, konnte die CPU Leistung abgerufen werden. Wenn der normale User jedoch KEIN lokaler Admin ist, was Security-Empfehlung ist, dann konnte der VMWare Prozess die Leistung der CPU nicht abrufen. Muss was mit dem Thema Performance,Efficiency und High-Efficieny Cores zu tun haben (Intel CPUs!).
Mit dem neuen Fix ist nachvollziehbar die Performance bei Usern ohne lokalen Admin-Rechten wieder sehr gut und die CPU taktet bei Leistungsanforderungen auch hoch. Wir reden hier von Messwerten um den Faktor 3.