App-V zu MSIX: die vier Dinge, die jedes Mal brechen

App-V Pakete nach MSIX zu konvertieren ist größtenteils mechanisch, bis es das nicht mehr ist. Vier Dinge machen die überwältigende Mehrheit der Meldungen nach dem Muster "es hat sauber konvertiert und verhält sich jetzt merkwürdig" aus, und es sind jedes Mal dieselben vier.

Es lohnt sich, sie vor dem Start zu kennen, denn jedes einzelne ist billig, wenn man es bewusst behandelt, und teuer, wenn man es erst im Testring entdeckt.

Der zugrunde liegende Grund ist in allen vier Fällen derselbe: App-V virtualisierte Dinge, die App-V kontrollierte, und MSIX kapselt sie anders. Alles, wofür sich die Anwendung auf App-V verlassen hat, braucht eine neue Antwort. Nichts davon ist ein Fehler in MSIX. Die beiden Formate ziehen die Grenze zwischen Paket und Umgebung schlicht an unterschiedlichen Stellen.

Öffnen Sie das Paket, bevor Sie es konvertieren

Ein App-V 5 Paket ist nicht undurchsichtig. Die .appv-Datei ist ein OPC-Container, praktisch ein ZIP mit einem Manifest darin, sodass alles, was Sie brauchen, lesbar ist, bevor ein Konvertierungswerkzeug es anfasst.

Drei Dateien tragen das Verhalten:

• AppxManifest.xml, innerhalb der .appv, enthält die Standardwerte, die beim Sequenzieren der Anwendung entstanden sind.
• <PackageName>_DeploymentConfig.xml trägt maschinenweite Einstellungen und Skripte im Maschinenkontext.
• <PackageName>_UserConfig.xml trägt benutzerspezifische Einstellungen und Skripte im Benutzerkontext.

Die Rangfolge lautet UserConfig vor DeploymentConfig vor dem Manifest, sodass eine Einstellung in allen dreien mit verschiedenen Werten auftauchen kann und nur eine aktiv ist. Lesen Sie nur das Manifest, entgehen Ihnen die später hinzugefügten Anpassungen, die die Anwendung zum Laufen brachten, und genau die sind die tragenden.

Das Extrahieren dauert Sekunden:

Copy-Item .\LineOfBusinessApp.appv .\LineOfBusinessApp.zip
Expand-Archive .\LineOfBusinessApp.zip -DestinationPath .\LineOfBusinessApp
Select-Xml -Path .\LineOfBusinessApp\AppxManifest.xml -XPath '//*[local-name()="EnvironmentVariables" or local-name()="Shortcut" or local-name()="FileTypeAssociation"]' | ForEach-Object { $_.Node.OuterXml }

Lesen Sie zuerst alle drei Konfigurationsquellen, dann leiten Sie jeden Befund dorthin, wo er jetzt hingehört.

1. Umgebungsvariablen

App-V erlaubte es, Umgebungsvariablen im Paket zu definieren, und die Anwendung sah sie innerhalb ihrer virtuellen Umgebung. Sie liegen in einem <EnvironmentVariables> Subsystem, und beide Konfigurationsdateien können sie hinzufügen oder löschen:

<EnvironmentVariables Enabled="true">
  <Include>
    <Variable Name="LOBAPP_DATA" Value="%UserProfile%\LineOfBusinessApp" />
  </Include>
</EnvironmentVariables>

MSIX handhabt das anders, und die in App-V deklarierten Variablen kommen nicht an. Eine Anwendung, die eine Variable liest, um einen Datenpfad, einen Servernamen oder einen Lizenzort zu finden, startet und verhält sich, als wäre sie nie konfiguriert worden. Sie funktioniert, sie weiß nur nichts.

Was zu tun ist: Erfassen Sie die vom Paket deklarierten Variablen, bevor Sie konvertieren. Diesen Schritt überspringen viele, weil die Variablen in der eigenen Konfiguration der Anwendung nicht sichtbar sind. Entscheiden Sie dann für jede einzelne: eine Variable auf Maschinen- oder Benutzerebene, die Ihre Deployment-Werkzeuge setzen, ein Wert in einer Konfigurationsdatei, die die Anwendung liest, oder etwas, das ein Startskript zuerst setzt.

Die Fehlersignatur ist eine Anwendung, die sauber startet und sich dann über einen fehlenden Server oder Pfad beschwert. Achten Sie auf die leisere Variante, bei der sie auf einen eingebauten Standardwert zurückfällt, statt einen Fehler zu melden, und Wochen später auftaucht.

2. Verknüpfungen

App-V Pakete trugen ihre Verknüpfungsdefinitionen vollständig mit sich. Das <Shortcut> Element benennt die zu erzeugende .lnk-Datei, ihr <Target>, <Icon>, <Arguments>, <WorkingDirectory> und <Description>, sodass ein sequenziertes Paket reproduzierte, was der Installer im Startmenü abgelegt hatte.

MSIX erzeugt seinen Eintrag stattdessen aus dem Paketmanifest, und das Ergebnis ist nicht immer das, was App-V hervorbrachte. Die Verknüpfung landet anderswo, das Symbol ist falsch oder fehlt, oder die Kommandozeilenargumente sind verschwunden.

Das letzte ist das gefährliche. Wenn die App-V Verknüpfung ein Argument übergab, das die Anwendung in einen bestimmten Modus versetzte, und der MSIX-Eintrag das nicht tut, bekommen Anwender eine Anwendung, die im falschen Zustand öffnet, statt einer, die sichtbar scheitert. Dieselbe Anwendung zweimal zu veröffentlichen, als "Finanzen" und als "Nur lesen", wobei der Unterschied vollständig in einem Schalter steckt, ist häufiger, als Ihnen lieb ist.

Was zu tun ist: Erfassen Sie die vollständige Verknüpfungsdefinition einschließlich Argumenten und Arbeitsverzeichnis und bilden Sie sie bewusst nach. Wo ein Argument tatsächlich zwei Betriebsarten der Anwendung unterscheidet, werden daraus meist zwei Anwendungseinträge im Manifest.

Prüfen Sie speziell das Arbeitsverzeichnis. Setzt es niemand, verwendet Windows für eine paketierte Anwendung das System32 Verzeichnis, weshalb "sie findet ihre eigenen Dateien nicht" ein so häufiges erstes Symptom ist. Das Package Support Framework setzt es explizit mit einem workingDirectory Wert in config.json, dem am häufigsten angewandten Fixup nach einer Konvertierung. Welches PSF-Fixup brauche ich ordnet den Rest zu.

3. Skripte

Das ist der größte einzelne Unterschied und derjenige, der Migrationen entgleisen lässt.

App-V unterstützte Skripte an acht Punkten im Lebenszyklus, was erklärt, wie viel Logik Umgebungen unbemerkt ansammeln:

Lang laufende App-V Umgebungen haben oft echte Logik in diesen Skripten: ein Laufwerk verbinden, Konfiguration holen, einen temporären Ort aufräumen, etwas registrieren. Über ScriptRunner.exe können mehrere Skripte an einem Trigger hängen, sodass ein einzelner AddPackage Eintrag vier Dinge nacheinander ausführen kann.

MSIX bietet nicht dieselben Lebenszyklus-Hooks für Skripte. Das nächste Äquivalent ist das Package Support Framework, das ein PowerShell-Skript vor einer paketierten ausführbaren Datei und eines nach deren Beenden ausführt, je ausführbarer Datei als startScript und endScript in config.json festgelegt.

Das deckt StartProcess und ExitProcess ab. Die anderen sechs deckt es nicht ab. Alles, was beim Hinzufügen, Veröffentlichen, Aufheben der Veröffentlichung oder Entfernen lief, wandert in Ihre Deployment-Werkzeuge, das Einzige, das jetzt noch weiß, wann ein Paket ankommt oder verschwindet.

Was zu tun ist: Finden Sie die Skripte, bevor Sie konvertieren, und lesen Sie sie. Manche werden zu Installations- oder Deinstallationsverhalten in Intune oder Configuration Manager. Manche werden zu einem Startskript im Paket. Manche werden zu Anwendungskonfiguration. Manche doppeln, was die Plattform jetzt nativ erledigt, und können erleichtert gelöscht werden.

Zwei praktische Hinweise. Die Skriptausführung erfordert, dass die PowerShell-Ausführungsrichtlinie sowohl für den 64-Bit- als auch für den 32-Bit-Host auf RemoteSigned gesetzt ist. Und StartingScriptWrapper.ps1 muss im Paket neben der ausführbaren Datei liegen, sonst läuft nichts und nichts erklärt, warum.

Die Fehlersignatur ist hier die schlimmste der vier, denn die Anwendung funktioniert für die Person, die sie testet, perfekt, weil deren Laufwerk bereits verbunden war.

4. Dateitypzuordnungen

App-V registrierte Zuordnungen innerhalb seiner virtuellen Umgebung detailliert: die Erweiterung, ihre ProgId, die sprechenden Namen und Shell-Befehle mit eigenen Kommandozeilen, sodass ein Rechtsklick-Verb "Bearbeiten" die ausführbare Datei mit einem anderen Schalter starten konnte als "Öffnen".

MSIX deklariert sie im Manifest als Extension, und die Deklaration muss stimmen:

<uap:Extension Category="windows.fileTypeAssociation">
  <uap:FileTypeAssociation Name="lobdoc">
    <uap:SupportedFileTypes>
      <uap:FileType>.lob</uap:FileType>
    </uap:SupportedFileTypes>
  </uap:FileTypeAssociation>
</uap:Extension>

Vier Dinge gehen schief, grob in dieser Häufigkeitsreihenfolge.

Die Zuordnung wird überhaupt nicht deklariert, sodass ein Doppelklick auf eine Datei nichts Sinnvolles bewirkt.

Sie wird deklariert, aber Windows berücksichtigt sie nicht, weil eine andere Anwendung diese Erweiterung bereits besitzt und die Benutzerwahl gewinnt. Das Ergebnis funktioniert auf dem Packaging-Rechner und nicht auf dem Gerät eines echten Anwenders.

Der Name ist falsch. Er muss kleingeschrieben sein und sollte über Aktualisierungen hinweg stabil bleiben, denn er ist der Bezeichner, unter dem Windows die Dateitypen gruppiert.

Die Erweiterung ist reserviert. Windows hält Erweiterungen und URI-Schemata für eingebaute Anwendungen vor, und eine Registrierung für eine davon wird ignoriert statt abgelehnt, sodass es aussieht, als hätte die Deklaration nicht gegriffen.

Die benutzerdefinierten Verben sind der Teil, den man vergisst. Shell-Befehle über ein einfaches Öffnen hinaus überstehen die Reise nicht.

Was zu tun ist: Listen Sie die Erweiterungen auf, die das Paket registrierte, mit ihren ProgId Werten und etwaigen Shell-Befehlen, deklarieren Sie sie im Manifest und testen Sie auf einem Gerät, auf dem die Anwendungen eines echten Anwenders vorhanden sind, nicht auf einer sauberen virtuellen Maschine ohne konkurrierende Ansprüche.

Notieren Sie, solange Sie dabei sind, auch die URL-Protokolle, AppPaths, Software-Clients und COM-Einstellungen, die dieselben Dateien tragen. Ein lobapp:// Handler, der still verschwunden ist, ist ein verwirrendes Ticket.

Die Reihenfolge, die Zeit spart

Erledigen Sie die gesamte Erkundung, bevor Sie irgendetwas konvertieren:

1. Extrahieren Sie die vom Paket deklarierten Umgebungsvariablen aus allen drei Quellen.
2. Extrahieren Sie die Verknüpfungsdefinitionen einschließlich Argumenten und Arbeitsverzeichnis.
3. Extrahieren und lesen Sie die Skripte und notieren Sie, an welchem Trigger jedes hängt.
4. Listen Sie die Dateitypzuordnungen, ihre ProgId Werte und ihre Shell-Befehle auf.
5. Notieren Sie die übrigen Subsysteme: URL-Protokolle, AppPaths, Software-Clients, COM.

Notieren Sie neben jedem Befund die Entscheidung, nicht nur den Befund. "Setzt LOBAPP_DATA" ist eine Notiz. "Setzt LOBAPP_DATA, wird zu einer Benutzervariablen in der Intune-Bereitstellung" ist ein Plan.

Das ist höchstens eine Stunde je Anwendung, und es macht aus der Konvertierung statt einer Erkundung eine Umsetzung. Überspringen Sie es, und Sie finden jeden dieser Punkte im Testring, mit einem Anwender, der das Symptom meldet und nicht die Ursache.

Ein Beispiel. Eine Finanzanwendung konvertiert sauber, dann tauchen im Pilot zwei Dinge auf: Sie findet ihre Vorlagen nicht, weil das Paket eine Variable setzte, die auf eine Freigabe zeigte, und die Hälfte der Gruppe öffnet sie im falschen Modus, weil die App-V Verknüpfung einen Nur-lesen-Schalter übergab. Beides stand in _DeploymentConfig.xml, bevor irgendjemand irgendetwas konvertierte.

Dann konvertieren Sie und testen als Standardbenutzer auf einem Gerät, das einem echten ähnelt.

Wo das hineinpasst

Der weitere Migrationspfad, einschließlich der Frage, welche Pakete überhaupt zu MSIX werden sollten, steht in App-V-zu-MSIX-Migration. Ergänzend lesenswert: Der App-V Server endet, App-V nicht, denn der Zeitplan ist weniger dringend, als die meisten Berichte nahelegten, und das Überstürzen dieser Konvertierungen ist der Weg, auf dem die vier obigen Probleme in die Produktion gelangen.

Legacy-zu-MSIX-Konvertierung behandelt dieselben Container-Verhalten für Anwendungen, die nie durch App-V gegangen sind.

Wo EtherApps Forge ansetzt

EtherApps Forge erfasst Anwendungen aus älteren Umgebungen und plant die Behebung als Teil der Paketierung ein statt als separates Projekt danach, sodass die Arbeitsverzeichnis-Korrektur, die Dateiumleitung und das Startskript entschieden werden, während das Paket gebaut wird, und nicht erst, nachdem ein Pilot gescheitert ist.

Es ist eine Windows-Desktop-Anwendung mit einer kostenlosen 7-tägigen Testversion, kein gehosteter Dienst, sodass Erfassungen und Ausgaben in Ihrer Umgebung bleiben. Die Route Legacy-Apps deckt Discovery und Remediation ab, MSIX Packaging und Deployment deckt Signierung, Validierung und Auslieferung ab, und Anwendungsmodernisierung und Migration deckt ab, welche Anwendungen diesen Weg überhaupt gehen.

Legacy-Anwendungsmodernisierung entdecken

Beantworten Sie die vier Fragen, bevor Sie konvertieren, dann hört die Konvertierung auf, Überraschungen zu produzieren.