Microsoft 365 Intune | registered, joined oder hybrid joined: Was passt?

Viele hybride Microsoft-Umgebungen sehen im Admin Center sauberer aus, als sie technisch sind. Benutzer werden synchronisiert, Geräteobjekte tauchen in Microsoft Entra ID auf, Microsoft-365-Anmeldungen funktionieren, Conditional Access ist teilweise aktiv. Trotzdem fehlt an der entscheidenden Stelle die Kontrolle: Das Gerät selbst ist noch nicht verwaltet.

AD-Sync, Microsoft Entra Connect Sync oder Cloud Sync lösen Identitätsabgleich. Intune löst Gerätesteuerung. Compliance-Richtlinien bewerten den Zustand des Endpunkts. Conditional Access nutzt diese Bewertung für Zugriffsentscheidungen. Werden diese Ebenen vermischt, entsteht kein modernes Endpoint Management, sondern ein Portalmix mit falschem Sicherheitsgefühl.

Administratoren erliegen oft einem Irrtum: Die bloße Synchronisierung von Identitäten über AD-Sync nach Microsoft Entra ID sei bereits eine vollständige Geräteverwaltung. Diese Annahme erzeugt ein Sicherheitsvakuum. Ein reines Geräteobjekt in der Cloud bietet keine Kontrolle über dessen Konfiguration. Die Synchronisation sorgt nur dafür, dass das Gerät als Identität im Verzeichnis bekannt ist. Ohne aktive MDM-Registrierung (Mobile Device Management) bleibt der Endpunkt für Intune praktisch unsichtbar.

Kausal betrachtet bedeutet das: Microsoft Entra ID kann ein Gerät kennen, ohne dass Intune BitLocker, Defender-Einstellungen, lokale Administratoren, Firewall-Regeln, Windows-Update-Vorgaben oder App-Bereitstellung steuert. Die Geräteidentität ist vorhanden, der Verwaltungszustand fehlt.

Für Conditional Access ist dieser Unterschied kritisch. Wenn eine Richtlinie verlangt, dass ein Gerät als compliant markiert sein muss, braucht Entra ID einen Compliance-Status aus Intune. Ohne MDM-Registrierung existiert dieser Status nicht. Die Richtlinie funktioniert dann nicht wie geplant: Entweder wird der Zugriff blockiert oder es entstehen Ausnahmen, die später kaum noch nachvollziehbar sind. Auch Device Claims sind hier relevant: Ist der Client nicht sauber registriert und verwaltet, fehlen dem Zugriffskontext belastbare Geräteinformationen, wodurch Conditional Access nur auf Basis einer unvollständigen Identitätslage entscheidet.

Die MDM-Registrierung ist deshalb der technische Übergang vom bekannten Gerät zum verwalteten Endpunkt. Erst danach kann Intune Richtlinien anwenden, den Gerätezustand auswerten und diesen Zustand an Entra ID zurückmelden.

Bevor du Windows-Geräte automatisch in Intune bringst, brauchst du die passende Lizenzierung. Für das Windows-Auto-Enrollment ist neben einer Intune-Berechtigung zwingend Microsoft Entra ID P1 oder P2 erforderlich. Diese Lizenz schaltet die automatische MDM-Registrierung frei.

Der zentrale Schalter ist der MDM-Benutzerbereich (MDM User Scope) für Microsoft Intune. Er legt fest, welche Benutzer ihre Geräte automatisch registrieren. Die Werte sind None, Some und All: Mit None bleibt die Registrierung deaktiviert, mit Some steuerst du den Rollout über Gruppen, mit All gilt sie für alle berechtigten Benutzer. Steht der Scope falsch, wird ein Gerät zwar joined oder registered, landet aber nicht automatisch in Intune und bleibt aus Verwaltungssicht blind.

Wichtig ist die saubere Trennung: Die MDM Authority muss auf Intune stehen, damit der Tenant weiß, welcher Dienst die Konfigurationshoheit besitzt. Die automatische Registrierung steuerst du über den MDM-Benutzerbereich. Genau dort entscheidet sich, ob Windows-Geräte nach Join oder Registrierung automatisch in Intune aufgenommen werden.

Der Join Type bestimmt, wie der Endpunkt mit Entra ID verbunden ist. Daraus folgen direkte Konsequenzen für Anmeldung, Verwaltung, Compliance und lokale Abhängigkeiten.

Entra registered passt zu privaten Geräten, deren Firmendaten du über App Protection Policies schützt. Entra joined passt zu neuen Firmengeräten, die direkt aus der Cloud bereitgestellt werden. Hybrid joined ist die Brücke für Bestandsgeräte mit lokalen Abhängigkeiten.

Für neue Windows-Geräte solltest du Hybrid Join nicht mehr setzen: Autopilot Device Preparation unterstützt nur Microsoft Entra Join. Das ist ein klares Signal für die Zielarchitektur, denn neue Geräte sollen nicht unnötig an lokale Domänenlogik gebunden werden, wenn die Arbeitslasten bereits cloudfähig sind. Das Ziel einer modernen Client-Strategie ist deshalb kein dauerhafter Parallelbetrieb: Bestandsgeräte kommen über Hybrid Join in Intune, neue Geräte über Autopilot und Entra Join. Dadurch sinkt die Abhängigkeit von Domain-Controller-Sichtbarkeit, VPN-Timing, GPO-Laufzeiten und lokaler OU-Logik.

Microsoft Entra Connect Sync und Microsoft Entra Cloud Sync werden beide für hybride Identitäten genutzt, sind aber architektonisch unterschiedlich. Connect Sync ist der klassische lokale Synchronisationsserver für komplexere Szenarien, zu denen die Geräteoptionen Hybrid Join und Device Writeback gehören. Device Writeback wird relevant, wenn Conditional Access für AD-FS-geschützte lokale Anwendungen oder bestimmte Windows-Hello-for-Business-Szenarien genutzt wird.

Cloud Sync arbeitet mit leichtgewichtigen Provisioning Agents und wird aus der Cloud gesteuert. Mehrere aktive Agents erhöhen die Verfügbarkeit, wodurch ein einzelner Synchronisationsserver als Engpass entfällt. Cloud Sync synchronisiert Benutzer, Gruppen und Kontakte. Geräteobjekte synchronisiert Cloud Sync nicht, weshalb Hybrid Join und Device Writeback weiterhin Connect Sync erfordern. Ein Parallelbetrieb beider Dienste ist supported, solange sie nicht denselben Objektbereich exportieren.

Cloud Sync ist damit keine pauschale Ablösung für jede bestehende Connect-Installation. Basiert deine Gerätekette auf Hybrid Join und lokalen Geräteoptionen, muss die Migrationsplanung diese Abhängigkeiten berücksichtigen. Sonst synchronisierst du Benutzer sauber, während die Gerätebereitstellung an anderer Stelle bricht.

Für bereits domänengebundene Windows-Geräte ist der Hybrid Join kein Job des Intune Connector for Active Directory. Der Hybrid Join wird über Microsoft Entra Connect vorbereitet: Im Entra-Connect-Assistenten aktivierst du unter "Configure device options" den Hybrid Join für deine Domänen, wodurch der Service Connection Point (SCP) im lokalen AD gesetzt wird. Der SCP teilt den Clients mit, zu welchem Tenant sie gehören, wodurch sich die Geräte selbstständig in Entra ID registrieren.

Ein Punkt wird in gewachsenen Umgebungen häufig übersehen, weil Entra Connect ursprünglich nur für Benutzer und Gruppen betrachtet wurde: Die OUs mit den Computerobjekten müssen im Sync-Scope liegen. Wird die OU mit den Client-Computerkonten nicht synchronisiert, kennt Entra ID das Gerät nicht korrekt und der Hybrid Join kann nicht sauber abgeschlossen werden.

Der Intune Connector for Active Directory wird hier oft falsch eingeordnet. Er ist nicht die allgemeine Brücke für Bestandsgeräte und auch kein Zertifikatsdienst für die Entra-ID-Kommunikation. Für bestehende Domänenclients brauchst du ihn nicht, nur weil du Hybrid Join nutzen willst.

Der Ablauf für Bestandsgeräte sieht vereinfacht so aus: Das Gerät ist Mitglied im lokalen AD, Entra Connect ist für Hybrid Join konfiguriert, der Client findet den SCP, registriert sich in Entra ID und kann danach per GPO zur MDM-Registrierung in Intune bewegt werden. Erst ab diesem Punkt wird aus dem hybrid joined Gerät ein Intune-verwaltetes Gerät. Die Verifikation läuft im Entra Admin Center unter Devices > All devices: Der Status "Pending" bedeutet, dass das Gerät den Registrierungsprozess noch nicht abgeschlossen hat.

Verlinke die Enrollment-GPO nicht direkt auf Domänenebene. Gerade beim MDM-Auto-Enrollment willst du nicht versehentlich Server, Admin-Workstations, Testsysteme oder Spezialclients in einen Prozess ziehen, den du noch nicht sauber ausgewertet hast.

Nutze eine Pilot-OU mit wenigen Windows-Clients. Die Geräte sollten repräsentativ sein: ein Standard-Notebook, ein Desktop-Client, ein VPN-Client, ein Gerät mit BitLocker, ein Gerät mit typischen Fachanwendungen. Dadurch erkennst du früh, ob Join-Status, Benutzerlizenz, MDM-Benutzerbereich, GPO-Anwendung und Conditional Access zusammenpassen.

Eine sprechende GPO-Benennung hilft im Betrieb, weil sie Zweck und Credential-Auswahl sichtbar macht. Das zahlt sich bei Audits, Troubleshooting und Übergaben aus:

Per Rechtsklick auf die OU wählst du "Gruppenrichtlinienobjekt hier erstellen und verknüpfen", wodurch GPO und Verknüpfung in einem Schritt entstehen und die Richtlinie nur auf die Computer dieser OU wirkt. Vergib den sprechenden Namen aus dem vorherigen Abschnitt und bestätige mit OK.

Danach öffnest du das GPO per Rechtsklick und "Bearbeiten". Im Editor navigierst du zu Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > MDM. Fehlt der MDM-Ordner, ist der Central Store veraltet: Aktualisiere die ADMX-Vorlagen (MDM.admx) aus einem aktuellen Windows-11-Build in SYSVOL, sonst siehst du die Richtlinie nicht.

Im MDM-Ordner öffnest du "Enable automatic MDM enrollment using default Microsoft Entra credentials" und setzt den Status auf Aktiviert. Im Dropdown "Select Credential Type to Use" wählst du User Credentials. Mehr konfiguriert diese Richtlinie nicht: Sie erstellt auf den Clients die geplante Aufgabe "Schedule created by enrollment client for automatically enrolling in MDM from Microsoft Entra ID", die nach der nächsten Benutzeranmeldung das Enrollment mit dem Entra-ID-Token startet. Auf dem Testclient beschleunigst du den Vorgang mit gpupdate /force und einer Ab- und Anmeldung.

Es bleibt bewusst bei dieser einen Richtlinie mit einer Einstellung. Alles Weitere (Lizenz, MDM-Benutzerbereich, Hybrid-Join-Zustand) liegt außerhalb der GPO und entscheidet trotzdem über Erfolg oder Misserfolg des Enrollments.

Für Bestandsgeräte in einer lokalen Domäne ist die Gruppenrichtlinie der klassische Hebel, um Geräte automatisch in Intune zu bringen. Die Richtlinie liegt unter Computer Configuration > Policies > Administrative Templates > Windows Components > MDM und heißt "Enable automatic MDM enrollment using default Microsoft Entra credentials".

Im Standardszenario wählst du User Credentials. Die Registrierung läuft über eine geplante Aufgabe, die nach der Anmeldung eines synchronisierten Benutzers dessen Entra-ID-Token verwendet, was zur nutzerzentrierten Intune-Lizenzierung passt. Der angemeldete Benutzer muss im MDM-Benutzerbereich liegen und eine Intune-Lizenz besitzen.

Device Credentials sind nicht die richtige Standardauswahl. Microsoft beschreibt diese Option für Spezialfälle wie Co-Management mit dem Configuration Manager und Azure-Virtual-Desktop-Multi-Session-Hosts. Setzt du Device Credentials ohne passendes Szenario, scheitert das Enrollment mit unklaren Symptomen auf dem Client.

Die Voraussetzungen für ein funktionierendes GPO-Enrollment sind damit klar: Das Gerät muss hybrid joined sein, der Benutzer synchronisiert und lizenziert, der MDM-Benutzerbereich muss greifen, die GPO muss auf die richtige OU wirken. Nach Richtlinien-Update und Benutzeranmeldung startet die geplante Aufgabe die Registrierung.

Für die automatische Ermittlung der Enrollment-Endpunkte werden häufig zwei CNAME-Einträge genannt: EnterpriseEnrollment und EnterpriseRegistration. Diese Einträge helfen vor allem bei Szenarien, in denen Benutzer Geräte manuell registrieren oder Windows die passenden Endpunkte über die Domäne finden soll.

Für die GPO-gesteuerte Registrierung hybrid joined Geräte sind die CNAMEs nicht der zentrale Schalter. Entscheidend sind der MDM-Benutzerbereich in Entra ID, die Intune-Lizenz des Benutzers, der korrekte Hybrid-Join-Zustand und die GPO-Einstellung. Die CNAMEs sind trotzdem sinnvoll, weil sie die Registrierungserfahrung stabilisieren und manuelle Eingaben vermeiden. Sie ersetzen aber keine fehlerhafte Auto-Enrollment-Konfiguration.

Der Intune Connector for Active Directory wird relevant, wenn du neue Geräte per Windows Autopilot als hybrid joined bereitstellst. In diesem Szenario erstellt der Connector das Computerkonto im lokalen AD und liefert dem Client einen Offline-Domain-Join-Blob (ODJ), wodurch der Domänenbeitritt während der Autopilot-Bereitstellung vorbereitet wird.

Dieses Modell ist technisch möglich, aber fehleranfälliger als Microsoft Entra Join. Der Client muss die lokale Domäne erreichen können, was Netzwerk, VPN, DNS, Domain-Controller-Erreichbarkeit und das Timing der Enrollment Status Page betrifft. Genau deshalb sollte Hybrid-Autopilot nicht mehr als Standard für neue Geräte gesetzt werden.

Betreibst du dieses Szenario, prüfe den Connector-Stand: Versionen vor 6.2501.2000.5 verarbeiten keine Registrierungsanfragen mehr. Die aktuelle Connector-Generation läuft mit einem Managed Service Account, was die Abhängigkeit von klassischen Dienstkonten reduziert, aber eine saubere Aktualisierung der Installation verlangt. Bei der Delegation gilt: Der Connector braucht Rechte zum Erstellen und Löschen von Computerobjekten in der Ziel-OU, nicht tenantweit und nicht auf der kompletten Domäne. Least Privilege ist hier kein optionaler Feinschliff, sondern Teil des Designs. Im Autopilot-Bereitstellungsprofil stellst du zusätzlich "Microsoft Entra hybrid joined" auf Ja, sonst führt das Gerät während der OOBE keinen ODJ durch.

Ohne dynamische Gerätegruppen wird Autopilot schnell unübersichtlich, weil Enrollment-Profile, Enrollment Status Page, Apps und Richtlinien sauber zugewiesen werden müssen. Die Gruppen erstellst du im Entra Admin Center als Sicherheitsgruppen mit dem Mitgliedschaftstyp "Dynamic Device".

Eine Gruppe für alle Autopilot-Geräte (ZTDid = Zero Touch Deployment ID):

Für Geräte mit Group Tag nutzt du das OrderID-Attribut:

Für Geräte aus einer bestimmten Bestellung die PurchaseOrderId:

Wichtig ist die Architektur dahinter. Group Tags sind keine zufällige Sortierhilfe, sondern sollten deine Bereitstellungslogik abbilden: Abteilung, Gerätekategorie, Standort oder Einsatzzweck. Nutzt du später Autopilot Device Preparation, muss die Gruppierung noch sauberer sein, weil Microsoft das neue Verfahren stärker auf Entra Join und Intune-Profile ausrichtet.

Seamless Single Sign-On verbessert die Anmeldung an Cloud-Diensten für domänengebundene Clients im Unternehmensnetz, indem es die lokale Kerberos-Identität des Benutzers nutzt. Es macht aus einem Gerät aber kein compliant device. Bei modernen Entra-joined- und Hybrid-joined-Geräten übernimmt ohnehin das Primary Refresh Token (PRT) das SSO, Seamless SSO greift ergänzend für Konstellationen ohne PRT.

Für Seamless SSO muss die URL https://autologon.microsoftazuread-sso.com in der Intranetzone des Benutzers liegen, weil Windows nur aus dieser Zone das Kerberos-Ticket automatisch herausgibt. Eine Zuordnung zu den Trusted Sites blockiert die Anmeldung. Früher wurden oft mehrere Microsoft-URLs breit in die Intranetzone gelegt: Solche Listen solltest du gezielt prüfen, statt sie blind zu übernehmen, denn eine zu breite Zonenzuweisung ist kein gutes Sicherheitsdesign. Die Umsetzung erfolgt per Benutzer-GPO über die "Site to Zone Assignment List" (Wert 1 = Intranetzone).

Beachte zusätzlich die Kerberos-Umstellung: Mit dem Juli-2026-Update ändert Windows Server den Standard-Verschlüsselungstyp von RC4 auf AES-256, wodurch Umgebungen mit erzwungenem RC4 in SSO-Probleme laufen können.

Die Einordnung bleibt entscheidend: Seamless SSO hilft bei der Benutzererfahrung. Conditional Access und Intune-Compliance entscheiden über den kontrollierten Zugriff. Fehlt das PRT (AzureAdPrt auf NO), wird die Anmeldung problematisch. Fehlt die Compliance, bleibt der Zugriff auf geschützte Ressourcen trotz SSO blockiert.

Nach erfolgreicher Registrierung beginnt der eigentliche Betrieb. Intune ersetzt nicht einfach die Gruppenrichtlinienkonsole im Browser. Der Settings Catalog arbeitet über Windows Configuration Service Providers (CSPs), die Einstellungen auf Geräte- oder Benutzerebene setzen und Statusdaten zurückliefern.

Der Vorteil liegt in der Auswertbarkeit: Du prüfst einzelne Einstellungen, erkennst Konflikte und steuerst Zuweisungen über Gruppen und Filter. Bei alten GPO-Landschaften ist dagegen oft unklar, welche Richtlinie am Ende gewinnt. Intune macht die Konflikte sichtbarer, wenn die Profile sauber gebaut sind.

Trotzdem sollte keine GPO ungeprüft migriert werden. Viele alte Richtlinien lösen Probleme, die in einer modernen Windows-11- und Microsoft-365-Umgebung nicht mehr existieren. Andere Einstellungen gehören besser in Endpoint-Security-Profile, Compliance-Richtlinien oder Security Baselines.

Wichtig ist die Scope-Logik. Einstellungen wirken im User-Scope (HKCU) oder Device-Scope (HKLM). Ist dieselbe Einstellung auf beiden Ebenen konfiguriert, hat laut Microsoft-Spezifikation der User-Scope Vorrang. Das wird relevant, wenn du Richtlinien auf Benutzergruppen und Gerätegruppen mischst. Ohne klare Zuweisungslogik entstehen Konflikte, die im Betrieb schwer zu lesen sind.

Compliance-Richtlinien sind der Punkt, an dem Gerätemanagement und Zugriffsschutz zusammenlaufen. Intune prüft den Gerätezustand, Entra ID nutzt diesen Zustand im Conditional-Access-Flow. Erst dadurch kann der Zugriff auf Exchange Online, SharePoint Online oder andere Cloud-Apps davon abhängen, ob der Client deine technischen Vorgaben erfüllt.

Typische Windows-Kriterien sind BitLocker, Secure Boot, Mindestversion des Betriebssystems, Defender-for-Endpoint-Risikostufe oder Passwortvorgaben. Welche Kriterien sinnvoll sind, hängt vom Schutzbedarf ab. Entscheidend ist die Reihenfolge: Zuerst muss das Gerät in Intune registriert sein. Danach braucht es eine Compliance-Richtlinie. Danach testest du die Auswertung mit einer Pilotgruppe. Erst dann sollte Conditional Access mit "Require device to be marked as compliant" produktiv greifen. Microsoft warnt ausdrücklich davor, eine solche Richtlinie ohne vorhandene Compliance-Richtlinie zu aktivieren, weil sie dann nicht wie geplant funktioniert.

Nicht jedes Gerät sollte vollständig per MDM verwaltet werden. Bei privaten Smartphones und Tablets ist App-Schutz oft der bessere Weg. App Protection Policies schützen Unternehmensdaten innerhalb verwalteter Apps, ohne das komplette Gerät zu übernehmen: Du blockierst Kopieren in private Apps, verhinderst Speichern in private Speicherorte, verlangst eine App-PIN und löschst Unternehmensdaten selektiv. Der Benutzer behält sein privates Gerät unter eigener Kontrolle, die Unternehmensdaten bleiben trotzdem geschützt.

Dieses Modell passt zu Geräten im Status Microsoft Entra registered. Der Benutzer fügt sein Geschäftskonto hinzu, Conditional Access verlangt verwaltete Apps, Intune schützt die Daten innerhalb der App. Für BYOD ist das meist sauberer als ein erzwungenes MDM-Enrollment.

Für Aufgaben außerhalb der Standard-MDM-Schnittstellen nutzt Intune die Intune Management Extension (IME). Sie erweitert Windows-MDM um PowerShell-Skripte und Win32-App-Bereitstellung und wird automatisch installiert, sobald ein unterstütztes Gerät ein Skript oder eine Win32-App zugewiesen bekommt. Der lokale Dienst heißt IntuneManagementExtension. Bei Problemen mit Skripten oder Win32-Apps ist die Dienstprüfung der erste sinnvolle Schritt:

Danach prüfst du die Logs auf dem Client und den App- oder Skriptstatus im Intune Admin Center. Ist das Gerät nur teilweise registriert, läuft ein nicht unterstütztes Betriebssystem oder greift die Zuweisung nicht, arbeitet die IME nicht wie erwartet.

Wenn ein Gerät nicht in Intune erscheint, prüfst du nicht zuerst die App-Verteilung, sondern die Identitätskette. Der wichtigste Befehl trennt Bauchgefühl von technischem Zustand:

Im Abschnitt Device State prüfst du:

Für hybrid joined Bestandsgeräte müssen beide Werte auf YES stehen. Steht DomainJoined auf YES und AzureAdJoined auf NO, fehlt der Cloud-Join. Steht AzureAdJoined auf YES, aber das Gerät taucht nicht in Intune auf, liegt das Problem eher im Enrollment oder im MDM-Benutzerbereich.

Im Abschnitt SSO State prüfst du:

Das Primary Refresh Token ist für den Zugriffskontext entscheidend. Steht AzureAdPrt auf NO, können SSO und die Conditional-Access-Auswertung fehlschlagen oder unvollständig wirken.

Im Abschnitt Tenant Details prüfst du die MDM-Werte:

Sind diese Werte leer, hat der Client die MDM-Konfiguration nicht erhalten oder noch nicht verarbeitet.

Für die Gruppenrichtlinie prüfst du lokal, ob die Auto-Enrollment-GPO wirklich angewendet wird:

In der Ereignisanzeige prüfst du:

Achte auf die Enrollment-Events: Event ID 75 meldet ein erfolgreiches Auto-Enrollment. Event ID 76 ist kein Erfolgshinweis, sondern taucht in Microsofts Troubleshooting-Dokumentation bei fehlgeschlagenem Auto-Enrollment auf, etwa mit Fehlercode 0x8018002b (häufig ein Hinweis auf Lizenz- oder UPN-Probleme). Erscheint weder Event ID 75 noch 76, wurde das Auto-Enrollment oft gar nicht getriggert, was auf eine nicht angewendete GPO hindeutet.

Nach der technischen Prüfung folgt der Funktionstest. Melde dich an einem Pilotgerät mit einem synchronisierten und lizenzierten Benutzer an. Prüfe den Zugriff auf Microsoft 365, etwa über Edge auf Office im Web. Greift das SSO sauber, läuft die Anmeldung ohne zusätzliche Passwortabfrage oder mit vorausgefülltem Konto.

Danach prüfst du im Intune Admin Center, ob das Gerät als verwaltet erscheint, eine Compliance-Richtlinie erhalten hat und einen Compliance-Status liefert. Erst wenn dieser Status stabil ist, ergibt eine Conditional-Access-Richtlinie mit "Require device to be marked as compliant" Sinn.

Das Portal ist dabei nur ein Teil der Wahrheit. Entscheidend ist der Abgleich aus Client-Status, Entra-Gerät, Intune-Gerät, Compliance-Status und den Conditional-Access-Sign-In-Logs. Wenn diese fünf Punkte zusammenpassen, ist die Gerätekette belastbar.

Android Device Administrator (DA) ist für moderne Intune-Umgebungen kein tragfähiger Verwaltungsmodus mehr. Google hat das Modell 2020 abgekündigt. Microsoft beendete den Support für DA auf Geräten mit Google Mobile Services (GMS) zum 31. Dezember 2024. Für Geräte ohne GMS beschreibt Microsoft eine eingeschränkte Legacy-Unterstützung auf Android 15 und älter über den Stichtag hinaus. Für normale Firmengeräte mit GMS solltest du nicht mehr auf DA setzen.

Die Zielmodelle heißen Android Enterprise Work Profile für private Geräte, Fully Managed für Firmengeräte und Dedicated Device für Kiosk- und Spezialhardware. Diese Modi nutzen die aktuellen Android-Enterprise-Schnittstellen, wodurch Sicherheitsfunktionen, App-Steuerung und Compliance-Anforderungen abgedeckt sind. Wichtig für die Abgrenzung: Auto-Enrollment und Verwaltungsmodus sind zwei unterschiedliche Dinge. Samsung Knox Mobile Enrollment und Google Zero Touch bleiben nutzbar, müssen aber in Android Enterprise münden, nicht in Device Administrator.

Für bestehende AD-Umgebungen ist ein kontrollierter Übergang besser als ein harter Schnitt. Bestandsgeräte kommen per Hybrid Join und GPO in Intune, wenn lokale Abhängigkeiten bestehen. Damit bekommst du Sichtbarkeit, Richtlinien und Compliance-Bewertung, ohne sofort alle lokalen Anwendungen umzubauen. Neue Windows-Geräte werden direkt über Autopilot und Entra Join bereitgestellt, wodurch der Anteil cloudnativ verwalteter Clients mit jeder Hardware-Erneuerung wächst.

Dynamische Autopilot-Gruppen bleiben nützlich, wenn sie bewusst gepflegt werden und Group Tags die Bereitstellungslogik abbilden. Pilot-OUs bleiben nützlich, wenn Bestandsgeräte per GPO aufgenommen werden. Seamless SSO bleibt nützlich, wenn es als Anmeldekomfort verstanden wird und nicht als Ersatz für Compliance.

Parallel bereinigst du die GPO-Landschaft. Sicherheitsrelevante Einstellungen wandern in Endpoint Security, Compliance Policies oder den Settings Catalog. Win32-Apps laufen über die IME. Private Geräte werden per MAM geschützt. Android DA wird durch Android Enterprise ersetzt.

Die Zielarchitektur ist eine klare Gerätekette: Identitätssynchronisation macht Benutzer und Verzeichnisobjekte bekannt. Device Join legt fest, wie das Gerät gegenüber Entra ID auftritt. Intune MDM steuert das Betriebssystem. Intune MAM schützt Firmendaten in Apps. Compliance bewertet den Zustand. Conditional Access erzwingt Zugriff auf Basis dieser Bewertung. Steht diese Kette, wird der Microsoft-365-Zugriff nicht mehr nur über Benutzername, Passwort und MFA gesteuert: Der Zustand des Endgeräts wird Teil der Entscheidung.

Ein Gerät in Microsoft Entra ID zu sehen, reicht nicht aus. Sichtbarkeit ist der Startpunkt, nicht das Ziel. Der technische Wert entsteht erst, wenn Geräteidentität, MDM-Registrierung, Compliance-Bewertung und Conditional Access zusammenspielen.

AD-Sync, Connect Sync oder Cloud Sync lösen den Identitätsabgleich. Sie beantworten die Frage, welche Benutzer, Gruppen und Verzeichnisobjekte in Entra ID verfügbar sind. Intune beantwortet eine andere Frage: Welchen Zustand muss ein Gerät haben, bevor es auf Unternehmensdaten zugreifen darf? Diese Trennung muss im Design sichtbar bleiben.

Für Bestandsgeräte bleibt der bewährte Ablauf richtig: OU-Scope prüfen, Pilot-OU verwenden, GPO mit User Credentials setzen, dsregcmd /status auswerten, Eventlogs prüfen und erst danach Conditional Access scharf schalten. Geändert hat sich die strategische Einordnung: Hybrid Join ist kein Zielbild für neue Clients mehr, sondern eine Brücke für gewachsene Umgebungen. Autopilot Device Preparation unterstützt keinen Hybrid Join, Microsofts Richtung ist damit klar: Neue Clients starten direkt Entra joined und cloudverwaltet. Hybrid-Autopilot bleibt technisch möglich, bringt aber Abhängigkeiten mit, die du nur für echte Legacy-Anforderungen akzeptieren solltest.

Für den Betrieb zählt Nachvollziehbarkeit. Wenn ein Gerät keinen Zugriff bekommt, musst du erkennen können, ob der Fehler im Join-Status, im Enrollment, in der Compliance-Richtlinie, in Conditional Access oder auf App-Ebene liegt. Genau deshalb ist eine saubere Architektur wichtiger als ein schnell befülltes Portal. Mit Entra Join für neue Geräte, Intune MDM für Firmengeräte, MAM für private Endpunkte, Compliance als Zugriffssignal und Android Enterprise statt Device Administrator entsteht eine belastbare Verwaltungsstruktur. Kein Stückwerk, kein doppeltes Richtlinienchaos, keine falsche Sicherheit durch bloße Geräteobjekte.