Client Intune Onboarding – Deep Dive

Microsoft Intune ist der Nachfolger der On-Premises Clientverwaltung SCCM (System Center Configuration Manager) und wird vollständig über Office365 gesteuert. Damit Clients über Intune verwaltbar sind, müssen sie zuvor konfiguriert und onboarded werden. Da der Prozess durchaus seine Tücken aufzeigt und für den Administrator nicht immer zu 100% einsehbar ist, möchte ich mit diesem Deep Dive etwas Licht ins Dunkle bringen. Dieser Artikel bildet bereits den zweiten Teil. Im ersten Beitrag haben wir das Azure AD Onboarding durchleuchtet. Da sowohl der Azure AD Join, als auch das Intune Onboarding Hand in Hand greifen, solltest du vorab dort vorbeischauen, wenn du den Beitrag noch nicht gelesen hat.

Voraussetzungen

Übersicht

Es gibt unterschiedliche Methoden, einen Client in Intune aufzunehmen. Je nach Aufbau der Infrastruktur wird sich die ein oder andere Methode besser eignen. In den meisten Fällen baut eine Unternehmensinfrastruktur auf einem On-Premises Active Directory auf und mittlerweile wird sie durch das Azure AD ergänzt. Das bildet eine klassische hybride Umgebung. Daher richtet sich diese Anleitung auch an genau diese Konstellation.

• On-Premises Active Directory Domäne
• On-Premises Nutzer werden mit dem Azure AD synchronisiert
• Clients sind bereits Azure AD Hybrid Joined -> siehe dazu folgende Anleitung
• Office365 Lizenzen inklusive Intune

Azure AD Connect

Wie bereits angesprochen bezieht sich dieser Deep Dive auf eine hybride Umgebung. Die Synchronisation der lokalen Active Directory Umgebung mit dem Azure AD geht damit einher. Außerdem müssen die Clients sowohl der lokalen Domäne, als auch dem Azure AD beigetreten sein. Wer mit den Begriffen noch nicht all zu viel anfangen kann, sollte sich vorab hier einlesen. Hat der Azure AD Hybrid Join noch mit einem lokalen Benutzer funktioniert, so gilt das für das Intune Onboarding nicht mehr. Es muss zwingend ein synchronisierte Hybrid-Nutzer mit entsprechender Office365 Subscription angemeldet sein.

Office365 Lizenzen

Intune ist natürlich nicht kostenlos und muss entsprechend lizenziert werden. Wurden beim SCCM noch die einzelnen Clients lizenziert, werden die Lizenzen mittlerweile größtenteils auf Benutzerebene verteilt. Es besteht zwar nach wie vor die Möglichkeit Intune Standalone Lizenzen für einzelne Clients zu beziehen, das ist aber nicht mehr der Standard. Office365 basiert auf User-Subscriptions und genau so ist es auch für Intune. Einige O365 Suits beinhalten bereits Intune, andere wiederum nicht. Diesen Faktor sollte man bei der Subscriptionauswahl definitiv beachten. Die gängigsten Subscriptions inklusive Intune sind:

• M365 E3 / E5
• M365 Business Premium
• M365 Enterprise Mobility & Security E3 / E5

Eine vollständige Liste von Microsoft findest du hier: Microsoft Intune Licensing.

Ablauf des Intune Onboardings

Azure AD Hybrid Join

Dieser Artikel baut bereits darauf auf, dass der Client erfolgreich sowohl dem On-Premises als auch Azure AD beigetreten ist. Dabei ist es notwendig, dass dieser im Azure AD Admin Center folgendermaßen aufscheint:

Sollte das bei dir noch nicht der Fall sein, kannst du dir als Hilfestellung folgenden Artikel anschauen.

Active Directory Group Policy

Wir machen uns die Eigenschaft zu Nutze, dass der PC bereits Mitglied der On-Premises Domäne ist. Das bietet uns den Vorteil, den Client ohne manuellen Eingriff im Intune onboarden zu können. Voraussetzung dafür ist natürlich, dass sich der Computer regelmäßig beim Domain Controller meldet und sich die aktuellsten Gruppenrichtlinien abholt.

Dazu erstellen wir eine Computer GPO mit folgender Konfiguration.

Sobald der Client die Richtlinie empfängt, wird ein zusätzlicher Task im Task Scheduler angelegt.

Aufgabe im Task Scheduler

Durch die zuvor konfigurierte Richtlinie, wird folgender Task angelegt.

Dieser Task wird alle 5 Minuten automatisch ausgeführt und startet den Onboarding Prozess für den jeweiligen Client im Intune. Dabei ist es notwendig, dass ein Hybrid-Nutzer mit entsprechender Office365 Intune Lizenz am Client angemeldet ist. Es reicht nicht aus, sich beispielsweise mit einem lokalen Nutzer anzumelden.

Azure AD MFA

Mittlerweile gehört es auch zum Standard, Nutzer mit der Multifaktor Authentifizierung (MFA) in Office365 abzusichern. Das hat natürlich den großen Vorteil, dass ein geleaktes Kennwort nicht direkt zur Accountübernahme führt. Bei jedem neuen Logon wird zusätzlich zum Nutzernamen und Passwort der zweite Faktor (TOTP, SMS, Anruf, …) abgefragt. Dies ist im Falle des automatisierten Intune Onboardings allerdings eher hinderlich. Glücklicherweise kann man über die Conditional Access Policies im Azure AD Admin Center Ausnahmen konfigurieren. So empfehle ich folgende Ausnahme zu setzen:

Damit wird MFA beim Intune Enrollment nicht erzwungen. Solltest du in deiner O365 Organisation auf den zweiten Faktor verzichten, ist dieser Schritt für dich nicht relevant.

Debugging

In der Regel funktioniert der Onboarding Prozess problemlos. Doch wie lässt sich der aktuelle Status überprüfen oder gegebenenfalls Fehler beheben? Eine wertvolle Ressource dafür bildet wie so oft der Event Viewer. Unter folgenden Pfad findet man eine Protokollierung des Intune Onboarding Prozesses: Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin.

Findet man kein Event mit der ID 75 konnte der Onboarding Prozess nicht erfolgreich durchgeführt werden. Als nächstes sollte ein Blick auf das Event mit der ID 76 geworfen werden – dieses gibt Aufschluss über den aufgetretenen Fehler.

Erfahrungsgemäß tritt zum Großteil folgender Fehler auf:

Log Name: Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin
Source: DeviceManagement-Enterprise-Diagnostics-Provider
Event ID: 76
Level: Error
Description: Auto MDM Enroll: Failed (Unknown Win32 Error code: 0x80180002b)

Der Code „0x80180002b“ lässt darauf schließen, dass der Client keinen Token für den angemeldeten Nutzer vom Azure AD beziehen konnte. Die Fehlerursache ist wie so oft vielfältig aber meistens trifft eine der nachfolgenden Gründe zu.

Der angemeldete Benutzer:

• hat keine gültige Intune Lizenz
• wird nicht mit dem Azure AD synchronisiert (er existiert nur im On-Premises Active Directory)
• besitzt keinen öffentlichen Domain Suffix (test.local ist nicht gültig, test.de hingegen schon)
• ist nicht dazu berechtigt, Clients in Intune aufzunehmen (MDM User Scope überprüfen)

In meinem Beispiel oben war ein lokaler Nutzer angemeldet. Sobald sich ein Hybrid-Nutzer mit entsprechender O365 Subscription angemeldet hat und der Task getriggert wurde, hat das Onboarding problemlos funktioniert.

Fazit

Der Intune Onboarding Prozess kann teilweise etwas länger dauern funktioniert aber in der Regel ziemlich gut. Solange sichergestellt werden kann, dass der korrekte Nutzer angemeldet ist sollte einem erfolgreichem Onboarding nichts im Wege stehen – es ist nicht einmal ein Neustart des Systems notwendig. Direkt nach erfolgter Aufnahme beginnt Intune bereits die Richtlinien und Programme zu deployen, die für den jeweiligen Computer/Nutzer vorgesehen sind.

Im Endpoint Manager Portal scheint der Client auch bereits nach kurzer Zeit auf.

Somit konnte der Client erfolgreich in Intune aufgenommen werden, ohne dass ein Administrator manuell auf das Gerät zugreifen musste. Gerade bei einer größeren Flotte an PCs kann das eine enorme Zeitersparnis bedeuten.

Auch Microsoft hat bereits sehr gute Arbeit geleistet und Troubleshooting Dokumentationen zum Thema Intune Onboarding verfasst.