Zum Inhalt
Kaffeeundcode

Sektion 42: Managing App Updates: Versioning Strategien

Learning 7 Min. Lesezeit

Die Verwaltung von App-Updates ist einer der kritischsten und gleichzeitig fehleranfälligsten Bereiche im modernen Endpoint Management. In einer idealen Welt würden Apps sich selbst aktualisieren, ohne die Systemstabilität zu gefährden oder die Bandbreite im Firmennetzwerk zu sprengen. In der Realität führt ein falsch getimtes Update oft zu „Broken Workflows“, inkompatiblen Plugins oder im schlimmsten Fall zu einem kompletten Produktivitätsausfall ganzer Abteilungen.

In dieser Masterclass-Sektion tauchen wir tief in die Versionierungsstrategien ein. Wir betrachten nicht nur, wie man einen Knopf in Intune drückt, sondern wie man ein Framework aufbaut, das Updates vorhersehbar, testbar und skalierbar macht. Wir unterscheiden dabei strikt zwischen den verschiedenen Deployment-Typen, da die Update-Logik bei Win32-Apps, Microsoft Store Apps (New) und Edge-basierten Lösungen fundamental divergiert.

1. Grundkonzepte: Die Anatomie der App-Versionierung

Bevor wir Tools konfigurieren, müssen wir verstehen, wie Intune „weiß“, ob eine App aktualisiert werden muss. Das Herzstück ist die Detection Rule (Erkennungsregel). Während die Installation eine App auf ein Gerät bringt, bestimmt die Erkennungsregel, ob die App bereits vorhanden ist und – entscheidend für Updates – welche Version installiert ist.

1.1. Die Logik des Updates in Intune

Intune hat keinen eingebauten „Update-Button“ für Win32-Apps. Ein Update wird technisch gesehen als ein neues Deployment betrachtet, das die bestehende Version ersetzt. Der Prozess folgt diesem Ablauf:

  • Versionserkennung: Intune prüft via Detection Rule, ob die aktuell installierte Version mit der im Paket definierten Version übereinstimmt.
  • Supersedence (Ersetzung): Wenn eine App eine andere „ersetzt“ (Supersede), wird die alte App als „überholt“ markiert und die neue App zur Installation vorgelegt.
  • Installations-Trigger: Die neue Version wird installiert, wobei die Installationsparameter darüber entscheiden, ob die alte Version sauber deinstalliert oder einfach „überbügelt“ (In-place Upgrade) wird.

1.2. Versionstypen und ihre Bedeutung

Wir unterscheiden in der Praxis drei Strategien der Versionierung:

  • Semantic Versioning (SemVer): (z.B. 2.4.1) – Major.Minor.Patch. Hier wissen wir: Ein Patch-Update ist sicher, ein Major-Update erfordert Tests.
  • Build-Nummern: (z.B. 2023.11.05.1200) – Oft bei internen Apps genutzt. Hier ist die zeitliche Abfolge das einzige Kriterium.
  • Evergreen/Rolling: (z.B. Chrome, Teams) – Die App aktualisiert sich selbst. Hier ist die Aufgabe von Intune nicht die Verteilung, sondern die Überwachung und ggf. die Kontrolle des Update-Zyklus.

2. Praxis-Implementierung: Strategien für verschiedene App-Typen

2.1. Win32-Apps und die Macht der Supersedence

Für klassische .exe oder .msi Pakete ist die Supersedence-Funktion das wichtigste Werkzeug. Wenn Sie Version 1.0 einer App haben und Version 2.0 deployen wollen, erstellen Sie eine neue Win32-App für V2.0 und konfigurieren unter „Supersedence“ die Version 1.0 als zu ersetzende App.

Hier gibt es zwei entscheidende Optionen:

  • Uninstall previous version: Ja $\rightarrow$ Intune führt den Deinstallationsbefehl von V1.0 aus, bevor V2.0 installiert wird. Sicher, aber zeitaufwendiger und oft mit Neustarts verbunden.
  • Uninstall previous version: Nein $\rightarrow$ V2.0 wird einfach installiert. Wenn das Installationsprogramm der App ein In-place Upgrade unterstützt (wie es die meisten modernen Installer tun), ist dies der effizienteste Weg.

2.2. Die perfekte Detection Rule für Updates

Ein häufiger Fehler ist die Nutzung von „File exists“ als Erkennungsregel. Für Updates ist das fatal, da die Datei bei V1.0 und V2.0 oft gleich heißt. Nutzen Sie stattdessen die MSI-Produktcodes oder die Registry-Abfrage der Versionsnummer.

Beispiel für eine Registry-basierte Detection Rule (JSON-Logik):

{
  "KeyPath": "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\{Your-App-GUID}",
  "DetectionValue": "2.4.1",
  "DetectionMethod": "String",
  "Operator": "Equals"
}

Wenn Sie eine „Greater than or equal to“ Logik benötigen (um z.B. alle Versionen ab 2.0 als „installiert“ zu markieren), müssen Sie auf Custom Detection Scripts (PowerShell) ausweichen.

2.3. Custom Detection Scripts für komplexe Versionierung

Wenn die Registry lügt oder Dateien in dynamischen Pfaden liegen, ist PowerShell die einzige Lösung. Ein Masterclass-Script prüft nicht nur die Existenz, sondern vergleicht Versionsobjekte.

# Detection Script für Version 2.4.1
$minVersion = [version]"2.4.1"
$appPath = "${env:ProgramFiles}\MyCompany\MyApp\app.exe"

if (Test-Path $appPath) {
    $currentVersion = [version](Get-Item $appPath).VersionInfo.FileVersion
    if ($currentVersion -ge $minVersion) {
        # Intune interpretiert alles, was in den Output geschrieben wird, 
        # und einen Exit Code 0 als "Installiert/Gefunden"
        Write-Output "Installed version $currentVersion is compliant."
        exit 0
    }
}

# Wenn nichts gefunden wird oder Version zu niedrig ist: Exit 1 (Nicht installiert)
exit 1

3. Versioning Strategien im Enterprise-Umfeld

3.1. The Ring-Based Deployment Model

Installieren Sie Updates niemals gleichzeitig auf allen Geräten. Implementieren Sie ein Ring-Modell, um die „Blast Radius“ (Ausfallrate) zu minimieren:

  • Ring 0 (Canary): IT-Abteilung und Early Adopters (1-5% der Geräte). Sofortiges Deployment.
  • Ring 1 (Pilot): Key User aus verschiedenen Fachabteilungen (10-20%). Deployment nach 3 Tagen Stabilität in Ring 0.
  • Ring 2 (Broad): Gesamte Organisation. Deployment nach einer Woche ohne kritische Tickets.

3.2. Umgang mit „Evergreen“ Apps

Apps wie Google Chrome oder Microsoft Edge aktualisieren sich selbst. Es ist ein administrativer Albtraum, diese als Win32-Apps zu versionieren. Die richtige Strategie hier ist: Infrastructure over Packaging.

Nutzen Sie Administrative Templates (ADMX) in Intune, um die Update-Kanäle zu steuern, anstatt die Binärdateien selbst zu verteilen. So stellen Sie sicher, dass alle Nutzer auf dem „Stable Channel“ sind, während die App-eigene Update-Logik die Arbeit erledigt.

4. Best Practices für das App-Lifecycle-Management

Um die Versionsverwaltung langfristig wartbar zu halten, sollten Sie folgende goldene Regeln befolgen:

  • Einheitliche Benennung: Benennen Sie Apps konsistent. Beispiel: [Software] Name vX.X.X - Architecture. Das erleichtert die Suche und die Zuordnung in der Supersedence-Liste.
  • Vermeidung von „App-Wildwuchs“: Wenn Sie eine App aktualisieren, löschen Sie die alte App-Version nicht sofort aus Intune, sondern entfernen Sie die Zuweisungen. Nur so bleibt die Historie gewahrt und die Supersedence-Kette stabil.
  • Packaging-Automatisierung: Nutzen Sie Tools wie den IntuneWinAppUtil.exe in Kombination mit PowerShell-Scripts, um die Erstellung der .intunewin Pakete zu standardisieren.
  • Dokumentation der Installer-Switches: Notieren Sie sich für jede App, ob sie /silent, /quiet oder /norestart benötigt. Nichts ist ärgerlicher als ein Update, das an einem versteckten „OK“-Dialog auf 500 Geräten hängen bleibt.

5. Troubleshooting: Wenn das Update scheitert

Update-Probleme äußern sich in Intune meist durch den Status „Failed“ oder „Pending“. Hier ist der Schlachtplan zur Analyse:

5.1. Die Log-Files analysieren

Intune schreibt alles in die Intune Management Extension (IME) Logs. Diese finden Sie unter: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.

Suchen Sie im IntuneManagementExtension.log nach folgenden Begriffen:

  • [Detection]: Hier sehen Sie, ob die Detection Rule die App fälschlicherweise als „installiert“ erkannt hat (und das Update daher übersprang).
  • [Supersedence]: Hier wird geloggt, ob die alte Version erfolgreich deinstalliert wurde.
  • [Execution]: Hier finden Sie den Exit-Code des Installers. Ein Code 1603 deutet oft auf fehlende Rechte oder eine bereits installierte Version hin, die den Installer blockiert.

5.2. Häufige Fehlerquellen und Lösungen

  • Problem: Update wird nicht getriggert.
    Ursache: Die Detection Rule der neuen Version ist zu „tolerant“ und erkennt die alte Version bereits als erfüllt an.
    Lösung: Versionen in der Registry präzise prüfen (Equals statt Greater Than).
  • Problem: App wird in einer Endlosschleife installiert/deinstalliert.
    Ursache: Die Installation von V2.0 schlägt fehl, aber die Supersedence-Regel hat V1.0 bereits deinstalliert. Intune versucht es erneut, da die Detection Rule von V2.0 nicht erfüllt ist.
    Lösung: Testen Sie den Installer manuell in einer VM mit der exakt gleichen Vorversion.
  • Problem: Neustart-Hölle.
    Ursache: Die App erzwingt einen Neustart, der von Intune nicht abgefangen wird.
    Lösung: Nutzen Sie die Intune-Option „Device Restart Behavior“ $\rightarrow$ „Intune will force a mandatory device restart“.

6. Fazit

Effektives App-Update-Management in Intune ist weniger eine Frage der Tool-Beherrschung als vielmehr eine Frage der Strategie. Wer blind auf Supersedence setzt, ohne die Detection Rules präzise zu definieren, baut sich eine technische Schuld auf, die bei der nächsten Major-Version explodiert.

Zusammenfassend für Ihren Workflow:
1. Definieren Sie eine präzise Detection Rule (Registry oder Script).
2. Nutzen Sie Supersedence für den Übergang von Alt zu Neu.
3. Rollen Sie in Ringen aus (Canary $\rightarrow$ Pilot $\rightarrow$ Broad).
4. Überwachen Sie die IME-Logs bei den ersten 5% der Geräte.

Mit diesem systematischen Ansatz verwandeln Sie das App-Update-Chaos in einen kontrollierten Prozess, der die Systemstabilität erhöht und den Administrationsaufwand massiv senkt.