Das "Xenocode Virtual Application Studio" kommt ohne die Installation eines Clients auf dem Zielrechner aus. Xenocode bringt zudem auch keine Backend-Komponente für die zentrale Verteilung und Steuerung virtualisierter Anwendungen mit. Die Software ist daher weniger eine Alternative zu komplexen Systemen wie Microsofts App-V, sondern lässt sich besser mit VMware Thinapp vergleichen.

Mini-Betriebssystem

Der Kern von Virtual Application Studio ist "Xenocode OS", ein Mini-Betriebssystem, das über eine kompakte Implementierung einiger zentraler Windows-APIs verfügt. Es stellt virtualisierten Anwendungen ein eigenes Dateisystem sowie eine virtuelle Registrierungsdatenbank zur Verfügung und besitzt ein eigenständiges Prozess- beziehungsweise Threading-Subsystem. Darüber hinaus steuert Xenocode OS den Zugriff auf Host-Objekte, etwa Verzeichnisse außerhalb der virtuellen Umgebung. Mit Windows-Tools wie dem Task-Manager hat man zur Laufzeit keinen direkten Zugriff auf die Objekte der Sandbox. Nützlich ist der Diagnose-Modus, in dem Xenocode OS zur Laufzeit des Virtualisierungsprogramms alle Schreib-und Lesezugriffe in einer Textdatei protokolliert.

Xenocode OS speichert beim ersten Start des Virtualisierungsprogramms Teile des virtuellen Dateisystems und der Registry in einer Sandbox. Der Speicherort auf dem Host lässt sich einstellen; standardmäßig befindet er sich im Profil des Anwenders. Das Virtualisierungsprogramm selbst liegt in der Regel im Programmverzeichnis des Hosts. So können auch mehrere Benutzer eines Computers darauf zugreifen. Die benutzerspezifischen Konfigurationen speichert Xenocode in der Sandbox, so dass jeder Anwender seine persönlichen Einstellungen wie bei herkömmlich installierten Applikationen dort hinterlegen kann. Arbeitet man mit Server-basierenden Profilen, dann sind diese individuellen Präferenzen netzwerkweit verfügbar.

Vier Schritte zur Anwendung

Die Erstellung einer virtuellen Anwendung mit Virtual Application Studio erfolgt in vier Phasen: Datenerfassung ("Capture"), Nachbearbeitung, Erzeugung des Virtualisierungsprogramms ("Build") und optional die Erstellung einer Windows-Installer-Datei (MSI).

Bevor die Anwendung installiert wird, muss der Administrator einen Snapshot des Master-PC erstellen. Nach der Installation des Programms ermittelt Virtual Application Studio die Differenz zum Ausgangszustand und verwendet diese als Grundlage für die virtuelle Registry sowie das virtuelle Dateisystem. Dabei werden nur die Systembereiche verglichen, die normalerweise bei der Anwendungsinstallation von Relevanz sind. Es besteht jedoch die Möglichkeit, Snapshots des Gesamtsystems zu erzeugen, was allerdings erheblich länger dauert.

Virtual Application Studio verfügt über eine gut durchdachte grafische Benutzeroberfläche, mit deren Hilfe sich nach der Datenerfassung Dateien oder Registry-Einträge hinzufügen oder entfernen lassen. An dieser Stelle muss der Administrator unter Umständen den Isolierungsgrad anpassen. In der Regel kann man die Standardeinstellungen beibehalten. Darüber hinaus besteht hier die Möglichkeit, Dateien zu verstecken, so dass sie in Dialogfenstern der virtualisierten Anwendung nicht auftauchen.

Gewohnte Verknüpfungen bleiben

Um ein Virtualisierungsprogramm zu erstellen, muss der Systemverwalter zunächst eine ausführbare Datei aus allen zur Anwendung gehörenden Files auswählen. Bei komplexen Applikationen ist es mitunter recht mühsam, das richtige Programm zu finden, weil Virtual Application Studio alle Dateien, also zum Beispiel auch DLLs, anzeigt. Der Administrator kann hier auch mehrere ausführbare Dateien wählen. Bei der Erstellung der MSI-Dateien lassen sich diese dann verschiedenen Desktop-Verknüpfungen zuweisen.

Office komplett verpackt

Auf diese Weise ist es beispielsweise möglich, ein komplettes Office-Paket in ein Virtualisierungsprogramm zu packen. Der Anwender kann dann Textverarbeitung oder Tabellenkalkulation wie gewohnt über die entsprechenden Verknüpfungen starten.

Für den Start der virtualisierten Anwendung ist im Grunde nur das Virtualisierungsprogramm erforderlich. Eine MSIDatei wird primär benötigt, um Verknüpfungen auf dem Desktop beziehungsweise im Startmenü anzulegen und um der virtualisierten Anwendung Dateiendungen auf dem Host-System zuzuweisen. Letzteres kann aufwändig werden, falls die Anwendung viele Dateitypen unterstützt. Der Administrator muss sie alle von Hand anlegen, weil Virtual Application Studio nicht in der Lage ist, diese Informationen während der Datenerfassung zu extrahieren.

Verteilung der Anwendungen

Einfachere Anwendungen, die keine Integration in den Desktop erfordern, kann der Systemverwalter über eine Netzfreigabe oder einen Web-Server bereitstellen. Sie lassen sich auch von externen Datenträgern wie USB-Sticks starten. Für komplexere Anwendungen kommt man häufig nicht um die Installation der MSI-Datei herum. Da Virtual Application Studio keine Backend-Komponente mitbringt, müssen die MSI-Dateien mit der Client-Management-Lösung eines Drittanbieters verteilt werden.

Die MSI-Datei enthält dabei nicht nur die Einstellungen für die Desktop-Integration, sondern auch das Virtualisierungsprogramm. Das hat den Vorteil, dass sich dieses auch wieder über eine MSI-Datei entfernen lässt. Leider lässt die Deinstallation mit der von Virtual Application Studio erzeugten MSI-Datei die zur virtualisierten Anwendung gehörige Sandbox zurück.

Virtual Application Studio unterstützt die Aktualisierung von virtualisierten Anwendungen. Allerdings muss der Administrator dies schon bei der Erstellung der MSI-Datei berücksichtigen. Mit Hilfe von Versionsnummern lässt sich steuern, ob eine virtualisierte Anwendung durch eine neuere MSI-Datei aktualisiert wird. Die benutzerspezifischen Einstellungen in der Sandbox bleiben bei einem Update erhalten.

Neue und alte Version parallel

Alternativ kann der Administrator eine neue Version der virtualisierten Anwendung bereitstellen. Die neue und die alte Version lassen sich dann auch parallel betreiben. Dabei legt Xenocode OS eine weitere Sandbox für die neue Version an, so dass der Anwender die Applikation dann unter Umständen neu konfigurieren muss.

Möchte der Administrator für verschiedene Benutzergruppen unterschiedliche Einstellungen vorgeben, kann er so genannte Xlayer-Dateien mit einer virtualisierten Anwendung verknüpfen. Eine Xlayer-Komponente ist eine virtuelle Umgebung ohne Xenocode OS. Sie lässt sich deshalb nur in Verbindung mit einer virtualisierten Anwendung nutzen. Dabei haben Xlayer-Objekte Vorrang gegenüber ihren Entsprechungen in der Applikation, so dass sie sich auch zum Einspielen von Updates eignen.

Dieses Verfahren eignet sich ferner dazu, um eine Laufzeitumgebung, etwa eine bestimmte Java-Runtime-Version, mit der Anwendung auszuliefern. Virtual Application Studio integriert Xlayer-Komponenten bei der Erzeugung in das Virtualisierungsprogramm. Sie werden also nicht wie beim Application-Link-Feature von VMware ThinApp zur Laufzeit dynamisch nachgeladen.

Fazit

Xenocode Virtual Application Studio ist eine einfach zu bedienende Lösung zur Anwendungsvirtualisierung. Im Gegensatz zu VMware ThinApp lässt sich die gesamte Konfiguration über die komfortable grafische Benutzeroberfläche erledigen, das Hantieren mit INI-Dateien entfällt somit.

Administratoren, die Erfahrung mit der Erstellung von Installationspaketen haben, werden die Oberfläche sehr schnell beherrschen. Leider bietet Xenocode kein Streaming von virtualisierten Anwendungen, was insbesondere die Bereitstellung von umfangreichen Anwendungen über das Web erschwert. Auch ThinApps "Application-Sync"-Feature, das die automatisierte Aktualisierung von virtualisierten Anwendungen erlaubt, fehlt Xenocode.

Der größte Vorteil gegenüber ThinApp dürfte Xenocodes deutlich niedrigerer Einstiegspreis sein. (ws)