Sektion 35: App Dependencies & Supersedence: Die Logik hinter App-Ketten

Einleitung

In einer idealen IT-Welt würde jede Software einfach funktionieren, sobald man auf „Installieren“ klickt. In der Enterprise-Realität sieht das anders aus. Anwendungen sind selten isolierte Einheiten; sie sind Teil eines komplexen Ökosystems aus Frameworks, Laufzeitumgebungen und Versionen. Wer versucht, eine App ohne Berücksichtigung ihrer Abhängigkeiten (Dependencies) zu deployen, wird schnell feststellen, dass Intune zwar „Erfolgreich“ meldet, die App auf dem Client jedoch abstürzt, weil die passende .NET-Version oder ein C++ Redistributable fehlt.

Die Beherrschung von App Dependencies und Supersedence ist der Moment, in dem ein Intune-Administrator vom „Software-Verteiler“ zum „Endpoint-Architekten“ wird. In dieser Sektion analysieren wir die logischen Ketten, mit denen wir sicherstellen, dass Software in der exakt richtigen Reihenfolge installiert wird und veraltete Versionen sauber ersetzt werden, ohne das System zu destabilisieren.

Grundkonzepte: Abhängigkeiten vs. Supersedence

Bevor wir in die Konfiguration gehen, müssen wir die fundamentale Logik verstehen. Es gibt zwei unterschiedliche Mechanismen, die oft verwechselt werden, aber völlig verschiedene Zwecke erfüllen.

App Dependencies (Abhängigkeiten)

Eine Abhängigkeit ist eine Voraussetzung. Wenn App B eine Abhängigkeit von App A hat, bedeutet das: „Bevor App B überhaupt versucht zu starten, muss App A bereits erfolgreich installiert sein.“

Logik: Wenn A fehlt → Installiere A → Wenn A Erfolg → Installiere B.
Ziel: Sicherstellen, dass die notwendige Infrastruktur (Runtime, Treiber, Basis-Software) vorhanden ist.
Beispiel: Ein proprietäres ERP-Tool benötigt zwingend den Java Runtime Environment (JRE). Das ERP-Tool ist App B, die JRE ist App A.

App Supersedence (Ersetzung)

Supersedence ist ein Upgrade-Pfad. Es definiert, dass eine neue Version einer App eine alte Version ersetzt.

Logik: Wenn Version 1.0 vorhanden ist → Installiere Version 2.0 → (Optional) Deinstalliere Version 1.0.
Ziel: Lebenszyklus-Management von Software und Vermeidung von Versions-Wildwuchs.
Beispiel: Google Chrome 120 wird durch Chrome 121 ersetzt.

Praxis-Implementierung: App-Ketten aufbauen

Schritt 1: Die Basis-Apps (Dependencies) vorbereiten

Der größte Fehler bei Abhängigkeiten ist, sie „on the fly“ zu lösen. Damit eine Dependency-Kette funktioniert, muss jede App in der Kette als eigenständige Win32-App in Intune existieren. Sie muss eine valide Detection Rule besitzen, denn Intune prüft vor der Installation der Haupt-App, ob die Dependency bereits erkannt wird. Wenn die Detection Rule der Dependency fehlschlägt, wird die Kette ausgelöst.

Ein klassisches Szenario ist die Installation von Microsoft Visual C++ Redistributables. Da diese oft in verschiedenen Versionen (2015, 2017, 2019, 2022) benötigt werden, empfiehlt es sich, diese als einzelne „Silent-Installer“ Apps anzulegen.

Schritt 2: Die Verknüpfung konfigurieren

Wenn Sie nun die Haupt-App (z. B. ein CAD-Programm) erstellen, navigieren Sie im Tab Dependencies zu „Add“. Hier wählen Sie die vorbereiteten Basis-Apps aus. Sie haben zwei Optionen:

Automatically install dependency: Intune installiert die Abhängigkeit automatisch, falls sie nicht erkannt wird. (Standard und empfohlen).
Manual: Der Benutzer muss die Abhängigkeit selbst installieren (praktisch nie in Enterprise-Szenarien genutzt).

# Logischer Ablauf einer Dependency-Kette in Intune:
[Client] → Prüft Haupt-App (App B)
[Intune] → Erkennt Dependency (App A)
[Client] → Prüft Detection Rule von App A
[Ergebnis: Nicht vorhanden] → Installiere App A (Silent)
[Ergebnis: Erfolg] → Installiere App B (Silent)
[Ergebnis: Fehler] → Abbruch der Installation von App B (Status: Failed)

Schritt 3: Supersedence konfigurieren

Beim Ersetzen einer App wählen Sie in der neuen App (V2) unter dem Tab Supersedence die alte App (V1) aus. Hier gibt es eine kritische Einstellung: Uninstall previous version.

Uninstall = No: Die neue App wird über die alte installiert. Dies funktioniert nur, wenn der Installer der neuen Version dies nativ unterstützt (In-place Upgrade).
Uninstall = Yes: Intune führt zuerst den Deinstallationsbefehl von V1 aus und installiert danach V2. Dies ist sicherer, aber zeitintensiver und kann Neustarts provozieren.

Best Practices für komplexe App-Strukturen

Die „Golden Dependency“ Strategie

Um zu vermeiden, dass Sie für jede App 10 einzelne Abhängigkeiten (JRE, .NET, C++, etc.) manuell zuweisen müssen, nutzen Sie Bundle-Apps oder eine „Base-Environment App“. Erstellen Sie ein PowerShell-Skript, das alle gängigen Runtimes prüft und installiert, und paketieren Sie dieses als einzige Win32-App „Enterprise Base Runtime“. Jede weitere App hat dann nur noch diese eine Abhängigkeit.

# Beispiel: Base-Runtime Checker (Fragment)
$RequiredRuntimes = @{
    "VC_2015-2022" = "C:\Windows\System32\vcruntime140.dll"
    "DotNet_48" = "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full"
}

foreach ($Runtime in $RequiredRuntimes.GetEnumerator()) {
    if (-not (Test-Path $Runtime.Value)) {
        Write-Host "Installing $($Runtime.Key)..."
        Start-Process "install_$($Runtime.Key).exe" -ArgumentList "/silent" -Wait
    }
}

Vermeidung von Circular Dependencies

Ein fataler Fehler ist die zirkuläre Abhängigkeit: App A benötigt App B, und App B benötigt App A. Intune wird in diesem Fall die Installation mit einem Fehler abbrechen. Planen Sie Ihre Kette immer linear: Infrastruktur → Middleware → Endanwendung.

Supersedence bei „Evergreen“ Apps

Für Software, die sich wöchentlich aktualisiert (wie Browser), ist Supersedence oft zu starr. Hier ist es effizienter, den Auto-Updater der App zu nutzen. Supersedence sollte für Major Releases (z. B. von v10 auf v11) oder für Software ohne eigenen Auto-Updater verwendet werden.

Troubleshooting: Wenn die Kette reißt

Problem: Dependency wird installiert, aber Haupt-App schlägt fehl

Dies liegt meist an einem Timing-Problem oder einem fehlenden Neustart. Viele Runtimes benötigen einen Reboot, bevor die nachfolgende App sie erkennt. Da Intune jedoch versucht, die Kette in einem Durchgang zu erledigen, schlägt die Haupt-App fehl.

Lösung: Prüfen Sie, ob Sie im Installer der Dependency ein „Soft-Reboot“ erzwingen können oder nutzen Sie die Intune-Option „Device Restart Behavior“, um einen Neustart zu signalisieren. In extremen Fällen müssen Sie die Dependency-Kette aufteilen und die Apps in unterschiedlichen Gruppen mit zeitlichem Versatz zuweisen.

Problem: Supersedence löst Deinstallation nicht aus

Wenn „Uninstall previous version“ auf „Yes“ steht, aber die alte App bleibt, prüfen Sie die Uninstall-Command der alten App. Wenn der Deinstallationsbefehl in der ursprünglichen App-Konfiguration falsch war, kann auch Supersedence ihn nicht reparieren. Intune nutzt exakt den Befehl, der in der ursprünglichen App-Definition hinterlegt wurde.

Analyse via Log-Files

Die Wahrheit liegt immer in den Logs. Für Win32-Apps finden Sie die entscheidenden Informationen hier:

Pfad: C:\Windows\CCM\Logs (bei Co-Management) oder C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
Datei: IntuneManagementExtension.log

Suchen Sie nach den Keywords [Win32App] und Dependency. Dort sehen Sie genau, welche Detection Rule gefeuert hat und warum die Kette gestoppt wurde.

Fazit

App Dependencies und Supersedence verwandeln Intune von einem einfachen Tool zum mächtigen Orchestrierungssystem. Während Dependencies die statische Voraussetzung sichern, steuert Supersedence die dynamische Evolution Ihrer Software-Landschaft.

Merken Sie sich die goldene Regel: Die Detection Rule ist das Herzstück. Ohne eine präzise Detection Rule ist jede Abhängigkeit ein Glücksspiel. Wenn Sie Ihre Runtimes zentralisieren, Ihre Ketten linear planen und Ihre Deinstallationsbefehle validieren, eliminieren Sie 90 % aller Deployment-Fehler in Ihrer Umgebung.

In der nächsten Sektion werden wir uns ansehen, wie wir diese Logik nutzen, um komplexe Software-Suites mit mehreren Komponenten automatisiert auszurollen.