K.O. Kriterien für die ThinApp virtualisierung?

[Clown007]

Halli, hallo,
welche Grenzen gibt es für die ThinApp Lösung?

Was geht:

Dienste
Anwendungen, die zur Laufzeit dlls erzeugen
.net Framework
Java Anwendungen

Was nicht geht:

Kernel Treiber
VPN Clients
Virenscanner

Mit der Bitte um Ergänzungen,
Martin

[continuum]

Dienste ? - gilt aber auch nicht fuer alle - oder ?

Ich habe mal Converter probiert - da liefen dann nicht alle Dienste

[Clown007]

Die Dienste müssen mit virtualisiert sein, und aus der Sandbox heraus gestartet werden.
Es kann dabei auch noch mit Scripten in der Sandbox nachgeholfen werden.

Aber im Detail muss man wohl schaun. Die genauen Abhängigkeiten kenne ich (leider) auch noch nicht. Die genauen Randbedinungen habe ich nirgendwo gefunden, deshalb ist mein Interese daran so gross

Gruß Martin

[continuum]

Martin - hantierst du viel mit Thinapp ?

Wenn man weiss wie man scripte von Hand starten kann - sollte es auch moeglich sein die meisten Dienste von Hand zu installieren - dabei ist dann aber immer die Frage ob man sie nachher auch wieder sauber los wird.

Allgemein wuerde ich erstmal sagen das Apps die Dienste oder Kernel-trieber bracuhen eher kein Kandidat fuer Thinapps sind.

[McStarfighter]

Man bedenke vor allem: Die Dienste und auch die Kerneltreiber eines solches Apps sind innerhalb der eigenen ThinApp-Umgebung, sollen aber auf dem reellen System verfügbar sein. Das kann nicht klappen, jedenfalls nicht ohne hängen und würgen.

Typische Programme, die man NICHT mit ThinApp oder Altiris SVS oder ähnlichem virtualisieren bzw. einpacken sollte, sind: Alle Anti-Viren-Programme außer BitDefender Free und ClamWin (denn die beiden haben keinen Wächter und sind auch nicht im Kernel verankert), so ziemlich alle Netzwerk- und Systemüberwachungsprogramme (denn die brauchen auch wieder spezielle Systemtreiber), Treiber an sich, Virtualisierungsprogramme per se und dann noch Programme, deren Lizenzfreigabe durch Hardware- oder Computer-IDs erfolgt. Denn zum einen verletzt du damit dann die Lizenz, zum anderen wird es wohl nicht mehr laufen, wenn es eine andere ID erkennt ...
Ach ja, und für Firewalls würde ich es auch nicht anraten ...

[Clown007]

Ich meinte auch weiniger solche offensichtichen Dinge, sondern vielmehr die Dinge, die eigentlich funktionieren sollten. (.net geht zum Beispiel mit APP-V nicht)

Vor allem sieht man den meisten Programen erst einmal nicht an, wie sie genau funktionieren. Mit dem Tool Admin Studio von Acresse kann man zum Beispiel schon im Vorfeld testen, ob diese Anwendung (wahrscheinlich) virtualisierbar ist.

Wir haben Anwendungen, die sich zur Laufzeit dlls generieren und diese registrieren und einige andere unschöne Dinge.

Wie sieht es mit dem Zugriff auf com Objekte aus. Kann ich Word oder Excel Plugins virtualisieren? Mit dem IE / Firefox Plugins klapp das ja ja sehr gut.

PS:Kenn jemand eine schöne Anleitung für eine systematische Fehlersuche in den Logs?

[McStarfighter]

Hm, also ich würde dir dann lieber Altiris SVS empfehlen. Kostet für den Privatuser nix und basiert auf einer sehr ausgefeilten Layer-Technik. Da können auch gerne DLLs zur Laufzeit generiert werden oder dynamische Reg-Einträge erfolgen, die bleiben alle in der jeweiligen Schicht machen keinen Streß.

Einfach mal danach googlen ...

[Clown007]

Hallo McStarfigher,
Altiris SVS haben wir ausgiebig gestet. Altiris bzw. jetzt Symantec isoliert nicht einmal die Namensräume mehrere virtualisierter Anwendungen gegeneinander, weil es die Treiberschicht nur ein mal (und nicht wie bei Thinapp in jedem Paket) gibt.

Altiris SVS wird von vielen nicht als ernsthafte Applikations Virtualisierungslösung angesehen. Man redet dabei eigentlich nur von Citrix (XenApp), VmWare (ThinApp) und Microsoft (App-v).

Zudem bei Symantec zur Zeit alles im Umbau ist: Symantec hat Altiris SVS, AppStream und NSuite aufgekauft um daraus die Symantec Endpoint Virtualization Suite zu machen.

Hat damit schon mal jemand ernsthaft getestet?

Gruß Martin

[McStarfighter]

XenApp und App-V sind nur leider als reine Desktop-Lösung ebenfalls nicht nutzbar, da sie ja auf einem Server-Client-Prinzip beruht.
Was mir bei ThinApp nicht gefällt: Das Ergebnis ist leider immer nur ne Single-Click-EXE. Ist für mich halt leider nicht grad optimal. Das Konzept von SVS gefällt mir da wesentlich besser, da man die Schichten ins laufende System transparent einbinden kann und auch darin selbst Veränderungen zulassen kann oder gar selbst vornimmt.
Sieh das jetzt bitte nicht als Bekehrungsversuch, ich wollte nur bei der Gelegenheit mal "laut denken".
Wenn jemand eine Lösung kennt, die nicht als Ergebnis ne Single-EXE liefert, dafür aber mit nem gescheiten Modell des transparenten Einbindens arbeitet UND als Desktop-Lösung möglich ist, dann BITTE SAGT ES MIR ... denn SVS scheint ja nicht wirklich gescheit was zu können (wollte es mir in ein paar Tagen zu Gemüte führen, um ein größeres Projekt auf die Beine zu stellen ...

[Clown007]

.. Guten Argumenten stehe ich immer offen gegenüber )

Genau habe ich leider nicht verstanden, was Du möchtest. Du möchtest eine Anwendung transparent ein- und ausblenden. Von aussen gesteuert? Du kannst Dir ja auch ein msi File generieren zum einblenden (wenn Du damit Desktop Verknüpfungen meinst).
Du kannst ThinApp über AD Berechtigungen steuern und es gibt viele Möglichkeiten mit vb Scripten zu arbeiten (die können dann sowohl in der Sandbox als auch ausserhalb zugreifen).

Du kannst zum Beispiel die ThinApp Applikation auf einem Share ablegen, und über eine Verknpfung starten. Dann kannst alles von aussen steuern.

(alles auch nur laut gedacht ...)

Gruß Martin

[McStarfighter]

Ok, mal zur Verdeutlichung: Ich suche eine Lösung, bei der ich Applikationen transparent einbinden kann (siehe Alitiris SVS) und zwar so, daß diese innerhalb des Layers auch keine Konflikte mit außen stehenden Dateien haben (speziell DLLs). Wenn eingebunden, sollen sie eben "im System" sein (also keine MSI oder EXE). Das Ganze dann auch bitte als reine Desktop-Lösung, also keine Client-Server-Lösung, sondern alles lokal ...

Danke für meine Geduld ...

[Clown007]

Hallo,
so ganz habe ich es nicht verstanden. Jede Anwendung auf dem PC hat doch eine exe Datei. Für die praktische Handhabung gibt es doch keinen Unterschied zwischen einer ThinApp und einer "echten" App. Der Unterschied zwischen SVS und Thinapp ist einfach, dass bei ThinApp die Applikation automatisch einblendet wird, wenn sie gestartet wird. Sobald sie beendet wird, ist sie wieder ausgeblendet. Kann SVS laufende .exe Dateien einfrieren und später wieder starten? Bei Thinapp hat jede Anwendung ihre eigene Treiberschicht (steuerbar per Script).

Wenn Du die exe nicht startest, ist auch nichts eingeblendet. Jede Virtualisierungslösung (ThinApp, SVS, Xen und Hyper-V) isoliert das Dateisystem und die Registry der Anwendung.

Bei Thinapp hat jede Anwendung seine eigene "Blase". Diese Trennung ist bei SVS nicht ganz so sauber.

Gruß Martin

[McStarfighter]

Also, nach meinem Verständnis ist bei ThinApp das Paket immer eine einzige große EXE, die sich dann bei Benutzung temporär entpackt. Dies würde aber (ebenfalls nach meinem Verständnis) ausschließen, daß man in dem Paket "live" was verändern kann. Es bedürfte dann also immer erst eines neuen Pakets. ThinApp arbeitet auch leider mit dem Snapshot-Modell, um ein solches Paket zu erstellen. SVS hingegen erlaubt es, innerhalb eines Layers die Installation an sich vorzunehmen, was in meinen Augen sauberer ist. Und mit Hilfe es Login Hooks für SVS kann man Benutzerkonten mit SVS-Layern so verknüpfen, daß diese automatisch beim Anmelden mit eingebunden werden. Ähnliches habe ich bei ThinApp bisher nicht erlesen können.

Ich versuche mal, die für mich wichtigen Features in Stichworte zu fassen:

"Live" Modifikationen des virtualisierten Programms (Update, händische Modifikationen)
KEIN Snapshot-Modell zur Erstellung einer Schicht, sondern direkte Installation innerhalb der Schicht
Automatisches Anmelden der Schicht bei Login

[Clown007]

Okay, ich versuche es mal mit meinem Wissen zu beantworten.

Paketierung:
Das Paket für SVS (die .vsa Datei) erstellst Du mit dem Wise Package Studio? und für ThinApp mit dem Snapshot Verfahren. Beide Verfahren haben Vor- und Nachteile. Mit dem Admin Studio von Acress kannst Du auch direkt ThinApp Pakete mit dem Packager erstellen (und auch .msi File direkt zu Thinapp Files wandeln).

Live Veränderung:
Bei SVS kannst Du live die .vsa Datei verändern (ich kenn nur: http://www.svsdownloads.de/anleitungen/ ... einspielen)?

Updates sind bei ThinApp durch Erstellung eines Delta Paket (Funktion Application Sync) möglich.

Ein- un Ausblenden:
SVS: Durch Layer ein- und ausblenden
ThinApp: Durch starten bzw. beenden der .exe


Automatisches Ausführen beim Anmelden:
ThinApp mit einem Autostart verknüpfen

Unsere Sofware konnte auch mit Unterstützung von Altiris mit SVS ncht virtualisiert werden (u.a. .net Framework nicht möglich). Hast Du gute Erfahrungen mit SVS?

SVS isoliert die virtialisierten Anwendungen nicht sauber gegeneinander (es gibt nur eine Sandbox / Blase). Das bedeutet mehrere virtualiserte Anwendungen mit unterschiedlichen dlls sind in nicht möglich. Damit ist der größte Benefit (keine Regressionstest der Anwendungen untereinander) nicht möglich.

Gruß Martin

[Drumcode2003]

Hallo Jungs,

was haltet Ihr von "InstallFree" als App. Virt. ?

Man benötigt keine zus. Hardware, außer einem Fileshare auf dem die Pakete liegen.
Hört sich für mich auf den 1. Blick cool an.
evt. hat jmd. das Produkt schon getestet?

So long...

[Clown007]

Mit Xenocode und InstallFree sind interessante neue Player auf dem Markt, die einen ähnlichen Ansatz wie ThinAPP verfolgen.

Für Unternehmen sind natürlich auch der Supprt ein grosses Thema.

By the Way
Bei Xenocode gibt etliche Browser zum Download : http://www.heise.de/netze/Webbrowser-ohne-Installation-testen--/news/meldung/133454

Ich hatte auch noch nicht viel Zeit zum testen, und bin für Erfahrungen dankbar.

Gruß Martin

[continuum]

Martin - danke fuer den Link - die Browser sind fuer meine LiveCDs sehr nuetzlich - bis auf Chrome laeuft alles

gruss

[Clown007]

Der Chrome Browser bringt eine eigene Sandbox mit. Für die Virtualisierung der 'alten' Chrome Version musste man mit dem Parameter" --no-sandbox" die Sandbox ausschalten.

Eventuell hilft es ja weiter ..

Gruß martin