Wie Sie eine EXE zu MSIX konvertieren, von Anfang bis Ende

Eine EXE zu MSIX zu konvertieren ist unkompliziert, wenn der Installer sich brav verhält, und wirklich schwierig, wenn er es nicht tut. Die meisten Anleitungen behandeln den ersten Fall. Diese behandelt den gesamten Weg, einschließlich der Stellen, an denen es schiefgeht, denn dorthin geht die Zeit tatsächlich.

Der Endzustand ist ein signiertes MSIX-Paket, das sauber installiert, sauber deinstalliert und über Intune bereitgestellt wird.

Bevor Sie beginnen: ist MSIX das richtige Ziel?

Dreißig Sekunden wert, weil es Tage spart.

MSIX passt zu gewöhnlichen Desktop-Anwendungen im Benutzermodus. Es passt nicht zu irgendetwas, das einen Treiber installiert, einen Systemdienst registriert, in maschinenweite Orte schreiben muss, die andere Anwendungen lesen, oder sich tief in das Betriebssystem einklinkt. Wenn Ihre EXE eines davon tut, paketieren Sie sie stattdessen als MSI oder über das PowerShell App Deployment Toolkit und ziehen Sie weiter. Sie in MSIX zu zwingen erzeugt ein Paket, das technisch existiert und nie ganz funktioniert.

Drei Fragen klären die meisten Fälle, bevor Sie irgendein Werkzeug öffnen:

• Braucht der Installer administrative Rechte für irgendetwas jenseits des Schreibens nach Program Files? Nach Program Files zu schreiben ist normal. Einen Dienst, einen Treiber oder einen systemweiten Hook zu installieren ist das Signal aufzuhören.
• Liest sonst irgendetwas, was diese Anwendung schreibt? MSIX leitet Schreibvorgänge in einen benutzerspezifischen Container um, sodass eine andere Anwendung, eine geplante Aufgabe oder ein Überwachungsagent, die eine von dieser Anwendung erzeugte Datei oder einen Schlüssel lesen, diese Daten durch die Umleitung nicht mehr sehen. Das sieht aus wie ein funktionierendes Paket und ist keines.
• Liefert der Hersteller bereits ein MSIX aus? Fragen Sie, bevor Sie erfassen. Einen Installer neu zu paketieren, für den es ein unterstütztes MSIX gibt, ist Arbeit, die Sie schlicht nicht machen müssen.

Wenn Sie unsicher sind, führen Sie die Konvertierung trotzdem durch, aber setzen Sie ein Zeitlimit. Das Scheitern wird offensichtlich sein.

Sechs Schritte, eine Schleife: eine fehlgeschlagene Diagnose schickt Sie zurück zum Snapshot, nicht vorwärts mit einem geflickten Paket.

Schritt 1: ein wirklich sauberer Rechner

Das ist der Schritt, den Leute überspringen und für den sie dann bezahlen.

Die Erfassung funktioniert, indem der Rechner vor und nach der Installation verglichen wird. Alles, was bereits vorhanden ist, ist für diesen Vergleich unsichtbar, sodass ein Rechner, auf dem die Abhängigkeiten der Anwendung bereits installiert sind, ein Paket erzeugt, das auf Ihrem Rechner funktioniert und sonst nirgends.

Nutzen Sie eine frische virtuelle Maschine, die zum Ziel-Windows-Build passt, auf der außer dem Betriebssystem nichts ist. Nehmen Sie vor dem Start einen Snapshot, damit Sie zu einem bekannten Zustand zurückkehren können, denn Sie werden das mehr als einmal tun.

Zwei Details machen den Unterschied zwischen einer sauberen und einer verrauschten Erfassung:

• Beruhigen Sie den Rechner zuerst. Windows Update, Sicherheitsdefinitionen und Store-App-Updates schreiben alle auf die Festplatte, während Ihre Erfassung läuft, und jeder dieser Schreibvorgänge wird Teil des Pakets. Lassen Sie den Rechner seine ersten Updates abschließen, pausieren Sie sie und nehmen Sie dann den Snapshot.
• Passen Sie den Build an, nicht nur die Version. Auf einem neueren Windows-Build zu erfassen, als Ihre Flotte betreibt, backt Redistributables und Framework-Versionen ein, die dort vorhanden und auf dem Ziel nicht vorhanden sind. Erfassen Sie auf dem ältesten Build, den Sie unterstützen.

Ein Erfassungsversuch auf einem Rechner, der eine fehlgeschlagene Installation trägt, ist wertlos, also setzen Sie vor jedem erneuten Versuch zurück.

Schritt 2: die Installation erfassen

Nehmen Sie die Baseline, führen Sie den Installer genau so aus, wie es ein Benutzer täte, und schließen Sie dann die Erfassung ab.

Zwei Dinge lohnen sich während der Installation:

Starten Sie die Anwendung einmal, bevor Sie die Erfassung abschließen. Viele Anwendungen führen eine Ersteinrichtung durch: Konfiguration anlegen, Registry-Standardwerte schreiben, Ressourcen entpacken. Wenn Sie erfassen, bevor das passiert, paketieren Sie eine Anwendung, die nie initialisiert wurde, und sie führt ihren ersten Lauf im Container durch, wo der Schreibvorgang möglicherweise nicht bestehen bleibt.

Notieren Sie alles, wonach der Installer Sie fragt. Lizenzschlüssel, Serveradressen, Installationsorte. Diese Entscheidungen sind jetzt im Paket eingebacken, und wenn sie falsch waren, bauen Sie neu.

Sie legen hier auch die Paketidentität fest, und die ist später umständlich zu ändern:

<Identity Name="Contoso.LineOfBusinessApp"
          Publisher="CN=Contoso Ltd, O=Contoso Ltd, C=GB"
          Version="1.0.0.0" />

Publisher ist das Entscheidende: Es muss Zeichen für Zeichen dem Antragsteller Ihres Signaturzertifikats entsprechen, entscheiden Sie es also jetzt, statt in Schritt vier eine Abweichung zu entdecken. Version ist eine vierteilige Nummer und die Bereitstellung achtet darauf, dass sie steigt, also legen Sie eine Konvention fest und schreiben Sie sie auf.

Wenn es überhaupt keinen Installer gibt, ist die Erfassung nicht Ihr Weg: Neu paketieren ohne den Original-Installer behandelt stattdessen diesen Fall.

Schritt 3: rechnen Sie mit Fehlverhalten und diagnostizieren Sie sauber

Das Paket wird sich installieren. Dann wird etwas nicht stimmen.

Fangen Sie nicht an, Fixes auf Verdacht anzuwenden. Reproduzieren Sie das Problem als Standardbenutzer, finden Sie heraus, wonach die Anwendung tatsächlich verlangt, und ordnen Sie das Symptom einer konkreten Ursache zu. Diese Zuordnung haben wir in welches PSF-Fixup brauche ich behandelt, und die Kurzfassung lautet: Prüfen Sie das Arbeitsverzeichnis, bevor Sie zu irgendetwas anderem greifen, denn es ist die mit Abstand häufigste Ursache.

Zwei Gewohnheiten halten das kurz. Reproduzieren Sie als Standardbenutzer, denn vieles an gemeldeten MSIX-Störungen ist eine Berechtigungsannahme, die schon immer in der Anwendung steckte und dadurch verdeckt war, dass alle als lokale Administratoren arbeiteten. Schauen Sie dann nach, wohin der Container den Schreibvorgang gelegt hat: benutzerspezifische Daten landen unter %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalCache, und die Datei dort zu finden beweist, dass der Schreibvorgang erfolgreich war und die Anwendung an der alten Stelle sucht.

Wenden Sie eine Änderung nach der anderen an und testen Sie erneut. Ein Paket mit vier Fixups, wo eines nötig war, ist ein Paket, das niemand pflegen wird.

Wenn das dritte Fixup es nicht geregelt hat, überdenken Sie das Ziel. Eine Legacy-Anwendung zu MSIX konvertieren behandelt diese Entscheidung, und es ist keine Schande, eine sperrige Anwendung anders auszuliefern.

Schritt 4: signieren

Ein unsigniertes MSIX lässt sich auf einem verwalteten Gerät nicht installieren. Das ist nicht optional, und hier hören viele erste Versuche auf.

Sie brauchen ein Code-Signing-Zertifikat, dessen Antragsteller exakt dem Publisher im Paketmanifest entspricht. Nicht ungefähr. Exakt. Eine Abweichung hier erzeugt einen Installationsfehler, dessen Meldung das Zertifikat gar nicht erwähnt, weshalb es Leute einen Nachmittag kostet. Vergleichen Sie die beiden direkt, bevor Sie signieren:

Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert |
  Select-Object Subject, Thumbprint, NotAfter

Was unter Subject zurückkommt, gehört in das Manifest-Feld Publisher, einschließlich der Reihenfolge und der Abstände der relativen definierten Namen. Kopieren Sie es, statt es abzutippen.

Signieren Sie aus dem Zertifikatspeicher über den Fingerabdruck, statt eine PFX-Datei zu handhaben, und nutzen Sie einen RFC 3161 Zeitstempelserver. Ohne Zeitstempel besteht das Paket die Prüfung nicht mehr, sobald das Zertifikat abläuft, obwohl es rechtmäßig signiert wurde, während dieses Zertifikat gültig war.

signtool sign /sha1 <thumbprint> /fd SHA256 /tr <your RFC 3161 timestamp URL> /td SHA256 .\ContosoApp.msix

Noch eine Sache erwischt interne Zertifikate: Das Zertifikat muss auf dem Gerät vertrauenswürdig sein, das das Paket installiert. Eine öffentliche Zertifizierungsstelle kettet bereits zu einer Wurzel, der Windows vertraut; Ihre eigene interne Zertifizierungsstelle oder ein selbstsigniertes Testzertifikat tut das nicht, also muss es zuerst in den Vertrauensspeicher des Geräts gelangen. Verteilen Sie es über Ihre normale Zertifikatsverwaltung, nicht von Hand auf einem Testrechner, sonst besteht Ihre Prüfung auf dem einzigen Gerät, auf dem sie es könnte.

Schritt 5: prüfen, bevor Sie ausliefern

Prüfen Sie das Paket und behandeln Sie einen Exit-Code ungleich null als Stopp. Es ist viel günstiger, ein fehlerhaftes Manifest jetzt zu finden als nachdem es einen Testring erreicht hat.

Bestätigen Sie, dass Signatur und Zeitstempel ebenfalls gelandet sind:

Get-AuthenticodeSignature .\ContosoApp.msix |
  Format-List Status, SignerCertificate, TimeStamperCertificate

Status sollte Valid lauten und TimeStamperCertificate sollte nicht leer sein. Ein leeres Zeitstempelfeld ist ein Paket, das sich an einem künftigen Datum ohne sichtbaren Grund nicht mehr installieren lässt.

Installieren Sie es dann tatsächlich auf einem sauberen Rechner, als Standardbenutzer, und prüfen Sie:

• Es startet.
• Es behält Einstellungen über einen Neustart hinweg.
• Es deinstalliert sauber und lässt nichts zurück.

Add-AppxPackage .\ContosoApp.msix
Get-AppxPackage -Name Contoso.LineOfBusinessApp | Select-Object Name, Version, PackageFullName
Remove-AppxPackage -Package <PackageFullName>

Letzteres ist der Sinn von MSIX. Wenn die Deinstallation Reste hinterlässt, wird etwas außerhalb des Containers geschrieben und Sie sind nicht fertig.

Fügen Sie eine vierte Prüfung hinzu, wenn Leute die Anwendung den ganzen Tag offen lassen: installieren, starten, dann eine erhöhte Version darüber installieren. Updates werden bereitgestellt, während die Anwendung läuft, und beim nächsten Start angewendet, sodass ein Benutzer, der sie nie schließt, das Update nie bekommt. Kein Fehler, aber ein Supportanruf, wenn niemand damit gerechnet hat.

Schritt 6: über Intune bereitstellen

Paketieren Sie das MSIX für Intune und weisen Sie es zu. Im Intune Admin Center ist das Apps, Alle Apps, Hinzufügen, dann der App-Typ Branchenanwendung, der die .msix-Datei direkt annimmt. Weisen Sie es zuerst als erforderlich einer Pilotgruppe zu und als verfügbar allen, sobald der Pilot gehalten hat.

Wissenswert: So bereitgestelltes MSIX aktualisiert sich über die Version, sodass Ihr Versionsschema jetzt zählt. Machen Sie es einmal falsch, und Geräte lehnen das Update ab, weil die Version nicht gestiegen ist. Beobachten Sie den Installationsstatus pro Gerät, statt der Zuweisung zu vertrauen, und beachten Sie, dass ein Gerät, das bereits eine mit einem anderen Publisher signierte Kopie trägt, die verwaltete ablehnt, weil es für Windows verschiedene Anwendungen sind.

Wohin die Zeit tatsächlich geht

Nicht in die Konvertierung. Die Konvertierung dauert Minuten. Die Zeit geht in die Disziplin des sauberen Rechners, in die Diagnose, wenn sich die Anwendung fehlerhaft verhält, und in die Signaturkonfiguration. Eine Anwendung zu machen lehrt Sie das Muster. Vierhundert zu machen ist ein anderes Problem und der Grund, warum Anwendungspaketierung eine Spezialistenaufgabe bleibt.

Der Unterschied liegt nicht im Aufwand pro Anwendung, sondern in der Konsistenz: ob jedes Paket auf demselben Build erfasst, auf dieselbe Weise signiert und seine Fixup-Entscheidungen irgendwo anders festgehalten wurden als im Gedächtnis einer Person. Das ist eher ein Workflow-Problem als ein Packaging-Problem, und deshalb landen Umgebungen bei Paketen, die niemand neu zu bauen wagt.

Wo EtherApps Forge ansetzt

EtherApps Forge ist für den Vierhundert-Fall gebaut: erfassen, routen, die Fixups vorbereiten, signieren und prüfen als ein Ablauf statt sechs Werkzeuge und ein Runbook. Entscheidungen werden mit dem Paket festgehalten statt erinnert, und genau das macht den zweiten Durchgang durch eine Umgebung günstiger als den ersten.

Es ist eine Windows-Desktop-Anwendung und kein gehosteter Dienst, sodass Erfassung und Signierung in Ihrer Umgebung bleiben, und es läuft mit einer kostenlosen 7-tägigen Testversion. Wenn Sie eigene Builds ausliefern, statt den Installer eines anderen zu erfassen, beginnt der Weg stattdessen bei einem Build-Ordner: MSIX-Paketierung für Entwickler und ISVs behandelt das, und MSIX in CI/CD ohne das Windows SDK bauen und signieren zeigt die Form der Pipeline. Für den Blick über die gesamte Umgebung läuft MSIX Packaging und Deployment von der Erfassung bis zur Auslieferung.

MSIX Packaging und Deployment entdecken, um zu sehen, wie Erfassung, Behebung, Signierung und Auslieferung als ein Ablauf statt als sechs laufen.