Die Paketierung von Standardsoftware ist in Intune ein Spaziergang. Doch sobald wir uns in den Bereich von SQL Server Express, ERP-Systemen oder komplexen CAD-Softwaren bewegen, verlassen wir die Komfortzone der einfachen MSI-Dateien. Diese Anwendungen sind sogenannte Heavy Apps: Sie bringen eigene Datenbank-Instanzen mit, erfordern spezifische System-Permissions, haben oft interaktive Installer-Dialoge und benötigen eine exakte Reihenfolge bei der Installation von Prerequisites.
In dieser Masterclass behandeln wir die Strategien, mit denen ihr diese „Monster“ bändigt. Wir verwandeln unhandliche Installer in saubere, silent-fähige Intune-Pakete, die ohne manuellen Eingriff auf tausenden Endpunkten funktionieren.
Grundkonzepte: Warum Heavy Apps scheitern
Bevor wir in den Code gehen, müssen wir verstehen, warum SQL Express und ähnliche Pakete oft im Intune-Deployment scheitern. Es gibt drei Hauptursachen:
1. Der Kontext-Konflikt (System vs. User)
Die meisten komplexen Apps müssen im System-Kontext installiert werden, um in C:\Program Files zu schreiben und Registry-Keys unter HKEY_LOCAL_MACHINE zu setzen. SQL Server hingegen benötigt oft spezifische Service-Accounts oder User-Profile für die Instanz-Konfiguration. Wenn der Installer versucht, ein User-Profil anzusprechen, während Intune ihn als SYSTEM ausführt, kracht es.
2. Die Interaktivitäts-Falle
Viele Heavy Apps haben „Hard-Coded“ Dialogfenster, die selbst im Silent-Modus erscheinen (z.B. Neustart-Warnungen oder Lizenzabfragen). Da Intune im Hintergrund (non-interactive) installiert, bleibt dieser Prozess für immer hängen. Das Resultat ist ein Timeout nach 60 Minuten und ein Fehlercode 0x87D1F42F.
3. Die Abhängigkeits-Hölle
Ein SQL Express Installer ist oft nur ein Wrapper. Er lädt im Hintergrund das .NET Framework, C++ Redistributables und verschiedene Setup-Support-Files. Wenn diese nicht vorab vorhanden sind oder der Installer keinen Internetzugriff hat, bricht die Installation lautlos ab.
Praxis-Implementierung: SQL Server Express paketieren
Wir nehmen SQL Server Express als Paradebeispiel, da es fast jede Heavy App repräsentiert: Ein komplexer Installer mit vielen Parametern und einer Datenbank-Komponente.
Schritt 1: Die Parameter-Analyse
SQL Express nutzt einen MSI-basierten Installer, erfordert aber eine Konfigurationsdatei oder spezifische Command-Line-Arguments für die Instanz-Benennung und die Authentifizierung. Wir nutzen nicht die .exe, sondern steuern den MSI direkt an, um maximale Kontrolle zu haben.
Die wichtigsten Parameter für eine Silent-Installation sind:
/Q: Quiet mode (keine UI).IACCEPTSQLSERVERLICENSETERMS=Yes: Zwingend erforderlich, sonst bricht das Setup sofort ab.SQLINSTANCENAME=SQLEXPRESS: Definition der Instanz.SQLSYSADMINACCOUNTS="BUILTIN\Administrators": Legt fest, wer Admin-Rechte auf der DB hat.
Schritt 2: Das Packaging-Script (PSADT)
Für Heavy Apps ist die Nutzung des PowerShell App Deployment Toolkit (PSADT) nicht optional, sondern obligatorisch. Es erlaubt uns, Neustarts zu unterdrücken, Prozesse zu killen und Log-Dateien lokal zu schreiben, bevor Intune das Paket als „fehlgeschlagen“ markiert.
# Beispiel für ein Installations-Snippet in Deploy-Application.ps1
# 1. Prüfen, ob SQL bereits installiert ist
if (Get-Service "MSSQL$SQLEXPRESS" -ErrorAction SilentlyContinue) {
Write-Log -Message "SQL Express bereits installiert. Überspringe Installation."
exit 0
}
# 2. Installation starten
Write-Log -Message "Starte SQL Express Installation..."
Execute-MSI -Action 'Install' -Path 'SQLServer2019-SSE-Expr.msi' -Parameters '/Q IACCEPTSQLSERVERLICENSETERMS=Yes SQLINSTANCENAME=SQLEXPRESS SQLSYSADMINACCOUNTS="BUILTIN\Administrators" ADDLOCAL=SqlCore'
# 3. Verifizierung der Installation
if (Get-Service "MSSQL$SQLEXPRESS" -ErrorAction SilentlyContinue) {
Write-Log -Message "Installation erfolgreich verifiziert."
} else {
Write-Log -Message "Installation fehlgeschlagen!" -Severity 3
exit 1603
}
Schritt 3: Intune Win32 App Konfiguration
Nachdem wir das Paket mit dem IntuneWinAppUtil.exe in eine .intunewin Datei gepackt haben, konfigurieren wir die App in Intune wie folgt:
- Install command:
Deploy-Application.exe - Uninstall command:
Uninstall-Application.exe - Install behavior: System
- Device restart behavior: Intune determines based on return codes (WICHTIG: Hier nicht „Force“ wählen, sondern die Return Codes des Installers nutzen).
Die Detektionsmethode für Heavy Apps
Bei einfachen Apps reicht die Prüfung eines Dateipfads. Bei SQL Express oder ERP-Software ist das riskant, da die Datei existieren kann, während der Dienst abgestürzt ist oder die Instanz nicht korrekt registriert wurde.
Wir nutzen für Heavy Apps immer ein Custom Detection Script. Hier prüfen wir nicht nur die Datei, sondern den Status des Dienstes und die Registry-Version.
# Detection Script für SQL Express
$service = Get-Service "MSSQL$SQLEXPRESS" -ErrorAction SilentlyContinue
$regPath = "HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.SQLEXPRESS\Setup"
if ($service -and $service.Status -eq 'Running' -and (Test-Path $regPath)) {
Write-Output "Installed"
exit 0
} else {
# Wenn der Dienst nicht läuft, ist die App für uns nicht "installiert"
exit 1
}
Best Practices für Heavy Apps
1. Das Prinzip der „Prerequisite-Kette“
Installiert niemals Heavy Apps in einem einzigen Paket, wenn sie Abhängigkeiten haben. Nutzt die Dependency-Funktion von Intune. Erstellt separate Apps für:
- .NET Framework (verschiedene Versionen)
- Visual C++ Redistributables (2015, 2017, 2019)
- Die eigentliche Heavy App (als letzte in der Kette)
2. Log-Management
Wenn ein SQL-Setup auf 500 Rechnern fehlschlägt, ist „Error 1603“ nutzlos. Konfiguriert euren Installer so, dass er Logs in einen zentralen Ordner schreibt, den ihr per Skript auslesen könnt, oder nutzt PSADT, um die Logs nach C:\Windows\Temp\AppLogs zu spiegeln.
3. Timeout-Management
Standardmäßig wartet Intune eine gewisse Zeit auf die Antwort des Installers. Heavy Apps brauchen oft länger (SQL kann je nach Hardware 20 Minuten benötigen). Erhöht das Timeout in den Intune-Einstellungen für die App auf das Maximum, um „False Negatives“ zu vermeiden.
Troubleshooting: Wenn es trotzdem hakt
Wenn die Installation im Intune-Portal auf „Failed“ steht, geht ihr nach diesem Workflow vor:
Szenario A: Der Prozess hängt (Infinite Loop)
Öffnet auf einem Testgerät den Task-Manager. Sieht ihr den msiexec.exe oder den App-Installer, der CPU-Last erzeugt, aber keine Fortschritte macht? Dann ist wahrscheinlich ein verstecktes Dialogfenster aktiv. Lösung: Prüft die Silent-Parameter erneut. Nutzt Tools wie den Process Monitor (ProcMon), um zu sehen, welche Registry-Keys oder Dateien der Installer gerade abfragt, bevor er stehen bleibt.
Szenario B: Fehler 0x80070005 (Access Denied)
Dies passiert oft, wenn ein Installer versucht, einen Neustart zu erzwingen oder einen Service zu starten, für den das SYSTEM-Konto in dieser spezifischen Umgebung keine Rechte hat. Lösung: Nutzt PSADT, um den Installer mit Start-Process -Verb RunAs zu kapseln oder prüft, ob lokale Antiviren-Software den Installer blockiert.
Szenario C: Installation erfolgreich, aber Detektion schlägt fehl
Das ist der klassische Intune-Fehler. Die App ist da, aber Intune meldet „Failed“. Lösung: Führt euer Detection-Script manuell in einer SYSTEM-PowerShell (via PSEXEC) aus. Oft stellen wir fest, dass das Skript als Administrator funktioniert, aber als SYSTEM keine Berechtigung hat, bestimmte Registry-Keys zu lesen.
Fazit für den Intune-Architekten
Das Packaging von komplexer Software ist keine Glückssache, sondern ein strukturierter Prozess. Die goldene Regel lautet: Entkoppeln und Kapseln.
- Entkoppeln: Trennt Prerequisites von der Hauptapp.
- Kapseln: Nutzt PSADT, um die unsauberen Installer-Logiken in eine kontrollierte PowerShell-Umgebung zu hüllen.
Wer SQL Express und Heavy Apps beherrscht, kann im Grunde jede Software der Welt in Intune verteilen. Es geht nicht darum, den Installer zu „bitten“, silent zu sein, sondern ihn durch präzise Parameter und robuste Detektionslogik dazu zu zwingen.