Troubleshooting

ESP-Logs auf dem Gerät prüfen

Falls das Gerät noch erreichbar ist (z. B. via Shift+F10 im OOBE für eine CMD):

Logpfad: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

Mit CMTrace öffnen und nach [Win32App] oder Error filtern, um die fehlgeschlagene App zu identifizieren.

Fehlgeschlagene App identifizieren

Im Intune Admin Center → Devices → Gerät suchen → App install status prüfen. Welche App zeigt einen Fehler?

Typische Verursacher:

• Apps mit fehlerhafter Detection Rule
• Apps mit Dependencies, die nicht aufgelöst werden können
• Sehr große Apps (>2 GB) bei langsamer Internetverbindung

App-Zuweisung korrigieren

• Schnelle Lösung: Fehlgeschlagene App aus der ESP-Blockierliste entfernen (die App wird dann nach dem Login im Hintergrund nachinstalliert)
• Nachhaltige Lösung: Detection Rule, Install Command und Dependencies der App prüfen und korrigieren (siehe Packaging-Richtlinien)

Gerät zurücksetzen und erneut testen

Nach Korrektur das Gerät via Autopilot Reset zurücksetzen (siehe Runbook 1.2) und den Enrollment-Prozess erneut durchführen.

Hash-Import im Admin Center prüfen

Intune Admin Center → Devices → Enrollment → Windows enrollment → Devices → Nach der Seriennummer des Geräts suchen.

Falls das Gerät nicht gelistet ist → weiter mit Schritt 2. Falls das Gerät gelistet ist, aber kein Profil zugewiesen → weiter mit Schritt 3.

Hardware-Hash erneut auslesen und importieren

Auf dem Gerät (Shift+F10 für CMD im OOBE):

PowerShell.exe -ExecutionPolicy Bypass
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile C:\Temp\hash.csv

CSV-Datei im korrekten Tenant importieren. Tenant-Name im Admin Center Header prüfen!

Sync auslösen und warten

Nach dem Import in Intune auf „Sync” klicken → 15 Minuten warten.

Gerät neu starten

Gerät komplett ausschalten und neu starten. Im OOBE-Screen sollte jetzt das Firmen-Branding erscheinen.

Error Code vom Red Screen notieren

Der rote Bildschirm zeigt einen Error Code und eine Beschreibung. Die häufigsten Codes:

TPM-Status prüfen (häufigster Fehler)

# Auf dem Gerät prüfen:
Get-Tpm
# Erwartetes Ergebnis: TpmPresent = True, TpmReady = True

Falls TPM nicht ready → im BIOS TPM aktivieren und ggf. einen TPM Clear durchführen.

Netzwerk- und Lizenzprüfung

• Internet-Zugang prüfen (DNS-Auflösung, Proxy-Einstellungen)
• Firewall-Freigaben für Intune-Endpoints validieren
• Intune-Lizenz des vorgesehenen Users im Entra ID prüfen

Erneut versuchen

Auf dem Error-Screen „Reset” klicken oder das Gerät komplett ausschalten → neu starten → erneut 5x Windows-Taste drücken.

Enrollment Restrictions prüfen

Intune Admin Center → Devices → Enrollment → Enrollment device platform restrictions → Sicherstellen, dass Windows (MDM) für die betroffene Gruppe erlaubt ist.

Device Limit prüfen

Intune → Devices → Enrollment → Device limit restrictions → Standard-Limit prüfen (Default: 5 Geräte pro User). Falls der User bereits das Maximum erreicht hat: Alte/inaktive Geräte des Users im Admin Center löschen.

Lizenzierung prüfen

Entra ID Admin Center → Users → User → Licenses → Sicherstellen, dass eine Intune-berechtigte Lizenz zugewiesen ist (M365 E3, E5, Business Premium, etc.).

Erneut enrollen

Nach Korrektur das Gerät neu starten und den OOBE-Prozess wiederholen.

Internet-Konnektivität prüfen

Auf dem Gerät testen, ob die Intune-Endpoints erreichbar sind:

Test-NetConnection -ComputerName "manage.microsoft.com" -Port 443
Test-NetConnection -ComputerName "login.microsoftonline.com" -Port 443
Test-NetConnection -ComputerName "graph.microsoft.com" -Port 443

Falls Verbindung fehlschlägt → Firewall-/Proxy-Einstellungen im Kundennetzwerk prüfen.

IME-Service prüfen und neustarten

# Status prüfen:
Get-Service -Name "IntuneManagementExtension" | Select-Object Status, StartType
 
# Neustarten:
Restart-Service -Name "IntuneManagementExtension" -Force

Manuellen Sync auslösen

Auf dem Gerät: Einstellungen → Konten → Auf Arbeit oder Schule zugreifen → Firmen-Account auswählen → Info → Sync.

Alternativ via PowerShell:

# Scheduled Task für Intune Sync manuell auslösen:
Get-ScheduledTask | Where-Object { $_.TaskName -like "*IntuneManagementExtension*" } | Start-ScheduledTask

Ergebnis prüfen

Im Intune Admin Center → Devices → Gerät → Last check-in sollte sich aktualisieren (ca. 5-10 Minuten).

Falls weiterhin kein Sync → Re-Enrollment in Betracht ziehen (Gerät aus dem Management entfernen und neu enrollen).

Conditional Access Sign-in Logs prüfen

Entra ID Admin Center → Monitoring → Sign-in logs → Nach dem betroffenen User filtern.

Die Spalte „Conditional Access” zeigt, welche Policy den Zugriff blockiert hat. Auf den Eintrag klicken → Tab „Conditional Access” → Details der angewendeten Policy prüfen.

Blockierungsgrund identifizieren

Problem beheben

Je nach Ursache die entsprechende Maßnahme durchführen. Nach Behebung den User bitten, sich erneut anzumelden (ggf. Browser-Cache leeren).

Bei Fehlkonfiguration: Policy im Report-Only prüfen

Falls der Verdacht besteht, dass die CA-Policy falsch konfiguriert ist:

1. Policy im Admin Center auf „Report-only” setzen
2. Sign-in Logs erneut prüfen
3. Nach Korrektur wieder auf „On” stellen

Sync-Status im Entra Connect Health prüfen

Entra ID Admin Center → Entra Connect → Connect Sync → Sync-Status und letzte Sync-Zeit prüfen.

Erwartung: Letzter Sync < 30 Minuten, Status: Healthy.

Sync-Fehler identifizieren

Tab „Sync errors” öffnen. Häufige Fehler:

Fehler im AD beheben

Die meisten Sync-Fehler haben ihre Ursache im lokalen Active Directory. Fehlerhafte Attribute direkt im AD bereinigen.

# Beispiel: ProxyAddress Duplikat finden
Get-ADUser -Filter * -Properties ProxyAddresses | 
  Where-Object { $_.ProxyAddresses -like "*duplicated@domain.com*" }

Delta-Sync manuell auslösen

Auf dem Entra Connect Server:

Start-ADSyncSyncCycle -PolicyType Delta

Ergebnis prüfen

Get-ADSyncConnectorRunStatus

Sicherstellen, dass der Sync-Lauf ohne Fehler abgeschlossen wurde. Anschließend im Entra ID Admin Center prüfen, ob der betroffene User korrekt synchronisiert wurde.

Error Code im Admin Center notieren

Intune Admin Center → Apps → App auswählen → Device install status → Fehlerhaftes Gerät identifizieren → Error Code notieren.

Error Code nachschlagen

IME-Log auf dem Gerät analysieren

Per Remote-Session oder vor Ort zum Gerät verbinden:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

Log mit CMTrace öffnen. Nach dem App-Namen oder dem [Win32App] Tag filtern. Die relevanten Einträge zeigen:

• Download-Status
• Content-Extraktion
• Ausführung des Install-Commands
• Detection-Ergebnis

Häufigste Korrekturen

• Detection Rule anpassen: Pfad, Dateiversion oder Registry-Key stimmen nicht mit der tatsächlichen Installation überein
• Install Command prüfen: Lokaler Pfad korrekt? Silent-Parameter vorhanden?
• .intunewin neu erstellen: Sicherstellen, dass der Setup-Folder korrekt gewählt und alle Dateien enthalten sind
• Dependencies prüfen: Fehlt eine Voraussetzung (z. B. .NET Framework, Visual C++ Redistributable)?

Retry auslösen

Nach Korrektur im Admin Center: App-Properties → Save (triggert Re-Evaluation) oder am Gerät: Sync → App wird erneut versucht.

Detection Rule überprüfen

Die häufigste Ursache ist eine falsch konfigurierte Detection Rule, die ein positives Ergebnis liefert, obwohl die App nicht (korrekt) installiert ist.

Im Admin Center → Apps → App → Properties → Detection Rules prüfen:

Detection direkt am Gerät testen

Am Gerät prüfen, ob die Detection-Methode wirklich zutrifft:

# Beispiel: File-Detection testen
Test-Path "C:\Program Files\AppName\app.exe"
 
# Beispiel: Registry-Detection testen
Get-ItemProperty -Path "HKLM:\SOFTWARE\AppName" -Name "Version" -ErrorAction SilentlyContinue
 
# Beispiel: MSI Product Code testen
Get-WmiObject -Class Win32_Product | Where-Object { $_.IdentifyingNumber -eq "{YOUR-PRODUCT-GUID}" }

Detection Rule korrigieren

Detection Rule im Admin Center anpassen → Save. Das Gerät wird beim nächsten Sync die Detection erneut durchführen und bei negativem Ergebnis die App neu installieren.

App-Zuweisung prüfen

Intune Admin Center → Apps → App → Assignments → Ist die App als „Available” der richtigen User- oder Gerätegruppe zugewiesen?

Gruppenmitgliedschaft des Users prüfen

Entra ID → Users → User → Groups → Ist der User Mitglied der Zielgruppe?

Bei dynamischen Gruppen: Prüfen, ob die Membership Rule korrekt ausgewertet wird (Entra ID → Groups → Gruppe → Dynamic membership rules → Processing status).

Company Portal App prüfen

• Ist das Company Portal als Required App zugewiesen und installiert?
• Ist das Company Portal korrekt als Online oder Offline Store-App konfiguriert?
• Ist das Branding konfiguriert? (Intune → Tenant administration → Customization)

Sync am Gerät auslösen

Im Company Portal: Oben rechts auf „…” → „Sync” klicken. Apps sollten nach 1-2 Minuten erscheinen.

Voraussetzungen prüfen

BitLocker Silent Encryption erfordert:

BitLocker-Status am Gerät prüfen

Get-BitLockerVolume -MountPoint "C:" | Select-Object VolumeStatus, EncryptionPercentage, ProtectionStatus, KeyProtector

Mögliche Ergebnisse:

• FullyDecrypted → Verschlüsselung wurde noch nicht gestartet
• EncryptionInProgress → Läuft gerade (abwarten)
• FullyEncrypted, aber ProtectionStatus: Off → Key Protectors fehlen

Event Logs prüfen

Get-WinEvent -LogName "Microsoft-Windows-BitLocker/BitLocker Management" -MaxEvents 20

Häufige Fehler:

• TPM ist nicht ready → TPM im BIOS aktivieren/clearen
• Policy conflict → Widersprüchliche GPOs aus dem alten On-Prem AD vorhanden? → GPOs prüfen oder via gpresult /h report.html analysieren

Recovery Key Escrow prüfen

Der Concat Standard konfiguriert: Recovery Key muss in Entra ID gespeichert werden, bevor die Verschlüsselung startet. Falls die Entra ID Verbindung gestört ist, blockiert dies die gesamte Verschlüsselung.

# Prüfen, ob der Recovery Key bereits in Entra ID liegt:
(Get-BitLockerVolume -MountPoint "C:").KeyProtector | Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" }

Manuell anstoßen (falls nötig)

# BitLocker manuell für C: aktivieren (Silent, TPM):
Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -TpmProtector
Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
# Anschließend Sync auslösen, damit der Key in Entra ID landet

Onboarding-Status am Gerät prüfen

# Sense-Service prüfen:
Get-Service -Name "Sense" | Select-Object Status, StartType
# Erwartung: Running, Automatic
 
# Onboarding-Status prüfen:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status" -Name "OnboardingState"
# Erwartung: OnboardingState = 1

Netzwerkkonnektivität testen

Defender benötigt Zugriff auf spezifische Endpoints:

# Microsoft Defender Connectivity-Test:
& "C:\Program Files\Windows Defender\MpCmdRun.exe" -ValidateMapsConnection

Falls der Test fehlschlägt → Firewall-/Proxy-Freigaben für Defender-Endpoints prüfen.

Lizenzierung prüfen

• Defender for Endpoint Plan 1: In M365 E3 / Business Premium enthalten
• Defender for Endpoint Plan 2: Nur in M365 E5 oder als Add-on

Im Entra ID → Users → User → Licenses prüfen, ob die korrekte Lizenz zugewiesen ist.

Manuelles Onboarding (Fallback)

Falls das automatische Onboarding via Intune nicht funktioniert:

1. Microsoft 365 Defender Portal → Settings → Endpoints → Onboarding
2. Deployment method: Local Script auswählen
3. Script herunterladen und auf dem Gerät als Administrator ausführen

Blockierte ASR Rule identifizieren

# ASR Events im Event Log prüfen:
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" | 
  Where-Object { $_.Id -in @(1121, 1122) } | 
  Select-Object -First 20 TimeCreated, Message

• Event 1121 = ASR Rule hat eine Aktion blockiert (Block Mode)
• Event 1122 = ASR Rule hat eine Aktion im Audit Mode erkannt

Betroffene Anwendung und Rule-ID notieren

Der Event-Eintrag enthält die ASR Rule GUID und den Prozess-/Dateipfad, der blockiert wurde.

Referenz der häufigsten ASR Rule GUIDs:

Ausnahme konfigurieren

Im Intune Admin Center → Endpoint Security → Attack Surface Reduction → Betroffene Policy öffnen → Exclusions hinzufügen:

• Pfad der betroffenen Anwendung als Ausnahme eintragen
• Ausnahme dokumentieren (Decision Log beim Kunden!)

Verifizieren

Nach dem nächsten Sync die Anwendung erneut testen. Im Event Log sollten keine weiteren ASR-Blockierungen für diese Anwendung erscheinen.

Active Hours prüfen

Windows unterdrückt Neustarts während der konfigurierten Active Hours (Standard: 08:00-18:00). Falls der User das Gerät abends herunterfährt statt neu zu starten, wird der Update-Restart nie durchgeführt.

Restart Grace Period prüfen

Nach Ablauf der Deadline hat der User eine 48-Stunden Grace Period, in der Neustarts verschoben werden können. Erst danach wird ein Reboot erzwungen.

Prüfen, ob die Deadline bereits verstrichen ist: Intune → Devices → Gerät → Update status.

User kontaktieren

In den meisten Fällen reicht eine freundliche Aufforderung an den User, das Gerät einmal neu zu starten (nicht herunterfahren!).

Hinweis: „Herunterfahren” in Windows führt mit aktiviertem Fast Startup nicht zu einem vollständigen Reboot. Nur „Neu starten” triggert den Update-Installationsprozess.

Forced Reboot (letztes Mittel)

Falls der User nicht reagiert und die Sicherheitslage kritisch ist:

Intune Admin Center → Devices → Gerät → Restart (Remote Action). Der User verliert ungespeicherte Arbeit — nur nach vorheriger Kommunikation verwenden!

Dual Scan Risiko verstehen

Dual Scan tritt auf, wenn ein Gerät gleichzeitig von einer GPO auf einen lokalen WSUS-Server verwiesen wird und Intune Update-Ringe zugewiesen sind. Die GPO gewinnt, Intune-Updates werden ignoriert.

GPO-Einstellungen prüfen

Am Gerät:

gpresult /h C:\Temp\gpo-report.html
# Report öffnen und nach "Windows Update" oder "WUServer" suchen

Relevante GPO-Einstellungen, die Dual Scan verursachen:

• Specify intranet Microsoft update service location
• Do not connect to any Windows Update Internet locations

GPO-Konflikte auflösen

Option A (empfohlen): Cloud-verwaltete Geräte aus dem GPO-Scope entfernen (z. B. eigene OU für Intune-Geräte → GPO-Verknüpfung dort deaktivieren).

Option B: GPO-Einstellungen via Intune überschreiben:

Administrative Templates > Windows Components > Windows Update > 
"Do not allow update deferral policies to cause scans against Windows Update" → Enabled

Ergebnis prüfen

Nach dem nächsten Sync und Policy-Refresh:

# Prüfen, wohin Windows Updates zeigt:
(Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -ErrorAction SilentlyContinue).WUServer
# Sollte leer sein für reine Cloud-Verwaltung

Service-Status auf dem Connector-Server prüfen

Per RDP auf den Connector-Server verbinden:

Get-Service -Name "ODJConnectorSvc" | Select-Object Status, StartType

Falls Stopped → Neustarten:

Restart-Service -Name "ODJConnectorSvc" -Force

Event Logs prüfen

Get-WinEvent -LogName "Application" -MaxEvents 50 | 
  Where-Object { $_.ProviderName -like "*ODJ*" -or $_.ProviderName -like "*Intune*" }

Typische Fehler:

• Netzwerk-Timeout: Ausgehender Port 443 zu Intune-Endpoints wird blockiert
• Zertifikat abgelaufen: Connector-Zertifikat muss erneuert werden
• AD-Berechtigung fehlt: gMSA-Account hat keine Rechte zum Erstellen von Computerobjekten in der Ziel-OU

Netzwerk-Konnektivität testen

Test-NetConnection -ComputerName "manage.microsoft.com" -Port 443
Test-NetConnection -ComputerName "enterpriseregistration.windows.net" -Port 443

Connector neu installieren (falls nötig)

Falls der Service nicht zu reparieren ist:

1. Alten Connector deinstallieren (Programme und Features)
2. Intune Admin Center → Windows enrollment → Intune Connector for Active Directory → Add
3. Connector Manager herunterladen und auf dem Server installieren
4. Ziel-OU und Hybrid Join Profil zuweisen

Connector-Status prüfen

Im Intune Admin Center → Tenant Administration → Connectors and tokens → Certificate connectors → Status prüfen.

Auf dem Connector-Server:

Get-Service -Name "IntuneCertificateConnector" | Select-Object Status

Certificate Connector Event Logs analysieren

Die detailliertesten Logs befinden sich im Event Viewer:

Get-WinEvent -LogName "Microsoft-Intune-CertificateConnectors/Operational" -MaxEvents 30

Häufige Fehler:

• NDES nicht erreichbar (bei SCEP): NDES-Server prüfen, IIS Application Pool läuft?
• CA Template Permissions: Connector-Service-Account hat keine Enroll-Berechtigung auf der Zertifikatsvorlage
• Subject Name Mismatch: CA-Template erlaubt kein „Supply in the request”

Zertifikatsvorlage prüfen

Auf dem CA-Server:

• certsrv.msc → Certificate Templates → Vorlage öffnen
• Tab „Security”: Hat der Connector-Service-Account die Berechtigung „Enroll”?
• Tab „Subject Name”: Ist „Supply in the request” aktiviert?

NDES-Server prüfen (nur bei SCEP)

# IIS Application Pool Status:
Get-WebAppPoolState -Name "SCEP"
 
# Test-URL (sollte ein Challenge-Password zurückgeben):
Invoke-WebRequest -Uri "https://ndes-server.domain.com/certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert" -UseBasicParsing

Test-Zertifikat anfordern

Nach der Fehlerbehebung einem Test-Gerät das Zertifikatsprofil zuweisen und den Sync auslösen. In den Connector-Logs beobachten, ob die Anforderung erfolgreich verarbeitet wird.