Viele Migrationsempfehlungen, die im Vorfeld von April 2026 veröffentlicht wurden, sagten, App-V ende. Das war nicht ganz richtig, und der Unterschied zählt, wenn Sie darauf gestützt Arbeit planen.
Das Supportende erreichte die App-V Server-Infrastruktur. Der Client und der Sequencer nicht. Sie wechselten im November 2024 in den erweiterten Support und folgen weiterhin dem Windows-Servicing-Zeitplan.
Wenn Sie Ihre Roadmap um "App-V ist im April tot" herum neu gebaut haben, lohnt es sich, noch einmal zu lesen, wozu Sie sich tatsächlich verpflichtet haben. Die Arbeit kann weiterhin die richtige Arbeit sein. Die Dringlichkeit, die ihr zugeschrieben wurde, war es vermutlich nicht.
Was tatsächlich das Supportende erreicht hat
Das Datum ist der 14. April 2026, und es gilt für eine ganz bestimmte Liste.
Nach Microsofts fester Lifecycle-Richtlinie wurde an diesem Tag die Microsoft Desktop Optimization Pack Generation der Werkzeuge außer Dienst gestellt. Application Virtualization Hosting for Windows Desktops steht darauf, neben BitLocker Administration and Monitoring, dem Diagnostics and Recovery Toolset, User Experience Virtualization und Advanced Group Policy Management. In App-V Begriffen bedeutet "Hosting" den Management-Server, den Publishing-Server und den Reporting-Server sowie die Datenbanken dahinter.
Der Client und der Sequencer werden getrennt behandelt, und Microsofts App-V Supportrichtlinie ist darin eindeutig. Sie sind in den festen erweiterten Support gewechselt und gelten nicht mehr als veraltet. Für sie gibt es kein neues Supportende-Datum.
Zwei Details erklären, warum der Client die Server überlebt. Der App-V Client wird seit Windows 10 Version 1607 innerhalb von Windows Enterprise und Windows Education ausgeliefert, er ist also eine Windows-Funktion, die Sie aktivieren, und kein separates Produkt, das Sie installieren. Der Sequencer wanderte in das Windows Assessment and Deployment Kit. Beide folgen jetzt dem Windows-Servicing-Zeitplan.
Erweiterter Support bedeutet, dass Microsoft die Funktion weiterhin als Teil von Windows ausliefert und weiterhin Fehler- und Sicherheitskorrekturen herausgibt, aber keine Designänderungen oder neuen Funktionen aufnimmt. Nicht aufgegeben. Aber auch nicht in Weiterentwicklung.
Was das in der Praxis bedeutet
Zwei verschiedene Situationen, die oft verwechselt werden.
Wenn Sie die vollständige App-V Infrastruktur betreiben, mit Management-, Publishing- und Reporting-Servern, dann ist das der Teil mit einer echten Frist dahinter. Nicht unterstützte Server-Infrastruktur zu betreiben, die die Anwendungsbereitstellung vermittelt, ist ein echtes Risiko, und diese Migration ist nicht optional.
Wenn Sie App-V Pakete ohne diese Server ausliefern, über Intune, Configuration Manager oder Skripte gegen den Client, ist Ihre Lage deutlich komfortabler, als die Schlagzeilen nahelegten. Der Client wird unterstützt. Sie haben Zeit, sauber zu planen.
Die meisten Umgebungen, die ich sehe, sind der zweite Fall und halten sich für den ersten.
Auf jedem Gerät, das die Pakete ausführt, klären Sie das in einer Minute:
Get-AppvPublishingServer | Select-Object Name, Url
Get-AppvClientPackage -All | Select-Object Name, Version, PackageId
Gibt der erste Befehl einen Publishing-Server zurück, der auf eine interne URL zeigt, haben Sie Server-Infrastruktur im Bereitstellungspfad und ein datiertes Stück Arbeit vor sich. Gibt er nichts zurück, während der zweite Befehl Pakete auflistet, wurden diese Pakete lokal von Configuration Manager, einem Intune-Skript oder einer Tasksequenz hinzugefügt und veröffentlicht, und es ist überhaupt kein Server beteiligt.
Führen Sie das über eine repräsentative Stichprobe aus statt auf einem einzelnen Rechner. Umgebungen, die über ein Jahrzehnt gewachsen sind, sind selten konsistent, und es kommt häufig vor, dass ein Geschäftsbereich noch auf einen Publishing-Server zeigt, den alle anderen vor Jahren aufgegeben haben.
Zwei sehr unterschiedliche Ausgangslagen, und die Prüfung, die Ihnen sagt, in welcher Sie sich befinden.
Warum das überzeichnet wurde
Zum Teil ehrliche Verwechslung zwischen "App-V Server" und "App-V". Zum Teil, weil eine Frist ein überzeugenderer Grund ist, ein Projekt zu starten, als "das wird allmählich zum Altbestand".
Der unglückliche Nebeneffekt ist, dass manche Organisationen Konvertierungen überstürzten, für die sie nicht bereit waren, was Pakete hervorbrachte, die im Test funktionieren und in der Produktion Support-Tickets erzeugen. Eine überstürzte Migration einer schwierigen Anwendung ist schlechter als eine geplante sechs Monate später.
Es kostet außerdem intern Glaubwürdigkeit. Fordern Sie Budget gegen eine Frist an, die sich für Ihre Umgebung als gar nicht zutreffend herausstellt, und das nächste Anwendungsprojekt, das Sie vorschlagen, startet aus einer schlechteren Position als dieses.
Was tatsächlich zutrifft
- Die Server-Komponenten haben das Supportende erreicht. Ziehen Sie von ihnen weg.
- Der Client und der Sequencer sind im erweiterten Support. Sie werden nicht an einem bestimmten Datum aufhören zu funktionieren.
- Erweiterter Support ist keine Strategie. Er ist Zeit, eine umzusetzen.
- App-V erhält keine neuen Investitionen. Alles Neue passiert rund um MSIX und App Attach.
- App-V App Attach ist ein unterstützter Weg, bestehende App-V Pakete auf Azure Virtual Desktop weiter zu betreiben, ohne einen eigenen App-V Server aufzubauen, und das ist eine echte Option, während Sie den Rest planen.
Was erweiterter Support Ihnen nicht verschafft, gehört klar gesagt. Es bedeutet nicht, dass das Format mit der Plattform Schritt hält. Es bedeutet nicht, dass ein Anwendungshersteller Ihnen noch hilft, wenn Sie einen Fehler aus einer virtuellen Umgebung heraus melden. Und es bedeutet nicht, dass Ihre Packager in drei Jahren noch wissen, wie man sequenziert, denn die Leute, die es gut konnten, wenden sich tendenziell den Formaten zu, in die investiert wird. Genau das ist in den meisten Umgebungen die Einschränkung, die zuerst zubeißt, und keine Supportrichtlinie behebt sie.
Die richtige Lesart ist nicht "keine Eile". Sie lautet "Sie haben genug Zeit, das sauber zu machen, also machen Sie es sauber".
Planen ohne die Panik
Die brauchbare Abfolge ist dieselbe wie bei jeder Migration einer Anwendungsumgebung, und sie beginnt damit, zu wissen, was Sie haben.
Inventarisieren Sie, was tatsächlich genutzt wird. App-V Umgebungen sammeln Pakete an, die seit zwei Jahren niemand mehr gestartet hat. Jedes davon, das Sie migrieren, ist verschwendeter Aufwand. Erst Nutzungsdaten, dann Entscheidungen. Wenn Sie keine Nutzungstelemetrie haben, trennen Veröffentlichungs- und Startereignisse auf dem Client das Aktive vom Archivierten gut genug, um damit zu arbeiten.
Sortieren Sie nach Ziel, nicht nach Alter. Manche Pakete werden zu MSIX. Manche sind als MSI oder PowerShell App Deployment Toolkit Pakete besser aufgehoben. Manche sollten ausgemustert werden. Manche sind Kandidaten für App Attach in einer virtuellen Desktop-Umgebung. Dies pro Anwendung vorab zu entscheiden verhindert das Muster, bei dem alles Richtung MSIX gedrängt wird und ein Drittel davon sich wehrt.
Die Kriterien, die es meist entscheiden, in der Reihenfolge, in der sie üblicherweise greifen:
- Startet sie überhaupt noch jemand? Ausmustern schlägt Konvertieren jedes Mal, und es ist der einzige Weg ohne Testaufwand.
- Liefert der Hersteller noch einen Installer aus? Paketieren Sie die aktuelle Version aus der Quelle, statt ein Paket zu konvertieren, das aus einem vier Versionen alten Release gebaut wurde.
- Installiert sie einen Treiber oder einen Systemdienst oder schreibt sie an maschinenweite Orte, die andere Anwendungen lesen? Das ist eine Aufgabe für MSI oder PSADT, nicht für MSIX.
- Wird sie ausschließlich innerhalb einer virtuellen Desktop-Umgebung genutzt? App Attach kann ein besseres Ziel sein als die Installation pro Gerät, und natives MSIX gegenüber App Attach legt die Abwägung dar.
- Ist es ein sauberes App-V 5.1 Paket im täglichen Gebrauch? Das ist die schnellste verfügbare Konvertierung und die richtige Form für Ihren ersten Durchgang.
Konvertieren Sie zuerst die einfachen, um die Pipeline aufzubauen. Nicht das schwierigste Paket, um zu beweisen, dass es geht. Sie wollen einen funktionierenden Prozess, eine Signierkonfiguration, die sich benimmt, und einen Testring, der wirklich etwas auffängt, bevor Sie den unangenehmen Fällen begegnen.
Rechnen Sie damit, dass bestimmte Dinge brechen. App-V und MSIX behandeln Umgebungsvariablen, Verknüpfungen, Skripte und Dateitypzuordnungen unterschiedlich, und genau in diesen Unterschieden landet der eigentliche Konvertierungsaufwand. App-V-zu-MSIX-Migration behandelt, was typischerweise schiefgeht und warum, und Legacy-zu-MSIX-Konvertierung behandelt die Container-Verhalten, die danach auftauchen.
Behalten Sie das App-V Paket, bis der Ersatz sich in der Produktion bewährt hat. Nicht bis er den Test besteht. Bis echte Anwender ihn zwei Wochen lang genutzt haben. Behalten Sie auch eine funktionierende Sequencing-Umgebung noch eine Weile, denn die Woche, in der Sie sie abbauen, ist die Woche, in der Sie noch ein Paket finden, das neu gebaut werden muss.
Die eine Sache, die sich jetzt lohnt
Stellen Sie fest, in welcher der beiden Situationen Sie sich befinden. Wenn Sie die Server-Infrastruktur betreiben, hängt daran eine echte Frist, und das sollte ordentlich eingeplant werden. Wenn nicht, wurde Ihnen Zeit geschenkt, und die beste Verwendung dafür ist Inventarisierung und Sortierung statt einer Welle hastiger Konvertierungen.
So oder so ist die Arbeit, die sich auszahlt, dieselbe: wissen, was Sie haben, wissen, was jedes einzelne werden soll, und bewusst konvertieren. Ein Team, das zwei Wochen auf Inventarisierung und Routing verwendet, ist mit der gesamten Umgebung meist schneller fertig als eines, das am ersten Tag mit dem Konvertieren begann, weil es nie die Pakete neu bauen muss, die es gar nicht hätte erstellen sollen.
Wo EtherApps Forge ansetzt
EtherApps Forge erfasst Anwendungen, auch aus älteren Umgebungen und älteren Windows-Versionen, entscheidet über den Paketierungsweg und erzeugt aus derselben Erfassung MSIX-, MSI-, PSADT- oder Intune-fertige Ausgaben. Die Routing-Entscheidung ist hier der entscheidende Teil, denn der Fehler in den meisten App-V Migrationen ist nicht die Konvertierung selbst. Es ist das Konvertieren von Dingen, die hätten ausgemustert werden sollen, und das Hineinzwängen von Dingen in MSIX, die anderswo hingehörten.
EtherApps Forge ist eine Windows-Desktop-Anwendung mit einer kostenlosen 7-tägigen Testversion, kein gehosteter Dienst, sodass Erfassungen und Ausgaben in Ihrer eigenen Umgebung bleiben. Unsere Route Legacy-Apps deckt die Discovery- und Remediation-Seite ab, Anwendungsmodernisierung und Migration deckt die Planung ab, und MSIX Packaging und Deployment deckt Signierung, Validierung und Auslieferung ab, sobald ein Paket existiert.
Legacy-Anwendungsmodernisierung entdecken
Beginnen Sie mit der Inventarisierung und der Routing-Entscheidung, dann werden die Konvertierungen zum einfachen Teil.