Sektion 44: Enterprise App Catalog: Drittanbieter-Apps ohne Paketierung

In den letzten Sektionen haben wir Apps selbst paketiert, Detection Rules gebaut, Updates per Supersedence ausgerollt und mit Microsoft 365 Apps die Sonderrolle der „Evergreen“-Apps kennengelernt. Das funktioniert, kostet aber Zeit. Jede neue Version von 7-Zip, Notepad++, Firefox oder Zoom heißt: herunterladen, testen, als .intunewin verpacken, Detection anpassen, Supersedence einrichten. Bei 50 Drittanbieter-Apps ist das ein Vollzeitjob.

Genau hier setzt Enterprise App Management (EAM) an. Microsoft stellt mit dem Enterprise App Catalog eine Sammlung fertig vorbereiteter Win32-Apps bereit, die Sie direkt aus dem Intune Admin Center auswählen und zuweisen. In dieser Sektion schauen wir uns an, wie der Katalog technisch funktioniert, wie Sie eine Katalog-App sauber anlegen, welcher Update-Weg wann passt und wo die Grenzen liegen.

Grundkonzepte: Was ist der Enterprise App Catalog?

Win32-Apps, die Microsoft für Sie paketiert

Eine Katalog-App ist technisch eine ganz normale Win32-App (siehe Sektion 31). Der Unterschied: Microsoft hat das Paket bereits vorbereitet und hostet die Inhalte selbst. Beim Anlegen füllt Intune folgende Werte automatisch aus:

• Installations- und Deinstallationsbefehl
• Installationsdauer, Neustartverhalten und Return Codes
• Installationskontext (System oder Benutzer)
• Detection Rules auf Basis von Datei, Dateiversion oder Registry
• Requirements wie Architektur und minimale Windows-Version

Installiert wird über die Intune Management Extension (IME), also über denselben Agenten wie bei Ihren eigenen Win32-Apps. Die Inhalte kommen aus Microsoft-Speicher über *.manage.microsoft.com. Wichtig: EAM nutzt nicht WinGet. Das ist ein anderer Weg als die Microsoft Store Apps aus Sektion 39.

Lizenz und Voraussetzungen

Enterprise App Management ist ein Zusatz-Abo zu Microsoft Intune Plan 1 oder Plan 2. Sie bekommen es als eigenständiges Add-on oder als Teil der Microsoft Intune Suite. Prüfen Sie vor dem Start, ob Ihr Tenant lizenziert ist. Ohne Lizenz taucht der App-Typ beim Erstellen gar nicht erst auf.

Dazu kommen zwei technische Voraussetzungen:

• Nur Windows: Der Katalog umfasst ausschließlich Windows-Apps (EXE und MSI).
• 64-Bit-Windows: EAM unterstützt nur verwaltete Geräte mit 64-Bit-Windows. Für 32-Bit-Betriebssysteme müssten Sie die vorausgefüllten Werte anpassen. In der Praxis spielt das kaum noch eine Rolle.

Produkte und Varianten

Im Katalog gibt es pro Produkt oft mehrere Varianten, etwa nach Sprache, Architektur oder Installer-Typ. Firefox gibt es in Dutzenden Sprachvarianten, Chrome als MSI- und als EXE-Variante. Die Wahl der richtigen Variante ist wichtiger, als es aussieht. Wenn Sie eine EXE-Variante auf ein Gerät bringen, auf dem dieselbe App bereits als MSI installiert ist, landen Sie schnell bei einer Parallelinstallation.

Praxis-Implementierung: Eine Katalog-App anlegen

Schritt 1: App auswählen

Im Intune Admin Center gehen Sie zu Apps > Alle Apps > Erstellen und wählen als App-Typ unter Windows Enterprise App Catalog app. Über Search the Enterprise App Catalog suchen Sie die App, zum Beispiel 7-Zip, und wählen anschließend das konkrete Paket nach Name, Sprache, Architektur und Version aus. Name, Beschreibung, Herausgeber und Version werden übernommen. Ergänzen Sie Kategorie, Besitzer und ein Logo, damit die App im Unternehmensportal sauber aussieht.

Schritt 2: Programm, Requirements und Detection

Auf den Seiten Programm, Anforderungen und Erkennungsregeln ist bereits alles vorausgefüllt. Hier gilt eine einfache Regel: Lesen, verstehen, so lassen. Microsoft empfiehlt ausdrücklich, die vorbelegten Befehle und Regeln zu verwenden. Das Installationsverhalten (System oder Benutzer) legt EAM anhand des Installers fest und lässt sich nicht ändern.

Anpassen sollten Sie nur, was zu Ihrer Umgebung gehört:

• Geräteneustartverhalten: Bei Tools wie 7-Zip ist „Keine bestimmte Aktion“ meist richtig.
• Deinstallation im Unternehmensportal zulassen: Für Pflicht-Apps auf „Nein“.
• Zusätzliche Requirement Rules: Etwa wenn die App nur auf Geräten mit einem bestimmten Registry-Wert landen soll.

Werfen Sie trotzdem einen kurzen Blick auf die Detection Rules. Sie basieren auf Datei, Dateiversion oder Registry, und Sie kennen die Logik aus Sektion 33. In seltenen Fällen prüft die Regel eine DLL-Version, die nicht zur angezeigten App-Version passt. Das ist kein Fehler, sollte Sie aber nicht überraschen, wenn Sie später Berichte vergleichen.

Optional: PowerShell-Skript statt Standardbefehl

Brauchen Sie zusätzliche Schritte, etwa eine Konfigurationsdatei nach der Installation, können Sie bei Installer type statt „Command line“ ein eigenes PowerShell script hinterlegen (maximal 50 KB). Das Skript ersetzt dann den Standardbefehl komplett. Es muss also den Installer selbst mit den richtigen Parametern aufrufen. Intune prüft danach wie gewohnt die Detection Rules. Zwei Stolpersteine:

• Keine Passwörter oder Secrets ins Skript schreiben. Skripte werden im Klartext gespeichert und können im Agent-Log landen.
• Beim Update per Supersedence wird das Skript nicht übernommen. Sie müssen es für die neue Version erneut hochladen.

Ist in Ihrem Tenant Multi-Admin Approval aktiv, können Sie beim Anlegen keine Skripte hochladen. Erst App erstellen, dann Skript ergänzen.

Schritt 3: Zuweisen

Die Zuweisung funktioniert wie bei jeder Win32-App mit Erforderlich, Verfügbar für registrierte Geräte oder Deinstallieren (siehe Sektion 36). Neu ist bei Erforderlich-Zuweisungen der Schalter für Auto-Update. Den schauen wir uns jetzt genauer an, denn er verändert Ihren gesamten Update-Prozess.

Updates: Auto-Update oder Guided Supersedence?

Weg 1: Guided Update Supersedence

Ohne Auto-Update bleibt die App auf der Version, die Sie angelegt haben. Neue Versionen zeigt Intune unter Apps > Überwachen > Enterprise App Catalog apps with updates an, inklusive installierter und neuester verfügbarer Version. Mit Update > Supersede app erzeugt Intune eine neue App mit dem aktuellen Paket und legt die Supersedence-Beziehung automatisch an. Das ist im Prinzip der Workflow aus Sektion 35 und 42, nur ohne Paketieren.

Achtung: Zuweisungen und Scope Tags werden nicht übernommen. Die neue App ist wie eine frisch angelegte. Genau das ist aber auch der Vorteil: Sie können die neue Version zuerst nur Ihrer Pilotgruppe zuweisen und erst danach breit ausrollen.

Weg 2: Auto-Update

Aktivieren Sie Auto-Update bei einer Erforderlich-Zuweisung, erkennt Intune neue Versionen im Katalog und aktualisiert die Geräte selbstständig. Keine neue App, keine Supersedence. Das klingt perfekt, hat aber klare Grenzen, die Microsoft selbst dokumentiert:

• Keine Ringe: Eine neue Version geht an alle zugewiesenen Geräte gleichzeitig. Es gibt keine gestaffelte Verteilung.
• Kein Rollback: Bei einer fehlerhaften Version müssen Sie selbst eingreifen, etwa per Deinstallations-Zuweisung oder Remediation.
• Nicht als blockierende App in ESP oder Autopilot Device Preparation: Auto-Update-Apps können Sie dort nicht auswählen.
• Nur Erforderlich: Verfügbar-Zuweisungen nutzen weiterhin den klassischen Update-Weg.
• Berichte zeigen nur den aktuellen Stand: Eine Versionshistorie pro Gerät gibt es nicht.

Self-updating Apps

Einige Katalog-Apps aktualisieren sich selbst über den Mechanismus des Herstellers, zum Beispiel Browser. Bei diesen prüft Intune nur eine Mindestversion: Ist die gefundene Version gleich oder höher, gilt die App als installiert. Das ist dieselbe Denkweise wie bei Office in Sektion 43. Denken Sie daran, dass die Geräte dafür die Update-Server des Herstellers erreichen müssen. Eine restriktive Firewall bremst sonst genau diese Updates aus.

Welcher Weg passt wann?

Eine pragmatische Faustregel aus der Praxis:

• Auto-Update für einfache, unkritische Tools ohne Abhängigkeiten: 7-Zip, Notepad++, PDF-Reader, Bildbetrachter.
• Guided Supersedence für Apps mit Geschäftsrelevanz oder Plugins: VPN-Clients, Java-Runtimes, Tools mit Add-ins für Office. Hier wollen Sie Pilotgruppe und Freigabe.
• Eigene Paketierung (Sektion 32 und 38) für alles, was nicht im Katalog steht oder eine stark angepasste Konfiguration braucht.

Den Katalog mit PowerShell durchsuchen

Die Auswahl im Admin Center ist für einzelne Apps praktisch. Für den Überblick, etwa „Welche unserer 40 Drittanbieter-Apps gibt es im Katalog?“, ist Microsoft Graph schneller. Der Katalog liegt auf dem beta-Endpunkt unter deviceAppManagement/mobileAppCatalogPackages. Sie brauchen nur das Modul Microsoft.Graph.Authentication und die Leseberechtigung DeviceManagementApps.Read.All:

# Enterprise App Catalog durchsuchen (nur lesend)
# Voraussetzung: Install-Module Microsoft.Graph.Authentication -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementApps.Read.All" -NoWelcome

$uri = "https://graph.microsoft.com/beta/deviceAppManagement/mobileAppCatalogPackages"
$packages = [System.Collections.Generic.List[object]]::new()

do {
    $response = Invoke-MgGraphRequest -Method GET -Uri $uri -OutputType PSObject
    $response.value | ForEach-Object { $packages.Add($_) }
    $uri = $response.'@odata.nextLink'
} while ($uri)

Write-Output "Katalog-Einträge gesamt: $($packages.Count)"

# Beispiel: Welche Varianten von 7-Zip und Notepad++ gibt es?
$suche = "7-Zip", "Notepad++"
$packages |
    Where-Object { $name = $_.productDisplayName; $suche | Where-Object { $name -like "*$_*" } } |
    Select-Object publisherDisplayName, productDisplayName, branchDisplayName,
                  versionDisplayName, packageAutoUpdateCapable |
    Sort-Object productDisplayName, branchDisplayName |
    Format-Table -AutoSize

branchDisplayName ist die Variante (z.B. Sprache und Architektur), versionDisplayName die aktuell angebotene Version und packageAutoUpdateCapable zeigt, ob sich die App selbst aktualisieren kann.

Mit einem zweiten Aufruf sehen Sie, welche Katalog-Apps bereits in Ihrem Tenant angelegt sind. Katalog-Apps haben in Graph den Typ win32CatalogApp:

# Im Tenant angelegte Enterprise-App-Catalog-Apps auflisten
$uri = "https://graph.microsoft.com/beta/deviceAppManagement/mobileApps?`$filter=isof('microsoft.graph.win32CatalogApp')"
$apps = [System.Collections.Generic.List[object]]::new()

do {
    $response = Invoke-MgGraphRequest -Method GET -Uri $uri -OutputType PSObject
    $response.value | ForEach-Object { $apps.Add($_) }
    $uri = $response.'@odata.nextLink'
} while ($uri)

$apps |
    Select-Object displayName, displayVersion, publisher, lastModifiedDateTime |
    Sort-Object displayName |
    Format-Table -AutoSize

Beide Skripte lesen nur. Für Automatisierungen, die Apps anlegen oder ändern, empfiehlt Microsoft bei Skript-Installern übrigens das Admin Center statt direkter Graph-Änderungen, da diese die Skripte beschädigen können.

Best Practices für den Katalog-Einsatz

• Eine App, ein Weg: Verwalten Sie eine App nie gleichzeitig als eigene Win32-App und als Katalog-App. Bei Auto-Update kann das in einem Wettlauf enden, bei dem die installierte Version ständig hin und her springt. Wenn Sie migrieren, weisen Sie die alte App zuerst ab oder lösen Sie sie per Supersedence ab.
• Variante bewusst wählen: Prüfen Sie vor dem Rollout, ob im Bestand bereits MSI- oder EXE-Installationen der App liegen, und wählen Sie die passende Variante.
• Sicherheit bleibt Ihre Aufgabe: Microsoft paketiert die Apps, übernimmt aber keine Garantie für deren Compliance oder Integrität. Wird eine schadhafte Version entdeckt, entfernt Microsoft sie aus dem Katalog und informiert im Admin Center. Betroffene Geräte finden und bereinigen müssen Sie selbst.
• Lizenzen der Hersteller: Der Katalog enthält auch lizenzpflichtige Software. Intune prüft keine Lizenzen. Die müssen Sie wie bisher beim Hersteller kaufen.
• Update-Zeiten einplanen: Laut Microsoft sind die meisten neuen Versionen innerhalb von 24 Stunden im Katalog, manuell geprüfte Updates innerhalb von sieben Tagen. Für Zero-Day-Patches kann das zu langsam sein. Halten Sie für kritische Apps einen Plan B bereit.
• Autopilot nutzen: Katalog-Apps lassen sich in ESP und Autopilot Device Preparation als blockierende Apps auswählen, aber nur ohne Auto-Update.

Troubleshooting: Wenn die Katalog-App nicht ankommt

„Content is still being prepared“

Nach dem Anlegen bereitet Intune die Inhalte vor. Das dauert normalerweise nur kurz. Hängt die App auch nach mehreren Stunden noch in diesem Status, empfiehlt Microsoft, die App zu löschen und neu anzulegen.

Installation schlägt auf dem Client fehl

Da Katalog-Apps über die IME laufen, gilt der Werkzeugkasten aus Sektion 41: IntuneManagementExtension.log und AppWorkload.log unter C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Typische Ursachen:

• Download scheitert: Proxy oder Firewall blockieren *.manage.microsoft.com.
• App wird nicht erkannt: Eine ältere, selbst paketierte Version oder eine andere Variante liegt bereits auf dem Gerät und passt nicht zur Detection Rule.
• Eigenes Install-Skript: Das Skript ruft den Installer mit falschen Parametern auf oder erwartet Benutzerinteraktion.

Version auf dem Gerät prüfen

Für eine schnelle Kontrolle direkt am Gerät reicht ein Blick in die Uninstall-Schlüssel der Registry. Dieses Skript zeigt Name, Version und Herausgeber einer App, egal ob 64- oder 32-Bit-Installation:

# Installierte Version einer App aus den Uninstall-Schlüsseln lesen
$appName = "7-Zip"

$paths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

$found = Get-ItemProperty -Path $paths -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -like "*$appName*" } |
    Select-Object DisplayName, DisplayVersion, Publisher, PSChildName

if ($found) {
    $found | Format-Table -AutoSize
} else {
    Write-Output "$appName ist auf $env:COMPUTERNAME nicht installiert."
}

Tauchen hier zwei Einträge derselben App auf, haben Sie mit hoher Wahrscheinlichkeit eine Parallelinstallation aus MSI- und EXE-Variante.

Fazit

Der Enterprise App Catalog nimmt Ihnen den mühsamsten Teil des App-Managements ab: das Paketieren und Nachpflegen von Standard-Software. Er ersetzt aber nicht Ihr Wissen über Win32-Apps. Detection Rules, Supersedence, Return Codes und die IME-Logs aus den letzten Sektionen brauchen Sie weiterhin, nur seltener.

Zusammenfassend für Ihren Workflow:

• Prüfen Sie Lizenz und Katalog-Abdeckung Ihrer Drittanbieter-Apps, gern per Graph-Skript.
• Übernehmen Sie die vorausgefüllten Befehle und Regeln und passen Sie nur Neustart, Deinstallation und Zuweisung an.
• Nutzen Sie Auto-Update für unkritische Tools und Guided Supersedence mit Pilotgruppe für alles Wichtige.
• Verwalten Sie jede App nur über einen einzigen Weg.

In der nächsten Sektion geht es darum, wie Sie Apps mit Assignment-Filtern und Gruppen gezielt an die richtigen Geräte bringen.

Quellen

• Microsoft Learn: Microsoft Intune Enterprise Application Management
• Microsoft Learn: Add an Enterprise App Catalog app to Microsoft Intune
• Microsoft Learn: Guided Update Supersedence for Enterprise App Management
• Microsoft Learn: Get-MgBetaDeviceAppManagementMobileAppCatalogPackage

↑ Zur Kursübersicht: Intune-Kurs (alle Sektionen)