Zum Inhalt
Kaffeeundcode

App-Paketierung mit PSADT und Intune

Einleitung

Eine Anwendung in Intune zu bringen ist kein Upload. Es sind vier Entscheidungen: Welche Installationsdatei, welche stillen Parameter, woran erkennt Intune die Installation, und was passiert beim Deinstallieren. Wer eine davon offen lässt, bekommt ein Paket, das auf dem Testgerät läuft und auf dem ersten echten Client scheitert.

Diese Seite ist der Einstieg in die Paketierung. Sie führt durch den Ablauf, verlinkt die Detailsektionen des Intune-Kurses und nennt die Stellen, an denen Pakete in der Praxis typisch hängen bleiben.

Sektion 31 starten

Wann du paketieren musst — und wann nicht

Ein Win32-Paket braucht man, wenn der Hersteller nur eine EXE oder MSI liefert und die Installation Argumente, Rückgabecodes oder eine eigene Deinstallationsroutine hat. Für Apps, die im Enterprise App Catalog oder als Store-App bereitstehen, ist der Umweg über ein eigenes Paket meist unnötig — Sektion 44 zeigt, wann sich das trotzdem lohnt und wann nicht.

Der Ablauf in fünf Schritten

  1. Quelle prüfen. Installer, Version, Hersteller-Silent-Switches aus der Herstellerdoku.
  2. Packen. Aus dem Quellordner wird per IntuneWinAppUtil eine .intunewin-Datei.
  3. Kommandozeilen festlegen. Install und Uninstall getrennt, jeweils mit vollständigem Pfad.
  4. Detection definieren. Nicht „Datei existiert“, sondern „Datei existiert an diesem Pfad mit dieser Version“.
  5. Testen. Auf einem frischen Gerät installieren, deinstallieren, neu installieren.

Die Schritte 2 bis 4 sind die Sektionen 32 bis 34. Schritt 5 ist der, den man nicht abkürzen kann.

Detection: der Punkt, an dem die meisten Pakete scheitern

Drei Wege sind üblich: Registry-Schlüssel, Dateiprüfung, eigenes PowerShell-Skript. Alle drei funktionieren — wenn sie den Zustand abbilden, den der Installer wirklich hinterlässt. Zwei typische Fehler: ein 32-Bit-Pfad in einem 64-Bit-Prozess, und eine Versionsprüfung, die bei jedem Update nachgezogen werden muss.

Details, inklusive der Frage, wann ein Skript die richtige Wahl ist: Detection Methods: Registry, Datei, Skript

PSADT: wann sich der Wrapper lohnt

Das PowerShell App Deployment Toolkit ist sinnvoll, sobald ein Paket mehr tut als „MSI aufrufen und fertig“: Prozesse beenden, Vorgängerversion entfernen, Konfiguration nachziehen, dem Nutzer einen Hinweis zeigen. Der Preis ist eine zusätzliche Schicht, die man verstehen und testen muss.

Für einfache Pakete reicht der direkte Weg. Für alles darüber ist PSADT die robustere Basis — mit Deploy-Application.ps1 als festem Vertrag und einheitlichen Exit-Codes.

Komplexe Installer und Abhängigkeiten

SQL Express, Office, Treiberpakete: Sobald ein Paket eine Vorbedingung hat, wird die Reihenfolge zum Teil der Lösung. Dependencies und Supersedence sind dafür da — aber sie sind kein Ersatz für ein Paket, das seinen eigenen Zustand kennt.

Wenn es nicht läuft

Der Intune Management Extension Log liegt auf dem Client unter C:ProgramDataMicrosoftIntuneManagementExtensionLogs. Wer dort zuerst schaut, spart sich die Hälfte der Fehlersuche. Die Client-Seite ist in Sektion 41 beschrieben, die Zuweisungslogik in Sektion 45.

Alle Sektionen und Beiträge zum Thema

Die folgenden 19 Beiträge decken den Weg von der Quelle bis zum Rollout ab. Sie sind nach Sektionen des Intune-Kurses und ergänzenden Praxisbeiträgen sortiert.

Sektionen 31–38 und 41–45

Ergänzende Praxisbeiträge

Der komplette Intune-Kurs

Der komplette Weg von Tenant bis Rollout steht im vollständigen Intune-Kurs — 45 Sektionen, kostenlos.