Formatauswahl

Basierend auf den für die Paketerstellung zur Verfügung gestellten Quellen sind folgende Verfahren möglich:

- Umwandlung eines bestehenden Hersteller-MSI.
- Erstellung von MSI durch Umpacken des Legacy-Installers oder von Grund auf.
- Verwendung von Legacy-Setup.
- Paketvirtualisierung (App-V/ThinApp/MSIX)

Allgemeine Best Practices für die Paketierung sind im Folgenden aufgeführt.

Hersteller-MSI	Ein originales Hersteller-MSI darf nicht verändert werden. Anpassungen müssen immer von MST vorgenommen werden. Die originalen MSI-Datenbanken dürfen nicht verändert werden. In Ausnahmefällen, wenn eine Transformationserstellung nicht möglich ist oder eine Fixierung der Hersteller-MSI nicht in einem akzeptablen Zeitrahmen möglich ist, kann die Setup-Erfassung durchgeführt werden.
Anpassungstool des Herstellers	Wenn ein herstellerspezifisches Anpassungstool (z. B. Adobe InstallTuner, Microsoft Office Customization Tool) für das Originalpaket verfügbar ist, sollte es verwendet werden.
Mehr als ein Hersteller-MSI von verschiedenen Herstellern	Wenn die Originalanwendung mehr als ein Hersteller-MSI von verschiedenen Herstellern enthält, sollte die Paketierungsaufgabe in separate Aufgaben für jedes Hersteller-MSI aufgeteilt werden.

Vorteile und Nachteile Applikations-Virtualisierung

Das Virtualisieren von Applikationen (z.B. in App-V/MSIX) kann dem Kunden Vorteile, aber auch Nachteile bieten:

Vorteile

Applikationen werden korrekt Installiert und Deinstalliert
Es gibt keinerlei Konflikte zwischen den Applikationen
Mehrere Versionen der gleichen Applikation können parallel installiert werden
Vorteile beim Rollout von Applikationen
Applikationen können pro Benutzer zugewiesen werden (z.B. bei VDI oder Citrix)

Nachteile

Virtualisierte Versionen von Applikationen werden nicht vom Hersteller angeboten
Die virtualisierte Applikation muss bei jedem Versionsupdate vom Hersteller neu erstellt werden
Durch das Sequence-Verfahren gehen in der Regel Garantieleistungen vom Hersteller verloren
Inkompatibilitäten verhindern das Erstellen von App-V Paketen
Es bleibt eine Mischung von Klassischen Applikationen mit Virtualisierten Applikationen, welche aufeinander abgestimmt werden muss

Strategien für die Applikationsvirtualisierung

Aggressive Applikationsvirtualisierung

Bei dieser Strategie versucht der Kunde, den höchstmöglichen Anteil seiner Applikationen zu virtualisieren. Das bringt ihm den Vorteil, dass er seine VDI oder TS Umgebung in der höchsten Ausbaustufe nutzen kann. Jeder Benutzer kann sich an seinem Thin-Client anmelden und hat alle seine Applikationen zur Verfügung. Es müssen keine permanenten virtuelle Clients bereitstehen.

Fallbezogene Applikationsvirtualisierung

Hier werden nur Applikationen virtualisiert, welche Projektbezogen sinn machen. Bei dieser Strategie wird nicht versucht, alle Applikationen generell zu virtualisieren. Das kann sein, dass ein Set von Applikationen auf VDI funktionieren muss oder über MSI-X auf private Geräte verteilt werden muss. Ein weiteres Beispiel könnte das Bereitstellen der Applikation auf demselben Gerät in einer unterschiedlichen Version sein.

Vorteile und Nachteile des Snapshot Verfahrens

Mit der Snapshot-Technik kann die Installation einer Applikation aufgezeichnet werden und z.B. in ein Windows Installer Paket (msi) konvertiert werden. Damit erhält der Kunde sämtliche Vorteile der Installer-Technik (Repair, Maschinen/Benutzerteile getrennt, Advertised Shortcuts, Standartisierung), aber gleichzeitig erlischt der Support durch den Hersteller. Die Verantwortung für das Paket liegt nun beim Ersteller dieses Snapshots und kann damit auch negative Effekte (z.B. Funktionsfehler, korrupte Deinstallationen) auslösen.

Der Snapshot muss in der Regel bei jedem Versionsupdate des Hersteller komplett neu erstellt werden.

Wir empfehlen die Snapshot Technik nur, falls entweder keine Installationroutine vom Hersteller vorliegt oder die Qualität der gelieferten Hersteller-Routine nicht korrekt ist (z.B. kein Silent Uninstall oder problematische Parameter).

Technische Erklärung zu den Formaten

	Klassische Formate	Virtuelle Formate	App-X, MSI-X	Universal Apps	Dockers / Containers
	MSI, Legacy, Snapshots von Drittherstellern	App-V, Portable Apps, Symantec VSA, ThinApp	App-X, MSI-X	UWP	Hyper-V and Windows Container
Registry, Filesystem	Nativ (teilw virt durch UAC)	Virtuell	Virtuell	Virtuell	Virtuell
Services, Treiber unterstützt	Ja	Nein (AppV kann Services)	Nein	Nein	Ja
CPU-Virtualisierung	Nativ	Nativ	Nativ	Nein	Ja
Kann Admin-Rechte verlangen	Ja	Ja	Nein	Nein	Ja
Läuft auf ARM oder Broadcom	Nein	Nein	Nein	Ja	Nein
Business Store (Azure)	Nein	Nein	Ja	Ja	Nein
OS Required	ab WinXP	ab Win7, Win10 (1607) keine Lizenz mehr nötig	ab Win10 (1607)	ab Win10	ab Win10 (1607)
Geignet für User-Deployment	Nein	Ja	Ja (zwingend)	Ja (zwingend)	Nein
Bemerkungen	voller Hersteller-Support, maximale Kompatibilität	Geeignet für VDI und Behebung von Installationskonflikten, nicht immer kompatibel (z.B. Hardware)	Apps können im Store published werden, keine Installationskonflikte, nicht immer kompatibel	Applikation muss als UWP kompiliert werden, kein Konvert möglich	Komplette Unabhängigkeit der Container untereinander, braucht mehr CPU und Memory

Architektur

Applikation und Betriebssystem

Es gibt zwei Kriterien für die Architekturen, es gibt die Architekture des Betriebssytems und die Architekture der Applikation, welche ausgeführt werden soll.

Windows Architektur

Betriebssystem/Applikation	Win x86	Win x64	Win Arm	Win Arm64
Windows 7/8/10 x86	OK	not OK	not OK	not OK
Windows 7/8/10 x64	OK	OK	not OK	not OK
Windows 8.1 arm (Windows RT)	not OK	not OK	OK	not OK
Windows 8/10 arm64 (Surface X)	OK **	OK (beta)	OK	OK

MacOS Architektur

Betriebssystem/Applikation	MacOS x64	MacOS M1
MacOS x64 (Intel)	OK	not OK
MacOS M1 (Apple Silicon)	OK **	OK

** Ausser Treiber und Hardwarenahe Programme