Sektion 34: App Installation Commands: Silent Switches & Logging

Einleitung: Warum Silent Switches das Rückgrat der Softwareverteilung sind

In der Welt des Enterprise Device Managements ist die User Experience (UX) das höchste Gut. Nichts ist für einen Endanwender frustrierender, als wenn während der Arbeit plötzlich ein Installationsfenster aufpoppt, das nach dem Installationspfad fragt oder eine Bestätigung verlangt, die der User gar nicht versteht. In einer Intune-Umgebung, in der Apps oft im System-Kontext (SYSTEM Account) installiert werden, führt ein interaktives Installationsprogramm nicht nur zu einer schlechten UX, sondern zum totalen Scheitern der Bereitstellung. Das Paket bleibt im Status „Installing“ hängen, bis es schließlich mit einem Time-out abbricht, weil der Installer im Hintergrund auf einen Klick wartet, den niemand jemals sehen wird.

In dieser Masterclass-Sektion tauchen wir tief in die Mechanik der Silent Switches und das essenzielle Thema des Loggings ein. Wir lernen nicht nur, wie man einen Installer „stumm“ schaltet, sondern wie wir eine professionelle Logging-Strategie implementieren, die es uns ermöglicht, Fehler auf tausenden von Geräten zu analysieren, ohne jemals physischen Zugriff auf den Client zu benötigen.

Grundkonzepte: Die Anatomie eines Silent Installers

Ein Installationsprogramm ist im Grunde ein komplexes Skript, das Dateien kopiert, Registry-Keys setzt und Abhängigkeiten prüft. Die meisten Hersteller bieten verschiedene Modi an, um dieses Verhalten zu steuern.

Was ist ein Silent Switch?

Ein Silent Switch (oder Parameter) ist ein Argument, das beim Aufruf der Installationsdatei über die Kommandozeile übergeben wird. Er weist den Installer an, alle Standardoptionen zu wählen und keine Benutzeroberfläche (GUI) anzuzeigen. Man unterscheidet hierbei oft zwei Stufen:

Passive Installation: Der User sieht einen Fortschrittsbalken, muss aber nichts bestätigen. Die Installation läuft automatisch ab.
Silent/Quiet Installation: Absolut keine visuelle Rückmeldung. Alles geschieht im Hintergrund. Dies ist der Goldstandard für Intune.

Die gängigsten Installer-Typen und ihre Standard-Switches

Je nachdem, mit welcher Technologie die App gebaut wurde, variieren die Switches. Hier ist die Referenz für die am häufigsten verwendeten Typen:

1. MSI (Microsoft Installer)

MSIs sind der Liebling von Intune-Admins, da sie standardisiert sind. Die Switches sind fast immer identisch:

msiexec.exe /i "App.msi" /qn /norestart

/i: Installiert das Paket.
/qn: Quiet, No UI (absolut stumm).
/qr: Quiet, Reduced UI (zeigt nur einen Fortschrittsbalken).
/norestart: Verhindert einen automatischen Reboot des Systems, was in Intune kritisch ist, um Datenverlust zu vermeiden.

2. EXE (InstallShield, Inno Setup, NSIS)

EXEs sind „Wild West“. Jeder Hersteller definiert seine eigenen Switches. Dennoch gibt es Muster:

Inno Setup: Meist /VERYSILENT /SUPPRESSMSGBOXES /NORESTART
NSIS: Meist /S (Großschreibung ist hier oft zwingend!)
InstallShield: Oft /s /v"/qn" (hier wird ein Switch an den internen MSI übergeben).

Praxis-Implementierung in Intune

Wenn du eine Win32-App in Intune erstellst, fragt dich das Portal nach dem „Install command“ und dem „Uninstall command“. Hier ist die präzise Anwendung deiner Kenntnisse gefragt.

Beispiel 1: Die klassische MSI-Bereitstellung

Für eine MSI-Datei ist der Befehl simpel, aber wir fügen das Logging direkt hinzu (siehe nächste Sektion). Der reine Installationsbefehl lautet:

msiexec /i "Software.msi" /qn /norestart

Beispiel 2: Die komplexe EXE mit Wrapper

Viele moderne Apps (wie Google Chrome oder Zoom) bieten spezifische Enterprise-Parameter an. Ein typischer Befehl für einen stummen EXE-Installer könnte so aussehen:

setup.exe --silent --install-dir="C:\Program Files\App" --accept-eula

Die Gefahr der Interaktivität

Ein häufiger Fehler ist die Verwendung von Switches, die zwar „silent“ heißen, aber bei bestimmten Fehlern (z.B. „App bereits installiert“) dennoch ein Fenster öffnen. Um dies zu verhindern, nutzen wir in professionellen Umgebungen oft PowerShell-Wrapper. Anstatt die EXE direkt in Intune aufzurufen, rufen wir ein install.ps1 Skript auf:

# install.ps1
$installerPath = ".\app_setup.exe"
$arguments = "/S /v`"/qn /norestart`""

try {
    $process = Start-Process -FilePath $installerPath -ArgumentList $arguments -Wait -PassThru -ErrorAction Stop
    if ($process.ExitCode -eq 0 -or $process.ExitCode -eq 3010) {
        Write-Output "Installation successful"
        exit 0
    } else {
        Write-Error "Installation failed with exit code $($process.ExitCode)"
        exit $process.ExitCode
    }
} catch {
    Write-Error "Critical error during installation: $_"
    exit 1
}

Professionelles Logging: Die Blackbox öffnen

Ohne Logs ist Intune ein Ratespiel. Wenn eine App den Status „Failed“ meldet, sagt dir Intune nur, dass der Exit-Code nicht 0 war. Er sagt dir nicht, WARUM.

MSI-Logging (Der Goldstandard)

MSIs haben eine integrierte Logging-Funktion, die extrem detailliert ist. Wir nutzen den /L Switch. Ein professioneller Logging-String sieht so aus:

msiexec /i "App.msi" /qn /norestart /L*V "C:\Windows\Temp\App_Install.log"

/L: Aktiviert das Logging.
*: Loggt alle Informationen.
V: Verbose Mode (extrem detailliert, zeigt jede Registry-Änderung und jeden Datei-Kopierprozess).

Logging für EXE-Installer

EXE-Installer sind inkonsistent. Manche unterstützen /log "path", andere -log oder schreiben automatisch in %TEMP%. Wenn der Installer kein eigenes Logging unterstützt, müssen wir das Logging auf der Shell-Ebene lösen.

Die Strategie: Zentrales Log-Repository auf dem Client

Damit du als Admin weißt, wo du suchen musst, empfehle ich die Erstellung eines Standard-Log-Ordners für alle deine Intune-Apps:

# Im Installationsskript zuerst den Ordner erstellen
$logDir = "C:\ProgramData\KaffeeUndCode\Logs"
if (!(Test-Path $logDir)) { New-Item -Path $logDir -ItemType Directory -Force }

$logFile = "$logDir\Sektion34_App.log"

# Den Installer mit diesem Pfad starten
Start-Process "setup.exe" -ArgumentList "/S /L$logFile" -Wait

Best Practices für den produktiven Einsatz

1. Der „Exit Code“ Check

Intune interpretiert Exit Codes. Du musst wissen, was sie bedeuten:

0: Erfolg.
1603: Fatal error during installation (oft Berechtigungsprobleme oder App bereits installiert).
1641 / 3010: Erfolg, aber ein Neustart ist erforderlich. In Intune solltest du diese Codes in den App-Einstellungen als „Soft Reboot“ markieren, damit Intune nicht fälschlicherweise einen Fehler meldet.

2. Vermeidung von User-Interaktion um jeden Preis

Prüfe deine Installer immer in einer virtuellen Maschine (VM). Nutze Tools wie den Process Monitor (ProcMon) von Sysinternals, um zu sehen, ob der Installer im Hintergrund versucht, eine Datei zu öffnen oder einen Registry-Key zu schreiben, der eine Administrator-Bestätigung triggert.

3. Absolute Pfade vs. Relative Pfade

Intune entpackt die .intunewin Datei in einen temporären Ordner unter C:\Windows\IMECache. Nutze in deinen Skripten immer relative Pfade oder ermittle das aktuelle Verzeichnis dynamisch:

$currentDir = Split-Path -Parent $MyInvocation.MyCommand.Definition

Troubleshooting: Wenn „Silent“ nicht funktioniert

Symptom: App bleibt auf „Installing“ hängen

Ursache: Der Installer ist nicht wirklich silent. Er wartet auf einen Klick („Weiter“, „Akzeptieren“).
Lösung: Überprüfe die Dokumentation des Herstellers erneut. Teste den Befehl manuell in einer CMD als SYSTEM-User (nutze psexec -i -s cmd.exe), um zu sehen, ob ein Fenster aufpoppt.

Symptom: Exit Code 1603

Ursache: Oft ist die App bereits in einer anderen Version installiert oder es gibt einen Konflikt mit einer bestehenden Datei.
Lösung: Analysiere das Logfile. Suche nach dem String Return Value 3. Die Zeilen unmittelbar darüber verraten dir meistens genau, welcher Schritt fehlgeschlagen ist.

Symptom: Installation erfolgreich, aber Intune meldet „Failed“

Ursache: Die Detection Rule (Erkennungsregel) schlägt fehl. Die App ist da, aber Intune findet sie nicht.
Lösung: Trenne die Installation von der Detektion. Prüfe, ob der Pfad, die Version oder der Registry-Key, den du für die Detektion definiert hast, exakt so existiert, wie die App ihn anlegt.

Fazit

Die Beherrschung von Silent Switches und Logging transformiert dich von einem „Trial-and-Error“-Admin zu einem Enterprise-Engineer. Ein perfekter App-Deployment-Prozess in Intune folgt immer diesem Muster: Silent Installation $\rightarrow$ Robustes Logging $\rightarrow$ Präzise Detektion.

Wenn du diese Prinzipien konsequent anwendest, reduzierst du die Ticket-Last massiv, da Installationen im Hintergrund ablaufen und Fehler innerhalb von Sekunden durch einen Blick in das Logfile auf dem Client (oder via Remote-Management) identifiziert werden können. In der nächsten Sektion werden wir uns ansehen, wie wir diese Installationen mit komplexen Abhängigkeiten verknüpfen.