Sektion 10: Windows Enrollment via Group Policy (GPO)

Einleitung

Wenn man über Windows-Enrollment in Microsoft Intune spricht, denken die meisten sofort an Windows Autopilot, an den manuellen Weg über „Auf Arbeits- oder Schulkonto zugreifen“ oder an Bulk-Enrollment mit Provisioning-Paketen. Dabei existiert ein Enrollment-Pfad, der gerade in Unternehmen mit gewachsener Active-Directory-Struktur oft der schnellste und effizienteste ist: das automatische MDM-Enrollment über Group Policy (GPO). Für Organisationen, die bereits über eine funktionierende Domänen-Infrastruktur mit Hybrid-Entra-Join verfügen, ist dieser Weg in der Regel mit weniger Aufwand verbunden als jedes andere Verfahren — und er ist der Standardpfad, wenn man schrittweise von On-Premises-Management zu Intune migriert.

In dieser Sektion behandeln wir das GPO-basierte Enrollment von Grund auf: die Architektur dahinter, die Voraussetzungen, die exakte Konfiguration in Entra ID und in der Gruppenrichtlinie, die internen Mechanismen (Scheduled Tasks, Registry, Tasksequenzen), die Verifikation des Enrollment-Status und ein systematisches Troubleshooting der typischsten Fehlercodes. Am Ende dieser Sektion beherrschst du nicht nur die Einrichtung, sondern verstehst auch, was auf dem Client tatsächlich passiert — und das ist der Unterschied zwischen einem Administrator, der Checklisten abarbeitet, und einem, der Probleme in Minuten statt Stunden löst.

Grundkonzepte

Was ist GPO-basiertes Enrollment?

Das GPO-basierte Enrollment — intern als „Automatic MDM Enrollment“ bezeichnet — ist ein Verfahren, bei dem ein domänen-verbundener Windows-Client sich selbstständig bei Microsoft Intune registriert, sobald die entsprechenden Richtlinien angewendet werden. Der entscheidende Punkt: Es handelt sich nicht um ein klassisches Intune-Enrollment durch einen Benutzer-Klick, sondern um einen Hintergrundprozess, den die Gruppenrichtlinie über einen Scheduled Task auslöst. Der Client meldet sich mit Entra ID-Credentials bei Intune an, bekommt ein MDM-Zertifikat ausgestellt und erscheint danach als verwaltetes Gerät in der Intune-Konsole.

Wichtig für das Verständnis der Einordnung: GPO-Enrollment ist der empfohlene Weg, wenn Geräte bereits Hybrid-Entra-joined sind (also gleichzeitig in der AD-Domäne und in Entra ID registriert). Es ist explizit nicht gedacht für reine Workgroup-Geräte oder Szenarien ohne Entra-Connect-Synchronisation. Wer reine Cloud-Umgebungen betreibt, nutzt stattdessen Autopilot — das haben wir in einer vorherigen Sektion behandelt und wird in einer späteren Sektion vertieft.

Architektur und Ablauf

Der Prozess läuft in mehreren Phasen ab, die man kennen muss, um Fehler richtig einordnen zu können:

Phase 1 — GPO-Anwendung: Die Gruppenrichtlinie schreibt zwei Registry-Werte unter HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM und erzeugt mehrere Scheduled Tasks unter \Microsoft\Windows\EnterpriseMgmt\.
Phase 2 — Task-Ausführung: Der Task „Enroll device to MDM from MDM user scope“ läuft im User-Kontext (bei User-Credential-Enrollment) bzw. im System-Kontext (bei Device-Credential-Enrollment) und triggert die Enrollment-Logik der MDM-Client-Komponente.
Phase 3 — Token-Beschaffung: Der Client fordert über Entra ID ein Token an. Bei User-Credentials wird das PRT (Primary Refresh Token) des angemeldeten Nutzers verwendet; bei Device-Credentials das Device-Token des Hybrid-Entra-Join.
Phase 4 — MDM-Enrollment: Der Client kontaktiert den Intune-Enrollment-Endpunkt (enrollment.manage.microsoft.com), durchläuft die MDM-Discovery und lässt ein Client-Zertifikat ausstellen.
Phase 5 — Bestätigung: Das Gerät erscheint in Intune, der Task wird deaktiviert, und die Initial-Synchronisation beginnt (Compliance-Policies, Konfigurationsprofile, Apps).

Dieser mehrstufige Aufbau erklärt, warum GPO-Enrollment-Fehler so vielfältig sind: Ein Fehler kann an der GPO-Vererbung liegen, an der Entra-Konfiguration, am Netzwerk (Proxy!), am Token oder am MDM-Service selbst. Ohne Verständnis der Kette debuggt man ins Blaue.

User-Scope vs. Device-Credentials — die zentrale Design-Entscheidung

Die Gruppenrichtlinie bietet zwei Credential-Typen, und diese Entscheidung hat substanzielle Konsequenzen:

User-Credentials (Standard): Das Enrollment erfolgt im Kontext des angemeldeten Benutzers. Konsequenz: Ein Gerät enrollt sich erst, wenn sich ein lizenzierter Benutzer anmeldet — und zwar mit seinem Intune-Kontext. Das bedeutet auch: Melden sich mehrere Benutzer an einem Gerät an, kann es zu Mehrfach-Enrollments bzw. Komplikationen kommen. Der Vorteil: keine besonderen Anforderungen an den Join-Typ.
Device-Credentials: Das Gerät meldet sich mit seiner eigenen Identität an (Voraussetzung: Hybrid-Entra-Join, Windows 10 1809+ empfohlen). Das Enrollment ist damit vom Benutzer unabhängig und läuft auch dann, wenn sich nie ein Benutzer anmeldet — relevant für Kiosk- oder shared Devices. Die MDM User Scope-Einstellung in Entra ID muss hierfür trotzdem korrekt gesetzt sein; die Device-Credential-Option umgeht nur die User-Abhängigkeit der Task-Ausführung.

In den meisten Enterprise-Umgebungen mit Hybrid-Join ist Device-Credential-Enrollment heute der sauberere Weg, weil es die Benutzer-Unabhängigkeit garantiert und das Problem der „Multi-User-Doppel-Enrollments“ eliminiert.

Abgrenzung zu anderen Enrollment-Methoden

Um die Einordnung zu schärfen, hier die Abgrenzung zu den Nachbarmethoden:

Autopilot: Cloud-native, hardware-hash-basiert; ideal für neue Geräte ohne AD-Geschichte. GPO-Enrollment gewinnt bei bestehenden, domänen-verbundenen Geräten, weil kein Hash-Import nötig ist.
Manuelles Enrollment („Connect“): Benutzer geht in die Einstellungen auf „Auf Arbeits- oder Schulkonto zugreifen“ > „Verbinden“. Funktioniert, skaliert aber nicht und ist fehleranfällig — und der häufigste Fehler ist hier ein versehentliches „Dieses Konto mit Microsoft Intune verbinden“ vs. „In Microsoft Entra ID einbinden“.
Co-Management (SCCM + Intune): Parallelbetrieb von Configuration Manager und Intune. Technisch nutzt auch Co-Management ein automatisches Enrollment, aber die Steuerung erfolgt aus SCCM heraus (Client-Setting „Automatische Registrierung in Intune“) und nicht direkt über die GPO. Wichtig: Beide Wege gleichzeitig zu konfigurieren führt zu Konflikten — entscheide dich für einen Pfad pro Gerätesammlung.

Praxis-Implementierung

Voraussetzungen prüfen

Bevor irgendetwas konfiguriert wird, prüfe die folgenden Punkte — 80 Prozent aller GPO-Enrollment-Vorfälle, die ich kenne, entstehen durch übersprungene Voraussetzungen:

Lizenzen: Jeder Benutzer, dessen Geräte enrollt werden sollen, benötigt eine Intune-Lizenz (direkt oder via Microsoft 365/EMS-Bundle). Bei Device-Credential-Enrollment: Der primäre Nutzer des Geräts muss lizenziert sein — Intune prüft die Lizenz im Enrollment-Flow.
Hybrid-Entra-Join: Der Client muss AzureAdJoined: YES und DomainJoined: YES in dsregcmd /status zeigen. Ist das Gerät nur Entra-registered (Arbeits-/Schulkonto ohne Join), funktioniert GPO-Enrollment mit Device-Credentials nicht.
MDM User Scope: In Entra ID muss der MDM User Scope aktiviert sein — dazu gleich mehr.
Netzwerk: Der Client muss enrollment.manage.microsoft.com, manage.microsoft.com und die Entra-Endpoints erreichen können. Achtung bei SSL-Inspection-Proxies: Hier scheitern mehr Umgebungen als an jeder anderen Stelle.
Windows-Version: Windows 10 1709+ für User-Credential-Enrollment, Windows 10 1809+ für Device-Credential-Enrollment (in der Praxis: alles unter 1909 ist heute ohnehin End-of-Life).

Schritt 1: MDM User Scope in Entra ID aktivieren

Ohne diese Einstellung schlägt jedes GPO-Enrollment mit dem Fehler 0x8018002a fehl — dem klassischen „MDM-Benutzerbereich nicht aktiviert“. Die Konfiguration erfolgt nicht in Intune, sondern im Entra-Portal:

Öffne entra.microsoft.com.
Navigiere zu Identity > Mobility (MDM und WIP).
Klicke auf Microsoft Intune.
Setze MDM-Benutzerbereich (MDM user scope) auf Einige (Some) und wähle die betroffenen Benutzergruppen — oder auf Alle (All) für die gesamte Organisation.
Stelle sicher, dass der MAM-Benutzerbereich auf Keine steht, wenn du keine MAM-only-Verwaltung (App-Schutz ohne Enrollment) für dieselben User willst. Wenn beide Scopes für denselben Benutzer aktiv sind, gewinnt MAM gegenüber MDM, und das Gerät enrollt nicht — ein absoluter Klassiker.
Speichere und warte, bis die Änderung propagiert ist (in der Regel Minuten, im Worst Case bis zu einer Stunde).

Ein häufig übersehener Punkt: Der MDM User Scope gilt pro Benutzer, nicht pro Gerät. Ein Gerät, an das sich ein nicht im Scope befindlicher Benutzer anmeldet, wird mit User-Credentials nicht enrollen. Device-Credentials umgehen diese Hürde teilweise, aber die Lizenzprüfung bleibt.

Schritt 2: Die Gruppenrichtlinie erstellen und verlinken

Jetzt kommt der eigentliche GPO-Teil. Öffne die Group Policy Management Console auf einem Domänen-Controller (oder per RSAT) und erstelle eine neue GPO — benenne sie sprechend, zum Beispiel INT-AutoMDMEnrollment:

Navigiere zu Computerkonfiguration > Administrative Vorlagen > Windows-Komponenten > MDM.
Öffne die Richtlinie „Automatische MDM-Registrierung mit von Entra ID verwendeten Standardanmeldeinformationen aktivieren“ (im Original: „Enable automatic MDM enrollment using default Azure AD credentials“).
Setze sie auf Aktiviert.
Wähle den Credential-Typ: Benutzeranmeldeinformationen (User Credential) oder Geräteanmeldeinformationen (Device Credential). Für Hybrid-Entra-Joined-Umgebungen: Device Credential wählen.
Schließe mit OK und verlinke die GPO auf die entsprechende OU. Setze die Sicherheitsoptionen so, dass die Computer-Objekte der Zielgeräte die Richtlinie lesen und anwenden können (Standard: „Authentifizierte Benutzer“ reicht, da die Einstellung im Computer-Zweig liegt).

Falls die ADMX-Vorlage „MDM“ in deiner Domäne fehlt (ältere Central Store), hole die aktuellen ADMX-Dateien aus einem Windows 10/11-Referenzclient (C:\Windows\PolicyDefinitions) und kopiere sie in den Central Store — oder konfiguriere die Werte direkt per Registry-Distribution, was auf dasselbe hinausläuft.

Schritt 3: Registry-Werte verstehen

Die GPO setzt letztlich nur zwei Registry-Werte — und genau diese Werte solltest du kennen, denn sie sind die Grundlage jeder Statusprüfung und auch der alternativen Verteilung per Startup-Script oder Drittanbieter-Tool:

Pfad: HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM

Name: AutoEnrollMDM
Typ:  REG_DWORD
Wert: 1

Name: UseAADCredentialType
Typ:  REG_DWORD
Wert: 1 = User-Credential-Enrollment
      2 = Device-Credential-Enrollment

Mit diesem Wissen kannst du die Enrollment-Aktivierung auch ohne GPO-Infrastruktur verteilen — etwa per Configuration Manager Baseline oder per PowerShell-Startup-Script:

# Aktiviert Auto-Enrollment mit Device-Credentials per Registry
$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM"
New-Item -Path $regPath -Force | Out-Null
Set-ItemProperty -Path $regPath -Name "AutoEnrollMDM" -Value 1 -Type DWord
Set-ItemProperty -Path $regPath -Name "UseAADCredentialType" -Value 2 -Type DWord
Write-Output "Auto-Enrollment aktiviert. Gpupdate oder Neustart ausführen."

Schritt 4: Enrollment auslösen und beobachten

Nachdem GPO und Scope stehen, forciere die Richtlinien-Anwendung auf einem Testgerät und beobachte den Enrollment-Flow live:

# GPO sofort anwenden
gpupdate /force

# Enrollment-Scheduled-Tasks prüfen (sollten nach GPO-Anwendung existieren)
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" |
    Select-Object TaskName, State, TaskPath

# Task manuell triggern (beschleunigt den Vorgang)
Start-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\" `
    -TaskName "Enroll device to MDM from MDM user scope"

Der Task läuft standardmäßig in einem Zyklen: sofort nach Anmeldung, alle 5 Minuten, nach 1 Stunde, nach 8 Stunden und einmal täglich — der Windows-Scheduler ist hier bewusst redundant ausgelegt, damit ein temporärer Netzwerkfehler oder ein offline genutztes Gerät das Enrollment nicht dauerhaft verhindert. Das heißt konkret: Wenn nach dem gpupdate nichts passiert, wartest du zunächst einfach 5–10 Minuten, bevor du dich in die Logs gräbst.

Das erfolgreich enrollte Gerät erkennst du am zuverlässigsten an zwei Stellen: erstens am Status in dsregcmd /status unter dem Abschnitt „MDM-Details“ (MDM Enrollment URL und MDM Enrollment: YES sollten gesetzt sein), und zweitens am Eintrag in der Intune-Konsole unter Devices > Windows, wobei die Verwaltungsautorität „MDM“ (nicht „SCCM“/“MDM+SCCM“) zeigen sollte — außer du betreibst bewusst Co-Management.

Verifikation per PowerShell und Graph

Für größere Rollouts willst du den Status nicht pro Gerät per dsregcmd abklicken. Hier zwei pragmatische Ansätze. Zunächst die lokale, vollständige Statusprüfung als Skript für Remote-Sammlungen:

$computer = "PC-MUSTER-01"
$output = Invoke-Command -ComputerName $computer -ScriptBlock {
    # 1. Registry prüfen (ist Auto-Enrollment überhaupt aktiviert?)
    $mdm = Get-ItemProperty `
        "HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM" `
        -ErrorAction SilentlyContinue
    $autoEnroll = $mdm.AutoEnrollMDM
    $credType   = $mdm.UseAADCredentialType

    # 2. Entra-Join-Status prüfen
    $dsreg = dsregcmd /status
    $azureJoined = ($dsreg | Select-String "AzureAdJoined").ToString()
    $domainJoined = ($dsreg | Select-String "DomainJoined").ToString()

    # 3. MDM-Enrollment-Status
    $mdmUrl = ($dsreg | Select-String "MDM Enrollment URL").ToString()

    [PSCustomObject]@{
        AutoEnrollMDM       = $autoEnroll
        CredType            = $credType
        AzureJoined         = $azureJoined
        DomainJoined        = $domainJoined
        MDMEnrollmentUrl    = $mdmUrl
    }
}
$output | Format-List

Und zweitens die zentrale Sicht über die Microsoft Graph API, mit der du prüfst, welche Geräte tatsächlich in Intune angekommen sind — nützlich, um die Diskrepanz zwischen „GPO angewendet“ und „wirklich enrollt“ zu messen:

# Voraussetzung: Graph PowerShell SDK installiert
# Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

$devices = Get-MgDeviceManagementManagedDevice -All `
    -Filter "operatingSystem eq 'Windows'"

$devices | Select-Object DeviceName, `
    @{N='JoinType';E={$_.DeviceRegistrationState}}, `
    @{N='ManagementState';E={$_.ManagementState}}, `
    @{N='LastSync';E={$_.LastSyncDateTime}} |
    Sort-Object LastSync -Descending |
    Format-Table -AutoSize

Der Vergleich zwischen der Anzahl der Geräte mit angewandter GPO (über Get-ADComputer + Registry-Removal-Check) und der Anzahl in Intune ist deine Rollout-Kennzahl: Die Differenz ist deine „Troubleshooting-Backlog“.

Best Practices

Staged Rollout statt Big Bang

Die verlockendste Option — MDM User Scope auf „Alle“, GPO auf die Domänen-Root-OU — ist zugleich die gefährlichste. Aktiviere das Enrollment bewusst gestaffelt: erst eine Pilot-OU mit 5–10 repräsentativen Geräten, dann eine Abteilung, dann Wellen von OUs. Der Grund ist nicht das Enrollment selbst (das ist harmlos), sondern der Moment danach: Sobald Geräte enrollt sind, erhalten sie Compliance-Policies und Konfigurationsprofile — und eine falsch konfigurierte Compliance-Policy, die auf einmal 2.000 Geräte trifft, produziert einen Incident, der dich den Rest der Woche kostet.

Eine Methode pro Gerät, klar dokumentiert

Mische niemals Enrollment-Methoden auf demselben Gerät. Wenn dein Ziel Co-Management mit SCCM ist, dann steuere das Enrollment über die SCCM-Client-Einstellung und lass die GPO weg (oder schließe die Co-Managed-Sammlung vom GPO-Scope aus). Wenn du klassisches MDM willst, nutze die GPO. Doppelte Enrollment-Trigger erzeugen die unangenehmsten Fehlerbilder: Geräte, die „enrolled, aber nie compliance“ sind, oder Flapping zwischen Verwaltungsautoritäten.

Wartungsmodus für die GPO-Vererbung

GPO-basiertes Enrollment hängt dauerhaft an der GPO. Wird die GPO später gelöscht oder der Link entfernt, enrollen sich neue Geräte nicht mehr — aber bereits enrollte Geräte bleiben enrollt (MDM-Unenrollment passiert nicht durch GPO-Entfernung!). Das ist wichtig für zwei Szenarien: Erstens solltest du die GPO als Teil deiner Enrollment-Dokumentation behandeln und bei OU-Reorganisationen mitdenken; zweitens kannst du die GPO gezielt als „Kill-Switch“ für neue Enrollments nutzen, ohne bestehende Geräte zu gefährden.

Lizenz- und Scope-Drift beobachten

Der MDM User Scope ist benutzerbezogen — und Benutzer wechseln Gruppen. Richte eine regelmäßige Prüfung ein (PowerShell + Graph, monatlich reicht), die zwei Fragen beantwortet: Welche lizenzierten Benutzer sind nicht im MDM-Scope? Und welche enrollten Geräte haben einen zuletzt angemeldeten Benutzer ohne Intune-Lizenz? Ersteres verhindert stille Enrollment-Lücken, letzteres verhindert Compliance-Chaos, weil unmanaged-ähnliche Zustände entstehen, sobald Lizenz und Enrollment auseinanderlaufen.

SSL-Inspection-Whitelist sauber pflegen

Wenn in deiner Umgebung ein SSL-Inspecting-Proxy steht, stelle sicher, dass die Intune- und Entra-Endpoints (*.manage.microsoft.com, login.microsoftonline.com, enterpriseregistration.windows.net) von der Inspection ausgenommen sind. Entra-Device-Authentifizierung und MDM-Enrollment reagieren auf zertifikatsmanipulierende Proxies mit kryptischen Fehlern, die du sonst später in der Troubleshooting-Sektion wiederfindest — präventive Proxy-Hygiene spart dir ganze Wochenenden.

Troubleshooting

Gehen wir die Fehler systematisch an — entlang der Enrollment-Kette, von hinten nach vorne. Die zentrale Anlaufstelle für die Diagnose ist das Event-Log DeviceManagement-Enterprise-Diagnostic-Provider, das du so ausliest:

$logName = "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostic-Provider/Admin"
Get-WinEvent -LogName $logName -MaxEvents 50 |
    Where-Object { $_.LevelDisplayName -ne "Information" } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

Daneben gibt es ein eigenes Auto-Enrollment-Operational-Log (Microsoft-Windows-DeviceManagement-Enterprise-Diagnostic-Provider/AutomaticEnrollment), das den Enrollment-Flow direkt protokolliert — wenn du nur ein Log liest, dann dieses.

Fehler 0x8018002a — MDM User Scope nicht aktiviert

Der mit Abstand häufigste Fehler. Bedeutung: Der Benutzer ist nicht im MDM User Scope in Entra ID. Prüfung: Ist der Scope auf „Some“ gesetzt und der Benutzer in der Gruppe? Hat die Änderung schon propagiert? Und — der Klassiker — ist versehentlich der MAM User Scope für denselben Benutzer aktiv, der dem MDM-Scope vorrangig ist? Behebung: Scope korrigieren, propagieren lassen, Task neu triggern oder 5 Minuten warten.

Fehler 0x80180026 — Lizenzproblem

Bedeutet: Der Account, unter dem das Enrollment läuft, hat keine gültige MDM-Lizenz. Bei User-Credential-Enrollment: dem angemeldeten Benutzer eine Intune-Lizenz zuweisen (Direktlizenz oder via Gruppe — Gruppenlizenzierung kann einige Stunden dauern, das ist ein wiederkehrendes „funktionierte am nächsten Morgen einfach“-Phänomen). Bei Device-Credential-Enrollment: prüfen, welcher Benutzer als primärer Nutzer dem Gerät zugeordnet ist — dessen Lizenz entscheidet.

Fehler 0x801c0021 / 0x801c03f2 — Entra-Join-Probleme

Diese Codes zeigen an, dass der Client kein gültiges Entra-Device-Token bekommt. Ursache fast immer: Das Gerät ist nicht (oder nicht mehr sauber) Hybrid-Entra-joined. Diagnose: dsregcmd /status ausführen und prüfen, ob AzureAdJoined: YES und DeviceId gesetzt sind. Ist das Gerät nur „Entra Registered“, fehlt der Device-Join — dann zuerst den Hybrid-Join reparieren (Sync-Service, Scheduled Task „Automatic-Device-Join“ prüfen), bevor du am MDM-Enrollment weitermachst.

Fehler 0x80192ee7 / WinHTTP-Fehler — Netzwerk und Proxy

Der Client kann den Enrollment-Endpunkt nicht erreichen. Prüfe zuerst die Basics: DNS-Auflösung, Test-NetConnection enrollment.manage.microsoft.com -Port 443. Sitzen die Geräte hinter einem Proxy, prüfe die WinHTTP-Proxy-Konfiguration — denn der Enrollment-Task läuft in einem Kontext, der die Benutzer-Proxy-Einstellungen des Browsers nicht übernimmt:

# WinHTTP-Proxy prüfen (relevant für den Enrollment-Task!)
netsh winhttp show proxy

# Bei Bedarf: Proxy korrigieren
netsh winhttp set proxy proxy-server="proxy.kaffeeundcode.local:8080" `
    bypass-list="*.kaffeeundcode.local;localhost"

# Proxy-Reset auf System-Standard
netsh winhttp reset proxy

Ein Browser funktioniert, der Enrollment-Task aber nicht? Dann ist zu 90 Prozent WinHTTP der Schuldige. Die restlichen 10 Prozent sind SSL-Inspecting-Proxies, die das Zertifikat des Enrollment-Endpunkts ersetzen.

Gerät enrollt nicht, aber es gibt keine Fehler — die stillen Fälle

Zwei stille Fallgruppen tauchen immer wieder auf. Erstens: Der Scheduled Task existiert gar nicht, weil die GPO nicht ankommt (gpresult /h report.html prüfen, ob die MDM-Richtlinie unter „Angewendete Gruppenrichtlinienobjekte“ steht — und die Loopback-Verarbeitung beachten, die Computer-Richtlinien killen kann). Zweitens: Das Gerät ist enrollt, aber du schaust an der falschen Stelle — es taucht unter „Enrolled by“ mit einem anderen primären Nutzer auf als erwartet, oder die Intune-Konsolen-Ansicht ist per Filter verstellt. Immer zuerst dsregcmd /status und die MDM-Details lesen, bevor du irgendetwas „reparierst“.

Manuelles Un-Enrollment — wissen, wie man zurückrollt

Für Tests musst du Enrollment rückgängig können. Der saubere Weg ist die Intune-Konsole (Gerät > Retire) oder remote:

# Vorsicht: entfernt das Device-Enrollment (Retire-Effekt)
# Nur auf Testgeräten ausführen!
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" |
    Unregister-ScheduledTask -Confirm:$false

# MDM-Enrollment-Zertifikat identifizieren (für die Diagnose)
Get-ChildItem Cert:\LocalMachine\My |
    Where-Object { $_.Issuer -match "Microsoft Intune MDM Device CA" } |
    Select-Object Subject, Thumbprint, NotAfter

Und eine wichtige Randnotiz für den Produktivbetrieb: Enthält eine GPO später den Wert AutoEnrollMDM = 0, disenrollt das Gerät nicht — es wird nur verhindert, dass künftige Enrollments getriggert werden. Ein echtes Disenrollment erfordert immer Retire/Wipe über Intune oder das lokale Löschen des Enrollments.

Fazit

Das GPO-basierte Windows-Enrollment ist die Brücke zwischen deiner On-Premises-Welt und dem modernen Cloud-Management — und genau deshalb verdient es einen festen Platz in deiner Intune-Architektur. Es ist kein Legacy-Hack, sondern ein von Microsoft dokumentierter, aktiv gepflegter Enrollment-Pfad, der in Hybrid-Umgebungen meistens der effizienteste Weg ist: keine Hardware-Hashes, kein Benutzer-Klick, keine Provisioning-Pakete — nur zwei Registry-Werte, ein Scheduled Task und eine korrekt konfigurierte Entra-Umgebung.

Die drei Dinge, die du aus dieser Sektion mitnehmen solltest: Erstens — die Reihenfolge der Prüfung bei Problemen folgt immer der Enrollment-Kette: GPO (Registry, Task) → Entra (Scope, Lizenz) → Join (dsregcmd) → Netzwerk (WinHTTP, Proxy) → MDM-Endpunkt. Wer in dieser Reihenfolge debuggt, findet jeden Fehler in Minuten. Zweitens — der MDM User Scope und der Credential-Typ sind Design-Entscheidungen, keine Detailfragen; Device-Credentials sind in Hybrid-Umgebungen fast immer die bessere Wahl. Drittens — der Moment nach dem Enrollment ist der gefährlichste: Starte mit einer Pilot-OU, und verschieße Compliance-Policies bewusst erst, wenn die Enrollment-Zahlen stabil sind.

Mit dem GPO-Enrollment beherrschst du nun den migrationsorientierten Enrollment-Pfad. In den kommenden Sektionen wenden wir uns den Cloud-nativen Wegen zu — Autopilot-Deployment-Profils, Enrollment-Status-Page und Self-Deploying-Szenarien — und vergleichen sie systematisch mit dem, was du hier gelernt hast. Denn am Ende entscheidest nicht du allein über den Enrollment-Pfad, sondern deine Geräte-Lifecycle-Realität: bestehende Flotte versus Neubeschaffung, Domänen-Historie versus Cloud-Only, und wie schnell deine Organisation Change verträgt.