Sektion 31: The Win32 App Model: Warum .intunewin?

Einleitung: Das fehlende Puzzleteil der App-Distribution

Wer in die Welt von Microsoft Intune einsteigt, wird schnell feststellen, dass die Bereitstellung von Software einer der komplexesten Bereiche des Modern Managements ist. Während LOB-Apps (Line-of-Business) oder Store-Apps oft mit einem einfachen Upload funktionieren, stoßen Administratoren bei klassischen Windows-Applikationen schnell an ihre Grenzen. Hier kommt das Win32 App Model ins Spiel.

Die Frage, die sich jeder Anfänger stellt, ist: Warum reicht es nicht, einfach eine .exe oder ein .msi Paket hochzuladen? Warum zwingt uns Microsoft dazu, unsere Software in ein spezielles .intunewin Format zu packen? In dieser Masterclass tauchen wir tief in die Architektur des Intune Management Extension (IME) Agents ein und analysieren, warum das Win32 Modell das absolute Fundament für jede professionelle Enterprise-Umgebung ist.

Grundkonzepte: MSI vs. Win32 und das Problem der „dummen“ Installer

Um zu verstehen, warum wir .intunewin benötigen, müssen wir verstehen, wie Intune ursprünglich gedacht war. In der Frühphase setzte Microsoft stark auf MSI (Microsoft Installer). MSIs sind standardisiert; sie wissen, wie sie sich installieren, wie sie updaten und vor allem, wie sie sich deinstallieren.

Die Realität in der IT-Welt sieht jedoch anders aus. Die meisten Anwendungen werden als .exe (Executables) ausgeliefert. Eine .exe ist im Grunde eine „Black Box“. Intune weiß nicht, was in einer .exe passiert. Es weiß nicht, welche Parameter für eine Silent Installation nötig sind, welcher Registry-Key beweist, dass die App installiert wurde, oder wie man sie sauber entfernt.

Das Problem der LOB-Apps

Viele Administratoren nutzen anfangs den „Line-of-Business“ (LOB) Upload für .msi Dateien. Das ist riskant. LOB-Apps werden vom nativen Intune-Agenten (MDM) verwaltet. Das führt oft zu Konflikten, wenn eine Win32-App und eine LOB-App gleichzeitig installiert werden sollen, da sie über unterschiedliche Mechanismen gesteuert werden. Win32-Apps hingegen werden über die Intune Management Extension (IME) verwaltet – ein separater Dienst, der weitaus mächtiger ist.

Was ist eigentlich ein .intunewin Paket?

Ein .intunewin Paket ist kein Installer im klassischen Sinne, sondern ein komprimiertes Archiv. Man kann es sich wie einen Versandcontainer vorstellen. In diesem Container befinden sich:

• Die eigentlichen Installationsdateien (Installer, Konfigurationsdateien, Lizenzen).
• Die Metadaten, die Intune mitteilen, welcher Befehl ausgeführt werden soll.

Der entscheidende Vorteil: Intune lädt den gesamten Container herunter, entpackt ihn in einen temporären Ordner auf dem Client und führt dort den definierten Befehl aus. Dadurch ist die Installation unabhängig von Netzwerkpfaden oder komplexen Share-Berechtigungen während des eigentlichen Installationsvorgangs.

Praxis-Implementierung: Der Weg zum .intunewin Paket

Das Werkzeug: Microsoft Win32 Content Prep Tool

Um eine App in das .intunewin Format zu bringen, nutzen wir das IntuneWinAppUtil.exe Tool. Der Prozess folgt einem strikten Workflow:

1. Setup-Ordner: Erstellen Sie einen Ordner mit dem Installer (z.B. C:\IntuneSource\Chrome).
2. Output-Ordner: Ein Zielordner für das fertige Paket (z.B. C:\IntuneOutput).
3. Execution-File: Die Datei, die den Prozess startet (z.B. googlechromestandaloneenterprise64.msi).

# Beispielhafter Aufruf des Tools via CMD
IntuneWinAppUtil.exe -c "C:\IntuneSource\Chrome" -o "C:\IntuneOutput" -s "googlechromestandaloneenterprise64.msi"

Die Konfiguration in Intune

Sobald die .intunewin Datei hochgeladen ist, fordert Intune drei kritische Informationen an, die über Erfolg oder Misserfolg entscheiden:

1. Die Installationsbefehle (Install Commands)

Da der User nichts bemerken soll, muss die Installation „silent“ erfolgen. Bei MSIs ist dies standardisiert, bei EXEs herstellerabhängig.

# MSI Beispiel
msiexec /i "app.msi" /qn /norestart

# EXE Beispiel (oft herstellerspezifisch)
setup.exe /S /v"/qn"

2. Die Deinstallationsbefehle (Uninstall Commands)

Intune muss wissen, wie die App entfernt wird, um sie z.B. bei einem Profilwechsel zu löschen oder ein Update durchzuführen.

# MSI Beispiel
msiexec /x "{Produkt-GUID}" /qn

3. Die Erkennungsregeln (Detection Rules)

Das ist der wichtigste Teil. Intune installiert eine App nicht einfach „blind“. Er prüft erst: Ist die App bereits da? Wenn ja, wird die Installation übersprungen. Wenn die Erkennung falsch konfiguriert ist, versucht Intune die App in jedem Zyklus neu zu installieren (Endlosschleife!).

Es gibt drei gängige Methoden:

• Datei/Ordner: Prüft, ob C:\Program Files\App\app.exe existiert.
• Registry: Prüft, ob ein bestimmter Key in HKEY_LOCAL_MACHINE\SOFTWARE\App vorhanden ist.
• MSI Produktcode: Intune prüft die GUID des Installers (am zuverlässigsten bei MSIs).

Best Practices: Professionelles Packaging

Ein „einfacher“ Upload funktioniert oft, aber in einer Enterprise-Umgebung mit 1000+ Clients führt das zu Chaos. Hier sind die Goldenen Regeln für Win32 Apps:

Verwendung von Wrapper-Skripten

Installieren Sie niemals eine komplexe App direkt über die .exe. Nutzen Sie stattdessen ein PowerShell-Skript als „Wrapper“. Packen Sie das PowerShell-Skript und den Installer gemeinsam in das .intunewin Paket. Das Skript übernimmt die Logik:

# Beispiel: install.ps1
# 1. Prüfen, ob eine alte Version läuft und diese beenden
Stop-Process -Name "Application" -Force -ErrorAction SilentlyContinue

# 2. Installation starten
Start-Process "setup.exe" -ArgumentList "/S" -Wait

# 3. Konfigurationsdatei kopieren
Copy-Item "config.ini" -Destination "C:\Program Files\App\config.ini"

# 4. Registry-Key für die Lizenz setzen
Set-ItemProperty -Path "HKLM:\Software\App" -Name "LicenseKey" -Value "123-456"

In Intune rufen Sie dann nur noch auf: powershell.exe -ExecutionPolicy Bypass -File install.ps1.

Die Wahl der richtigen Detection Rule

Verlassen Sie sich nicht nur auf die Existenz der .exe. Viele Installer erstellen die .exe, aber die Installation schlägt später fehl. Die sicherste Methode ist die Kombination aus Version und Pfad oder die Nutzung eines spezifischen Registry-Werts, der erst am Ende des Installationsskripts geschrieben wird.

Kontext-Management (System vs. User)

Entscheiden Sie präzise, in welchem Kontext die App läuft:

• System: Die App wird mit Administratorrechten installiert. Notwendig für fast alle Programme in Program Files.
• User: Die App wird im Kontext des angemeldeten Benutzers installiert. Wichtig für Apps, die nur in %AppData% landen.

Troubleshooting: Wenn die Installation auf „Failed“ steht

Win32 Apps können frustrierend sein, weil Intune in der Konsole oft nur „Failed“ anzeigt, ohne zu sagen, warum. Der Schlüssel zur Lösung liegt in den Logs auf dem Client.

Wo liegen die Logs?

Alle Operationen der Intune Management Extension werden hier geloggt:

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

Nutzen Sie das Tool CMTrace oder den Support Tool von Intune, um diese Logs in Echtzeit zu lesen. Suchen Sie nach Keywords wie [Win32App] oder Detection Check.

Häufige Fehlerbilder

• Error 1603: Ein generischer MSI-Fehler. Meistens bedeutet dies, dass die App bereits installiert ist, der Installer keine Admin-Rechte hat oder ein Neustart aussteht.
• Detection Rule failed: Die App wurde erfolgreich installiert, aber Intune „sieht“ sie nicht. Prüfen Sie den Pfad oder den Registry-Key erneut.
• Timeout: Die Installation dauert länger als die Standard-Zeit von Intune (meist 60 Minuten). Hier muss in den Einstellungen die Zeit erhöht werden.

Fazit: Warum .intunewin der Standard ist

Das Win32 App Model ist weitaus mehr als nur ein Verpackungsformat. Es ist die Brücke zwischen der klassischen Software-Welt (lokale Installer) und der modernen Cloud-Welt. Durch die Entkopplung des Downloads vom Installationsprozess und die Einführung der Intune Management Extension bietet Microsoft Administratoren eine Flexibilität, die mit reinen MSI-Uploads niemals möglich wäre.

Wenn Sie verstehen, wie Sie Wrapper-Skripte einsetzen, die Erkennungsregeln präzise definieren und die IME-Logs lesen, haben Sie die Kontrolle über Ihre Software-Distribution zurückgewonnen. In den kommenden Sektionen werden wir diese Grundlagen nutzen, um komplexere Szenarien wie App-Abhängigkeiten und dynamische Gruppen-Zuweisungen zu meistern.