Wie lassen sich Microsoft-Intune-Fehlercodes und Richtlinienkonflikte eindeutig interpretieren?

Fehler- und Statussystem in Intune: Zuordnung nach Komponente, Zeitverhalten und Zustandsquellen (Konsole, Gerät, Logs)

Intune liefert kein einheitliches „Fehlerobjekt“, sondern mehrere, teils unabhängig arbeitende Statussysteme: MDM-Check-ins (Gerätemanagementkanal), Richtlinien- und Profilauswertung (CSP/MAM/Win32), Compliance-Bewertung sowie Bereitstellungszustände für Apps, Updates und Skripte. Die Konsole bildet diese Quellen in verschiedenen Kacheln und Detailansichten ab, aggregiert sie aber zeitversetzt. Dadurch entstehen typische Erscheinungsbilder wie „Erfolg“ bei einem Profil, während der Gerätezustand in Windows weiterhin abweicht, oder „Konflikt“, obwohl die wirksame Einstellung bereits feststeht.

Technisch entscheidet das Zusammenspiel aus Entra ID (Identität, Gerätestatus, Conditional Access), Plattform-Agents (z. B. Windows MDM-Client/OMA-DM, Company Portal, Management Extension) und Dienstkomponenten in Intune (Policy Engine, Compliance Service, Delivery/Content Services), welche Statusmeldungen entstehen. Eine eindeutige Interpretation gelingt nur, wenn die Meldung einer Komponente, einem Zeitpunkt im Lebenszyklus (Enrollment, Check-in, Anwendung, Remediation) und einer Zustandsquelle (Konsole, Gerät, Logs) zugeordnet wird.

Zustandsquellen und ihre Semantik: „Was“ wird gemessen, „wann“ wird es sichtbar?

Die Intune-Konsole zeigt Statuswerte meist als Ergebnis einer serverseitigen Auswertung, die auf zuletzt eingegangenen Geräteberichten basiert. Windows wiederum zeigt in den lokalen MDM-Diagnosen den Status der CSP-Anwendung, was nicht identisch mit der Intune-UI sein muss: Ein CSP kann „applied“ melden, obwohl die gewünschte Wirkung wegen lokaler Abhängigkeiten (Edition, Dienstezustand, Treiber, vorhandene GPO) ausbleibt. Umgekehrt kann Intune „Fehler“ führen, weil ein Bericht fehlt oder veraltet ist, während das Gerät den Zustand bereits korrigiert hat.

Komponentenmodell: Managementkanäle, Auswertungs-Engines und Ergebnisräume

Für die Zuordnung ist entscheidend, welcher Kanal eine Konfiguration transportiert. MDM-Richtlinien laufen bei Windows über CSPs (OMA-URI/Policy CSP) und werden vom lokalen MDM-Client verarbeitet. Win32-Apps, PowerShell-Skripte und Proactive Remediations laufen über die Intune Management Extension (IME). MAM/APP Protection greift über den App-SDK-Stack bzw. den MAM-Client. Update-Richtlinien werden zwar in Intune definiert, die tatsächliche Umsetzung erfolgt aber über Windows Update for Business/Update-Stack; Intune ist dort Steuer- und Reporting-Ebene, nicht der Installer.

Jede Engine besitzt eigene Statuscodes und Retry-Strategien. Ein „Fehler“ kann deshalb bedeuten: Der Dienst konnte nicht zustellen (Transportproblem), das Gerät konnte nicht anwenden (lokaler Fehler), die Richtlinie wurde angewendet, aber durch eine höhere Priorität übersteuert (Konflikt), oder Intune hat (noch) keinen aktuellen Bericht (stale/no data). Ohne Kanalzuordnung werden diese Bedeutungen häufig vermischt, was in der Praxis zu widersprüchlichen Interpretationen führt.

• MDM/CSP-Auswertung (Windows): zentrale Events in Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin und Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Operational; Diagnosepaket über mdmdiagnosticstool.exe -area DeviceEnrollment;DeviceProvisioning;Autopilot -cab C:\Temp\MDM.cab
• IME-Status (Win32/Skripte): Logpfad C:\ProgramData\Microsoft\IntuneManagementExtension\Logs; Dienstname IntuneManagementExtension; typische Korrelation über IntuneManagementExtension.log und App-spezifische Install/Detection-Ausgaben
• Check-in/Sync-Kanal: Geräteaktionen „Sync“ in der Konsole stößt keinen sofortigen Vollabgleich aller Workloads an; der lokale Sync-Trigger kann über dsregcmd /status (Gerätebindung) und MDM-Events nur indirekt zeitlich korreliert werden
• Entra ID-Statusquellen: Registrierung und Gerätestatus über dsregcmd /status; Sign-in/CA-Entscheidungen in Entra „Sign-in logs“ und „Audit logs“; häufige Ursache für „stimmt nicht“ zwischen Intune-Gerät und Entra-Gerät ist eine ausstehende Geräteobjekt-Aktualisierung

Zeitverhalten: Warum Fehler oft „verzögert“, „flackernd“ oder „widersprüchlich“ erscheinen

Intune arbeitet ereignis- und intervallgetrieben. Geräte melden Ergebnisse nicht kontinuierlich, sondern in Check-in-Zyklen und als Reaktion auf einzelne Workloads. Gleichzeitig kann eine Konfiguration aus mehreren Schichten bestehen: Zuweisung (wer bekommt was), Zielberechnung (Scope Tags, Filter, Gruppenmitgliedschaften), Zustellung (Push/Fetch), lokale Anwendung (CSP/IME) und schließlich Reporting. Jede Schicht besitzt eigene Zeitkonstanten und Fehlermodi; „widersprüchlich“ ist häufig nur eine Momentaufnahme aus unterschiedlichen Zeitständen.

Konfliktanzeigen entstehen zudem nicht nur durch „zwei Profile setzen denselben Wert“, sondern durch parallele Steuerungspfade: MDM versus Gruppenrichtlinie (GPO), Security Baselines versus Settings Catalog, Defender/ASR-Policies versus lokale Sicherheitssoftware, sowie Update-Ringe versus Feature Update Policies. Auf Windows zeigt sich das als teils erfolgreiche CSP-Anwendung, aber anschließendem Rückrollen oder Ignorieren durch den jeweils dominanten Stack.

Praktische Zuordnungssystematik: Von der Meldung zur betroffenen Komponente

Eine systemische Einordnung beginnt mit drei Achsen: (1) betroffener Workload (MDM/CSP, IME/Win32, Compliance, Update, MAM), (2) Zeitpunkt im Lebenszyklus (Enrollment, erste Policy-Verarbeitung, laufender Drift, Remediation) und (3) Quelle des Status (Konsole aggregiert, Gerät lokal, Entra ID-Identität). Erst danach lohnt die Detailarbeit an einzelnen Codes. Im Alltag ist die schnellste Trennlinie oft: „Kann das Gerät grundsätzlich mit Intune sprechen?“ (Check-in/Token), „Kann der lokale Agent anwenden?“ (CSP/IME) und „Ist die Zielberechnung korrekt?“ (Zuweisung/Filter/Gruppen).

• Identitäts- und Registrierungsbasis verifizieren: dsregcmd /status (AzureAdJoined/DomainJoined, DeviceId, TenantId) und Entra-Geräteobjekt gegen Intune-Gerät abgleichen; Abweichungen deuten auf Doppelregistrierung oder Objektwechsel nach Reset hin
• MDM-Anwendungspfad prüfen (CSP): Event Viewer: Applications and Services Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Admin; Fehler erscheinen dort oft vor der UI-Sichtbarkeit in Intune
• IME-Pfad prüfen (Win32/Skripte): Dienstzustand und Logs in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs; typische Ursachen sind Download/Hash, Detection Rules, Install-Exitcodes und Neustartbedingungen
• Zuweisung und Zielberechnung isolieren: Gruppenzugehörigkeit (dynamisch/statisch), Filter-Logik, Scope Tags; bei „unerklärlichem“ Status zunächst sicherstellen, dass das Gerät tatsächlich im Ziel liegt und kein Ausschluss greift
• Zeitstempel statt Statusfarbe interpretieren: In der Konsole konsequent „Last check-in“ und „Last modified“ der Richtlinie berücksichtigen; ältere Fehler ohne frischen Gerätebericht besitzen geringe Aussagekraft für den aktuellen Zustand

Mit dieser Zuordnung wird sichtbar, warum Intune-Fehler oft nicht als „ein Defekt“, sondern als unvollständige Zustandskette auftreten: Identität kann stimmen, aber der Managementkanal ist blockiert; der Kanal kann funktionieren, aber ein lokaler CSP scheitert; oder alles ist korrekt, jedoch fehlt ein aktueller Bericht. Die Folge sind scheinbar inkonsistente Statusbilder, die erst durch konsequente Trennung von Quelle, Zeitpunkt und Komponente belastbar werden.

Geräteregistrierung, Authentifizierung und MDM-Konnektivität: Entra ID, Zertifikate, Token, Plattformbesonderheiten und typische Fehlercodes

Geräteregistrierung und MDM-Enrollment in Microsoft Intune bestehen aus einer Kette klar separierter Teilschritte: Identität in Entra ID, Geräteeintrag (Device Object), Erwerb von Tokens, Ermittlung des MDM-Endpoints, Aufbau der TLS-Verbindung und erst danach die eigentliche MDM-Sitzung (Richtlinienabfrage, Status-Upload, Compliance). Viele sichtbare Intune-Probleme sind keine „einzelnen“ Fehler, sondern Zustandsbrüche innerhalb dieser Kette: Ein Entra-ID-Token ist gültig, aber das Geräteobjekt fehlt; die MDM-URL ist korrekt, aber TLS scheitert; die Registrierung ist abgeschlossen, aber der Client erreicht den Dienst nicht mehr. Das führt typischerweise zu verzögerten, unvollständigen oder widersprüchlichen Konfigurationen, weil Intune auf den nächsten erfolgreichen Check-in angewiesen bleibt.

Identitäts- und Autorisierungskette: Entra ID, Token und MDM-Discovery

Bei Windows (Entra ID Join, Hybrid Join, Workplace Join/Entra Registered) entscheidet Entra ID über Geräteidentität und Berechtigung zur MDM-Registrierung. Der MDM-Enrollmentpfad nutzt OAuth-basierte Tokens und eine Dienstermittlung („MDM discovery“). Ist die MDM-Benutzerzuweisung nicht wirksam oder wird die Registrierung durch Conditional Access unterbrochen, bleiben lokale Enrollment-Artefakte bestehen, ohne dass der MDM-Kanal stabil aufgebaut wird. Im Intune-Portal erscheinen Geräte dann oft als „nicht eincheckend“, obwohl sie in Entra ID existieren; umgekehrt kann ein lokales Enrollment gestartet sein, ohne dass ein verwaltetes Geräteobjekt in Intune angelegt wird.

Rollen- und Lizenzbedingungen wirken dabei als harte Gatekeeper. Besonders häufig ist die Kollision aus (a) fehlender Intune-Lizenz am Benutzer, (b) deaktivierter automatischer MDM-Registrierung in Entra ID oder (c) einer Enrollment-Restriktion (Plattformversion, Gerätekategorie, Gerätetyp). Diese Ursachen führen nicht zwingend zu einer „roten“ Fehlermeldung im Portal, sondern zu Abbrüchen im Client-Flow, die nur in Ereignisprotokollen und Enrollment-Logs erkennbar werden.

• MDM-Autorisierung (Benutzer nicht für MDM berechtigt): Windows-Enrollment endet häufig mit 0x80180018 (typisch, wenn keine MDM-Berechtigung/MDM-User-Scope greift oder Enrollment durch Richtlinien eingeschränkt wird) und bleibt damit in der Phase „Account setup“ stehen.
• „Zugriff blockiert“ durch Conditional Access: Die Entra-ID-Anmeldung bricht mit AADSTS53003 („Access has been blocked by Conditional Access policies.“) oder interaktiv mit AADSTS50076 (MFA erforderlich) ab; Enrollment kann dann zwar gestartet, aber nicht abgeschlossen werden, wenn Interaktion nicht möglich ist (z. B. bei Autopilot/ESP ohne zulässige CA-Ausnahmen).
• Geräteobjekt/Join-Zustand inkonsistent: Häufige Indikatoren sind dsregcmd /status mit nicht passenden Flags (z. B. AzureAdJoined : NO bei erwarteter Join-Variante) sowie ein fehlender oder verwaister Geräte-Token-Cache; Folge sind wiederholte Registrierungsversuche ohne stabilen MDM-Channel.
• MDM-Discovery/Enrollment-Endpoint nicht erreichbar: Netzwerk-/Proxy-Fehlkonfigurationen oder TLS-Inspection brechen die Discovery ab; prüfbar über https://enterpriseregistration.windows.net und https://enrollment.manage.microsoft.com sowie (tenantabhängig) die in dsregcmd /status angezeigten Enrollment-URLs.

Windows-spezifische Enrollment-Artefakte: MDM-Client, Aufgabenplanung und Check-in

Auf Windows erfolgt die MDM-Anbindung über den integrierten MDM-Client (OMADM) und geplante Aufgaben, die den regelmäßigen Check-in triggern. Ein erfolgreicher Enrollment-Status bedeutet lediglich, dass ein MDM-Enrollmentobjekt angelegt wurde; Richtlinienzustellung erfordert anschließend eine funktionierende Kommunikation. Sichtbar wird das in Intune als „Letzte Überprüfung“ (Last check-in) und in Windows als wiederkehrende OMADM-Sitzungen. Wird der Check-in durch Netzwerk oder lokale Fehler unterbrochen, können Profile in Intune als „zugewiesen“ gelten, während der Client sie nie abgerufen hat.

Fehlercodes im Windows-Enrollment sind häufig HRESULT/Win32-basiert und verweisen auf den betroffenen Layer: Entra-ID-Token, MDM-Serverkontakt, lokale Gerätezertifikate oder Policy-Engine. Wichtig ist die Zuordnung: Ein Code beim Enrollment ist nicht automatisch ein „Richtlinienfehler“, sondern häufig ein Hinweis auf MDM-Konnektivität oder Identität.

Zertifikate, TLS und Proxy-Ketten: Warum „MDM nicht erreichbar“ oft kein Intune-Fehler ist

MDM-Verbindungen sind TLS-geschützt; jede Manipulation der Zertifikatskette (z. B. TLS-Inspection durch Proxy) oder eine unterbrochene Validierung (fehlende Root-CAs, falsche Uhrzeit) wirkt unmittelbar auf Enrollment und Check-in. Intune selbst „sieht“ dann nur den fehlenden Geräte-Check-in. Der Client hingegen protokolliert Schannel/WinHTTP-Fehler, die streng zwischen DNS, TCP, TLS-Handshake und HTTP-Status unterscheiden. Bei iOS/iPadOS und Android Enterprise sind ähnliche Effekte sichtbar: Das Betriebssystem bzw. die Management-API bricht die Session ab, Intune zeigt nachgelagert nur die ausbleibende Statusrückmeldung.

Bei Zertifikaten sind zwei Ebenen zu unterscheiden: (1) Serverseitige TLS-Validierung der Microsoft-Endpunkte durch das Gerät und (2) optionale Client-Authentifizierung über ausgerollte Identitätszertifikate (z. B. SCEP/PKCS) für nachgelagerte Ressourcen wie WLAN/VPN. Fehler in Ebene (2) verhindern nicht zwangsläufig den Intune-Check-in, können aber den Eindruck erzeugen, Richtlinien seien „unwirksam“, weil abhängige Profile (WLAN/VPN) nicht funktionsfähig werden und dadurch Compliance oder App-Zugriffe scheitern.

• Schannel-/TLS-Indikatoren (Windows): wiederkehrende Fehler mit 0x80072F8F deuten häufig auf Zeit/Trust-Probleme; die technische Korrektur beginnt bei w32tm /query /status und der Prüfung der Vertrauenskette, nicht bei Intune-Richtlinien.
• Proxy-Erzwingung vs. Systemkontext: Enrollment/Check-in laufen teils im Systemkontext; Proxy-Konfigurationen, die nur für Benutzer gelten, brechen den Dienstzugang. Relevante Prüfpfade sind netsh winhttp show proxy und (falls verwendet) netsh winhttp import proxy source=ie.
• Endpoint-Blockaden: Wenn DNS/Firewall Microsoft-Managementendpunkte nicht erlaubt, entstehen „stille“ Zustandsfehler (kein Check-in). Technische Indikatoren sind wiederholte Verbindungsabbrüche mit 0x80072EFE oder Zeitüberschreitungen; Abhilfe erfordert die Freigabe der relevanten Intune/Entra-ID-Endpunkte im Unternehmensnetz.

Plattformbesonderheiten: iOS/iPadOS, Android Enterprise und macOS im Enrollment-Kontext

Auf iOS/iPadOS bestimmt die Enrollment-Art (z. B. Automated Device Enrollment über Apple Business Manager, Benutzerregistrierung oder Geräte-Enrollment) den Identitätsanker und die erlaubten MDM-Funktionen. In der Praxis führen Fehler eher zu „stehendem“ Enrollment als zu granularen Intune-Codes, weil Apple die MDM-Transaktion kapselt. Typische Bruchstellen sind abgelaufene oder fehlkonfigurierte Tokens/Zertifikate in der Apple-Integrationskette (APNs, ADE-Token) sowie Netzwerkpfade zu Apple-Diensten. Intune zeigt dann häufig generische Registrierungs- oder Synchronisationsprobleme, während die technische Ursache in der Apple-Kommunikation liegt.

Android Enterprise hängt stark vom Play-Dienst- und Google-Enterprise-Status ab (Device Policy, Managed Google Play, Work Profile). Fehler zeigen sich häufig als nicht abgeschlossene Arbeitsprofilbereitstellung oder als ausbleibende App-/Policy-Synchronisation. macOS wiederum nutzt unterschiedliche Enrollmentmechanismen (ADE, Benutzerinitiierung) und hat mit Zertifikaten/Trust ähnliche Risiken wie Windows, insbesondere bei TLS-Inspection. Plattformübergreifend gilt: Wenn die Identitätsphase (Entra ID/Apple/Google) nicht konsistent abgeschlossen ist, sind spätere Intune-Richtlinienzustände logisch nicht interpretierbar, weil das Gerät den Managementkanal nie stabil etabliert hat.

Richtlinien-, Compliance-, App- und Update-Bereitstellung: Konfliktlogik, Auswertungsreihenfolge, häufige Meldungen und ihre technische Bedeutung

Intune bewertet Gerätekonfigurationen nicht als „eine“ Einstellung, sondern als Ergebnis mehrerer Zuweisungsströme: Gerätekonfigurationsprofile, Sicherheitsbaselines, Endpoint-Security-Policies, Compliance-Richtlinien, App-Zuweisungen sowie Update- und Feature-Deployment. Sichtbare Fehler entstehen häufig nicht durch eine einzelne falsche Policy, sondern durch Kollisionen, zeitversetzte Auswertung und kanalabhängige Durchsetzung (MDM CSP, Win32-Installationsengine, Windows Update for Business, Apple MDM, Android Enterprise).

Wesentlich ist die Trennung zwischen „Zielzustand“ (was Intune zuweisen will) und „Istzustand“ (was das Betriebssystem oder der Management-Agent tatsächlich umgesetzt hat). Intune zeigt viele Probleme als Status „Error“, „Conflict“ oder „Not applicable“, obwohl das Gerät später konsistent wird, weil eine nachgelagerte Abhängigkeit (z. B. Neustart, Check-in, Detection Rule, WU-Scan) zeitlich verzögert eintritt.

Auswertungsreihenfolge und Konfliktlogik: Warum „Conflict“ selten ein Einzelfehler ist

Konflikte entstehen, wenn zwei oder mehr Richtlinien dieselbe Einstellung mit inkompatiblen Werten adressieren und die Plattform keinen deterministischen Merge zulässt. Windows-spezifisch ist zudem, dass unterschiedliche Policy-Typen über verschiedene Kanäle in dieselbe technische Zielvariable schreiben können (z. B. MDM Policy CSP vs. GPO/MDM-Richtlinienbrücke). Intune kann dann zwar den Konflikt erkennen, aber nicht auflösen, weil die Durchsetzung am Endpunkt entscheidet, welcher Wert tatsächlich wirksam wird.

Die Auswertung hängt außerdem von Scope, Filter, Zuweisungsart (Benutzer/Gerät), Lizenz- und Enrollment-Kontext ab. „Not applicable“ bedeutet häufig nicht „ignoriert“, sondern „nicht auswertbar“, etwa weil das Setting nicht zur SKU, zum OS-Build oder zum Enrollment-Typ passt. „Pending“ beschreibt meist einen asynchronen Zustand: Intune hat zugewiesen, aber der Client hat noch nicht bestätigt oder eine nachgelagerte Evaluierung steht aus.

• Status „Conflict“ (Konfigurationsprofil): Intune erkennt widersprüchliche Zielwerte für dieselbe Konfigurationseinheit; typisch bei parallel zugewiesenen Profilen oder Baselines. Auf Windows zeigt sich das in Geräteansichten als Conflict; technisch liegt oft eine Kollision auf MDM-CSP-Ebene vor (ein CSP-Node kann nicht gleichzeitig zwei Werte halten).
• Status „Error“ (Konfigurationsprofil): Der Client meldet einen Fehlercode an den MDM-Server zurück (SyncML-Status). In Windows-Protokollen korreliert das häufig mit 0x87D1FDE8 (Assignment/Applicability-Probleme) oder CSP-spezifischen HRESULTs; die Ursachen reichen von fehlender OS-Unterstützung bis zu Zugriff/Abhängigkeiten (z. B. BitLocker-Protector, Neustart erforderlich).
• Status „Not applicable“: Die Richtlinie ist zwar zugewiesen, erfüllt aber Kriterien nicht (Plattform, Edition, OS-Version, Management-Kanal). Windows-UI zeigt oft „Nicht zutreffend“; auf Policy-Ebene ist dies ein Applicability-Filterergebnis, nicht zwingend ein Fehler.
• Status „Pending“ / „In progress“: Das Gerät hat den Auftrag erhalten, aber noch nicht final gemeldet. Windows-Clientverhalten hängt am MDM-Check-in und an lokalen Evaluierungen; Diagnosepfad über Event Viewer > Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider.

Compliance: Auswertung, Grace-Period, „Nicht konform“ trotz korrekter Konfiguration

Compliance ist in Intune eine separate Bewertungsschicht: Konfigurationsprofile setzen Zustände, Compliance-Richtlinien prüfen Zustände. Eine technisch korrekte Konfiguration kann dennoch „Nicht konform“ melden, wenn die Messmethode abweicht (z. B. Antivirus-Provider-Wechsel), wenn Reporting verzögert ist oder wenn ein Compliance-Check auf einen anderen Datenprovider zugreift als die Konfiguration. Conditional Access in Entra ID konsumiert den Compliance-Status, wirkt aber nicht rückwärts auf die Gerätekonfiguration; dadurch entstehen scheinbar widersprüchliche Situationen, etwa „Policy erfolgreich“, aber „Zugriff blockiert“.

Typische Compliance-Meldungen sind „Noncompliant“, „In grace period“ und „Error“. „Error“ bedeutet nicht zwingend Sicherheitsdefizit, sondern oft, dass der Client die Abfrage nicht ausführen konnte (z. B. WMI/Health Attestation nicht verfügbar). In Windows kann ein Compliance-Fehler außerdem auftreten, wenn das Gerät zwar registriert ist, aber die MDM-Health-Komponente (Intune Management Extension ist hierfür nicht maßgeblich) keine frischen Ergebnisse liefert.

App-Bereitstellung: Erkennungslogik, Abhängigkeiten und typische Fehlercodes

App-Fehler sind häufig keine Installationsfehler im engeren Sinn, sondern Detection- und Kontextfehler. Bei Win32-Apps entscheidet die Detection Rule, ob Intune „Installed“ meldet; eine fehlerhafte Erkennung führt zu Endlosschleifen („installiert“ lokal, aber „nicht erkannt“ in Intune). Zudem wirken Abhängigkeiten (Dependencies) und Supersedence: Wird eine abhängige App blockiert, bleibt die Ziel-App im Status „Waiting for install status“ oder „Failed“, obwohl der Installer selbst korrekt wäre.

Viele Win32-Fehlercodes sind HRESULT- oder Windows Installer-Codes, die Intune in 32-bit/hex anzeigt. Häufig sind 0x87D1041C (Anforderung nicht zutreffend / Requirement Rule nicht erfüllt), 0x87D1041F (App bereits installiert/Erkennung inkonsistent, je nach Kontext), 0x87D30068 (Content-Download/Delivery Optimization/Cache-Probleme) oder 0x80070005 (Zugriff verweigert, z. B. Kontext/ACL). Bei MSI taucht klassisch 1603 als generischer fataler Installationsfehler auf; die technische Ursache liegt dann im MSI-Log, nicht in Intune.

• Requirement nicht erfüllt: Intune meldet häufig 0x87D1041C; die App wird nicht installiert, weil eine Requirement Rule (OS-Version, Architektur, Disk Space, Registry/File) negativ ausfällt. Kontrolle über IntuneManagementExtension.log und die im Portal definierten Requirements.
• Detection Rule inkonsistent: Gerät installiert, aber Status bleibt „Failed“ oder „Install pending“, wenn die Detection (z. B. HKLM\Software\...\Uninstall, Datei-Pfad, Produktcode) nicht zur Realität passt oder 32/64-bit-Redirect nicht berücksichtigt wird. Typisch ist ein Wechsel zwischen „Installed“ und „Not installed“ nach erneuter Evaluierung.
• Download-/Caching-Probleme: Fehler wie 0x87D30068 entstehen bei Content-Transfer, DO/WinHTTP-Fehlern oder beschädigtem Cache. Abgleich über IntuneManagementExtension.log sowie Windows-Protokolle zu Delivery Optimization.
• Installer-Rückgabecode aus dem Setup: MSI-Returncodes wie 1603 oder EXE-spezifische Codes werden durchgereicht; die technische Einordnung erfordert Hersteller-Logs bzw. MSI-Logging über msiexec /i package.msi /l*v C:\Windows\Temp\app.log.

Update- und Feature-Deployment: WUfB, Scan-Zyklen, Safeguard Holds und „Offer not received“

Windows-Updates über Intune basieren in der Regel auf Windows Update for Business (WUfB) und lokalen Windows Update-Komponenten. Intune steuert Ringe, Qualitätsupdates, Feature Updates sowie Expedite Policies; die tatsächliche Verfügbarkeit hängt jedoch von lokalen Scans, Microsoft Update-Services, Content Policies und von Microsoft-seitigen Schutzmechanismen ab. Dadurch entstehen häufig Zustände, in denen Intune „assigned“ zeigt, das Gerät aber noch kein Angebot erhält oder Installationen zurückstellt.

Typische Ursachen sind fehlende Scan-Auslösung, ungeklärte Dual-Scan-Konstellationen, WSUS-Konflikte, fehlende Neustarts oder Safeguard Holds (Kompatibilitätsblockaden), die ein Feature Update trotz Zielversion nicht anbieten. Intune-Statusmeldungen wirken dann widersprüchlich: Die Policy ist erfolgreich, die Update-Installation bleibt aber „Pending“, weil Windows Update das Angebot nicht bereitstellt.

• „Update not applicable“ / „Not applicable“ (Update Reports): Gerät erfüllt die Kriterien nicht (z. B. bereits auf Zielversion, falsche Produktfamilie, Edition nicht unterstützt). Technisch entscheidet Windows Update Applicability; Intune kann das Angebot nicht erzwingen.
• „Offer not received“ / keine Zielversion sichtbar: Häufig bei Feature Updates unter Safeguard Hold oder wenn das Gerät nicht gegen Microsoft Update scannt. Analyse über Get-WindowsUpdateLog (Windows) und WindowsUpdateClient-Events; Abgleich der konfigurierten Update-Quelle und ggf. WSUS-Policy-Kollisionen.
• „Pending restart“ / Installationsstau: Qualitäts- oder Feature-Update installiert, aber Abschluss hängt an Neustart-/Active-Hours- und Deadline-Logik. Die Durchsetzung erfolgt lokal durch Windows Update; Intune meldet verzögert, sobald die WU-Compliance zurückfließt.

In der Praxis sind Bereitstellungsprobleme auf dieser Ebene selten durch „Intune kann nicht“, sondern durch die Kopplung von Richtlinienzustand, Gerätetelemetrie und lokalen Update-Engines erklärbar. Die technische Einordnung muss deshalb immer den betroffenen Kanal trennen: Zuweisung in Intune, Durchsetzung am Endpunkt, Rückmeldung über Reporting. Erst daraus ergibt sich, ob ein Konflikt tatsächlich in Intune entsteht oder ob der Client eine korrekte Policy aufgrund lokaler Regeln, Abhängigkeiten oder Blockaden nicht umsetzt.