Alte Windows-Anwendungen nach MSIX zu konvertieren bedeutet, eine ältere Anwendung, ob sie als setup.exe, als altes MSI, als App-V- oder ThinApp-Paket oder als Live-Installation ankam, deren Medien vor Jahren verschwanden, zu nehmen und als signiertes MSIX-Paket neu aufzubauen, das sich sauber auf Windows 11 installiert und deinstalliert und über Microsoft Intune bereitgestellt wird. Organisationen wählen den Weg von Legacy zu MSIX, weil das moderne Containerformat vorhersehbare Installationshygiene, einen sauberen Weg zu Azure Virtual Desktop und Windows 365 und eine unterstützbare Möglichkeit mitbringt, jahrzehntealte Branchensoftware am Laufen zu halten, während ältere Packaging-Formate ausgemustert werden. Dieser Leitfaden deckt die gesamte Reise ab: was als Legacy zählt, warum MSIX das Ziel ist, die Konvertierungswege im Vergleich, was üblicherweise bricht, wann MSIX die falsche Antwort ist und ein praktischer Workflow, dem Sie Anwendung für Anwendung folgen können.
Was als alte Windows-Anwendung zählt
Legacy hat weniger mit dem Alter zu tun als damit, wie eine Anwendung paketiert wurde und wie viel von ihrem ursprünglichen Kontext noch erhalten ist. Mehrere Muster tauchen in fast jeder Umgebung auf.
- setup.exe und alte MSI-Installer. Herstellerinstaller, die für Windows 7 oder frühes Windows 10 gebaut wurden, oft mit fest codierten Pfaden, benutzerdefinierten Aktionen und Silent-Install-Schaltern, die niemand dokumentiert hat.
- App-V-Pakete. Virtuelle Anwendungspakete aus einer App-V-Umgebung, die nun einen Plan für die Zukunft braucht, besonders dort, wo die App-V-Serverseite das Ende ihrer unterstützten Lebensdauer erreicht hat.
- ThinApp und andere virtualisierte Formate. Anwendungen, die in ein älteres Virtualisierungsformat verpackt sind, von dem sich die Organisation abwendet, während sie sich auf einen einzigen modernen Container standardisiert.
- Anwendungen mit verlorenen Installationsmedien. Software, die in der Produktion problemlos läuft, deren Installer aber verschwunden ist, weil der Hersteller den Betrieb einstellte, das Download-Portal gesperrt ist oder die Medien auf einer Freigabe lagen, die aufgeräumt wurde.
- Anwendungen, die von älteren Windows-Versionen erfasst wurden. Branchen-Tools, die nur je auf Windows 7 oder frühen Windows 10 Referenzrechnern installiert waren und nun auf eine aktuelle Basislinie umziehen müssen.
Der rote Faden ist, dass die laufende Anwendung, nicht ein makelloser Installer, oft die zuverlässigste Quelle der Wahrheit ist.
Warum MSIX das moderne Ziel ist
MSIX ist ein containerisiertes Packaging-Format, das die Dateien und Registry-Schreibvorgänge einer Anwendung vom Rest des Systems isoliert, sodass Installationen und Deinstallationen sauber sind und wenig zurücklassen. Diese Hygiene ist der Hauptgrund, warum Teams sich darauf standardisieren, aber drei praktische Vorteile besiegeln die Entscheidung meist.
Es läuft, wo moderne Umgebungen laufen. MSIX wird nativ auf Windows 10 Version 1709 und später sowie auf Windows 11 unterstützt, sodass ein konvertiertes Paket die Plattformen adressiert, zu denen sich die meisten Organisationen bereits bewegen. Ältere Windows-Versionen benötigen die MSIX Core Kompatibilitätsschicht.
Es passt zu Cloud- und virtueller Bereitstellung. MSIX app attach hängt eine Anwendung dynamisch an eine Benutzersitzung auf Azure Virtual Desktop an, ohne sie auf dem Sitzungshost zu installieren, was Images schlank hält und den Anwendungslebenszyklus vom Betriebssystem trennt. Auf physischen Geräten und Windows 365 Cloud-PCs wird dasselbe signierte MSIX über Intune an verwaltete Endpunkte bereitgestellt.
Es wird über die Tools bereitgestellt, die Sie bereits betreiben. Ein signiertes MSIX wird zu Intune hinzugefügt und Benutzern oder Geräten in gestaffelten Ringen zugewiesen. Das Signieren ist nicht optional: Windows verlangt, dass jedes MSIX-Paket mit einem Zertifikat signiert wird, das zu einem Stammzertifikat führt, dem das Gerät vertraut, und es installiert kein unsigniertes Paket. Es gibt keine Herstellersignatur, die von einer erfassten Anwendung geerbt werden könnte, sodass das Paket das eigene Code-Signing-Zertifikat Ihrer Organisation übernimmt.
Die Konvertierungswege im Vergleich
Es gibt keinen einzigen Weg von Legacy zu MSIX. Die richtige Methode hängt davon ab, ob der Quell-Installer erhalten ist, wie viele Anwendungen Sie umziehen und wie komplex jede einzelne ist. Nach Methode statt nach Produkt verglichen:
| Methode | Am besten für | Automatisierungsgrad | Zu beachten |
|---|---|---|---|
| Manuelles Repackaging mit dem MSIX Packaging Tool | Eine Handvoll Anwendungen mit sauberen Installern oder umständlicher Installationslogik, die ein menschliches Auge braucht | Gering, durchgehend manuell | Langsam und schwer identisch zwischen Packagern zu wiederholen |
| Skript- oder Batch-Konvertierung über die Kommandozeile des Packaging Tools und Template-Dateien | Größere Umgebungen, in denen viele Installer in Masse konvertieren | Hoch, template-gesteuerte Läufe | Benötigt solide Templates und danach appweise Validierung |
| Capture-First-Konvertierung auf einer kontrollierten sauberen VM mit KI-geführter Prüfung | Anwendungen mit verlorenen Medien, älteren virtualisierten Formaten oder komplexen Footprints | Hoch, agentisch mit menschlicher Prüfung | Bestätigen Sie die Lizenzrechte, bevor Sie eine installierte Anwendung neu erfassen |
Das Microsoft MSIX Packaging Tool untermauert die ersten beiden Wege. Es erstellt ein MSIX-Paket aus einem MSI-, EXE-, ClickOnce-, App-V 5.1- oder Skript-Installer, und für App-V konvertiert es das 5.1-Format direkt, während 4.x-Pakete stattdessen aus ihrem Quell-Installer konvertiert werden. Für Massenarbeit läuft dasselbe Tool über die Kommandozeile gegen ein Konvertierungs-Template, das die Paketinformationen und Einstellungen trägt, sodass eine Konfiguration über viele Anwendungen und spätere Versionen hinweg wiederverwendet werden kann:
MsixPackagingTool.exe create-package --template C:\conversions\LineOfBusinessApp.xml -v
Erzeugen Sie das Template einmal über die Oberfläche des Tools und verwenden Sie es dann für skriptgesteuerte Läufe wieder. Wo der Installer vollständig fehlt, wird Capture-First zum praktischen Weg: Die laufende Anwendung wird von einem laufenden, sauberen Rechner erfasst und als Paket neu aufgebaut, was der Capture-First-Pfad zu MSIX für komplexe Anwendungen ausführlich behandelt.
Legacy-Quellen fließen durch Erfassung und Remediation in moderne Ausgaben, die über Intune, Azure Virtual Desktop und Windows 365 bereitgestellt werden.
Was üblicherweise bricht und wie PSF hilft
Ein konvertiertes Paket, das sich installiert, ist nicht dasselbe wie eines, das funktioniert. Weil MSIX die Anwendung in einem Container ausführt, der bestimmte Datei- und Registry-Schreibvorgänge umleitet, beginnen manche Verhalten, die bei einer herkömmlichen Installation in Ordnung waren, zu scheitern.
Die üblichen Verursacher sind eine Anwendung, die in ihren eigenen Installationsordner schreibt, eine, die von einem bestimmten Arbeitsverzeichnis abhängt, das der Container nicht setzt, und eine, die beim Start Parameter oder eine Umgebungsvariable erwartet. Genau dafür gibt es das Package Support Framework (PSF). PSF ist ein Open-Source-Kit von Microsoft, das gezielte Fixups auf eine Anwendung anwendet, ohne ihren Quellcode zu berühren, sodass sie sich innerhalb des Containers korrekt verhält. Es kann das Arbeitsverzeichnis korrigieren, Dateischreibvorgänge an einen unterstützten Ort umleiten und beim Start ein Skript ausführen, um die Umgebung vorzubereiten, die die Anwendung erwartet.
Zwei Grenzen sollten Sie vor dem Start kennen. MSIX unterstützt keine Windows-Treiber, sodass eine Anwendung, die einen Kernelmodus-Treiber installiert, sich nicht sauber containerisieren lässt. Dienste werden unterstützt, aber erst ab Windows 10 Version 2004 und nur als maschinenweite Dienste, die unter einem Systemkonto laufen; benutzerbezogene Dienste werden nicht unterstützt, und ein Dienstpaket benötigt Administratorrechte zur Installation. Auch die benutzerbezogene Konfiguration ist wichtig: Eine Erfassung auf Maschinenebene überträgt keine Lizenzdateien oder Erststart-Zustände, die in ein Benutzerprofil geschrieben werden, sodass dieser Zustand bewusst behandelt werden muss.
Wann MSIX das falsche Ziel ist
MSIX ist das richtige Ziel für die meisten Desktop-Anwendungen, aber nicht für alle, und es zu erzwingen ist eine häufige Ursache für Nacharbeit. Wählen Sie eine andere Ausgabe, wenn eine Anwendung einen Windows-Treiber benötigt, von einem benutzerbezogenen Dienst abhängt oder auf tiefe Shell- oder COM-Integration setzt, die außerhalb des Pakets sichtbar sein muss. In diesen Fällen hält ein signiertes MSI die Anwendung bereitstellbar, während es respektiert, was der Container nicht leisten kann, und eine erfasste Nutzlast kann daneben bestehen. Wo der unmittelbare Bedarf cloud-verwaltete Bereitstellung statt Containerisierung ist, wird ein IntuneWin-Paket, das mit dem Microsoft Win32 Content Prep Tool gebaute Win32-Anwendungsformat, genauso bereitwillig über Intune bereitgestellt. Die Disziplin besteht darin, den Footprint jeder Anwendung das Format bestimmen zu lassen, statt jede Anwendung auf MSIX festzulegen, bevor Sie sie verstehen.
Ein praktischer Workflow von Legacy zu MSIX
Wie auch immer die Mischung der Quellen aussieht, dieselbe Abfolge hält die Arbeit vorhersehbar.
- Bestandsaufnahme. Listen Sie jede Anwendung, ihren Eigentümer, ihre Version, ihre Installationsquelle und ob die Originalmedien noch existieren.
- Rationalisieren. Mustern Sie aus, was niemand nutzt, und konsolidieren Sie Duplikate, bevor Sie Aufwand investieren, sodass Sie nur modernisieren, was seinen Platz verdient.
- Wählen Sie einen Weg pro Anwendung. Nutzen Sie die Bestandsaufnahme, um jede Anwendung auf manuelle, skriptgesteuerte oder Capture-First-Konvertierung auszurichten, und kennzeichnen Sie jene, die besser zu MSI oder IntuneWin passen.
- Erfassen oder konvertieren Sie auf einer sauberen VM. Arbeiten Sie auf einem sauberen, gepatchten Windows 11 Rechner, sodass Sie die Anwendung paketieren und nicht das Durcheinander eines Arbeitsdesktops.
- Beheben. Wenden Sie PSF-Fixups an, wo der Container das Verhalten ändert, einschließlich eines Startskripts, wo eines benötigt wird.
- Testen Sie auf repräsentativen Geräten. Prüfen Sie Start, Kernabläufe, Lizenzaktivierung, benutzerbezogene Einstellungen und Deinstallation auf Geräten, die zur Zielumgebung passen.
- Signieren. Signieren Sie jedes Paket mit einem vertrauenswürdigen Code-Signing-Zertifikat, dessen Identität mit dem Manifest-Herausgeber übereinstimmt.
- Stellen Sie über Intune in Ringen bereit. Weisen Sie zuerst einen Pilot-Ring zu, dann erweitern Sie, sodass jedes Problem auf wenigen Geräten auftaucht statt über die ganze Umgebung.
Die hartnäckigen Fälle, verlorene Medien und ältere virtualisierte Formate, sind dort, wo sich ein erfassungsgeführter Ansatz auszahlt. Unsere Leitfäden dazu, wie man eine Anwendung neu paketiert, wenn der Installer verloren ist, und zu einer App-V-zu-MSIX-Migration gehen bei diesen beiden Wegen tiefer, und Legacy-Windows-Apps modernisieren deckt die Bewertung ab, die ihnen vorausgeht.
Wo EtherApps Forge ansetzt
Der größte Teil der Schwierigkeit in einem Legacy-zu-MSIX-Programm sitzt im Rest: die Anwendungen ohne Installer, mit einem älteren virtualisierten Format oder einem Footprint, der zu komplex ist, um blind konvertiert zu werden. EtherApps Forge ist für diesen Rest gebaut. Es ist eine Win32-Anwendung, die Sie innerhalb Ihrer eigenen Umgebung bereitstellen, statt eines SaaS-Dienstes, sodass Erfassungen und Packaging unter Ihrer Kontrolle bleiben, und es erfasst Anwendungen sowohl aus älteren Windows-Versionen als auch aus aktuellen, was genau das ist, was eine Legacy-Umgebung braucht.
Der Workflow ist agentische App-Paketierung mit menschlicher Prüfung: Ein AI Controller, der auf einer VM in Azure innerhalb Ihrer eigenen kontrollierten Umgebung läuft, analysiert den erfassten Footprint und empfiehlt einen Weg über MSIX, MSI, IntuneWin und app attach, während ein Packager die Entscheidung bestätigt, statt so zu tun, als würden sich schwierige Anwendungen selbst paketieren. Jede Lizenz umfasst Schulung und Support, und eine kostenlose 7-tägige Testversion lässt ein Packaging- oder Endpunkt-Team das Ergebnis an einer echten Anwendung beweisen, bevor die breitere Umgebung angegangen wird. Für die Lieferseite deckt MSIX Packaging und Deployment Signierung, PSF-Prüfung und Intune-Rollout ab, und agentische Anwendungspaketierung erklärt das Erfassungs- und Prüfmodell vollständig. Das Produkt selbst sehen Sie auf EtherApps Forge.
Legacy zu MSIX ist eine Entscheidungsaufgabe, bevor es eine Packaging-Aufgabe ist: nehmen Sie die Umgebung auf, leiten Sie jede Anwendung zu der passenden Methode, beheben Sie, was der Container ändert, signieren Sie das Ergebnis und stellen Sie mit Zuversicht über Intune bereit.
Modernisieren Sie Ihre Legacy-Windows-Anwendungen mit einer Bewertung und einem Capture-First-Ansatz, der undokumentierte Software in signierte, bereitstellbare Pakete verwandelt.