MS365 Intune | Geräteverwaltung

Viele Unternehmen haben Windows-Clients über Jahre mit Active Directory, Gruppenrichtlinien, WSUS, Login-Skripten und manueller Softwareverteilung betrieben. In rein lokalen Umgebungen war das lange ein funktionierendes Modell. Der Client war im LAN, der Domain Controller erreichbar, GPOs wurden verarbeitet und Updates kamen über interne Mechanismen.

Dieses Modell passt aber nur noch bedingt zu heutigen Arbeitsweisen. Benutzer arbeiten im Homeoffice, greifen von unterwegs auf Microsoft 365 zu, nutzen private oder mobile Geräte und erwarten, dass Anwendungen unabhängig vom Standort funktionieren. Gleichzeitig steigt der Sicherheitsdruck. Es reicht nicht mehr, nur zu prüfen, ob Benutzername und Kennwort korrekt sind. Du musst wissen, ob das Gerät verschlüsselt ist, ob der Virenschutz aktiv ist, ob Updates installiert sind und ob geschäftliche Daten in verwalteten Apps bleiben.

Genau hier liegt der Unterschied zwischen klassischer Clientverwaltung und modernem Endpoint-Management. Es geht nicht mehr nur darum, Einstellungen auf ein Gerät zu schreiben. Es geht darum, den Zustand eines Endpunkts kontinuierlich zu bewerten und diese Bewertung in Zugriffsentscheidungen einfließen zu lassen.

Microsoft Intune ist die zentrale Plattform für Mobile Device Management und Mobile Application Management in Microsoft 365. Über das Microsoft Intune Admin Center verwaltest Du Windows, macOS, iOS, iPadOS und Android. Dabei geht es nicht nur um Geräteinventar oder App-Installation. Intune liefert Richtlinien, Compliance-Status, Sicherheitskonfigurationen, App-Schutz, Update-Steuerung und Berichte.

Der alte Blick auf Intune als „MDM für Mobilgeräte“ greift zu kurz. In der Praxis ist Intune heute einer der wichtigsten Bausteine für Microsoft-365-Sicherheit. Sobald Unternehmensdaten über Exchange Online, SharePoint Online, OneDrive, Teams oder Copilot zugänglich sind, wird der Zustand des zugreifenden Endgeräts relevant.

Ein sauber verwalteter Windows-Client kann automatisch konfiguriert, mit Apps versorgt, mit Sicherheitsrichtlinien versehen und über Compliance-Regeln bewertet werden. Ein privates Smartphone muss dagegen nicht zwingend vollständig verwaltet werden. Dort reichen je nach Szenario App-Schutzrichtlinien aus, um Unternehmensdaten innerhalb von Outlook, Teams oder anderen verwalteten Apps zu schützen.

Diese Flexibilität ist der eigentliche Wert von Intune. Du kannst verschiedene Geräteszenarien unterschiedlich behandeln, ohne alles in ein einziges Verwaltungsmodell zu pressen.

In vielen Microsoft-365-Tenants sieht man Geräteobjekte in Microsoft Entra ID und geht davon aus, dass damit bereits Gerätemanagement vorhanden ist. Das ist ein typischer Denkfehler.

Ein Geräteobjekt beantwortet zunächst nur die Frage, ob ein Gerät in Entra ID bekannt ist. Es sagt noch nicht automatisch aus, ob das Gerät über Intune verwaltet wird, ob Richtlinien angewendet werden oder ob der Sicherheitszustand akzeptabel ist.

Für ein belastbares Betriebsmodell brauchst Du mehrere Ebenen:

Erst diese Kette ergibt eine technische Zugriffskontrolle. Wenn ein Gerät nur synchronisiert oder hybrid eingebunden ist, aber keine Compliance-Regel erfüllt, darf es nicht automatisch als vertrauenswürdig gelten.

Gerade bei hybriden Umgebungen ist diese Trennung entscheidend. Microsoft Entra Connect Sync oder Cloud Sync synchronisieren Identitäten und Verzeichnisobjekte. Sie verwalten aber keine Endgeräte im Sinne von Intune. Die eigentliche Steuerung des Gerätezustands erfolgt über MDM-Richtlinien, Compliance Policies, Security Baselines, Update-Ringe und App-Zuweisungen.

Conditional Access ist einer der stärksten Sicherheitsmechanismen in Microsoft 365. Trotzdem wird er häufig zu früh oder zu grob eingesetzt. Eine Regel wie „Zugriff nur von compliant devices“ klingt einfach, funktioniert aber nur dann zuverlässig, wenn die Compliance-Bewertung sauber vorbereitet wurde.

Ohne passende Intune-Compliance-Richtlinien fehlt Conditional Access die Grundlage. Das Gerät muss zunächst registriert sein, die Richtlinie erhalten, den Zustand melden und als compliant oder noncompliant bewertet werden. Erst danach kann Microsoft Entra ID diesen Status für Zugriffsentscheidungen verwenden.

Typische Compliance-Anforderungen sind:

Wichtig ist: Compliance ist kein Ersatz für Security Hardening. Compliance sagt nur, ob ein Gerät definierte Mindestanforderungen erfüllt. Die eigentliche Härtung erfolgt über Konfigurationsprofile, Endpoint Security Policies, Security Baselines, Defender-Richtlinien und App-Kontrollen.

Intune kann Geräte verwalten, aber auch Anwendungen schützen. Diese Unterscheidung ist im Alltag wichtig.

MDM, also Mobile Device Management, eignet sich für firmeneigene Geräte. Hier darf die IT Betriebssystemeinstellungen setzen, Apps installieren, Zertifikate verteilen, WLAN- oder VPN-Profile ausrollen, Updates steuern und Geräte bei Verlust zurücksetzen.

MAM, also Mobile Application Management, ist besonders relevant für BYOD-Szenarien. Dabei wird nicht zwingend das gesamte Gerät verwaltet. Stattdessen schützt Intune Unternehmensdaten innerhalb verwalteter Apps. Du kannst zum Beispiel verhindern, dass geschäftliche Daten aus Outlook in private Apps kopiert werden. Du kannst eine App-PIN erzwingen, Speichern in privaten Speicherorten blockieren oder Unternehmensdaten selektiv aus der App entfernen.

Das ist besonders wichtig, wenn Mitarbeitende private Smartphones nutzen. Die IT sollte dort nicht mehr Kontrolle ausüben als notwendig. Gleichzeitig müssen Unternehmensdaten geschützt bleiben. Genau dafür sind App Protection Policies gedacht.

Die Einschränkung darf man aber nicht übersehen: Ohne vollständige MDM-Registrierung kannst Du keine vollständige Gerätekonfiguration erzwingen. WLAN-Profile, Zertifikate, VPN-Konfigurationen oder App-Installationen liegen dann weiterhin außerhalb Deines direkten Zugriffs. MAM schützt Daten in Apps, ersetzt aber kein Gerätemanagement.

Windows Autopilot reduziert den klassischen Aufwand bei der Clientbereitstellung erheblich. Neue Geräte müssen nicht mehr zwingend manuell installiert, betankt und anschließend an den Benutzer übergeben werden. Stattdessen registrierst Du Geräte im Autopilot-Prozess, weist Profile zu und lässt Windows beim ersten Start automatisch die Unternehmenskonfiguration beziehen.

Für neue Geräte ist ein cloudzentriertes Modell oft sauberer: Microsoft Entra joined, automatische Intune-Registrierung, App-Zuweisung, Konfigurationsprofile, Security Policies und Compliance-Bewertung. Der Benutzer meldet sich mit seinem Unternehmenskonto an, und das Gerät wird schrittweise in den verwalteten Zustand gebracht.

Das bedeutet nicht, dass Hybrid Join sofort verschwindet. In gewachsenen Umgebungen gibt es weiterhin Abhängigkeiten zu lokalen Dateiservern, Legacy-Software, Kerberos-Szenarien oder bestehenden Configuration-Manager-Prozessen. Aber Hybrid Join sollte nicht unreflektiert das Standardmodell für neue Clients bleiben. Wenn Du neue Geräte ohnehin modern ausrollst, solltest Du prüfen, ob Entra Join und Cloud-Management technisch ausreichen.

Der entscheidende Vorteil liegt im Betriebsmodell: Weniger lokale Abhängigkeiten, bessere Unterstützung für mobile Arbeit, klarere Richtlinienzuweisung und eine engere Verzahnung mit Conditional Access.

Ein häufiger Fehler bei Intune-Projekten ist der Versuch, bestehende Gruppenrichtlinien möglichst vollständig nach Intune zu übertragen. Das führt selten zu einem guten Ergebnis. Viele GPO-Umgebungen sind historisch gewachsen, enthalten Altlasten, doppelte Einstellungen, nicht dokumentierte Ausnahmen und Richtlinien, deren ursprünglicher Zweck längst nicht mehr bekannt ist.

Intune sollte nicht als cloudbasierter GPO-Ersatz verstanden werden. Besser ist ein Neuaufbau auf Basis aktueller Sicherheits- und Betriebsanforderungen.

Für Windows-Geräte sind dabei mehrere Bausteine relevant:

Security Baselines sind dabei kein Blindflug-Template. Sie liefern eine sinnvolle Grundlage, müssen aber gegen reale Anforderungen, Supportprozesse und bestehende Applikationen geprüft werden. Gerade restriktive Einstellungen können Fachanwendungen, Remote-Support oder Sonderfälle beeinflussen.

Intune steuert Windows-Updates über Windows Update for Business. Das unterscheidet sich deutlich von klassischem WSUS-Denken. Du genehmigst nicht jede einzelne KB manuell, sondern definierst Update-Ringe, Fristen, Neustartverhalten, Feature-Update-Ziele und Benutzererfahrung.

Ein praxistaugliches Modell besteht meist aus mehreren Ringen:

Ziel ist nicht maximale Verzögerung, sondern kontrollierte Geschwindigkeit. Sicherheitsupdates müssen zuverlässig installiert werden, ohne den Betrieb unnötig zu stören. Feature Updates sollten planbar ausgerollt werden, statt irgendwann ungeordnet auf Clients zu landen.

Intune bietet hierfür Berichte und Statusinformationen. Trotzdem bleibt saubere Gruppierung entscheidend. Wenn Geräte gleichzeitig alte WSUS-GPOs, lokale Update-Einstellungen und Intune Update Rings erhalten, entstehen Konflikte. Vor einer Migration solltest Du deshalb prüfen, welche Update-Mechanismen aktuell wirklich greifen.

Endpoint Security in Intune ist ein eigener Bereich, der für Administratoren besonders relevant ist. Hier bündelst Du sicherheitsnahe Richtlinien wie Antivirus, Firewall, Attack Surface Reduction, Endpoint Detection and Response, Account Protection und Disk Encryption.

In Kombination mit Microsoft Defender for Endpoint entsteht ein deutlich stärkeres Sicherheitsmodell. Defender kann Gerätesignale liefern, Risiken bewerten und diese Informationen in Compliance- oder Conditional-Access-Szenarien einfließen lassen. Dadurch wird aus einer statischen Geräteverwaltung ein dynamischeres Sicherheitsmodell.

Praktisch bedeutet das: Ein Gerät ist nicht nur deshalb vertrauenswürdig, weil es einmal registriert wurde. Sein Zustand wird regelmäßig bewertet. Wenn Schutzmechanismen ausfallen, Richtlinien nicht greifen oder ein erhöhtes Risiko erkannt wird, kann der Zugriff eingeschränkt werden.

Das ist Zero Trust im Alltag. Nicht als Marketingbegriff, sondern als technische Kette aus Identität, Gerätezustand, Risiko und Zugriffsentscheidung.

Viele größere Unternehmen nutzen weiterhin Microsoft Configuration Manager. Das ist nicht falsch. Configuration Manager bleibt in vielen Umgebungen wichtig, etwa für komplexe Softwareverteilung, bestehende Task-Sequenzen, Inventarisierung oder lokale Sonderprozesse.

Co-Management erlaubt es, Windows-Geräte gleichzeitig mit Configuration Manager und Intune zu betreiben. Workloads können schrittweise verschoben werden. So kannst Du bestehende Prozesse weiter nutzen und gleichzeitig moderne Cloud-Funktionen einführen.

Wichtig ist aber die Zieldefinition. Co-Management sollte bewusst geplant werden. Welche Workloads bleiben vorerst bei Configuration Manager? Welche gehen zu Intune? Welche Altprozesse werden abgelöst? Ohne diese Entscheidungen entsteht schnell ein Doppelbetrieb, bei dem niemand mehr eindeutig sagen kann, welche Plattform für welche Einstellung verantwortlich ist.

Ein sinnvolles Vorgehen ist, zunächst Transparenz zu schaffen. Welche Geräte gibt es? Welche GPOs wirken? Welche Software wird verteilt? Welche Compliance-Anforderungen bestehen? Danach verschiebst Du Workloads schrittweise und dokumentierst jede Änderung.

Intune ist in vielen Microsoft-365-Plänen enthalten, aber Lizenzierung sollte nicht oberflächlich betrachtet werden. Entscheidend ist, welche Funktionen Du tatsächlich benötigst.

Microsoft Intune Plan 1 deckt die klassischen MDM- und MAM-Funktionen ab und ist in mehreren Microsoft-365- und Enterprise-Mobility-Paketen enthalten. Erweiterte Funktionen können über Intune Plan 2 oder die Microsoft Intune Suite hinzukommen. Dazu zählen je nach Lizenzmodell zusätzliche Szenarien wie Endpoint Privilege Management oder weitere erweiterte Endpoint-Funktionen.

Für die Praxis bedeutet das: Prüfe nicht nur, ob „Intune dabei“ ist. Prüfe, welche Benutzer und Geräte direkt oder indirekt vom Dienst profitieren, welche Add-ons benötigt werden und ob Sicherheitsfunktionen wie Defender for Endpoint separat lizenziert oder bereits enthalten sind.

Gerade bei Microsoft 365 Business Premium, E3 und E5 unterscheiden sich die enthaltenen Sicherheits- und Verwaltungsfunktionen deutlich. Eine saubere Lizenzprüfung verhindert spätere Überraschungen im Projekt.

Eine Intune-Einführung sollte nicht damit beginnen, wahllos Profile anzulegen. Der bessere Start ist ein klares Betriebsdesign.

Zuerst definierst Du Gerätekategorien: Firmengeräte, BYOD, mobile Geräte, Admin-Workstations, Kiosk-Systeme, geteilte Geräte und Sonderfälle. Danach legst Du fest, welche Plattformen unterstützt werden und welche Mindestanforderungen gelten.

Anschließend baust Du Gruppen- und Zuweisungslogik. Dabei solltest Du dynamische Gruppen, Gerätekategorien und klare Namenskonventionen nutzen. Ohne saubere Struktur wird Intune schnell unübersichtlich.

Danach folgen Pilotgruppen. Starte mit IT-nahen Benutzern und wenigen Geräten. Prüfe Registrierung, Richtlinienverarbeitung, App-Installation, Compliance-Status, Update-Verhalten und Conditional Access. Erst wenn diese Kette stabil funktioniert, solltest Du den Rollout erweitern.

Ein guter Projektablauf sieht so aus:

Besonders wichtig ist die Kommunikation mit den Benutzern. Bei Firmengeräten ist die Erwartung klar: Das Gerät wird verwaltet. Bei privaten Geräten brauchst Du mehr Transparenz. Benutzer müssen verstehen, dass App-Schutzrichtlinien Unternehmensdaten schützen, aber nicht automatisch private Fotos, private Apps oder persönliche Nachrichten auslesen.

Microsoft Intune ist kein einzelnes Feature, sondern ein zentraler Bestandteil moderner Microsoft-365-Architekturen. Der eigentliche Wert entsteht nicht durch das reine Registrieren von Geräten, sondern durch das Zusammenspiel aus Identität, MDM, MAM, Compliance, Endpoint Security, App-Verteilung, Update-Steuerung und Conditional Access.

Für Administratoren bedeutet das: Intune muss sauber geplant, dokumentiert und betrieben werden. Wer nur alte GPOs kopiert oder Geräteobjekte in Entra ID als Verwaltung interpretiert, baut keine belastbare Sicherheitsarchitektur. Wer dagegen den Gerätelebenszyklus konsequent denkt, gewinnt Kontrolle, Automatisierung und Transparenz.

Das Ziel ist nicht, jeden Client maximal zu kontrollieren. Das Ziel ist, für jedes Geräteszenario das richtige Maß an Verwaltung und Schutz zu definieren. Firmengeräte brauchen vollständiges Management. Private Geräte brauchen kontrollierten App-Schutz. Kritische Rollen brauchen strengere Regeln. Und Zugriff auf Unternehmensdaten sollte nie allein von einer erfolgreichen Anmeldung abhängen.

Intune ist damit einer der wichtigsten Bausteine für Zero Trust in Microsoft 365. Nicht, weil ein Portal viele Optionen bietet, sondern weil es den Gerätezustand messbar macht und diesen Zustand in echte Zugriffsentscheidungen übersetzt.