Eine App-V-zu-MSIX-Migration überführt eine alte App-V-Anwendungsumgebung auf das moderne MSIX-Packaging-Format, damit diese Anwendungen sauber auf Windows 11 laufen und über Intune bereitgestellt werden. In der Praxis ist die Arbeit eine kurze, wiederholbare Abfolge: die App-V-Umgebung bewerten, die Pakete konvertieren, die sich direkt konvertieren lassen, alle auftretenden Laufzeitlücken beheben, auf echten Geräten testen, jedes Paket mit einem vertrauenswürdigen Zertifikat signieren und dann über Intune mit gestaffelten Zuweisungs-Ringen bereitstellen. Manche Pakete konvertieren in Minuten; andere brauchen einen anderen Weg, und zu wissen, welches welches ist, bevor Sie beginnen, hält das Projekt vorhersehbar.
Warum Organisationen von App-V weggehen
App-V funktioniert weiterhin, und Microsoft stellt klar, dass Teams, deren App-V-Funktionsumfang ihren Anforderungen weiterhin genügt, nicht zur Migration gezwungen sind. Der Grund, warum so viele Umgebungen den Umzug dennoch planen, ist, dass die Plattform jetzt eingefroren ist. App-V wird nicht mehr weiterentwickelt. Der App-V-Client und der Sequencer wurden in festen erweiterten Support überführt: Sie werden weiterhin in Windows ausgeliefert und erhalten Fehler- und Sicherheitskorrekturen, aber es kommen keine neuen Funktionen hinzu. Die App-V-Server-Komponenten gingen weiter: Sie wurden als veraltet eingestuft und ihr Support endete im April 2026, sodass die Serverseite einer App-V-Bereitstellung nun über ihre unterstützte Lebensdauer hinaus ist.
Diese Kombination aus einem eingefrorenen Client und einem nicht unterstützten Server ist der Grund, warum vorausschauende Planung jetzt sinnvoll ist, solange Zeit bleibt, sie in Ruhe statt gegen eine Frist zu erledigen. Teams, die App-V-Pakete weiterhin auf Azure Virtual Desktop laufen lassen müssen, ohne App-V-Server-Infrastruktur aufzubauen, können App-V App Attach nutzen, den unterstützten Microsoft-Weg, der Raum verschafft, um einen sauberen Umzug zu MSIX zu planen.
Was sich konvertieren lässt und was nicht
Nicht jedes App-V-Paket nimmt denselben Weg zu MSIX, und die Trennlinie ist die App-V-Version.
Das MSIX Packaging Tool konvertiert App-V 5.1 Pakete direkt. Richten Sie es über die Oberfläche oder die Kommandozeile auf die .appv-Datei, und das Tool übersetzt das vorhandene Manifest in ein MSIX-Paket. Weil die Paketinformationen bereits strukturiert sind, ist dies die schnellste und sauberste verfügbare Konvertierung.
App-V 4.x Pakete sind eine andere Sache. Direkte Konvertierung wird nicht unterstützt, und Microsofts Empfehlung ist, zum ursprünglichen Quell-Installer zurückzukehren und stattdessen diesen zu MSIX zu konvertieren. Wo der Quell-Installer verloren gegangen ist, und in älteren Umgebungen ist das häufig der Fall, ist ein Capture-First-Repackaging aus einer Live-Installation der praktische Weg: Sie behandeln die laufende Anwendung als maßgebliche Quelle und bauen sie als signiertes Paket neu auf.
Die Konvertierung endet außerdem selten beim Paket. Manche Anwendungen verhalten sich innerhalb eines MSIX-Containers anders, der bestimmte Datei- und Registry-Schreibvorgänge umleitet. Diese Laufzeitverhalten werden mit dem Package Support Framework (PSF) behoben, das gezielte Fixups anwendet und beim Start Skripte ausführen kann, um die Umgebung vorzubereiten, die die Anwendung erwartet.
Prüfen Sie die App-V-Umgebung, bevor Sie migrieren
Eine Migration ist nur so gut wie ihre Bestandsaufnahme. Bevor Sie irgendetwas konvertieren, machen Sie sich ein Bild davon, was die Umgebung enthält und wie sie genutzt wird. Die Prüfung sollte Folgendes erfassen:
- Paketbestand. Jedes App-V-Paket im Umlauf, mit Version, Eigentümer und wo es veröffentlicht ist.
- Nutzung. Welche Pakete aktiv gestartet werden und von wem; brachliegende Pakete sind die Migration vielleicht nicht wert.
- Aufteilung App-V 4.x gegenüber 5.x. Das entscheidet den Weg pro Paket: 5.1 konvertiert direkt, 4.x geht über den Quell-Installer oder Capture-First.
- Fehlende Quellmedien. Kennzeichnen Sie Pakete, deren Original-Installer verschwunden ist, denn das sind Ihre Capture-First-Kandidaten.
- Skripte und Middleware. App-V-Skripte, Runtimes und gemeinsame Abhängigkeiten, die nach der Konvertierung behandelt werden müssen.
- Verbindungsgruppen. Bei Paketen, die zusammen laufen, müssen ihre Beziehungen verstanden werden, bevor sie auseinandergerissen werden.
- Ausmusterungskandidaten. Anwendungen, die niemand nutzt oder die bereits einen modernen Ersatz haben, sollten ausgemustert statt migriert werden.
Das Ergebnis ist eine Entscheidung pro Paket: direkt konvertieren, aus der Quelle konvertieren, Capture-First oder ausmustern. Diese Liste ist das Rückgrat des gesamten Projekts.
Von der Prüfung der App-V-Umgebung zu signierten MSIX-Paketen, die über Intune bereitgestellt werden.
Eine App-V-zu-MSIX-Migrationsmethode wählen
Mit der Prüfung in der Hand kann jedes Paket auf die richtige Methode ausgerichtet werden, die von seiner Version abhängt, davon, ob seine Quelle erhalten ist, und davon, wie viele Sie umziehen müssen.
| Methode | Am besten für | Automatisierungsgrad | Zu beachten |
|---|---|---|---|
| Manuelles Repackaging | Anwendungen ohne App-V-Quelle und mit umständlicher Installationslogik | Gering, durchgehend manuell | Langsam und schwer konsistent zwischen Packagern zu wiederholen |
| MSIX Packaging Tool Konvertierung | App-V 5.1 Pakete mit sauberem, gut verstandenem Verhalten | Mittel, geführter UI-Workflow | Nur App-V 5.1 konvertiert direkt; 4.x braucht den Quell-Installer |
| Skriptgesteuerte Batch-Konvertierung (Kommandozeilen-Template-Läufe) | Große App-V 5.x Umgebungen, die in Masse konvertiert werden | Hoch, template-gesteuerte Läufe | Benötigt solide Templates und danach appweise Validierung |
| Capture-First-Repackaging (EtherApps Forge) | App-V 4.x oder Pakete, deren Quelle verloren ist | Hoch, agentisch mit menschlicher Prüfung | Bestätigen Sie die Lizenzrechte, bevor Sie eine installierte Anwendung neu erfassen |
Der Konvertierungs-Workflow
Welche Methode ein Paket auch nimmt, die Konvertierung selbst folgt einer konsistenten Form.
Beginnen Sie auf einem sauberen Rechner. Nutzen Sie einen sauberen, gepatchten virtuellen Windows 11 Rechner oder Referenzrechner als Konvertierungsumgebung, sodass Sie die Anwendung paketieren und nicht das Durcheinander eines Arbeitsdesktops.
Bewerten Sie zuerst. Verstehen Sie den Installer oder das App-V-Paket, bevor Sie es konvertieren, damit Sie wissen, ob es sauber konvertiert und was es schreibt.
Konvertieren. Führen Sie für ein App-V 5.1 Paket das MSIX Packaging Tool aus. Für einen Massenlauf über eine größere App-V 5.x Umgebung steuern Sie es über die Kommandozeile mit einem Template:
MsixPackagingTool.exe create-package --template C:\conversions\LineOfBusinessApp.xml -v
Das Template trägt die Paketinformationen und Einstellungen, sodass eine Konfiguration für spätere Versionen wiederverwendet und über viele Pakete skriptgesteuert werden kann. Erzeugen Sie es einmal über die Oberfläche und verwenden Sie es dann für Batch-Läufe wieder.
Prüfen Sie das Paket. Öffnen Sie das resultierende MSIX im Paket-Editor und prüfen Sie das Manifest, die Einstiegspunkte und die Capabilities vor dem Signieren.
Wenden Sie PSF an, wo nötig. Wo sich eine konvertierte Anwendung im Container fehlerhaft verhält, fügen Sie das Package Support Framework mit dem benötigten Fixup hinzu, einschließlich eines Startskripts, falls die Anwendung eines erwartet.
Testen, Signieren und Intune-Bereitstellung
Ein konvertiertes Paket ist nur ein Kandidat, bis es getestet und signiert ist.
Signieren Sie es. MSIX-Pakete müssen mit einem Zertifikat signiert werden, dem die Umgebung vertraut, bevor sie auf verwalteten Geräten installiert werden. Es gibt keine App-V-Signatur zum Erben, sodass das Paket das Code-Signing-Zertifikat Ihrer Organisation übernimmt, dessen Identität mit dem im Manifest genannten Herausgeber übereinstimmen muss.
Testen Sie auf repräsentativen Geräten. Installieren und erproben Sie jedes Paket auf echten Windows 11 Geräten, die zur Zielumgebung passen: Prüfen Sie Start, Kernabläufe, Lizenzaktivierung, benutzerspezifische Einstellungen und Deinstallation, nicht nur, dass es sich installiert.
Stellen Sie über Intune mit Ringen bereit. Fügen Sie das signierte MSIX zu Intune hinzu und weisen Sie es in Stufen zu: zuerst ein Pilot-Ring, dann breitere Ringe, sodass ein Problem auf einer Handvoll Geräte auftaucht statt auf der ganzen Umgebung.
Ein durchgerechnetes Beispiel
Betrachten Sie zwei Pakete aus derselben Prüfung.
Das erste ist eine App-V 5.1 Branchenanwendung im täglichen Gebrauch, deren Verhalten gut verstanden ist. Sie konvertiert direkt: Das MSIX Packaging Tool liest die .appv-Datei und erzeugt in einem Durchgang ein MSIX-Paket. Ein Windows 11 Pilot bringt einen Blocker zutage, die Anwendung stützt sich auf ein Startskript, das eine Umgebungsvariable setzte, die der Container nicht übernahm. Ein Package Support Framework Fixup führt dieses Skript beim Start aus und sie verhält sich korrekt. Das Paket wird signiert, auf einem kleinen Ring pilotiert und dann breiter in Intune zugewiesen.
Das zweite ist ein älteres App-V 4.x Paket, dessen Installer vor Jahren verloren ging, ohne Quellmedien als Rückfalloption. Direkte Konvertierung ist nicht verfügbar, sodass es stattdessen den Capture-First-Weg nimmt: aus einer Live-Installation erfasst, als signiertes MSIX neu aufgebaut, auf Windows 11 getestet und auf dieselbe Weise bereitgestellt. Gleiches Ziel, anderer Weg, und die Prüfung sagte dem Team, was jedes Paket brauchte, bevor Zeit aufgewendet wurde.
Fragen zur App-V-zu-MSIX-Migration, beantwortet
Können App-V-Pakete direkt zu MSIX konvertiert werden?
App-V 5.1 Pakete können es: Das MSIX Packaging Tool konvertiert sie direkt aus der .appv-Datei, über die Oberfläche oder die Kommandozeile. App-V 4.x Pakete können es nicht; Microsoft empfiehlt die Konvertierung aus dem ursprünglichen Quell-Installer oder ein Capture-First-Repackaging aus einer Live-Installation, wo dieser Installer verloren ist.
Welche Tools stehen für die App-V-zu-MSIX-Migration zur Verfügung?
Microsofts MSIX Packaging Tool übernimmt die direkte App-V 5.1 Konvertierung und skriptgesteuerte Batch-Läufe über die Kommandozeile, und das Package Support Framework übernimmt danach die Laufzeit-Fixups. Für Pakete, die sich nicht direkt konvertieren lassen, baut ein Capture-First-Ansatz die Anwendung aus einer laufenden Installation neu auf, und genau hier passt EtherApps Forge.
Was bricht während der Konvertierung?
Die häufigen Brüche sind Laufzeitverhalten, die der MSIX-Container ändert: Datei- oder Registry-Schreibvorgänge, die er umleitet, Startskripte, die die Umgebung einrichten, und benutzerspezifische Konfiguration, die eine Konvertierung auf Maschinenebene nicht überträgt. Die meisten werden mit einem Package Support Framework Fixup gelöst; App-V 4.x Pakete brechen den direkten Weg vollständig.
Müssen konvertierte Pakete neu signiert werden?
Ja. Jedes MSIX-Paket muss mit einem Zertifikat signiert werden, dem die Umgebung vertraut, bevor es auf verwalteten Geräten installiert wird, und es gibt keine App-V-Signatur zur Wiederverwendung. Stellen Sie sicher, dass die Zertifikatsidentität mit dem Manifest-Herausgeber übereinstimmt.
Wie stelle ich migrierte MSIX-Apps mit Intune bereit?
Fügen Sie das signierte MSIX zu Intune hinzu und weisen Sie es in gestaffelten Ringen zu, beginnend mit einer Pilotgruppe. Testen Sie zuerst auf repräsentativen Windows 11 Geräten, dann erweitern Sie Ring für Ring, sodass jedes Problem früh erkannt wird.
Wo EtherApps Forge ansetzt
Die meisten App-V-Umgebungen sind eine Mischung: App-V 5.1 Pakete, die sich direkt konvertieren, und ein hartnäckiger Rest von App-V 4.x oder Paketen mit verlorener Quelle, die es nicht tun. EtherApps Forge ist für diesen Rest gebaut. Als Capture-First-Packager erfasst es die Anwendung aus einer Live-Installation und baut sie neu auf, sodass ein verlorener Installer keine Sackgasse mehr ist.
Der Workflow ist agentisch mit menschlicher Prüfung: EtherApps Forge analysiert den erfassten Footprint und empfiehlt einen Weg, und ein Packager bestätigt ihn, statt so zu tun, als würden sich schwierige Anwendungen selbst paketieren. Die Ausgaben umfassen MSIX, MSI, PowerShell App Deployment Toolkit, IntuneWin und App Attach, sodass eine Erfassung die Intune-Lieferung oder ein Azure Virtual Desktop App Attach Szenario speisen kann. Beweisen Sie es zuerst an einer echten Anwendung mit der 7-tägigen kostenlosen Testversion, bevor Sie die breitere Umgebung angehen.
Für die Lieferseite siehe MSIX Packaging und Deployment, und für Pakete, deren Quelle verschwunden ist, deckt Legacy-Windows-Apps modernisieren den Pfad des verlorenen Installers ab. Die begleitenden Leitfäden zu einem Capture-First-Pfad zu MSIX für komplexe Anwendungen und dazu, wie man eine Anwendung neu paketiert, wenn der Installer verloren ist, gehen tiefer, und agentische Anwendungspaketierung erklärt das automatisierte Erfassungs- und Prüfmodell.
Eine App-V-zu-MSIX-Migration ist zuerst eine Planungsaufgabe und erst dann eine Packaging-Aufgabe: prüfen Sie die Umgebung, leiten Sie jedes Paket zur passenden Methode, beheben Sie die Laufzeitlücken, signieren, testen und stellen Sie über Intune in Ringen bereit. Machen Sie die Prüfung gut, und der Rest wird zur Routine.
MSIX Packaging und Deployment entdecken für Unterstützung bei der App-V-zu-MSIX-Migration über Konvertierung, PSF-Fixups, Signierung und Intune-Rollout.