Sektion 32: IntuneWin App Packaging Tool: Schritt-für-Schritt Anleitung

Willkommen in Sektion 32. Wenn wir über die Softwareverteilung in Microsoft Intune sprechen, landen wir unweigerlich beim IntuneWin App Packaging Tool. Es ist das Herzstück jeder Win32-App-Strategie. Während die einfache Verteilung von MSI-Paketen oft ausreicht, scheitern viele Admins an EXE-Installern, komplexen Setups mit Abhängigkeiten oder proprietärer Software, die spezifische Parameter benötigt.

In dieser Masterclass lernst du nicht nur, wie man ein Tool bedient, sondern wie man professionelle Software-Pakete baut, die in einer Enterprise-Umgebung stabil, reproduzierbar und wartungsarm funktionieren. Wir gehen tief in die Mechanik des .intunewin-Formats und die Logik der Installationsbefehle.

1. Grundkonzepte: Was ist eigentlich eine Win32-App?

Bevor wir das Tool öffnen, müssen wir verstehen, was Intune im Hintergrund macht. Ein Standard-MSI (Microsoft Installer) ist „intelligent“; er enthält Informationen über die Installation, Deinstallation und Versionierung. Eine EXE hingegen ist oft nur ein Wrapper. Intune kann mit EXEs nicht nativ umgehen, da es nicht weiß, wie man sie lautlos (silent) startet oder wie man erkennt, ob die App bereits installiert ist.

Hier kommt das Microsoft Win32 Content Prep Tool ins Spiel. Es transformiert deinen Installationsordner in eine .intunewin-Datei. Diese Datei ist im Grunde ein komprimiertes Archiv, das zwei Dinge enthält: die eigentlichen Installationsdateien und eine Manifest-Datei, die Intune mitteilt, wie die Dateien auf dem Client zu behandeln sind.

Der Lebenszyklus einer Win32-App auf dem Client

Sobald du eine App hochlädst, passiert auf dem Endgerät folgendes:

Download: Der Intune Management Extension (IME) Agent lädt die .intunewin-Datei aus dem Azure CDN herunter.
Entpacken: Die Datei wird in einem temporären Cache-Ordner (meist unter C:\Windows\IMECache) entpackt.
Detection: Intune prüft die „Detection Rule“. Wenn die App bereits da ist, bricht der Prozess ab.
Execution: Der definierte Installationsbefehl wird ausgeführt.
Verification: Die Detection Rule wird erneut geprüft. Erfolg oder Fehler wird an den Tenant gemeldet.

2. Praxis-Implementierung: Schritt-für-Schritt Anleitung

Schritt 1: Die Umgebung vorbereiten

Ein häufiger Fehler ist es, das Packaging Tool direkt im Download-Ordner zu starten. Das führt oft zu Berechtigungsproblemen oder unübersichtlichen Pfaden. Erstelle eine strikte Ordnerstruktur auf deinem Packaging-Server oder Laptop:

C:\IntunePackaging\
├── Tool\             (Hier liegt IntuneWinAppUtil.exe)
├── Source\           (Die nackten Installationsdateien der App)
└── Output\            (Hier landet die fertige .intunewin Datei)

Lade das Tool vom offiziellen Microsoft GitHub Repository herunter. Es ist eine einfache Konsole-App, die keine Installation erfordert.

Schritt 2: Die Source-Dateien analysieren

Bevor du packst, musst du den „Silent Switch“ finden. Eine App, die ein Fenster öffnet und auf „Weiter“ wartet, wird in Intune als „Failed“ markieren, weil der User im System-Kontext (SYSTEM Account) keine Fenster sieht. Suche nach Parametern wie /S, /silent, /quiet oder /qn.

Pro-Tipp: Nutze Tools wie Usagi oder schau in die Dokumentation des Herstellers. Wenn du unsicher bist, teste den Befehl lokal in einer administrativen PowerShell:

# Beispiel für einen Chrome Silent Install
Start-Process "GoogleChromeStandaloneEnterprise64.msi" -ArgumentList "/qn /norestart" -Wait

Schritt 3: Das Tool ausführen

Öffne die PowerShell als Administrator und navigiere zum Tool-Ordner. Starte die Anwendung:

.\IntuneWinAppUtil.exe

Das Tool stellt dir nun drei Fragen:

Please specify the source folder to process: Gib den Pfad zu C:\IntunePackaging\Source an. Wichtig: Nur der Ordner, keine einzelne Datei!
Please specify the setup file: Gib den Namen der Datei an, die den Prozess startet (z.B. setup.exe).
Please specify the output folder to place the .intunewin file in: Gib C:\IntunePackaging\Output an.

Das Tool komprimiert nun den gesamten Inhalt des Source-Ordners. Alle Dateien, die du dort abgelegt hast (z.B. Konfigurationsdateien, Lizenzen, Skripte), werden mit in das Paket gepackt.

3. Die Konfiguration in Intune (MEM)

Nachdem du die .intunewin-Datei hochgeladen hast, musst du die Logik definieren. Hier trennt sich die Spreu vom Weizen.

Installations- und Deinstallationsbefehle

Wenn dein Setup-File setup.exe heißt und den Switch /S nutzt, ist der Befehl simpel: setup.exe /S. Aber was ist, wenn du Vorab-Konfigurationen brauchst? Nutze ein Wrapper-Skript.

Anstatt die EXE direkt zu starten, packst du eine install.ps1 in deinen Source-Ordner und rufst im Intune-Portal nur diese auf: powershell.exe -ExecutionPolicy Bypass -File install.ps1.

Beispiel für eine professionelle install.ps1:

# 1. Log-File erstellen für Troubleshooting
Start-Transcript -Path "C:\Windows\Temp\AppInstall_MyApp.log"

try {
    # 2. App installieren
    $process = Start-Process -FilePath "setup.exe" -ArgumentList "/S" -Wait -PassThru
    
    if ($process.ExitCode -ne 0 -and $process.ExitCode -ne 3010) {
        throw "Installation failed with Exit Code $($process.ExitCode)"
    }
} catch {
    Write-Error $_.Exception.Message
    exit 1
} finally {
    Stop-Transcript
}

Die Detection Rule (Erkennungsregel)

Dies ist der wichtigste Teil. Intune fragt: „Ist die App schon da?“. Wenn die Antwort „Nein“ ist, wird installiert. Wenn die Installation fertig ist, fragt Intune erneut. Findet es die App jetzt nicht, meldet es „Failed“, obwohl die Software vielleicht perfekt installiert wurde.

Die drei gängigsten Methoden:

MSI Product Code: Automatisch gefüllt bei MSIs. Am zuverlässigsten.
Datei/Ordner: Prüfe, ob C:\Program Files\MyApp\app.exe existiert. Achte auf die Version!
Registry: Prüfe einen Key unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. Das ist der Standard für fast alle EXE-Installer.

4. Best Practices für Enterprise Packaging

Um zu verhindern, dass dein Intune-Tenant ein Friedhof aus „Failed“-Installationen wird, befolge diese Regeln:

A. Der „System“ Kontext

Win32-Apps werden standardmäßig als System installiert. Das bedeutet: Die App hat volle Admin-Rechte, aber kein User-Profil. Befehle wie %AppData% funktionieren nicht, da es keinen aktuellen User gibt. Wenn du Einstellungen in das User-Profil schreiben musst, musst du entweder die Installation auf „User“ stellen oder komplexe Skripte nutzen, die über alle Profile iterieren.

B. Exit Codes verstehen

Intune versteht standardmäßig, dass 0 Erfolg bedeutet. Aber es gibt Spezialfälle:

3010: Erfolg, aber Neustart erforderlich. (Intune markiert dies als „Pending Restart“).
1603: Fatal error während der MSI-Installation. Meist ein Berechtigungsproblem oder die App ist bereits in einer anderen Version installiert.

Du kannst in den App-Einstellungen unter „Return Codes“ definieren, wie Intune auf spezifische Codes reagieren soll.

C. Versionierung

Übergebe niemals eine App ohne Versionsnummer. Wenn du MyApp_v1.intunewin heute hochlädst und in drei Monaten MyApp_v2 kommt, solltest du die App aktualisieren (Supersedence), anstatt eine neue App zu erstellen. Das verhindert Duplikate auf den Clients.

5. Troubleshooting: Wenn es nicht funktioniert

Wenn eine App auf „Failed“ steht, ist das Intune-Portal blind. Du musst auf das Gerät gehen.

Die Log-Dateien analysieren

Der heilige Gral des Intune-Troubleshootings ist der IME Log. Gehe zu:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

Nutze den CMTrace (aus dem SCCM Paket) oder den Log Parser, um die Datei zu lesen. Suche nach Keywords wie [Win32App］ oder dem Namen deiner App. Hier siehst du exakt, ob der Download fehlgeschlagen ist oder welcher Exit Code vom Installer zurückgegeben wurde.

Häufige Fehlerquellen

Falscher Pfad in der Detection Rule: Du hast C:\Program Files (x86) statt C:\Program Files angegeben.
Interaktive Dialoge: Der Installer versucht, ein Fenster zu zeigen, das im SYSTEM-Kontext unsichtbar ist. Der Prozess hängt ewig (Timeout) und schlägt dann fehl.
Architektur-Konflikt: Eine 32-Bit App wird auf einem 64-Bit System installiert, aber die Detection Rule sucht im falschen Registry-Hive (WOW6432Node).

6. Fazit

Das IntuneWin App Packaging Tool ist simpel in der Bedienung, aber komplex in der Anwendung. Der Erfolg einer Softwareverteilung hängt zu 10% vom Tool und zu 90% von der Vorbereitung ab: der Analyse des Silent-Switches, der Wahl der richtigen Detection Rule und der Behandlung von Exit Codes.

Zusammenfassung für deinen Workflow:
1. Source-Ordner sauber trennen.
2. Silent-Switch verifizieren.
3. Mit IntuneWinAppUtil.exe packen.
4. Detection Rule auf Datei- oder Registry-Basis präzise definieren.
5. Bei Fehlern im IntuneManagementExtension.log suchen.

Mit diesen Techniken bist du nun bereit, jede beliebige Windows-Software professionell in deine Flotte auszurollen. In der nächsten Sektion schauen wir uns an, wie wir diese Apps über Gruppenrichtlinien-Alternativen und Filter intelligent zuweisen.