MSIX-Paketierung ohne Original-Installer, für Intune, AppAttach und Cloud PC-Lieferung.

Der Windows 10-Support endete im Oktober 2025. Intune setzt standardmäßig auf moderne Bereitstellungspfade, und Azure Virtual Desktop AppAttach erfordert MSIX. Das Migrationsfenster ist für die meisten Teams von Jahren auf Monate geschrumpft, und MSIX ist das Format, das neben IntuneWin über Intune, AVD AppAttach und moderne Cloud PC-Bereitstellung hinweg landet.

Ja. Capture-First bedeutet keine Installer-Medien-Abhängigkeit. EtherApps Forge erfasst den installierten Anwendungs-Footprint von einem Live-System (Dateien, Registry, AppData, Dienste und Abhängigkeiten) und produziert signierte MSIX-, MSI-, IntuneWin- und AppAttach-Ausgaben aus einer Erfassung. Das ist der Hauptgrund, warum Teams EtherApps Forge gegenüber traditionellen Packaging-Toolchains für Legacy-Umgebungen wählen.

Ja. Eine Erfassung produziert signiertes MSIX für Intune, IntuneWin für Legacy-Pfad-Intune-Bereitstellung und MSIX AppAttach für Azure Virtual Desktop. Windows 365-Lieferung verwendet MSIX oder IntuneWin aus derselben Erfassung. Windows 365 unterstützt derzeit kein AppAttach, sodass Cloud PC-Lieferung über den MSIX- oder IntuneWin-Pfad geht.

Nein. KI-geführte Routenführung erweitert das Team, indem sie die MSIX-Skills-Lücke schließt und den richtigen Pfad pro Anwendung vorschlägt, aber ein menschlicher Prüfer zeichnet jedes Paket noch ab. EtherApps Forge arbeitet neben bestehenden Packaging-Workflows statt Packager-Urteil zu ersetzen.

App-V 5.1 Pakete können direkt mit dem Microsoft MSIX Packaging Tool konvertiert werden, über die Oberfläche oder die Kommandozeile für Batch-Läufe. App-V 4.x Pakete werden nicht direkt unterstützt; Microsoft empfiehlt die Konvertierung aus dem Quell-Installer, und wo der Installer verloren ist, ist ein Capture-First-Repackaging aus einer Live-Installation der praktische Weg. EtherApps Forge deckt diesen Capture-First-Pfad mit menschlicher Prüfung vor der Freigabe ab.

Die üblichen Blocker sind Start- und Abmelde-Skripte, Laufzeitverhalten, das den App-V-Client voraussetzte, Middleware-Abhängigkeiten und Pakete, deren Quellmedien nicht mehr existieren. Das Package Support Framework behebt viele Laufzeitlücken nach der Konvertierung, und Pakete, die sich direkter Konvertierung widersetzen, können stattdessen Capture-First neu paketiert werden. Ein kurzer Bewertungsdurchlauf vor der Migration findet diese Blocker früh.

Ja. Jedes MSIX-Paket muss mit einem Zertifikat signiert werden, dem die Umgebung vertraut, bevor Windows es installiert, also planen Sie die Zertifikatsbehandlung als Teil des Migrations-Workflows statt als nachträglichen Gedanken. EtherApps Forge baut die Signierung in die Packaging-Pipeline ein, und dieselbe Zertifikatsdisziplin gilt für Pakete, die mit Microsoft-Tools konvertiert wurden.

Weisen Sie die signierten MSIX-Pakete über Intune zu wie jede moderne Windows-App, beginnend mit einem Pilot-Ring auf repräsentativen Windows 11 Geräten vor breiter Zuweisung. Halten Sie das App-V-Paket verfügbar, bis der Pilot bestätigt, dass sich die konvertierte App korrekt verhält, und ziehen Sie dann den alten Lieferpfad zurück, sobald jede Welle abgeschlossen ist.

Das Package Support Framework ist eine Open-Source-Laufzeit von Microsoft, die Verhalten korrigiert, auf das Anwendungen angewiesen sind, das im MSIX-Container aber nicht möglich ist. Typische Fälle sind das Schreiben von Dateien neben die eigene EXE, ein fest erwarteter Installationspfad oder das Lesen von Maschinen-Registry-Pfaden, die der Container umleitet. EtherApps Forge stellt das Framework als Teil der Paketierung bereit und wendet Datei- und Registry-Umleitung sowie Korrekturen des Arbeitsverzeichnisses an, damit eine erfasste Legacy-Anwendung ohne Änderung ihres Quellcodes korrekt läuft.

Ja. Die forge_msix-CLI ist ein Drop-in-Ersatz für Microsofts makeappx.exe und ruft dieselbe Windows-Paketierungs-Engine auf, sodass aus einem Build-Ordner ein signiertes, validiertes MSIX wird, mit denselben Schaltern, die eine bestehende Pipeline bereits übergibt. Entwickler und ISVs können ein Manifest aus der gebauten EXE erzeugen, in einem Schritt erstellen und signieren, das Ergebnis validieren und einem Smoke-Test unterziehen, alles als Stufen einer Release-Pipeline statt als manueller Schritt nach dem Build.

Microsoft hat den App-V-Client und Sequencer in festen erweiterten Support überführt, sodass sie weiterhin mit Windows ausgeliefert werden, aber nur Fixes erhalten, und der Support für die App-V-Server-Komponenten endete im April 2026. Teams, die App-V-Pakete bereits auf Azure Virtual Desktop nutzen, können App-V App Attach ohne einen App-V-Server verwenden, und die meisten Umgebungen nutzen dieses Fenster, um eine kontrollierte App-V-zu-MSIX-Migration zu planen.

ClickOnce installiert in einen benutzerbezogenen Profilpfad ohne Administratorrechte und ohne Isolation vom restlichen System, gedacht für selbstaktualisierende Fachanwendungen, die ein Entwickler direkt veröffentlicht. MSIX installiert in einen sandboxed Container mit Datei- und Registry-Virtualisierung, sauberer Deinstallation und integrierter Intune-/AVD-AppAttach-Bereitstellung. ClickOnce eignet sich für eine kleine interne App mit eigenem Update-Kanal; MSIX eignet sich für estateweites Packaging, bei dem IT konsistente Bereitstellung, saubere Entfernung und zentrale Verwaltung braucht.

MSI installiert direkt auf dem Rechner und verändert gemeinsam genutzte Speicherorte (Program Files, Registry, gemeinsame DLLs), sodass zwei per MSI installierte Apps im Laufe der Zeit in Konflikt geraten können. MSIX containerisiert jede App mit eigenem virtualisiertem Datei- und Registry-Namespace, sodass Installationen isoliert bleiben und Side-by-Side-Versionen sowie saubere Deinstallationen zuverlässig funktionieren. Der Kompromiss: Manche Legacy-MSI-Apps schreiben außerhalb ihres eigenen Containers, genau dafür ist die Datei- und Registry-Umleitung des Package Support Framework beim MSIX-Packaging gedacht.

App-V ist Microsofts älteres Anwendungsvirtualisierungsformat, inzwischen im festen erweiterten Support mit serverseitigem Support-Ende im April 2026, und benötigt einen eigenen Client oder App-V AppAttach auf Azure Virtual Desktop, um überhaupt zu laufen. MSIX ist das aktuelle Windows-Packaging-Format, funktioniert nativ mit Intune-Bereitstellung und AVD-/Windows 365-AppAttach ohne separaten Client, und ist das Ziel, auf das Microsofts eigenes Tooling inzwischen hinarbeitet. Ein neues Packaging-Projekt sollte MSIX anvisieren; App-V ist an diesem Punkt ein Migrationsquellformat, kein Zielformat.

Es gibt keinen einzelnen Button, der einen ganzen Bestand auf einmal sicher konvertiert, weil sich Abhängigkeiten und Installationsverhalten von Anwendung zu Anwendung unterscheiden. Was tatsächlich skaliert, ist derselbe Capture-first-Workflow wiederholt anzuwenden: EtherApps Forge erfasst den echten Fußabdruck einer laufenden Anwendung, leitet sie durch KI-gestützte Packaging-Entscheidungen für Signierung und Manifest-Fix-ups und gibt MSIX, MSI, IntuneWin oder AppAttach aus, dann folgt die nächste Anwendung demselben Weg. Ein Bestand kommt schneller durch, weil jede App denselben wiederholbaren Weg nimmt, nicht weil ein einzelner Vorgang alle unbeaufsichtigt konvertiert.

Intune stellt beide bereit, daher hängt die Wahl von der jeweiligen Anwendung ab, nicht von einer pauschalen Regel. MSIX bietet sauberes Deinstallieren, keine zurückbleibenden Dateien oder Registry-Einträge und funktioniert mit AVD-/Windows 365-AppAttach; das macht es zum Standard für alles, was eine Packaging-Auffrischung durchläuft. Eine Win32-/LOB-App bleibt die richtige Wahl, wenn eine Anwendung sich wirklich nicht containerisieren lässt, ohne dabei kaputtzugehen, und kein MSIX-Fix-up die Lücke schließt. Im Zweifel zuerst als MSIX packen und nur für die konkreten Anwendungen, die es brauchen, auf Win32 zurückfallen, statt das Format bestandsweit im Voraus festzulegen.

Die Konvertierung selbst ist dieselbe Arbeit wie bei jeder anderen App-V-zu-MSIX-Migration: Forge erfasst die laufende Anwendung und erzeugt ein signiertes MSIX oder MSI. Was sich für eine Citrix-Umgebung ändert, ist der Auslieferungsschritt, und der ist nativ, kein zusätzliches Tool: Citrix Virtual Apps and Desktops und Citrix DaaS unterstützen MSIX und MSIX App Attach direkt auf Session-Hosts. Die Ausgabe einer Forge-Erfassung geht also direkt in Citrix' eigene Funktion für Anwendungspakete.

Ja. Parallels RAS 19 und später liefert MSIX-Pakete und MSIX App Attach nativ aus, erweitert auf VDI in 19.1 und auf AVD in 19.2. Ein signiertes MSIX aus Forge lässt sich direkt in Parallels RAS' Funktion für Anwendungspakete importieren, sodass die Modernisierung einer App-V- oder MSI-App für eine Parallels RAS-Umgebung keinen separaten Packaging-Weg gegenüber jedem anderen MSIX-Ziel benötigt.

Ja, und sie sollte sauber sein. Das MSIX Packaging Tool von Microsoft erwartet einen sauberen Windows-Rechner oder eine Hyper-V-VM, damit der Capture keine Altlasten vom Arbeitsrechner eines Technikers mitnimmt. EtherApps Forge setzt dasselbe Prinzip über eine kontrollierte VM in Ihrer eigenen Azure-Umgebung um: Jeder Capture startet von einem geprüften Image, sodass das Paket wiederholbar und auditfähig ist statt von zufällig installierter Software geprägt. Damit entfällt auch der manuelle Neuaufbau der Paketierungs-VM zwischen Anwendungen, in dem bei einem Windows 11-Rückstau die meiste Zeit verloren geht.