So paketieren Sie eine PSADT v4 App für Intune

Das PowerShell App Deployment Toolkit und Intune sind ein gutes Gespann: PSADT übernimmt die unangenehmen Teile der Installation einer Windows-Anwendung, und Intune übernimmt es, sie auf die Geräte zu bringen. Die Kette dazwischen ist die Stelle, an der Teams Zeit verlieren, denn die beiden haben unterschiedliche Auffassungen von Ordnerstruktur, Exit-Codes und davon, was als Erfolg zählt.

Dies behandelt speziell v4. Wenn Sie einer Anleitung folgen, die für v3 geschrieben wurde, hat sich die Befehlssyntax geändert, und Sie erhalten Fehler, die wie Packaging-Probleme aussehen, es aber nicht sind.

Die Kurzfassung: Halten Sie die Ordnerstruktur des Toolkits intakt, benennen Sie seinen Einstiegspunkt als Setup-Datei, wenn Sie die .intunewin erstellen, spiegeln Sie den Install-Befehl im Uninstall-Befehl, wählen Sie eine Erkennungsregel, die eine Version von einer anderen unterscheiden kann, und bilden Sie die Neustart- und Wiederholungs-Exit-Codes ab.

Warum überhaupt, wenn es doch MSIX gibt

Weil viele Anwendungen keine MSIX-Kandidaten sind. Alles, was einen Treiber oder einen Systemdienst installiert, alles, was echte maschinenweite Schreibvorgänge braucht, alles mit einem Installer, der darauf besteht, ein Installer zu sein. MSIX ist das richtige Ziel, wenn es passt, und PSADT ist die richtige Antwort, wenn nicht.

PSADT gibt Ihnen außerdem Dinge, die MSIX nicht bietet: Benutzerhinweise vor einem Neustart, das saubere Schließen laufender Anwendungen, Aufschübe und Protokolle, die ein Service Desk tatsächlich lesen kann.

Die Entscheidung fällt meist schnell:

• Installiert sie einen Kernel-Mode-Treiber oder einen maschinenweiten Dienst, von dem andere Software abhängt? Nehmen Sie PSADT.
• Liest eine andere Anwendung das, was sie außerhalb ihres eigenen Ordners schreibt? Die Container-Umleitung verbirgt diesen Schreibvorgang, was wie eine Lösung aussieht und keine ist.
• Muss sie ein offenes Dokument schließen oder vor einem Neustart einen Aufschub anbieten? PSADTs Heimspiel, ohne MSIX-Entsprechung.
• Nichts davon, und der Installer verhält sich anständig? Versuchen Sie zuerst MSIX. Eine EXE zu MSIX konvertieren geht diesen Weg durch.

Aus einem PSADT-Quellordner wird eine intunewin-Datei, und vier Intune-Einstellungen entscheiden, ob es funktioniert.

Schritt 1: die Ordnerstruktur richtig hinbekommen

Das Packaging-Tool von Intune nimmt einen Quellordner und erzeugt eine einzelne .intunewin-Datei. Es bündelt alles in diesem Ordner, also kommt es auf das Layout an.

Halten Sie die PSADT-Struktur intakt. Das Toolkit erwartet seine eigenen Ordner an bekannten Stellen und findet seine Ressourcen nicht, wenn Sie sie verflachen oder umsortieren. Legen Sie den Installer der Anwendung in den Files-Ordner des Toolkits, lassen Sie den Rest unangetastet und richten Sie das Packaging-Tool auf die Spitze dieser Struktur.

In v4 sieht das funktionierende Layout so aus, wobei Ihr Installer das Einzige ist, was Sie hinzufügen:

ContosoApp\
  Invoke-AppDeployToolkit.ps1
  Invoke-AppDeployToolkit.exe
  PSAppDeployToolkit\
  Config\
  Strings\
  Files\
    ContosoAppSetup.exe
  SupportFiles\

Erstellen Sie das Paket dann mit dem Microsoft Win32 Content Prep Tool:

IntuneWinAppUtil.exe -c C:\Packaging\ContosoApp -s Invoke-AppDeployToolkit.exe -o C:\Packaging\Output

Die Setup-Datei, die Sie benennen, sollte das Bereitstellungsskript sein, nicht der Installer der Anwendung selbst. Das ist der mit Abstand häufigste Fehler. Wenn Sie die Hersteller-EXE benennen, entsteht ein Paket, das Ihren PSADT-Wrapper vollständig ignoriert, was verwirrend ist, weil es zu funktionieren scheint.

Zwei Grenzen sind es wert, bekannt zu sein. Eine Intune Win32 App ist auf 8 GB begrenzt, und das Tool verschlüsselt den Ordner in eine einzelne undurchsichtige Datei, sodass Sie danach keine einzelne Zeile des Bereitstellungsskripts mehr korrigieren können. Halten Sie den Quellordner in der Versionsverwaltung und behandeln Sie die .intunewin als Build-Artefakt.

Schritt 2: die Install- und Uninstall-Befehle

In v4 hat sich der Aufruf geändert. Das Bereitstellungsskript und seine Wrapper-Programmdatei wurden umbenannt, und die Funktionsnamen des Toolkits änderten sich mit ihnen, sodass eine v3-Befehlszeile eine Datei benennt, die es nicht mehr gibt. Eine solche in eine Intune App zu kopieren, führt zu einem sofortigen Fehlschlag mit einer wenig hilfreichen Meldung. Die Befehle, die Sie wollen, sind diese:

Invoke-AppDeployToolkit.exe -DeploymentType Install -DeployMode Silent
Invoke-AppDeployToolkit.exe -DeploymentType Uninstall -DeployMode Silent

Zwei Dinge, die stimmen müssen:

Führen Sie es unbeaufsichtigt aus. Interaktive Eingabeaufforderungen haben keinen Ort, an dem sie erscheinen könnten, wenn Intune das Paket im Systemkontext ausführt, und die Installation bleibt hängen, statt sauber fehlzuschlagen.

Passen Sie den Uninstall-Befehl an den Install-Befehl an. Intune wird ihn nutzen, und eine Deinstallation, die nicht funktioniert, macht aus einer einfachen Änderung der App-Zuweisung einen manuellen Besuch am Gerät.

Bevorzugen Sie die mitgelieferte Programmdatei gegenüber einem eigenen Aufruf von powershell.exe: Sie kümmert sich um die Architektur des PowerShell-Hosts. Die Intune Management Extension ist ein 32-Bit-Prozess, wenn Sie PowerShell also direkt aufrufen, wird %windir%\System32 auf SysWOW64 umgeleitet und Sie brauchen %windir%\Sysnative\WindowsPowerShell\v1.0\powershell.exe, um den 64-Bit-Host zu erreichen.

Testen Sie beide Befehle im Systemkontext, bevor Sie irgendetwas paketieren. Ein Lauf unter Ihrem eigenen Administratorkonto beweist weniger, als Sie denken, denn Ihr Profil trägt Umgebungsvariablen und Zertifikatsvertrauen, die SYSTEM nicht hat:

PsExec.exe -s -i cmd.exe

Führen Sie die Installation aus, dann die Deinstallation, und lesen Sie die Protokolle, bevor Sie sich Intune nähern. PSADT schreibt standardmäßig nach C:\Windows\Logs\Software; die Intune-Seite liegt in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. Zusammen sagen sie Ihnen, ob das Problem beim Paket oder bei der Zuweisung lag.

Schritt 3: Erkennungsregeln, wo es wirklich schiefgeht

Intune entscheidet anhand der Erkennungsregel, ob die Anwendung installiert ist, nicht durch Nachfragen beim Paket. Machen Sie das falsch, passiert eines von zwei Dingen: Intune installiert die Anwendung bei jedem Check-in neu, oder Intune glaubt, sie sei installiert, obwohl sie es nicht ist.

Wählen Sie eine Erkennungsmethode, die spezifisch für die Version ist, die Sie bereitstellen:

• Eine Dateiversionsprüfung an der Haupt-Programmdatei der Anwendung ist meist die verlässlichste. Zeigen Sie auf den echten Installationspfad, wählen Sie den Versionsvergleich statt der bloßen Existenz und vergleichen Sie mit größer oder gleich der Version, die Sie ausliefern.
• Eine Registry-Prüfung am Uninstall-Schlüssel funktioniert gut, wenn der Hersteller eine sinnvolle DisplayVersion schreibt. Bei einer 32-Bit-Anwendung auf 64-Bit-Windows liegt dieser Schlüssel unter WOW6432Node, und Intune hat dafür einen eigenen Schalter. Das zu vergessen, ist eine sehr häufige Ursache dafür, dass eine Anwendung sich einwandfrei installiert und dennoch als nicht installiert gemeldet wird.
• Ein eigenes Erkennungsskript, wenn der Zustand wirklich komplexer ist als eine Datei oder ein Wert. Intune betrachtet die Anwendung nur dann als erkannt, wenn das Skript mit 0 endet und etwas in die Standardausgabe schreibt. Ein Skript, das still mit 0 endet, meldet nicht erkannt.
• Eine reine Dateiexistenzprüfung ist eine Falle. Sie kann Version 1 nicht von Version 2 unterscheiden, sodass Upgrades stillschweigend nie stattfinden.

Die Fehlersignatur, die Sie erkennen sollten, ist 0x87D00324, die Anwendung wird nach einer als erfolgreich gemeldeten Installation nicht erkannt. Sie bedeutet selten, dass die Installation fehlgeschlagen ist. Sie bedeutet, dass die Erkennungsregel an der falschen Stelle, in der falschen Bitness oder nach dem Falschen sucht.

Was auch immer Sie wählen, verifizieren Sie es gegen einen Rechner, auf dem die Anwendung wirklich fehlt, und einen, auf dem sie wirklich vorhanden ist. Beide Fälle, jedes Mal.

Schritt 4: Exit-Codes

PSADT gibt aussagekräftige Exit-Codes zurück, und Intune hat seine eigenen Auffassungen davon, welche davon Erfolg bedeuten.

Intune liefert eine Standardzuordnung mit, die das meiste abdeckt, was Sie brauchen: 0 und 1707 sind Erfolg, 3010 ist ein weicher Neustart, 1641 ist ein harter Neustart und 1618 ist eine Wiederholung. Der Fehler besteht darin, diese Standardwerte zu löschen, wenn Sie einen eigenen Code hinzufügen. Ergänzen Sie die Liste, ersetzen Sie sie nicht.

Am wichtigsten ist der Code für den weichen Neustart. Wenn eine Bereitstellung einen Neustart braucht und Intune nicht weiß, dass dieser Code Erfolg mit ausstehendem Neustart bedeutet, wird die App als fehlgeschlagen angezeigt und Intune versucht es erneut. Konfigurieren Sie die Rückgabecodes so, dass ein Ergebnis mit ausstehendem Neustart als Erfolg mit erforderlichem Neustart behandelt wird.

Der zweite ist Exit-Code 1618, eine weitere Installation ist im Gange. Behandeln Sie ihn als Wiederholung statt als Fehlschlag: Er ist vorübergehend und häufig auf frisch bereitgestellten Geräten, auf denen mehrere Anwendungen gleichzeitig landen.

Zwei weitere für die Liste. PSADT reserviert einen Block von Codes im Bereich 60000 für Ergebnisse auf Toolkit-Ebene, etwa wenn ein Benutzer über das erlaubte Fenster hinaus aufschiebt: Das sind keine Anwendungsfehler, und sie auf Fehlschlag abzubilden, erzeugt ein Dashboard, dem niemand traut. Und 1603 ist der generische schwere Fehler von Windows Installer, der für sich genommen nichts aussagt, lesen Sie also stattdessen das PSADT-Protokoll.

Schritt 5: die ganze Kette testen

Auf einem sauberen Gerät, im selben Kontext, den Intune nutzen wird:

1. Installieren. Bestätigen Sie, dass es gelingt und die Erkennungsregel es als vorhanden meldet.
2. Neu starten und bestätigen, dass es das übersteht.
3. Über Intune deinstallieren und bestätigen, dass die Erkennungsregel es als abwesend meldet.
4. Erneut darüber installieren, um das Upgrade-Verhalten zu prüfen.

Schritt vier ist der, den alle überspringen, und der, der sechs Monate später Support-Tickets erzeugt.

Zwei Ergänzungen. Wenn Sie eine neuere Version von etwas ausliefern, das bereits bereitgestellt ist, nutzen Sie Supersedence statt einer zweiten App: Zwei Apps, die dieselbe Programmdatei beanspruchen, streiten sich um die Erkennung, und das Gerät verliert. Und wenn die Anwendung während der Geräteeinrichtung als erforderlich zugewiesen ist, testen Sie sie hinter der Enrollment Status Page, wo alles, was höflich wartet, die erste Anmeldung eines Benutzers blockiert.

Das wiederholt tun

Für eine Anwendung ist das eine Stunde. Für einen Katalog ist es eine Fertigungsstraße, und die interessante Frage ist nicht mehr, wie man eine Anwendung paketiert, sondern welchen Packaging-Weg jede Anwendung nehmen sollte. Manche sind MSIX-Kandidaten. Manche sind PSADT. Manche sollte man in Ruhe lassen.

Diese Weichenstellung ist der Teil, der nicht durch Einstellungen skaliert. Anwendung für Anwendung von dem getroffen, der in der Woche gerade frei ist, erzeugt sie eine Umgebung, die niemand erklären kann. Nach konsistenten Kriterien getroffen und aufgeschrieben, wird sie zu einer Bestandsaufnahme, gegen die Sie planen können, was die Grundlage der Arbeit an Anwendungsmodernisierung und -migration ist.

Wo EtherApps Forge ansetzt

EtherApps Forge trifft diese Weichenstellung ausdrücklich und erzeugt MSIX-, MSI-, PSADT- und Intune-fertige Ausgaben aus derselben Erfassung, sodass die Wahl festgehalten statt pro Anwendung neu ausdiskutiert wird. Es ist eine Windows-Desktopanwendung mit einer 7-tägigen Testversion, sodass Erfassungen und Packaging in Ihrer eigenen Umgebung bleiben.

Die eher fummeligen als schwierigen Teile dieses Artikels sind die, die sich zu automatisieren lohnen: jedes Mal dasselbe Ordnerlayout, zueinander passende Install- und Uninstall-Befehle und eine Aufzeichnung, warum eine Anwendung als PSADT statt als MSIX endete. Wo eine sauber konvertiert und sich dann im Container fehlerhaft verhält, behandelt welches PSF-Fixup brauche ich die Diagnose, und Legacy-Windows-Anwendungen modernisieren behandelt die Bewertung davor.

Wenn Sie Ihre eigenen Builds paketieren statt die von anderen, ist der Weg für Entwickler und ISVs der passende, und MSIX in CI ohne das Windows SDK bauen behandelt die Pipeline-Seite.

Anwendungsmodernisierung und -migration entdecken

Eine Anwendung gut zu paketieren ist eine Fertigkeit; vierhundert konsistent zu paketieren ist eine Entscheidungsdokumentation, und das ist der Teil, den aufzubauen sich lohnt.