Wir verwalten unsere Geräte schon länger mit SCCM und wollen nun langsam in Richtung “modern management”, also der Verwaltung mit Intune. In der Übergangszeit (oder vielleicht auch längerfristig) verwalten wir unsere Geräte sowohl mit SCCM als auch mit Intune, Microsoft nennt dies Co-Management.

Damit die Geräte auch über Intune verwaltet werden können, müssen sie “enrolled” werden. Dieser Vorgang ist hier beschrieben und funktioniert kurz zusammengefasst so:

• Azure AD Connect so konfigurieren, dass die Gerätekonten ins Azure AD synchronisiert werden.
• In Intune konfigurieren, dass der MDM-Benutzerbereich nicht auf “Kein”, sondern auf “Einige” oder “Alle” steht.
• Den Benutzern Intune Lizenzen zuweisen. Dies kann gemäss diesem Beitrag automatisiert werden.

Dieses Vorgehen funktionierte bei den meisten Geräten, aber etwa 100 Geräte haben sich nie in Intune gemeldet.

Vermutung über die Ursache
Die 3 Punkte von der Aufzählung oben sind eigentlich einfach und übersichtlich. Im Internet finden sich aber unzählige Anleitungen, die zum Teil veraltet sind, da sich beim Vorgehen viel geändert hat. Früher musste man Intune mit dem SCCM verbinden, heute ist das nicht mehr möglich, man muss den SCCM Client parallel zur Einbindung in Intune betreiben. Beides wird mit Hybrid (Azure AD Join und ähnlichem) bezeichnet. Dann liest man wieder, dass Hybrid veraltet ist und nicht mehr unterstützt wird. Da ist dann aber nur die Einbindung in SCCM gemeint. Bei meinen Tests habe ich z.B. auch die Gruppenrichtlinie, auf die in manchen Dokumenten verwiesen wird, eingesetzt. Daher gehe ich davon aus, dass sich diese 100 Geräte über einen “falschen” Weg mit Intune verbinden wollten und dann aus diesem Zustand nicht mehr herausgekommen sind. Dies ist aber einfach eine Vermutung von mir.

Symptome
Betroffene Geräte werden in Azure AD angezeigt, aber nicht in Intune. Im Co-Management Log (C:\Windows\CCM\Logs\CoManagementHandler.log) finden sich widersprüchliche Angaben:
“Device is already MDM enrolled.
MDM enrollment succeeded
Device is not MDM enrolled yet. All workloads are managed by SCCM.”

In der Ereignisanzeige unter “Anwendungs- und Dienstprotokolle” –> “Microsoft” –> “Windows” –> “DeviceManagement-Enterprise-Diagnostics-Provider” –> “Administrator” findet sich eine Fehlermeldung mit Ereignis-ID 49 und dem Text “MDM Unenroll: Error sending unenroll alert to server. Result: (Schwerwiegender Fehler).” Wenn man zu den “Details” wechselt, sieht man, dass es sich um den Fehler 0x8000ffff handelt.

Wenn man unter “Windows-Einstellungen” –> “Konten” –> “Auf Arbeits- oder Schulkonto zugreifen” –> “Mit … AD Domäne verbunden” auf “Info” klickt, sieht man, dass bei den betroffenen Geräten zwar steht “Die Synchronisierung war erfolgreich”, aber keine Zeit und keine verwalteten Bereiche.

Was alles NICHT funktioniert
Ich habe dann im Internet recherchiert und verschiedenes getestet, was aber nicht erfolgreich war.

• Das Gerät über den Befehl “dsregcmd.exe /debug /leave” in einer mit Adminrechten gestarteten Eingabeaufforderung aus Intune entfernen (unenrollment)
• SCCM Client entfernen und erneut installieren
• Gerät über “Auf Arbeits- oder Schulkonto zugreifen” –> “Info” trennen (von AD und AAD). Anschliessend wieder in die Domäne aufnehmen
• Crypto Keys unter C:\ProgramData\Microsoft\Crypto\Keys löschen
• Gerät aus AAD löschen

Die oben genannten Punkte habe ich in diversen Zusammensetzungen und mit verschiedener Reihenfolge getestet was alles nichts genützt hat.

Lösung
Von Anfang an funktionierte alles wie gewünscht, wenn man ein betroffenes Gerät mit SCCM neu aufsetzte. Aber 100 Geräte neu aufzusetzen wäre höchstens die zweitbeste Lösung gewesen, vor allem, da unsere Surfaces alle zuerst mit einem Lan Adapter mit dem Netzwerk verbunden werden müssen. Daher habe ich mich noch an den Microsoft Support gewendet, der mir auch nicht helfen konnte, das Problem aber ans Entwicklerteam weitergeleitet hat. Die ersten Vorschläge waren aber auch nicht hilfreich und bevor sie mir helfen konnten bin ich dann noch über einen neuen Beitrag gestolpert (obwohl ich doch vorher schon fast das ganze Internet gelesen hatte ).

In diesem Reddit Beitrag wird ein ähnliches Problem beschrieben. Bei den Antworten schreibt ein Benutzer, dass er ein ähnliches Problem hatte und ihm der Microsoft Support eine Anleitung geschickt hat, die er nun verlinkt hat.

In der Anleitung gibt es diverse Punkte, die man abarbeiten sollte. Ich musste aber nur Punkt 4 daraus umsetzen, um mein Problem zu lösen. In der Registry gibt es unter HKLM\SOFTWARE\Microsoft\Enrollments diverse Unterordner, die man alle ausser die beiden im Bild markierten löschen muss.

Meine Idee war dann den ganzen Ordner “Enrollments” zu löschen und danach neu zu erstellen mit nur den beiden richtigen Ordnern. Beim Test mit dem System Account (den auch der SCCM Server verwendet) stellte ich dann fest, dass gar nicht der ganze Ordner gelöscht werden konnte, weil der System Account nur Leseberechtigung auf die beiden benötigten Ordner hatte, was das weitere Vorgehen natürlich noch vereinfachte.

Lösung automatisieren
Um die Problemlösung zu automatisieren, habe ich ein Skript erstellt, dass den Ordner löscht und dann ein Logfile auf dem Computer erstellt:

@echo off
start /wait reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments /f
echo %computername%>>c:\fixMDM.log
REM Return exit code to sccm
exit /B %EXIT_CODE%

Daraus kann man eine Anwendung erstellen und diese dann an eine Sammlung mit den betroffenen Computern verteilen.