Sektion 36: App Monitoring & Troubleshooting – Win32-Deployments analysieren

Intune A–Z Mastercourse · Sektion 36 · Stand: Oktober 2026

Eine Win32-App ist in Intune angelegt, einer Gruppe zugewiesen und das Paket wurde hochgeladen – trotzdem steht der Installationsstatus auf Fehlgeschlagen oder Nicht erkannt. In dieser Lektion lernst du, wie du die Ursache reproduzierbar eingrenzt, die richtigen Clientlogs liest und einen belastbaren Nachweis für erfolgreiche Bereitstellungen erstellst.

Voraussetzungen: Grundwissen zu .intunewin-Paketen, Installationsbefehlen, Erkennungsregeln sowie App-Abhängigkeiten und Supersedence aus den vorherigen Lektionen.

1. Die fünf Phasen einer Win32-App-Bereitstellung

Zuweisung: Trifft die App-Zuweisung auf den Benutzer oder das Gerät zu?
Anwendbarkeit: Werden Voraussetzungen, Betriebssystem und Requirements erfüllt?
Download: Kann die Intune Management Extension (IME) das Paket herunterladen?
Installation: Führt der Client den richtigen Installationsbefehl mit dem passenden Kontext aus?
Erkennung und Status: Findet Intune die App nach der Installation anhand der definierten Detection Rule?

Diese Trennung ist wichtig: Ein erfolgreich beendeter Installer bedeutet noch nicht automatisch, dass Intune die Anwendung als installiert meldet.

2. Erstdiagnose im Intune Admin Center

Öffne Intune Admin Center und prüfe die betroffene Win32-App im Bereich Apps mit ihren Geräte- beziehungsweise Benutzerinstallationsstatus. Öffne die Installationsdetails eines betroffenen Geräts. Achte auf den gemeldeten Status, den Fehlercode und den Zeitpunkt der letzten Verarbeitung.

Prüfe anschließend die Zuweisung: Richtige Entra-Gruppe? Gewünschte Aktion Erforderlich oder Verfügbar? Ausschlussgruppe? Richtige Zuordnung zum Benutzer oder Gerät? Insbesondere bei wechselndem Benutzer- und SYSTEM-Kontext können Fehler erst am Client sichtbar werden.

Wenn verfügbar, nutze die Funktion zur Protokollsammlung in den Installationsdetails. Änderungen an Zuweisungen und Richtlinien erscheinen aufgrund der Synchronisierung nicht zwingend sofort.

3. Intune Management Extension prüfen

Die IME verarbeitet unter anderem Windows-PowerShell-Skripte und Win32-App-Bereitstellungen. Auf dem Client liegen ihre Logs normalerweise unter:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Öffne den Ordner in einer PowerShell mit passenden Berechtigungen:

$LogPath = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
Test-Path -LiteralPath $LogPath
Get-ChildItem -LiteralPath $LogPath -Filter '*.log' |
    Select-Object Name, Length, LastWriteTime |
    Sort-Object LastWriteTime -Descending

Das ist eine lesende Diagnose; es werden keine Logs gelöscht und keine Richtlinien verändert.

Die wichtigsten Protokolle

Datei	Wofür sie dient
IntuneManagementExtension.log	Agent-Check-in, Richtlinienverarbeitung und Statusmeldungen
AppWorkload.log	Win32-App-Workflow: Bewertung, Download, Installation und Erkennung
AppActionProcessor.log	App-Aktionen, Requirements und Erkennungsprüfungen
AgentExecutor.log	Ausführung von über Intune bereitgestellten PowerShell-Skripten

Die Dateinamen und ihre Zuständigkeiten dokumentiert Microsoft in der offiziellen IME-Dokumentation.

Logeinträge effizient durchsuchen

$Log = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log'
if (-not (Test-Path -LiteralPath $Log)) {
    throw 'AppWorkload.log wurde nicht gefunden. IME-Installation und Berechtigungen prüfen.'
}
Select-String -LiteralPath $Log -Pattern 'error','failed','detection','install' |
    Select-Object -Last 50

Suche möglichst zusätzlich nach der konkreten App-ID und vergleiche die Zeitstempel mit dem Intune Admin Center. Einzelne Schlüsselwörter sind nur ein Einstieg, kein Beweis für die Fehlerursache. Microsoft empfiehlt für solche Protokolle unter anderem CMTrace.

4. Die drei häufigsten Fehlerklassen

A. Der Installer schlägt fehl

Teste den Installationsbefehl mit demselben Installationsumfang und Ausführungskontext, der in Intune eingestellt ist. Unterscheide Benutzer- und SYSTEM-Installationen, prüfe die Parameter des Installers und dokumentiere seinen Rückgabecode. Im Fehlerfall können fehlende Dateien im Paket, falsche Arbeitsverzeichnisse oder nicht unterstützte Silent-Switches eine Rolle spielen.

Verwende für eigene Installer eindeutige Return Codes und richte diese in Intune passend ein. Nicht jeder von null verschiedene Exitcode bedeutet zwangsläufig denselben Fehler; beispielsweise kann ein Hersteller einen Neustart anfordern.

B. Die Erkennungsregel passt nicht

Ein Installer kann erfolgreich laufen, obwohl die Detection Rule auf den falschen Registry-Zweig oder einen nicht vorhandenen Dateipfad zeigt. Prüfe insbesondere 32-/64-Bit-Registry-Ansichten, per-user gegenüber per-machine Installationen, Dateiversionen und den Rückgabewert eigener Erkennungsskripte.

# Beispiel einer reinen Dateiexistenz-Prüfung
$ExpectedFile = 'C:\Program Files\ExampleApp\ExampleApp.exe'
if (Test-Path -LiteralPath $ExpectedFile) {
    Write-Output 'Installed'
    exit 0
}
exit 1

Beispielcharakter: Ersetze den Dateipfad durch den tatsächlichen Herstellerpfad. Für den produktiven Einsatz sollte die Erkennung je nach Anwendung zusätzlich eine geeignete Version oder ein anderes stabiles Merkmal prüfen. Anforderungen an die Skriptausgabe und den Exitcode sind in der Microsoft-Dokumentation beschrieben.

C. Die App ist nicht anwendbar

Kontrolliere Requirements, Architektur, Mindestbetriebssystem, freien Speicher, Zuordnungsgruppen und Abhängigkeiten. Eine App kann als nicht anwendbar gelten, wenn ihre definierten Voraussetzungen nicht erfüllt sind. Bei Supersedence musst du zudem prüfen, ob Ersetzung und Deinstallation der Vorgängerversion wie beabsichtigt konfiguriert wurden.

5. Ein reproduzierbarer Prüfplan

Referenzgerät bestimmen: Windows-Build, Architektur, IME-Status und Benutzerkontext notieren.
Zuweisung prüfen: Zielgruppe, Ausschlüsse, Abhängigkeiten, Requirements und Detection dokumentieren.
Logs korrelieren: Zeitstempel und App-ID in Intune sowie im AppWorkload.log abgleichen.
Installationsbefehl isoliert testen: Silent-Parameter und Return Codes auf einem Testgerät prüfen.
Erkennung isoliert testen: Sicherstellen, dass der Nachweis genau zur gewünschten Version und Installationsart passt.
Pilotdeployment wiederholen: Das korrigierte Paket zunächst auf wenigen Testgeräten prüfen, bevor eine breite Zuweisung erfolgt.

6. Was ins Support-Ticket gehört

Eine belastbare Fehlerdokumentation enthält App-Name und App-ID, Paketversion, betroffenen Benutzer-/Gerätekontext, Installations- und Erkennungsregeln, Zeitpunkt der Bereitstellung, Intune-Status, relevante Logzeilen und den tatsächlich zurückgegebenen Exitcode. Sensible Namen und Gerätekennungen sollten vor der Weitergabe anonymisiert werden.

7. Abgrenzung: WinGet, Store und Win32-App

Die hier beschriebenen IME-Logs und Detection-Regeln beziehen sich auf Win32-Apps in Microsoft Intune. Die interne Bereitstellung von Microsoft Store-App (neu) sowie lokale WinGet-Aufrufe nutzen andere Abläufe. Übertrage deshalb nicht automatisch die gleiche Fehlerbehandlung auf jeden App-Typ.

Fazit und nächste Lektion

Systematisches Troubleshooting folgt immer demselben Muster: Zuweisung → Anwendbarkeit → Download → Installation → Erkennung → Status. Mit den richtigen Logs und einer klaren Fehlerdokumentation lassen sich wiederkehrende Störungen erheblich schneller eingrenzen.

In Sektion 37 geht es anschließend darum, komplexe Installationen mit dem PowerShell App Deployment Toolkit (PSADT) besser zu strukturieren.