Neu JTL WaWi Client unter Linux

[Tomka]

Wir betreiben seit zwei Jahren MSSQL (Standard Edition) auf Ubuntu 22.04 – bisher vollkommen problemlos.
Um die Hardware nicht im eigenen Haus betreiben zu müssen, haben wir uns bei IONOS einen Dedicated Server für rund 50 € monatlich gemietet. Darauf laufen aktuell zwei VM-Dienste:

• einmal MSSQL
• einmal ein Windows-Rechner mit dem Worker

Warum IONOS? Die Einrichtung ist unkompliziert, die Firewall sehr einfach zu konfigurieren und das System ist von außen gut abgesichert. Es gibt lediglich einen WireGuard-Zugang für den Admin, und im Notfall können Ports freigeschaltet werden, um per SSH (MSSQL) oder Remote Desktop direkt auf den Windows-Rechner zuzugreifen.

Wir mussten auf die Standard Edition wechseln, da wir die 10-GB-Begrenzung der Express-Version regelmäßig überschritten haben. Zusätzlich war die Performance nicht optimal, damals lief das Ganze noch über einen Servicepartner (eCom Data), ebenfalls für etwa 50 € monatlich.

Testweise hatten wir außerdem einen zweiten Rechner im Einsatz, auf dem mehrere virtuelle Maschinen (Windows mit JTLWawi) liefen, auf die per Remote Desktop direkt gearbeitet wurde. Wie bereits von anderen erwähnt, ist das Lizenzthema hier jedoch nicht trivial. Deshalb haben wir diesen Ansatz vorerst verworfen.

Was wir bei Gelegenheit noch testen möchten: auf Ubuntu als User-Gerät mittels WinBoat (oder einer Alternative) zu arbeiten.

 

[NoOne]

Was wir bei Gelegenheit noch testen möchten: auf Ubuntu als User-Gerät mittels WinBoat (oder einer Alternative) zu arbeiten.

Tatsächlich hab ich mir WinBoat auch mal angeschaut. Das ist auch 'nur' eine QEMU Instanz, auch wenn dort mittels RDP Tricksereien die Anwendung wie Linux-Native wirkt. Außerdem ist das ganze noch in einen Docker-Container verpackt. Das ist aber dennoch nichts anderes als eine VM + RDP.

 

[DennisB]

Wir arbeiten jetzt seit knapp zwei Wochen unter CachyOS mit den Wawi-Clients unter Winboat.

Für die Einrichtung sollte man "Bock auf Software" haben, dann ist das alle gut dokumentiert für Jeden recht einfach umzusetzen. Der wildeste Punkt war das Durchschleifen der Drucker in die WinBoat-Wawi und selbst das war max. 10 Minuten nachforschen und austesten.

Die Wawi läuft bei uns seit dem Umstieg stabiler und schneller als unter Windows direkt. Auch die WMS läuft problemlos und gefühlt einen Tacken schneller. Wir starten dabei btw. Wawi und WMS direkt als App und nicht über den Windows-Desktop. Träumchen und produktiv absolut gut nutzbar.

Was natürlich richtig ist, ist dass man bei technischen Problemen selber findig sein muss. Allerdings würde ich diese Aussage sowohl für Linux/WinBoat als auch nativen Windowsbetrieb unterstreichen. Darum denke ich @SebiW das "IT Kompetenz ist in den meisten KMUs überschaubar vorhanden. JTL ist klar ein System für KMUs. Viele hier könnten nichtmal selber einen Shop aufsetzen und hosten. Installationen jenseits der Standardwege sind für solche Firmen überkomplex." AUCH für Linux zählt, aber grundlegend auch für Windows. Wer die Basiskenntnisse zum installieren, verbinden mit der SQL und anschließender Produktivnutzung der Ameise hat (und so jemandem benötigt man ja dringend auch in einem KMU zum grundlegenden betreiben), der bekommt auch die mittlerweile immens einfache Installation und das Betreiben von Linux und WinBoat-Wawi hin.

Ein anderen Thema könnte natürlich die zusätzliche Migration des SQL-Datenbankserver sein. Damit habe ich mich bislang noch nicht beschäftigt. So fluffig wie der Umstieg der Clients inklusive dem Verarbeitungsboost bringt, werde ich das aber - natürlich zuerst mit einem nicht produktiven System - dringend mal beizeiten probieren müssen.

 

[DennisB]

Außerdem ist das ganze noch in einen Docker-Container verpackt. Das ist aber dennoch nichts anderes als eine VM + RDP.

Für die Performance ist da schon ein deutlicher Unterschied. Docker packt in den Container mit Winboat nur das nötigste, was er für den Betrieb der Software im Container benötigt. VM + RDP virtualisiert klassischer Weise ein komplettes (und gerne mal aufgeblähtes) Windows und verbindet über den RDP-Dienst. Die Containerlösung ist in der Regel merklich schneller.

 

[NoOne]

Für die Performance ist da schon ein deutlicher Unterschied. Docker packt in den Container mit Winboat nur das nötigste, was er für den Betrieb der Software im Container benötigt. VM + RDP virtualisiert klassischer Weise ein komplettes (und gerne mal aufgeblähtes) Windows und verbindet über den RDP-Dienst. Die Containerlösung ist in der Regel merklich schneller.

Damit wollte ich sagen, dass das nichts an der Lizenzsituation ändert. Das ist ein Windows auf einer VM. Im Businessumfeld sind dort Lizenzen nötig, und Microsofts Lizenzsystem ist notorisch undurchsichtig.

Und nein. Winboat virtualisiert standardmäßig ein komplettes Windows, keine abgespeckte Sonderform. Natürlich kann man das anpassen, aber das kann man eine normale Windowsinstallation ebenfalls. Winboat ist mit einer Standardinstallation auch nicht schneller als VM+ RDP. Weil das eben eine VM+RDP ist. Containerisiert und damit einfacher zu handhaben, aber performancetechnisch macht das kaum einen Unterschied zu einer QEMU-VM. Schon gar keinen deutlichen. Winboat ist nichts Magisches. Docker ist ebenfalls nichts Magisches.

 

[SebiW]

Was natürlich richtig ist, ist dass man bei technischen Problemen selber findig sein muss. Allerdings würde ich diese Aussage sowohl für Linux/WinBoat als auch nativen Windowsbetrieb unterstreichen. Darum denke ich @SebiW das "IT Kompetenz ist in den meisten KMUs überschaubar vorhanden. JTL ist klar ein System für KMUs. Viele hier könnten nichtmal selber einen Shop aufsetzen und hosten. Installationen jenseits der Standardwege sind für solche Firmen überkomplex." AUCH für Linux zählt, aber grundlegend auch für Windows. Wer die Basiskenntnisse zum installieren, verbinden mit der SQL und anschließender Produktivnutzung der Ameise hat (und so jemandem benötigt man ja dringend auch in einem KMU zum grundlegenden betreiben), der bekommt auch die mittlerweile immens einfache Installation und das Betreiben von Linux und WinBoat-Wawi hin.

Du brauchst erhebliche zusätzliche Kompetenz. Nenn vorinstallierten Windows Rechner kannst Du bei Aldi kaufen. Anbindung machst Du nach Guide oder zahlst nemm SP kleines Geld.
Das Aufsetzen eines Betriebssystems und einer VM Lösung welcher Art auch immer ist ein erheblich größerer Kompetenzblock.
Und wenn Du in nemm typischen Windows Umfeld Probleme mit der Wawi hast kannst Du Dir im Zweifel günstig Support kaufen. Meist hilft eine Suche im Forum.

Nicht falsch verstehen, ich hab da auch schon öfter drüber nachgedacht. Aber wenn ich vom Fahrrad falle und hier die Drucker nicht mehr laufen (und da rede ich noch nichtmal über das komplexe Zeug wie Maschinendrucker) dann ist Land unter. Da kannste nicht einfach nemm Servicepartner 2-300 rüberschieben und der setzt die immer gleichen Haken via TV.

JTL auf Linux ist immer ein zusätzlicher Komplexitätslayer. Da ich am Ende bei jeder Winboat Lösung immer noch eine Windows Lizenz brauche löse ich damit auch nicht das Thema Unabhängigkeit von Redmond final auf. Gleiches gilt auch für den SQL Server. Es ist betriebswirtschaftlich schlicht sinnlos sich zusätzliche Komplexität ins Haus zu holen, ohne dabei an anderer Stelle relevante Kosten zu sparen. Kurz, eine Linux Lösung ist Stand jetzt erheblich teurer als eine banale MS Lösung. Ich sehe da im JTL Kosmos auch wenig Ausweg. Glücklicherweise macht JTL einem die Suche nach Alternativen derzeit ohnehin mit Nachdruck schmackhaft. Und eine solche Alternative WIRD dann nativ auf Linux laufen, ohne alle Bastellösungen.

 

[mvh]

Moin. Ich stimme @SebiW und @NoOne zu.
Meine Hoffnung wird die neue WaWi 2.0.
Durch den .NET Core 8.X wäre es möglich die WaWi für Windows und Linux (zumindest Ubuntu)
zu kompilieren. Aber hier entscheidet letztendlich JTL, ob es gemacht wird oder nicht.

 

[unblack]

Gleiches gilt auch für den SQL Server.

Jain, MSSQL gibt es ja als Linux-Distribution. Man spart sich zumindest eine Windows-(Server)-Lizenz. Bleibt halt trotzdem ein M$ Produkt.

 

[SebiW]

Jo. Und ne Windows Lizenz krieg ich für nenn Apfel und n Ei. Das teure ist der SQL. Und wenn ich DB Updates fahren will brauch ich trotzdem wieder ein Windows System. JTL ist halt MS Ökokosmos. Worker muss ich auch auf nemm Win System laufen lassen. Und offiziellen Support gibts keinen. Ich gewinne dadurch nur Komplexität solange JTL nicht grundlegendes ändert. Und der Weg Richtung FOSS Support scheint mir nicht unbedingt zu JTLs aktuellem Businessmodell zu passen

Gehen tut immer alles. Pragmatisch nimmt man das, was am wenigstens Probleme verursacht. JTL auf Linux kann man machen, aber im Endeffekt gewinnt man nur nenn weiteren Layer der zusätzlichen Aufwand erfordert. Ich bin erheblich teurer als ne Win 11 Lizenz...

 

[DennisB]

Damit wollte ich sagen, dass das nichts an der Lizenzsituation ändert. Das ist ein Windows auf einer VM. Im Businessumfeld sind dort Lizenzen nötig, und Microsofts Lizenzsystem ist notorisch undurchsichtig.

Und nein. Winboat virtualisiert standardmäßig ein komplettes Windows, keine abgespeckte Sonderform. Natürlich kann man das anpassen, aber das kann man eine normale Windowsinstallation ebenfalls. Winboat ist mit einer Standardinstallation auch nicht schneller als VM+RDP. Weil das eben eine VM+RDP ist. Containerisiert und damit einfacher zu handhaben, aber performancetechnisch macht das kaum einen Unterschied zu einer QEMU-VM. Schon gar keinen deutlichen. Winboat ist nichts Magisches. Docker ist ebenfalls nichts Magisches.

Das muss ich widersprechen. Bei uns läuft die Wawi in Winboat deutlich schneller. Winboat baut um alle Funktionen von Windows Container. Wenn man nicht den Desktop als App lädt, dann werden die unnötigen Programteile nicht automatisch auch in die anderen Container geladen. JTL-WaWi und WMS können gut in ihrem eigenen Container betrieben werden.

Die Lizenz sollte dabei auch absolut kein Problem sein. Die Lizenz wird in WinBoat neu installiert. Sollte man im Vorfeld Windows nicht legal ohne Key betrieben haben, dann kann man für die Legalität den Key für wenig Geld nachkaufen.

Winboat und Docker sind in der tat nichts magisches, sie sind aber sehr schnell und out of the box effizienter aufgestellt.

 

[NoOne]

Winboat baut um alle Funktionen von Windows Container

Wie kommst du darauf? Winboat ist eine QEMU-VM (bzw. KVM) die permanent läuft und es per angepasstem RDP so wirken lässt, als wäre die Anwendung Linux-Native. Da werden keine "Windows Funktionen" containerisiert. Da wird ein komplettes Windows 10 oder 11 containerisiert. Winboat führt eine komplette Windows-Installation in der VM aus. Winboat ist nicht WINE. Und da ist auch nichts "effizienter" aufgestellt. Winboat automatisiert lediglich einige Dinge. Eine KVM läuft minimal langsamer als eine Bare-Metal Installation. Eigentlich immer. Wenn du das Windows aus der Winboat-Installation exakt so direkt auf den gleichen Rechner spielen würdest, dann wäre die mit ziemlicher Sicherheit genauso schnell. Eventuell minimal schneller.

Du kannst natürlich mehrere VMs anlegen. Verglichen mit einem Bare-Metal Setup wäre das dann so, als hättest du pro Rechner eine komplette Windows-Installation mit einem einzigen installiertem Programm darauf.

Die Lizenz sollte dabei auch absolut kein Problem sein. Die Lizenz wird in WinBoat neu installiert. Sollte man im Vorfeld Windows nicht legal ohne Key betrieben haben, dann kann man für die Legalität den Key für wenig Geld nachkaufen.

Für "wenig Geld" kriegst du höchstens Gebraucht-Lizenzen. Die sind zwar grundsätzlich legal, aber auch die sind an Bedingungen geknüpft. Wenn die Lizenz nicht aus dem EWR stammt, kann das Probleme geben. Wenn die Lizenz beim Vorbesitzer noch in Benutzung ist, kann das Probleme geben. Die 'billigen' Keys sind meistens nicht Audit-sicher, weil dort keine dokumentierte Lizenzübertragung stattfindet. Wenn du bei einem Audit keinen Lizenznachweis hast, dann haftest du.

Edit: Damit will ich natürlich nicht sagen, das es Unsinn ist das per Winboat zu machen. Man braucht in der Windows Installation natürlich nur die Wawi, und sonst nichts. Was es verglichen mit einer normalen Windows-Installation mit drölfzig Programmen im Hintergrund natürlich schneller macht. Und trotzdem nur einen Rechner. Aber bezogen auf die Wawi ist das der einzige Vorteil. Man braucht einen Rechner, statt zwei.

 

[DennisB]

Wie kommst du darauf?

Hey. Zum einen, weil unsere Rechner seit der Umstellung von nativem Windows auf die Winboat Lösung, wie geschrieben, deutlich schneller auch in der Wawi und WMS arbeiten. Zum anderen durch die Erklärungen der Unterschiede VM vs Docker auf u.a. diesen Seiten:

https://www.ionos.de/digitalguide/server/knowhow/docker-vs-virtual-machines/
https://aws.amazon.com/de/compare/the-difference-between-docker-vm/
https://supperundsupper.com/docker-container-vs-virtuelle-maschine

Die Aussage z.B. von ionos "Docker ermöglicht eine schnelle Bereitstellung von Anwendungen, eine einfache Skalierung sowie einen geringeren Ressourcenverbrauch im Vergleich zu herkömmlichen Virtualisierungstechnologien wie virtuellen Maschinen." erleben wir hier sehr deutlich. Und da WaWi und WMS deutlich unterschiedlich im Solo-Dock vs im Windows-Oberflächendock performen, erscheint es naheliegend, dass nur die Teile von Windows in das Solo-Dock geladen werden, die WaWi oder WMS benötigt.

 

[sebjo82]

Hey. Zum einen, weil unsere Rechner seit der Umstellung von nativem Windows auf die Winboat Lösung, wie geschrieben, deutlich schneller auch in der Wawi und WMS arbeiten. Zum anderen durch die Erklärungen der Unterschiede VM vs Docker auf u.a. diesen Seiten:

https://www.ionos.de/digitalguide/server/knowhow/docker-vs-virtual-machines/
https://aws.amazon.com/de/compare/the-difference-between-docker-vm/
https://supperundsupper.com/docker-container-vs-virtuelle-maschine

Die Aussage z.B. von ionos "Docker ermöglicht eine schnelle Bereitstellung von Anwendungen, eine einfache Skalierung sowie einen geringeren Ressourcenverbrauch im Vergleich zu herkömmlichen Virtualisierungstechnologien wie virtuellen Maschinen." erleben wir hier sehr deutlich. Und da WaWi und WMS deutlich unterschiedlich im Solo-Dock vs im Windows-Oberflächendock performen, erscheint es naheliegend, dass nur die Teile von Windows in das Solo-Dock geladen werden, die WaWi oder WMS benötigt.

winboat erstellt eine reguläre qemu windows vm und verpackt diese in docker mit nem netten ui. es handelt sich bei winboat nicht um echte container
diese kann also nicht schneller sein als bare-metal außer eurer server hat hardware probleme oder eurer vm image unterscheidet sich von eurer normalen windows installation

bare metal -> linux -> qemu -> windows vm -> docker (winboat)
vs
bare metal -> windows

 

[NoOne]

Die Aussage z.B. von ionos "Docker ermöglicht eine schnelle Bereitstellung von Anwendungen, eine einfache Skalierung sowie einen geringeren Ressourcenverbrauch im Vergleich zu herkömmlichen Virtualisierungstechnologien wie virtuellen Maschinen." erleben wir hier sehr deutlich. Und da WaWi und WMS deutlich unterschiedlich im Solo-Dock vs im Windows-Oberflächendock performen, erscheint es naheliegend, dass nur die Teile von Windows in das Solo-Dock geladen werden, die WaWi oder WMS benötigt.

Grundsätzlich ist es richtig, das Docker einen geringeren Ressourcenverbrauch im Vergleich zu anderen Virtualisierungstechnologien hat, wenn eine einzelne App containerisiert wird. Das der Docker nur eine einzelne App containerisiert ist auch in diesem Fall korrekt, aber Docker containerisiert eine KVM. Und diese führt das komplette Windows aus. Das ist nur schneller, weil sonst *nichts* anderes in dem Windows installiert ist bzw. im Hintergrund läuft. Wie gesagt, hättest du auf dem gleichen Rechner die exakt gleiche Windows-Installation, ohne Linux als zwischenschicht, würde das genauso schnell laufen. Möglicherweise noch ein wenig schneller. Aber dann darf dort auch wirklich nichts anderes installiert sein.

Docker ist tatsächlich effizienter, wenn es Linux-Programme containerisiert, weil Docker dann den Kernel und die Hardware/die Treiber mit dem Host-System teilt. Das ist bei einer Windows-Applikation unter Linux aber *nicht* möglich. Zwar ist die KVM durchaus Linux-nativ und profitiert ihrerseits, als reine App, von Docker, aber die KVM die darauf läuft, die muss trotzdem die komplette Windows-API bereitstellen und laden.

Winboat ist aber nicht nur Docker, sondern eine VM/KVM *in* Docker. Weil die KVM in diesem Fall eben in Docker läuft. Damit hast du das 'vs' erst gar nicht, weil nicht das eine oder das andere verwendet wird, sondern beides zusammen. Und auch das kann performancetechnisch schon leicht ineffizienter sein, als wenn du die VM direkt in Linux installieren würdest. Aber den Unterschied würde man vermutlich kaum merken, daher ist Docker in dem Fall besser, weil einfacher zu handhaben und viel portierbarer.

 

[sah]

Hat jemand schon Erfahrungen mit Mono und Wawi 2.0 gemacht?

 

[mvh]

Hat jemand schon Erfahrungen mit Mono und Wawi 2.0 gemacht?

Das net Core Runtime für Linux ist vorhanden. Es wird aber von JTL nicht für Linux kompiliert und durch Windows Desktop Runtime Abhängigkeit - wird es vermutlich auch mit net Core 8 nicht mehr gemacht. Warten wir ab, vielleicht mit Net Core 10 wagt jtl diesen Schritt.

 

[EinForumAccount]

Darf ich das Thema nochmal aufgreifen und fragen wie sich die erwähnten Lösungsansätze bisher in der Praxis schlagen?
Also ob mit Problemen öfter mal zu rechnen ist und was praktische Hürden sind die Ihr bisher nehmen musstet.
Denn "Bastellösung" hin oder her... Ich bin gerne bereit Neues zu lernen und mir selbst zu helfen oder mich mit anderen zu dem Thema auszutauschen.

Noch haben wir hier zwar erweiterten Support für Win 10 aktiv, der läuft aber auch mal aus, weshalb ich jetzt schaue wie es weitergehen kann. Windows 11 ist schlicht keine Option und ich nehme nicht hin "dass es eben so muss". Dann kann ich auch wieder Angestellter sein und nach anderer Leute Pfeife tanzen.
Ich habe auch nicht wirklich Lust gerade mal 5-6 Jahre alte Hardware die einwandfrei funktioniert und für die wir noch Ersatzteile parat haben schon wieder zu ersetzen - zum einen unnötige Ausgaben für Neuanschaffungen bei den aktuellen Hardwarepreisen, zum Anderen sind Lizenzen ja auch nicht ohne in der Menge.
Die Kollegen benutzen im Grunde auch nur den Browser, einen email Client und die Wawi. Außer für JTL sind wir also nicht auf Windows angewiesen.
Zumindest empfinde ich alles oberhalb der 1000 Euro für etwas das nichts für mich tut und keine wirkliche Existenzberechtigung hat immer noch als viel Geld.
Sich das leisten können schön und gut, aber eigentlich ist das objektiv irrsinnig.

Das Gegenargument "Wenn mal was ist [...] kein Support" kann ich so auch nicht nachvollziehen. Laufende (Software-)Systeme gehen extrem selten von heute auf morgen einfach so kaputt.
Fehler durch Updates kann man verhindern, da diese unter Linux nicht aufgezwungen werden und man kann selbst bestimmen was und wann es passiert.
Updates kann man dann auf einem einzelnem / gesondertem Rechner testen, bevor es auf allen einspielt wird.
So dürfte es eigentlich keine bösen Überraschungen geben, wenn es denn einmal läuft - zumindest in der Theorie und genau darum wollte ich nochmal nachfragen was bisher die Praxiserfahrung sagt.

 

[SebiW]

In der Praxis hast Du halt auch Themen wie: DHL schaltet zum 31.05. Versenden 3.0 ab. Bedeutet Du musst mindestens eine JTL Wawi 1.11.7+ einsetzen. Wenn Du dann mit diesen neuen Zwangsversionen Probleme hast geht das Gebastel los.
JTL schraubt regelmässig an Anzeige etc rum (Stichwort zb WebView 2). Es kann Dir jederzeit passieren, dass Du durch externe Faktoren, auf die Du keinen Einfluß hast, in eine Sackgasse kommst.

Es gibt zwei saubere Lösungen, um das Problem zu beheben wenn Du lokal was anderes als W11 fahren willst: Winapps (oder vergleichbares, je nach Vortualisierung, Distri etc) + RDP auf ne lokale oder zentrale Windows VM - oder anderes ERP, das für Dein gewünschtes Ökosystem nativ geeignet ist.

Ein "ich nehme nicht hin dass es eben so muss" hilft Dir nicht weiter. Alles was Du damit erreichst ist zentrale Betriebsprozesse Deiner Firma unnötig zu gefährden. Du nimmst ja auch Gurtmaße von Versanddienstleistern, Formularvorgaben vom Finanzamt etc hin.

Ganz abgesehen davon, dass es jede Menge einfache Lösungen gibt W11 auf nicht supporteter Hardware zum Laufen zu bringen. Rufus hat ne extra Setuproutine dafür.

 

[EinForumAccount]

Klar kann immer extern etwas geändert werden, schief gehen oder wegfallen, das gilt aber ungeachtet der Umgebung in der ich die WaWi betreiben will.
Deshalb erinnere ich an meine eigentliche Frage dazu:
Ich möchte wissen, wie man sich bisher in der Praxis so damit geschlagen hat, z.B. ob es eben Probleme mit dem Update auf 2.0 gab (was dein Beispiel-Problem ja beseitigen würde)
oder in Kurz: Wie praxistauglich sind diese Methoden bisher erfahrungsgemäß - nicht nur theoretisch?

Ich werde also wohl erstmal mit einer bzw. zwei Windows Instanzen und RDP-Verbindung befassen und gucken wie das bei den Kollegen ankommt. Wenn ich dann nur einen oder zwei Rechner im Windowsbetrieb halten muss, dann wäre das ein Kompromiss und einfach umzusetzen. Evtl kann ich parallel Aufgaben neu verteilen, so dass nicht mehr jeder direkten WaWi Zugriff braucht.

Mein "nehme ich nicht hin" ist übrigens kein "ich stelle mich quer" und nur weil ich etwas grundsätzlich ablehne heißt es nicht dass ich es realistisch nicht nutzen werde - ich bin ja kein trotziges Kind - denn gerade weil ich unsere Abläufe NICHT gefährden will, informiere ich mich ja was alternativ möglich ist, solange ich noch die Zeit habe das zu planen und zu testen.
Wenn es eng wird steht mir die Standardmethode ja immer noch offen. Das heißt allerdings nicht, dass ich es hinnehme, sondern nur dass ich meine Prinzipien hinten anstelle, solange keine besser Lösung da ist.

 

[SebiW]

Naja, praxistauglich und vielfach bewährt ist RDP. Deshalb war das auch mein Vorschlag.

Ich meine, wir reden hier über IT. Wenn genug Kompetenz und Kapital vorhanden ist geht quasi alles. Wenn JTL direkt in einem der Wrapper nicht läuft kann man das ganz, ganz sicher mit Zeit und Geld zum Laufen bringen. Muss man halt im Zweifelsfall was eigenes bauen/forken und maintainen. Die zentrale Frage ist: Ist es das wert.

Bezüglich der RPD Lösung: Wenn Du das mit sowas wie Winapps umsetzt ist das für den Enduser als würd er einfach nur ein Programm starten - die kriegen die VM gar nicht zu Gesicht. Man muss sich halt um die entsprechenden VMS kümmern - wenn man das sauber konfiguriert kommen die Dinger aber ja nirgendwo raus wo se nicht hin sollen. Schlicht eine Frage des Aufwandes den man betreiben möchte. VMs haben bei Druckern etc ja immer so ihre Eigenheiten Und natürlich sollten die VMs auch am besten W11 sein - W10 wird sicher zeitnah ein Problem bekommen was Geschichten wie Änderungen an runtimes etc angeht. Und JTL wird W10 sicher nicht weiter supporten.

Kurz: gehen tut alles. Und man kann auch alles am Laufen halten. Ob die meisten Lösungen aber einer rein wirtschaftlichen Kosten/Nutzen Rechnung standhalten ist wieder ne ganz andere Frage