Sektion 08: MDM Authority & Enrollment Restrictions

Einleitung: Die Pforte zu deinem Intune-Tenant

Bevor ein einziges Gerät jemals eine Richtlinie empfangen, eine App installieren oder ein Compliance-Profil auswerten kann, muss es in Intune angemeldet werden. Dieser Vorgang — das sogenannte Enrollment — ist die fundamentalste Interaktion zwischen einem Endgerät und deinem Mobile Device Management. Und genau hier, an dieser Schnittstelle, entscheidet sich, ob dein gesamter Intune-Tenant sich wie ein wohlgeöltes Maschinengetriebe verhält oder wie ein Chaos aus unkontrollierten, nicht verwalteten Geräten.

Die MDM Authority (Mobile Device Management-Autorität) ist der conceptuelle „Besitzanspruch“ deines Intune-Tenants auf Geräte. Sie definiert, welcher Service die Verwaltungshoheit über Geräte hat. Enrollment Restrictions hingegen sind die Türsteher-Regeln: Sie bestimmen, welche Geräte sich überhaupt anmelden dürfen, welche Plattformen zugelassen sind und welche Blockaden automatisch greifen, bevor ein Gerät auch nur ein Byte an Richtlinien-Daten empfängt.

In dieser Sektion gehen wir extrem tief auf beide Konzepte ein — von der historischen Context-Komplexität über Config Manager Co-Management bis hin zu präzisen PowerShell-Automatisierungen für Bulk-Enrollment-Restrictions. Dies ist kein Oberflächen-Überblick. Dies ist das Fundament, auf dem alle weiteren 82 Sektionen aufbauen.

Grundkonzepte: Was ist die MDM Authority wirklich?

Die historische Evolution

Um die MDM Authority in ihrer heutigen Form zu verstehen, muss man kurz in die Geschichte zurückblicken. In den frühen Tagen von Intune (damals noch „Windows Intune“ genannt, circa 2011-2013) war die MDM Authority ein hartes Entweder-Oder: Entweder Intune war die Autorität, oder der lokale Configuration Manager (damals SCCM). Es gab kein „beide gleichzeitig“. Diese als „MDM Authority Set“ bezeichnete Operation war faktisch irreversibel — einmal gesetzt, konnte sie nur durch einen Support-Call bei Microsoft geändert werden.

Mit der Einführung von Co-Management in Configuration Manager Current Branch (1706+) und der Modern Management-Ära verschwamm diese Grenze. Microsoft führte das Konzept der coexistence ein: Ein Gerät kann gleichzeitig über Intune (für moderne Richtlinien, Apps, Compliance) und über Config Manager (für legacy-Pakete, OS Deployment, tiefe Windows-spezifische Workloads) verwaltet werden. Die MDM Authority wurde damit von einem binären Schalter zu einem nuancierten Konfigurations-Modell.

Der aktuelle Zustand: Intune als primäre Autorität

Heute, im Jahr 2026, ist die Situation klarer, aber nicht einfacher. Wenn du einen neuen Intune-Tenant aufsetzt, wird Intune automatisch als MDM Authority gesetzt. Es gibt keinen manuellen „Set-MDMAuthority“-Schritt mehr für reine Cloud-Tenants. Aber für Hybrid-Umgebungen — und davon gibt es in Enterprise-Landschaften weiterhin sehr viele — bleibt die Konfiguration komplex.

Die drei möglichen Autoritäts-Modelle sind:

• Intune (Cloud-only): Intune ist die alleinige MDM-Autorität. Alle Geräte werden direkt über Intune verwaltet. Dies ist das Modell für moderne, cloud-native Umgebungen und der empfohlene Zustand für neue Tenants.
• Config Manager (On-Prem): Der Configuration Manager besitzt die MDM-Autorität. Intune wird lediglich als „Erweiterung“ genutzt, beispielsweise für den Zugriff auf den Intune App-Store oder Conditional Access. Dieses Modell ist deprecated und sollte nicht mehr neu aufgesetzt werden.
• Co-Management (Hybrid): Beide Services verwalten das Gerät, aber mit klar definierten Workload-Aufteilungen. Die MDM Authority bleibt bei Intune, aber bestimmte Workloads (z.B. Compliance Policies, Resource Access Policies, Windows Update Policies) können an Config Manager delegiert werden.

Die Autorität überprüfen — Graph API und PowerShell

Du kannst die aktuelle MDM Authority deines Tenants nicht über das Intune Portal direkt einsehen — Microsoft hat diese Information in die Tiefen der Graph API verbannt. Die relevanteste Methode ist der Aufruf der organization-Ressource mit ausgewählten Eigenschaften.

# Verbindung zum Microsoft Graph herstellen
Connect-MgGraph -Scopes "Organization.Read.All"

# MDM Authority über die Graph API abfragen
$org = Get-MgOrganization
$mdmAuthority = (Get-MgOrganization -Property mobileDeviceManagementAuthority).MobileDeviceManagementAuthority

Write-Host "Tenant Name: $($org.DisplayName)"
Write-Host "Tenant ID: $($org.Id)"
Write-Host "MDM Authority: $mdmAuthority"
# Mögliche Werte: "unknown", "intune", "sccm", "office365"

Die zurückgegebenen Werte haben folgende Bedeutung:

• unknown — Die MDM Authority wurde nie explizit gesetzt. In neuen Tenants kommt dieser Wert selten vor, da Intune beim ersten Intune-Lizenz-Aktivieren automatisch gesetzt wird.
• intune — Intune ist die primäre MDM-Autorität. Dies ist der gewünschte Zustand für die meisten modernen Umgebungen.
• sccm — Config Manager besitzt die Autorität. Wenn du diesen Wert in einem neuen Tenant siehst, ist etwas schiefgelaufen oder es wurde ein bewusster Hybrid-Entscheid getroffen.
• office365 — Die MDM-Lösung von Microsoft 365 (die vereinfachte, limitierte MDM-Variante ohne Intune-Lizenz) besitzt die Autorität. Dies ist ein häufiger Stolperstein, den wir im Troubleshooting-Abschnitt genauer betrachten.

Enrollment Restrictions: Die Türsteher-Regeln

Während die MDM Authority definiert, welcher Service verwaltet, definieren Enrollment Restrictions, was verwaltet wird. Sie sind die erste Verteidigungslinie deines Tenants gegen unkontrollierte Device-Enrollments.

Drei Ebenen von Restrictions

Enrollment Restrictions operieren auf drei konzeptionellen Ebenen, die nacheinander ausgewertet werden:

1. Platform Restrictions (Plattform-Ebene): Bestimmen, welche Betriebssysteme sich überhaupt bei Intune anmelden dürfen. Du kannst Windows, iOS/iPadOS, macOS, Android (Device Administrator), Android (Google Play Managed) und Android Enterprise (Dedicated/Managed) einzeln erlauben oder blockieren.

2. Device Limit Restrictions (Mengen-Ebene): Limitieren, wie viele Geräte ein einzelner Benutzer bei Intune anmelden kann. Standard ist 15 Geräte pro Benutzer. In BYOD-Szenarien kann dieser Wert reduziert werden, in kiosk-artigen Umgebungen erhöht.

3. Platform Restrictions (Detaillierte Filter): Innerhalb jeder Plattform kannst du granular festlegen, welche Geräte sich anmelden dürfen — basierend auf Modell, Hersteller, Betriebssystemversion oder persönlichem vs. firmeneigenem Besitz.

Default vs. Custom Restrictions

Jeder Intune-Tenant hat eine Default Enrollment Device Restriction, die automatisch greift, wenn keine benutzerdefinierte Restriction zutrifft. Diese Default-Restriction erlaubt typischerweise alle Plattformen und hat ein Device Limit von 15. Du kannst die Default-Restriction bearbeiten, aber nicht löschen.

Zusätzlich kannst du Custom Restrictions erstellen und diese spezifischen Gruppen zuweisen. Custom Restrictions haben Priorität über die Default-Restriction, wenn ein Benutzer in der Zielgruppe der Custom Restriction ist. Die Zuweisungslogik folgt dem Standard-Intune-Pattern: Group-based Assignment mit Include/Exclude-Filter.

Praxis-Implementierung: Schritt für Schritt

Schritt 1: Platform Restrictions konfigurieren

Navigiere im Intune Portal zu Devices → Enrollment restrictions → Device type restrictions. Hier siehst du die Default-Restriction und kannst Custom Restrictions erstellen.

Ein typisches Enterprise-Szenario: Eine Organisation erlaubt Windows und iOS für alle Benutzer, blockiert aber Android Device Administrator (veraltet) und macOS (noch nicht supporting) für die breite Masse, erlaubt macOS jedoch für eine spezifische Entwickler-Gruppe.

{
  "name": "Developer-MacOS-Allowed",
  "description": "Erlaubt macOS Enrollment fuer Entwicklergruppe",
  "platformSettings": [
    {
      "platformType": "macOS",
      "platformBlocked": false,
      "personalDeviceEnrollmentBlocked": false,
      "minimumOSVersion": "12.0",
      "maximumOSVersion": null,
      "blockedManufacturers": [],
      "blockedSkus": []
    },
    {
      "platformType": "androidForWork",
      "platformBlocked": true,
      "personalDeviceEnrollmentBlocked": true
    },
    {
      "platformType": "android",
      "platformBlocked": true,
      "personalDeviceEnrollmentBlocked": true
    }
  ],
  "assignments": [
    {
      "target": {
        "@odata.type": "#microsoft.graph.groupAssignmentTarget",
        "groupId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
      }
    }
  ]
}

Schritt 2: Device Limit Restrictions

Das Device Limit ist kritisch für BYOD-Umgebungen. Wenn Benutzer ihre privaten Handys, Tablets, Smartwatches und drei Laptops bei Intune anmelden, füllt ein einzelner Benutzer schnell 10 der 15 verfügbaren Slots. Reduziere das Limit für BYOD-Benutzer auf 5 und erhöhe es für IT-Admins auf 25.

# Device Limit Restrictions über Graph API abfragen
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

$restrictions = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurations"

foreach ($r in $restrictions.value) {
    Write-Host "Name: $($r.displayName)"
    Write-Host "Typ: $($r.'@odata.type')"
    Write-Host "Limit: $($r.limit)"
    Write-Host "Priorität: $($r.priority)"
    Write-Host "---"
}

Schritt 3: Prioritäten verstehen und verwalten

Enrollment Restrictions haben eine Prioritäts-Nummer (1 = höchste Priorität). Wenn ein Benutzer Enrollment auslöst, evaluiert Intune alle zugewiesenen Restrictions in Prioritäts-Reihenfolge. Die erste Restriction, die zutrifft, bestimmt das Ergebnis. Die Default-Restriction hat immer die niedrigste Priorität und greift als Fallback.

Du kannst Prioritäten über das Portal per Drag-and-Drop ändern oder über die Graph API:

# Priorität einer Custom Restriction ändern
$restrictionId = "abc123-def456-..."
$body = @{
    "@odata.type" = "#microsoft.graph.deviceEnrollmentLimitConfiguration"
    "priority" = 2
}

Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceEnrollmentConfigurations/$restrictionId/assign" `
    -Body $body

Best Practices: Production-Grade Configuration

Best Practice 1: Blockiere veraltete Plattformen sofort

Android Device Administrator (DA) ist deprecated und sollte in keinem modernen Tenant mehr erlaubt sein. Blockiere DA-Enrollment in der Default-Restriction und erlaube stattdessen ausschließlich Android Enterprise (Personal-Profile mit Work Profile oder Fully Managed). Das Gleiche gilt für iOS-Enrollments über den Apple Configurator mit DEP — nutze stattdessen Automated Device Enrollment (ADE) via Apple Business Manager.

Best Practice 2: Mindestversionen erzwingen

Setze Minimum-OS-Versionen in deinen Platform Restrictions. Dies verhindert, dass sich Geräte mit veralteten, unsicheren Betriebssystemen bei Intune anmelden. Empfohlene Mindestversionen (Stand 2026):

• Windows: 11 23H2 (Build 22631) — Windows 10 Support endet im Oktober 2025
• iOS/iPadOS: 17.0 — Apple unterstützt typischerweise die aktuelle und die zwei vorherigen Major-Versionen
• macOS: 14.0 (Sonoma) — mindestens die aktuelle und eine vorherige Version
• Android: 13.0 — Minimum für Android Enterprise Work Profile

Best Practice 3: Persönliche vs. firmeneigene Geräte trennen

Verwende die personalDeviceEnrollmentBlocked-Eigenschaft strategisch. Für Abteilungen, die ausschließlich mit firmeneigenen Geräten arbeiten (z.B. Lager, Produktion, Kiosk-Devices), blockiere persönliche Enrollments komplett. Dies verhindert, dass ein Mitarbeiter versehentlich sein prives Handy mit dem firmen-Account bei Intune anmeldet.

Best Practice 4: Die Default-Restriction restriktiv halten

Die Default-Restriction sollte immer die restriktivste Variante sein — erlaubt nur die Plattformen, die in deiner Organisation tatsächlich verwendet werden. Lockere dann gezielt über Custom Restrictions für spezifische Gruppen. Der umgekehrte Ansatz (Default = alles erlaubt, Custom = blockieren) ist fehleranfällig, weil ein vergessener Custom-Assignment dazu führt, dass unerwünschte Plattformen automatisch durchrutschen.

Co-Management: Wenn Config Manager und Intune koexistieren

In vielen Enterprise-Umgebungen existiert der Config Manager weiterhin — und das nicht ohne Grund. OS Deployment, deep- Imaging, tiefgreifende Windows-Konfigurationen und legacy-Paketverteilung sind Dinge, die Intune (noch) nicht vollständig abdeckt. Co-Management ist die Brücke zwischen beiden Welten.

Bei Co-Management wird das Gerät sowohl bei Intune als auch beim Config Manager angemeldet. Die MDM Authority bleibt bei Intune, aber acht spezifische Workloads können zwischen den beiden Services aufgeteilt werden:

• Compliance Policies
• Resource Access Policies
• Device Configuration
• Windows Update Policies
• Endpoint Protection
• Office Click-to-Run Apps
• Client Apps
• Conditional Access

Jede Workload kann auf einen von drei Werten gesetzt werden:

• Intune — Intune verwaltet diese Workload vollständig.
• Config Manager — Config Manager verwaltet diese Workload.
• Pilot Intune — Config Manager verwaltet die Workload für alle Geräte außer einer definierten Pilot-Gruppe, für die Intune zuständig ist. Dies ist der empfohlene Migrations-Pfad.

# Co-Management Status über WMI auf einem Windows-Client abfragen
$coMgmt = Get-CimInstance -Namespace "root\ccm\SIH" `
    -ClassName "CCM_CoMgmt_Config"

if ($coMgmt) {
    Write-Host "Co-Management ist aktiv"
    Write-Host "InternetFacingMP: $($coMgmt.InternetFacingMP)"
    Write-Host "SiteCode: $($coMgmt.SiteCode)"
} else {
    Write-Host "Co-Management ist auf diesem Gerät nicht aktiv"
}

# Detaillierte Workload-Verteilung
$workloads = Get-CimInstance -Namespace "root\ccm\Policy\Machine\ActualConfig" `
    -ClassName "CCM_CoMgmt_Policy"

foreach ($wl in $workloads) {
    Write-Host "Workload: $($wl.WorkloadName)"
    Write-Host "  Intune: $($wl.Intune)"
    Write-Host "  ConfigMgr: $($wl.ConfigMgr)"
    Write-Host "  PilotIntune: $($wl.PilotIntune)"
}

Troubleshooting: Die häufigsten Fallstricke

Problem 1: „MDM Authority ist office365 statt intune“

Dies ist einer der häufigsten und verwirrendsten Fehler. Wenn ein Tenant Microsoft 365 Business Premium-Lizenzen zugewiesen bekommt, wird automatisch die Basic Mobility and Security (früher MDM for Office 365) aktiviert. Diese setzt die MDM Authority auf office365, was Intune-Enrollments blockiert.

Symptome: Geräte können sich nicht bei Intune anmelden. Im Event Log des Clients erscheint Fehler 0x80180014 oder ähnliche Enrollment-Fehler. Im Intune Portal tauchen die Geräte nicht auf, obwohl der Benutzer eine Intune-Lizenz hat.

Lösung:

1. Deaktiviere Basic Mobility and Security im Microsoft 365 Admin Center unter Security & Compliance → Device Security → Manage.
2. Setze die MDM Authority explizit auf Intune, falls sie sich nicht automatisch korrigiert:

# MDM Authority auf Intune setzen (erfordert privilegierten Zugriff)
Connect-MgGraph -Scopes "Organization.ReadWrite.All"

# Dies ist ein irreversibler Vorgang in alten Tenants — 
# in modernen Tenants ist die Authority bereits korrekt gesetzt
$body = @{
    mobileDeviceManagementAuthority = "intune"
}

Update-MgOrganization -BodyParameter $body

# Verifikation
$updated = (Get-MgOrganization -Property mobileDeviceManagementAuthority).MobileDeviceManagementAuthority
Write-Host "Neue MDM Authority: $updated"

Problem 2: „Gerät enrolled, aber empfängt keine Richtlinien“

Ein Gerät hat sich erfolgreich bei Intune angemeldet (es taucht unter Devices auf), aber keine einzige Richtlinie wird angewendet. Dies passiert häufig, wenn Enrollment Restrictions das Enrollment teilweise blockieren — beispielsweise wenn die Plattform erlaubt ist, aber die OS-Version unter dem Minimum liegt.

Diagnose: Prüfe im Intune Portal unter Devices → Enrolled Devices, ob das Gerät als Compliant oder In Grace Period markiert ist. Prüfe dann unter Devices → Enrollment restrictions, ob eine Custom Restriction mit einem Minimum-OS-Filter existiert, die das Gerät verfehlt.

# Enrollment-Status eines spezifischen Geräts über Graph abfragen
$deviceName = "DESKTOP-ABC123"
$device = Get-MgDeviceManagementManagedDevice -Filter "deviceName eq '$deviceName'"

if ($device) {
    Write-Host "Device ID: $($device.Id)"
    Write-Host "Enrollment State: $($device.EnrollmentState)"
    Write-Host "Management State: $($device.ManagementState)"
    Write-Host "OS Version: $($device.OsVersion)"
    Write-Host "Last Sync: $($device.LastSyncDateTime)"
    Write-Host "Enrollment Profile Name: $($device.EnrollmentProfileName)"
} else {
    Write-Host "Gerät nicht in Intune gefunden"
}

Problem 3: „Custom Restriction greift nicht“

Du hast eine Custom Enrollment Restriction erstellt und einer Gruppe zugewiesen, aber Geräte von Benutzern in dieser Gruppe enrollen sich weiterhin nach der Default-Restriction. Die häufigsten Ursachen:

• Priorität zu niedrig: Eine andere Custom Restriction mit höherer Priorität und conflicting settings greift zuerst.
• Gruppenzuweisung fehlerhaft: Der Benutzer ist in der Include-Gruppe, aber auch in einer Exclude-Gruppe.
• Lizenz fehlt: Der Benutzer hat keine Intune-Lizenz. Enrollment Restrictions werden nur für lizenzierte Benutzer ausgewertet.
• Cache: Das Gerät hat bereits ein Enrollment-Attempt gestartet, bevor die Restriction zugewiesen wurde. Ein Re-Enrollment ist erforderlich.

Problem 4: Co-Management Workload-Konflikte

Wenn ein Gerät Co-Managed ist und eine Workload auf Pilot Intune steht, aber das Gerät nicht in der Pilot-Gruppe ist, erhält es keine Richtlinien von Intune für diese Workload — sondern weiterhin vom Config Manager. Dies ist kein Bug, sondern Design, aber es führt regelmäßig zu Verwirrung, wenn Admins erwarten, dass Intune-richtlinien greifen sollten.

Prüfe auf dem Client, welche Workloads tatsächlich von Intune verwaltet werden:

# Auf dem Windows-Client ausführen
# Co-Management Workload-Status abfragen
$comanagementHandler = New-Object -ComObject "Microsoft.Policy.ClientCoMgmtHandler"
# Alternativ über Registry:
$regPath = "HKLM:\SOFTWARE\Microsoft\DeviceManageabilityCsp\DMClient\ProviderProviderID\CoMgmt"
if (Test-Path $regPath) {
    $workloads = Get-ItemProperty -Path $regPath
    $workloads | Format-List
} else {
    Write-Host "Kein Co-Management Registry-Schlüssel gefunden"
}

# Detaillierter: über MDM-Diagnostic
mdmdiagnosticstool -area "DeviceEnrollment" -out "C:\Temp\MDMDiag"

Best Practices: Die Checkliste für den Produktivbetrieb

• Auditieren: Liste alle Enrollment Restrictions in deinem Tenant auf — mindestens quartalsweise. Custom Restrictions, die für temporäre Pilot-Phasen erstellt wurden, sind oft noch aktiv und vergessen.
• Naming Convention: Nutze ein klares Namensschema: [ Plattform ] - [ Scope ] - [ Aktion ], z.B. iOS - Developers - Allow Personal. Dies macht die Restriction-Liste im Portal sofort lesbar.
• Dokumentation der Prioritäten: Erstelle eine einfache Tabelle mit Restriction-Name, Priorität und zugewiesener Gruppe. Wenn ein Enrollment-Problem auftritt, ist dies der erste Anlaufpunkt.
• Device Limit Monitoring: Überwache, wie viele Benutzer nah am Device Limit sind. Benutzer, die ihr Limit erreicht haben, können keine weiteren Geräte enrollen — was zu Helpdesk-Tickets führt, die oft schwer zu diagnostizieren sind.
• Conditional Access Integration: Enrollment Restrictions sind die erste Hürde. Conditional Access ist die zweite. Stelle sicher, dass beide konsistent konfiguriert sind. Wenn Enrollment Restrictions iOS erlauben, Conditional Access aber iOS blockiert, entsteht eine inkonsistente Benutzererfahrung.

Fazit: Das Fundament steht

Die MDM Authority und Enrollment Restrictions sind nicht die glamourösesten Themen in Intune — sie sind aber das Fundament, auf dem alles andere steht. Ein falsch konfiguriertes Device Limit kann Helpdesk-Tickets generieren, eine falsche MDM Authority kann den gesamten Enrollment-Prozess blockieren, und eine vergessene Custom Restriction kann ungeprüfte Geräte in deinen Tenant lassen.

Die wichtigsten Erkenntnisse aus dieser Sektion: Intune ist heute automatisch die MDM Authority in neuen Tenants — aber in Hybrid-Umgebungen bleibt die Konfiguration komplex und erfordert Verständnis der Co-Management-Workloads. Enrollment Restrictions sind deine erste Verteidigungslinie — halte die Default-Restriction restriktiv und lockere gezielt über Custom Restrictions. Prioritäten und Gruppen-Zuweisungen sind die häufigsten Fehlerquellen — dokumentiere sie und auditiere sie regelmäßig.

In der nächsten Sektion werden wir uns mit dem Windows Autopilot befassen — der Automatisierungs-Ebene, die auf diesem Fundament aufsetzt und das Enrollment-Erlebnis für Endbenutzer nahtlos gestaltet. Denn wenn die Restrictions korrekt konfiguriert sind, ist der nächste Schritt, den Enrollment-Prozess so automatisiert wie möglich zu machen.