Warum ersetzt Microsoft Intune Active Directory und GPOs nicht vollständig – und wann ist Intune trotzdem die richtige Wahl?

Was klassische On-Prem-Clientverwaltung tatsächlich leistet: AD, GPO-Verarbeitung, Skripting, Timing und Offline-Betrieb

Klassische On-Prem-Clientverwaltung basiert auf einer engen Kopplung zwischen Windows-Clients, Active Directory (AD) und Gruppenrichtlinien (GPOs), meist ergänzt um ein Softwareverteilungssystem. Der technische Kern ist nicht „Verwaltung“ im abstrakten Sinn, sondern ein deterministisches Zusammenspiel aus Identität (Computer- und Benutzerkonto), Domänenmitgliedschaft, zentralen Richtliniendefinitionen und einem ausgereiften Client-seitigen Policy-Engine-Stack. Daraus entstehen Eigenschaften, die Cloud-MDM bewusst nicht in gleicher Tiefe abbildet: unmittelbare Anwendbarkeit im lokalen Netzwerk, feingranulare Verarbeitungsschritte mit klarer Priorisierung und ein Zugriff bis in Betriebssystem- und Anmeldepfade hinein.

AD-Integration als Fundament: Identität, Autorisierung und Zielgruppenbildung

Die Domänenmitgliedschaft verankert Geräte in einem konsistenten Identitäts- und Vertrauensmodell. Ein Computer authentifiziert sich gegenüber Domänencontrollern, erhält Zugriff auf Ressourcen (Kerberos; NTLM typischerweise nur noch für Legacy-Szenarien), und kann über AD-Attribute, OU-Strukturen und Sicherheitsgruppen zielgenau adressiert werden. Diese Zielgruppenbildung ist nicht nur organisatorisch, sondern technisch wirksam: GPO-Scope, Security Filtering und WMI-Filter greifen ineinander, ohne dass zusätzliche Agenten oder externe Verfügbarkeit vorausgesetzt werden.

In der Praxis bedeutet das: Ein Gerät, das in einer bestimmten OU liegt und Mitglied definierter Gruppen ist, erhält genau die für diesen Kontext vorgesehenen Einstellungen, Skripte und Softwarezuweisungen. Für viele Umgebungen ist dabei entscheidend, dass diese Logik unabhängig von Internetzugriff funktioniert und im LAN mit geringer Latenz arbeitet, inklusive Fallbacks über Site-Affinität und mehrere Domänencontroller.

GPO-Verarbeitung: Reihenfolge, Vererbung, Konfliktlösung und Nachvollziehbarkeit

Die Gruppenrichtlinienverarbeitung folgt klar definierten Regeln: Lokale Richtlinien, Site-, Domänen- und OU-GPOs werden in fester Reihenfolge ausgewertet (LSDOU), Vererbung und „Enforced“/„Block Inheritance“ steuern die Reichweite, und Konflikte werden in der Praxis pro Richtlinienerweiterung bzw. pro Einstellungstyp aufgelöst (häufig „zuletzt angewendet gewinnt“, aber nicht als universelle Regel für alle CSEs). Dadurch entsteht eine hohe Vorhersagbarkeit, die in größeren Umgebungen wesentlich ist, etwa bei sicherheitsrelevanten Baselines oder bei restriktiven Hardening-Vorgaben.

GPOs wirken zudem über unterschiedliche Erweiterungen (Client Side Extensions) tief in Windows hinein: Sicherheitsoptionen, Administrative Vorlagen, Softwareinstallation (MSI), Folder Redirection, Drive Mappings, Firewall-Regeln, geplante Aufgaben, Einschränkungen für Dienste oder Geräteklassen. Viele dieser Bereiche sind historisch gewachsen, aber technisch stabil, weil sie direkt an OS-Komponenten andocken, statt über ein generisches MDM-Abstraktionsmodell zu laufen.

Skripting und Automatisierung: Start, Anmeldung, Shutdown und kontextabhängige Logik

Ein wesentlicher Differenzierungsfaktor ist die Skriptsteuerung entlang definierter System- und Benutzerübergänge. Start-/Shutdown-Skripte laufen im Systemkontext, Anmelde-/Abmeldeskripte im Benutzerkontext. Damit lassen sich Abhängigkeiten sauber abbilden, etwa: „Vor der Benutzeranmeldung muss ein Zertifikat importiert und ein Dienst konfiguriert sein“ oder „Beim Abmelden werden Profile bereinigt“. Diese Kopplung an den Lebenszyklus reduziert Timing-Risiken, die bei asynchronen Policy-Modellen typischerweise entstehen.

Hinzu kommt die Möglichkeit, sehr spezifische Logik auszuführen: Prüfungen auf installierte Komponenten, Netzwerkstandort, Domänenvertrauen, Vorhandensein von Shares oder Zertifikaten. Skripte können wiederholt werden (z. B. über geplante Aufgaben oder wiederkehrende Logon-Trigger), bis ein gewünschter Zustand erreicht ist, ohne auf Cloud-Check-ins oder MDM-Refresh-Intervalle warten zu müssen.

• Verarbeitungs- und Diagnosebasis: gpupdate /force
gpresult /r
gpresult /h C:\Temp\gpresult.html
• Lokalisierung der GPO-Events: Event Viewer > Applications and Services Logs\Microsoft\Windows\GroupPolicy\Operational
• Skripte über GPO zuweisen: Computer Configuration\Policies\Windows Settings\Scripts (Startup/Shutdown)
User Configuration\Policies\Windows Settings\Scripts (Logon/Logoff)
• Gezielte Konfigurationsprüfung in PowerShell: Get-Service -Name w32time
Test-Path "\\fileserver\share\policy.flag"

Timing und Determinismus: Warum „sofort“ im LAN häufig tatsächlich sofort bedeutet

GPOs werden beim Systemstart und bei der Benutzeranmeldung verarbeitet; zusätzlich greifen Hintergrundaktualisierungen in definierten Intervallen. In domänenbasierten Netzen führt das zu einem für Betrieb und Change-Management wichtigen Effekt: Ein Rollout lässt sich an Ereignisse koppeln, die ohnehin stattfinden, und die Wirkung tritt reproduzierbar ein. Wenn eine Einstellung zwingend vor der interaktiven Anmeldung gelten muss (z. B. Firewall-Profile, Credential Guard-Voraussetzungen, Sperrbildschirmrichtlinien), kann On-Prem-Policy-Verarbeitung diesen Zeitpunkt technisch erzwingen.

Auch Abhängigkeiten in der Reihenfolge sind besser kontrollierbar: Erst Netzwerk, dann Computerrichtlinien, dann Startskripte, dann Benutzeranmeldung, dann Benutzerrichtlinien. Kombiniert mit „Always wait for the network at computer startup and logon“ kann die Umgebung sicherstellen, dass Richtlinien nicht ins Leere laufen, wenn ein Client kurzzeitig ohne DC-Kontakt startet.

Offline-Betrieb und lokaler Zugriff: Funktionalität ohne Internet als Designmerkmal

Klassische Clientverwaltung ist nicht darauf angewiesen, dass ein Gerät permanent online ist oder einen Cloud-Dienst erreicht. Ein Notebook kann im Offline-Modus weiterarbeiten, lokale Sicherheitsrichtlinien und zuvor angewendete GPO-Einstellungen bleiben wirksam, und viele administrative Vorgaben greifen ohne erneuten Kontakt zum Domänencontroller (Änderungen werden dann allerdings erst beim nächsten erfolgreichen Richtlinien-Refresh wirksam). Für Außenstellen, Produktionsnetze oder isolierte Umgebungen ist dieser Aspekt oft keine Komfortfrage, sondern Voraussetzung.

Der tiefe Systemzugriff ergibt sich außerdem daraus, dass GPOs und Skripte auf dem Endpunkt im Kontext des Betriebssystems wirken. Dadurch lassen sich auch Konfigurationen durchsetzen, die in MDM-Welten nur eingeschränkt oder gar nicht modelliert sind, etwa sehr spezifische Registry-Änderungen, komplexe Dateisystem- und ACL-Anpassungen oder mehrstufige Installationslogiken für Legacy-Software. Gleichzeitig bleibt die Wirkung innerhalb der Domäne beobachtbar und auditierbar, weil Richtlinienquellen, Verarbeitungsstatus und Konflikte auf dem Client detailliert protokolliert werden.

Wie Intune technisch arbeitet: MDM/MAM-Architektur, Richtlinien-Check-ins, deklarative Profile und Abhängigkeiten (Identität, Internet, Plattformgrenzen)

Microsoft Intune verwaltet Geräte und Anwendungen über eine cloudbasierte MDM/MAM-Architektur. Technisch entsteht daraus ein grundsätzlich anderes Steuerungsmodell als bei on-premises Clientverwaltung: Intune greift nicht „im Systemstart“ deterministisch ein, sondern orchestriert Konfiguration über Registrierungsprozesse, tokenbasierte Identität, geräte- und benutzerbezogene Richtlinienobjekte sowie wiederkehrende Check-ins. Die erreichbare Tiefe hängt dabei stark von Plattform-APIs (Windows CSP, Apple MDM, Android Enterprise) und vom Zustand der Cloud-Anbindung ab.

MDM/MAM-Grundlagen: Steuerung über Plattform-APIs statt Domänenmitgliedschaft

Intune arbeitet primär als MDM-Dienst (Geräteverwaltung) und MAM-Dienst (Anwendungsverwaltung, insbesondere über App-Schutzrichtlinien). MDM-Konfigurationen werden nicht als „lokal auswertbare GPO-Objekte“ verarbeitet, sondern als Profile/Policies, die auf dem Endgerät über die jeweiligen Management-Schnittstellen umgesetzt werden. Unter Windows 10/11 ist das vor allem der MDM-Stack mit Configuration Service Providers (CSP), der Einstellungen in das System schreibt und den Status zurückmeldet. Auf iOS/iPadOS und macOS erfolgt die Umsetzung über Apple MDM, auf Android über Android Enterprise (Work Profile bzw. Fully Managed/Corporate-Owned).

Diese Architektur setzt eine saubere Identitätskette voraus: Geräte müssen registriert sein, Benutzer authentifizieren sich gegen Microsoft Entra ID, und die Autorisierung von Richtlinien basiert auf Gruppen- und Gerätezustand. Die enge Verzahnung mit Entra ID ist funktional gewollt: Ohne gültige Tokens und ohne funktionierenden MDM-Kanal kann Intune weder zuverlässig zustellen noch „erzwingen“, sondern muss auf den nächsten erfolgreichen Kontakt warten.

• Geräte- und Identitätsanker: Entra-Registrierungszustände wie Microsoft Entra joined, Microsoft Entra registered und Koexistenz über Hybrid Microsoft Entra joined bestimmen, welche Richtlinienpfade (Gerät vs. Benutzer) stabil greifen.
• MDM-Umsetzung auf Windows: Viele Einstellungen laufen über CSP-Pfade, sichtbar etwa in Diagnose/MDM-Reporting, nicht über klassische GPO-Verarbeitung; typische Mechanismen sind Policy CSP und der MDM-Stack (z. B. MDM-Diagnoseberichte/Ereignisprotokolle).
• MAM ohne Geräteeinschreibung: App-Schutzrichtlinien für Microsoft 365-Apps können in Szenarien ohne MDM wirken, binden aber konsequent an Identität und App-SDK/Container (z. B. in Outlook/Teams) statt an Systemzustand.

Richtlinienzustellung: Check-in-Zyklen, Push-Benachrichtigungen und Statusrückmeldungen

Intune ist zustands- und ereignisgetrieben, jedoch nicht deterministisch im Sinne „sofort beim Boot/Logon“. Geräte melden sich in Intervallen beim Dienst (Check-in), holen neue Zuweisungen ab und melden Umsetzungs- und Fehlerstatus zurück. Zusätzliche Impulse entstehen durch Push-Benachrichtigungen (plattformabhängig), die ein zeitnahes Synchronisieren anstoßen können, aber weiterhin eine funktionsfähige Netzwerkverbindung und einen intakten Management-Kanal voraussetzen.

Das Zusammenspiel aus Zuweisung, Gerätezustand und Reporting folgt dabei einem verteilten Modell: Eine Policy gilt als „zugewiesen“, wird lokal „angewendet“ und im Portal „als erfolgreich/fehlgeschlagen/ausstehend“ gemeldet. Zwischen diesen Zuständen liegen typische Fehlerquellen wie ausstehende Neustarts, fehlende Berechtigungen der Plattform-API, Konflikte zwischen Profilen oder schlicht fehlende Erreichbarkeit. Dadurch unterscheidet sich Intune klar von GPOs, die innerhalb der Domäne über Replikation und lokale Verarbeitung in klaren Verarbeitungsphasen (Computer/Benutzer) arbeiten.

Deklarative Profile und Konfliktlogik: „Desired State“ statt Skriptphase

Intune ist in vielen Bereichen deklarativ: Zielzustände werden beschrieben, und das Gerät setzt sie über Management-APIs um. Daraus folgt eine andere Fehler- und Konfliktlogik als bei skriptbasierter Steuerung. Wenn zwei Profile dieselbe Einstellung unterschiedlich definieren, entscheidet nicht „Reihenfolge im Skript“, sondern die Konfliktauswertung des MDM-Stacks, die pro Einstellungstyp und Plattform variieren kann. Gleichzeitig lassen sich viele klassische „wenn-dann-sonst“-Abläufe nur eingeschränkt abbilden, weil Intune keine allgemeine Ablaufsteuerung mit garantierter Reihenfolge über Gerätestart und Benutzeranmeldung hinweg bereitstellt.

Wo eine deklarative Beschreibung nicht reicht, kommen Ergänzungen wie PowerShell-Skripte oder Proactive Remediations (Intune Suite) ins Spiel. Diese helfen bei Korrekturen und Drift-Management, ändern aber die Grundlogik nicht: Ausführung erfolgt über den Intune Management Extension-Kanal, ist an den Check-in gekoppelt und kann nicht mit derselben Verlässlichkeit an präzise Zeitpunkte wie „vor der Shell“ oder „bei jedem Logon“ gebunden werden. Zudem ist die Ausführung auf Windows zentriert; auf iOS/iPadOS und Android gelten deutlich engere Grenzen für Skripting und Systemeingriffe.

• Deklarative Konfiguration: Profile definieren Zielzustände (z. B. Passwortrichtlinien, Geräteeinschränkungen) und werden über MDM umgesetzt; eine feste „Reihenfolge“ wie bei Logon-Skripten existiert nicht.
• Skripte auf Windows: Ergänzende Maßnahmen laufen typischerweise über die Intune Management Extension; typische Pfade/Artefakte sind C:\Program Files (x86)\Microsoft Intune Management Extension\ und zugehörige Logs.
• Remediation-Logik: Proactive Remediations arbeiten als Erkennung/Behebung, sind aber an Ausführungsintervalle gebunden; sie ersetzen keine deterministische GPO-Phase wie „Computer Startup“.

Abhängigkeiten und Plattformgrenzen: Identität, Internet und OS-spezifische Managementräume

Die technische Leistungsfähigkeit von Intune steht und fällt mit Abhängigkeiten, die in klassischen on-prem-Umgebungen weniger dominant sind. Ohne Internetzugang oder ohne funktionierende Namensauflösung zu Microsoft-Endpunkten bleiben Zuweisungen und Statusrückmeldungen aus. Auch wenn Geräte zeitweise offline weiterarbeiten, stoppt der Managementfluss: keine neuen Profile, keine Aktualisierung von Compliance, keine neu zugewiesenen Apps. Das betrifft besonders „Day-0/Day-1“-Abläufe wie Ersteinrichtung, Geräteaustausch oder Sicherheitsreaktionen, bei denen die Zeitkomponente kritisch wird.

Zusätzlich begrenzen Plattformen die Eingriffstiefe. Windows MDM deckt viele Sicherheits- und Basiskonfigurationsbereiche solide ab, erreicht jedoch nicht die vollständige Bandbreite klassischer GPOs und lokaler Richtlinienobjekte. Auf Apple- und Android-Plattformen ist der MDM-Rahmen enger: Viele Einstellungen sind bewusst nicht adressierbar oder nur in bestimmten Enrollment-Modi verfügbar. Damit entsteht ein faktischer „Managementraum“ pro OS, der sich nicht beliebig erweitern lässt, selbst wenn administrative Rechte und Skriptkompetenz vorhanden wären.

Schließlich wirkt Intune selten allein: Conditional Access, Gerätekonformität, Defender-Signale und Zertifikats-/PKI-Themen greifen ineinander. Technisch bedeutet das, dass „Richtlinie“ oft nicht nur eine Einstellung ist, sondern eine Kette aus Identitätsentscheidung (Entra), Gerätezustand (Compliance), App-Zugriff (CA) und Geräteumsetzung (MDM). Jede schwache Stelle in dieser Kette verlagert Fehlerbilder von „die GPO zieht nicht“ hin zu komplexeren Ursachen wie Token-Problemen, veralteten Compliance-States, fehlender Broker-/Authenticator-Komponente oder blockierten Cloud-Endpunkten.

Praxisvergleich und Entscheidung: typische GPO-Use-Cases in Intune nachbauen (oder bewusst nicht), Grenzen bei Legacy-Apps und Skriptlogik, sinnvolle Hybridmodelle

Der Praxisvergleich zwischen GPO-basierter Clientverwaltung und Intune entscheidet sich selten an „kann grundsätzlich“, sondern an Umsetzbarkeit unter realen Betriebsbedingungen: Timing, Fehlertoleranz, Wiederholbarkeit und Abhängigkeiten zu Legacy-Komponenten. Viele klassische GPO-Use-Cases lassen sich in Intune funktional abbilden, aber oft mit anderen Semantiken: Richtlinien greifen nach Check-in statt synchron beim Start, Abhängigkeiten zwischen Einstellungen sind nur begrenzt modellierbar, und die Fehleranalyse verläuft über andere Telemetriepfade. Daraus entsteht die zentrale Architekturfrage, ob eine 1:1-Portierung sinnvoll ist oder ob Intune bewusst nur einen Teil des Regelwerks übernimmt.

Typische GPO-Use-Cases: praktikable Intune-Entsprechungen mit klaren Grenzen

Ein großer Teil klassischer „Hygiene-GPOs“ eignet sich gut für Intune: Sicherheitsbaselines, BitLocker-Konfiguration, Defender-Einstellungen, Firewall, Geräte-Restriktionen, Update- und Neustartregeln sowie viele administrative Vorlagen (ADMX) lassen sich über Settings Catalog, Security Baselines und Endpoint Security Policies abbilden. Der Unterschied liegt im Verhalten: GPOs wirken in der Regel synchron beim Boot/Logon und anschließend über Hintergrund-Refresh; Intune wirkt über MDM-Policy-Verarbeitung, die auf Check-in und deklarativer Zielzustandslogik basiert. Das ist in stabil vernetzten Szenarien unkritisch, kann aber bei zeitkritischen Abhängigkeiten (z. B. „Setting muss vor erstem Benutzerlogin aktiv sein“) zu echten Abweichungen führen.

Für mehrere Standardfälle existieren robuste Muster, die sich in Intune wiederverwenden lassen. Entscheidend ist, nicht die GPO-Struktur zu kopieren, sondern das gewünschte Ergebnis in wenige, konfliktarme Profile zu bündeln, mit klarer Scope-Logik (Geräte- statt Benutzerzuweisung, Filter nach OS-Version/Ownership) und nachvollziehbarer Rollback-Strategie.

• BitLocker wie per GPO: Umsetzung über Endpoint Security Disk Encryption; Recovery Key-Backup in Entra ID (geräteabhängig, z. B. Entra-Join/Hybrid-Join) und Compliance-Checks als Gate für Zugriff via Conditional Access, statt reinem „Enable und hoffen“.
• Windows Update for Business statt WSUS-GPO: Konfiguration über Update Rings und Feature/Quality Update Policies; zeitliche Steuerung und Deadline-Verhalten werden über Ring-Parameter und ggf. separate Treiber-/Firmware-Strategien abgebildet (je nach Windows-Version und Update-Architektur).
• Firewall/Defender-Hardening: Nutzung von Endpoint Security Firewall und Antivirus Policies; der Settings Catalog eignet sich für ergänzende Detailwerte, während Baselines eine konsistente Mindesthärtung liefern.
• Lokale Administratoren (Restricted Groups/LAPS): Verwaltung über Windows LAPS (Policy in Intune) und ggf. Endpoint Security Account Protection; harte GPO-Mechanismen wie „Restricted Groups“ sollten nicht blind ersetzt werden, wenn lokale Sonderrechte pro Standort/Schichtbetrieb erforderlich sind.

Wenn GPO-Logik in Intune „funktioniert“, aber betrieblich kippt: Timing, Reihenfolge, Abhängigkeiten

Klassische GPO-Designs nutzen häufig Reihenfolgen: erst Datei/Registry setzen, dann Dienstkonfiguration, danach Applikationsinstallation, anschließend Logonskript, das auf installierte Komponenten prüft. Intune bietet dafür keine gleichwertige, deterministische Orchestrierung über Boot/Logon-Grenzen hinweg. Zwar lassen sich Win32-Apps mit Abhängigkeiten, Detection Rules und Requirements steuern; für Konfigurationsprofile gilt diese Abhängigkeitslogik jedoch nicht in gleicher Weise. In der Praxis entstehen Fehlerbilder, die es unter GPO selten gibt: Policies „pending“, weil ein Gerät zu selten eincheckt; Einstellungen werden später angewendet als die dazugehörige App; oder Konflikte zwischen Settings Catalog, Baselines und ADMX-Importen erzeugen inkonsistente Ergebnisse.

Für zeitkritische Abläufe ist daher zu entscheiden, ob der Prozess umgebaut wird (z. B. Vorkonfiguration über Autopilot und device-assigned Policies) oder ob weiterhin ein on-prem Mechanismus den deterministischen Teil übernimmt. Besonders relevant ist das beim Erstaufbau: GPOs können vor der ersten interaktiven Sitzung greifen; Intune hängt von Enrollment-Status, ESP-Konfiguration und erreichbaren Cloud-Endpunkten ab. Das ist beherrschbar, aber nicht identisch.

Legacy-Apps: Warum „Softwareverteilung ist Softwareverteilung“ ein Trugschluss ist

Bei Legacy-Anwendungen entscheidet weniger die Paketierungsform als das Integrationsverhalten. Intune kann Win32-Apps zuverlässig verteilen, auch komplexere Installer, sofern sie silent-fähig sind und stabile Detection Rules besitzen. Problematisch werden Anwendungen, die auf Geräte-Startskripte, Domänenpfade, COM-Registrierungen im Kontext von SYSTEM vs. User, oder auf unmittelbare Verfügbarkeit von Fileshares/On-Prem-Services angewiesen sind. Klassische Softwareverteilungssysteme im LAN (inklusive BranchCache/Peer-Mechanismen, je nach Produkt) können in solchen Umgebungen operativ überlegen bleiben, weil sie Downloadpfade, Vorbedingungen und Rollback-Prozesse seit Jahren für diese Art von Workloads optimiert haben.

Ein technischer Mindeststandard für Win32-Verteilung über Intune umfasst saubere Erkennung, klare Install/Uninstall-Kommandos und getrennte Konfiguration von Installation und Konfigurations-Tweaks. Sobald „Installer und Konfiguration“ in ein einziges, vielzweckiges Skript wandern, steigen Fehlerquoten und Diagnoseaufwand typischerweise stark an.

• Robuste Detection statt „Install war erfolgreich“: bevorzugt über MSI ProductCode oder eindeutige Artefakte, z. B. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID} oder eine verlässliche Dateiversion unter C:\Program Files\....
• Trennung von Install und Konfiguration: Installation als Win32-App; Nachkonfiguration als Remediation (Proactive Remediations in Intune Suite) oder separates Skript, statt alles in install.cmd zu bündeln.
• Abhängigkeiten kontrolliert modellieren: Win32-App-Dependencies nutzen, wo möglich; Konfigurationsprofile nicht als „Installationsschritt“ missbrauchen, weil sie keine garantierte Reihenfolge zu App-Deployments bieten.
• Netzabhängigkeiten explizit machen: Wenn Installationen auf UNC-Pfade angewiesen sind, diese Abhängigkeit eliminieren oder durch Cloud-Distribution ersetzen; Pfade wie \\server\share\package sind in reinen Internet-Szenarien operativ fragil.

Skriptlogik und „kleine Automationen“: wann Intune-Skripte passen und wann sie technische Schulden erzeugen

GPO-Skripte (Startup/Shutdown/Logon/Logoff) werden oft als Allzweckwerkzeug genutzt: Dateien kopieren, Zertifikate importieren, Registry setzen, Dienste neu starten, Drucker zuweisen. Intune bietet zwar PowerShell-Skripte und Remediations, aber ohne die gleiche Kopplung an den Logon-Prozess und ohne die gleiche Vorhersagbarkeit im Zeitpunkt der Ausführung. Zudem fehlen bewährte Mechanismen wie „synchron ausführen und bei Fehlern blockieren“ als generelles Konzept. Remediations sind für Zustandserhaltung gut, für sequentielle Prozessketten aber nur bedingt.

Für Skripte gilt daher eine klare Faustregel: Alles, was einen deklarativen Zielzustand beschreibt (z. B. „Registrywert muss X sein“), gehört bevorzugt in Settings Catalog/ADMX oder in eine Remediation mit klarer Detection. Alles, was transaktional ist (z. B. „wenn A, dann B, dann C, abhängig von Benutzergruppen und Uhrzeit“), bleibt in klassischen Mechanismen oder wird als echte Applikation/Service mit Logging, Telemetrie und Fehlerbehandlung umgesetzt.

Sinnvolle Hybridmodelle: klare Aufgabentrennung statt Doppelverwaltung

Ein Hybridansatz ist technisch sauber, wenn Verantwortlichkeiten eindeutig getrennt sind und Konflikte aktiv verhindert werden. Typisch ist die Aufteilung nach „Modern Management“ für Basis-Sicherheit, Compliance, Conditional Access und Standard-Applikationen, während on-prem weiter die wenigen, aber kritischen Sonderfälle abdeckt: sehr spezifische OS-Tweaks, deterministische Start-/Logon-Abläufe, komplexe Legacy-Installationen oder Standortlogik. Konfliktträchtig wird Hybrid, wenn dieselben Einstellungen parallel über GPO und Intune gesetzt werden. Dann entscheidet nicht „besser“, sondern die konkrete CSP/GPO-Interaktion, und das Ergebnis ist oft schwer reproduzierbar.

Praktikable Hybridmodelle nutzen Co-Management (Configuration Manager + Intune) oder eine bewusst reduzierte GPO-Fläche. Co-Management erlaubt Workload-Splitting (z. B. Compliance/Conditional Access über Intune, Win32-Software weiterhin über ConfigMgr) und reduziert den Druck, jede historische GPO sofort zu portieren. Alternativ kann eine „GPO-Quarantäne“ etabliert werden: Nur noch wenige, dokumentierte Richtlinien bleiben aktiv, alle neuen Anforderungen wandern zuerst in Intune, sofern keine klaren Gegenargumente bestehen.

• Intune-first für Zugriffskontrolle: Gerätezustand über Compliance Policies und Zugriff über Conditional Access; technische Kopplung an Identität/Token statt an Netzwerkstandort.
• On-Prem für deterministische Abläufe: Start-/Logonskripte, die vor dem Arbeiten zwingend fertig sein müssen, bleiben bei GPO oder werden als Managed-Installer-Prozess mit klarer Orchestrierung betrieben.
• Co-Management für Win32-Schweregrade: komplexe Pakete und Task-Sequenzen bleiben bei Configuration Manager; Intune übernimmt Enrollment, Compliance und mobile Szenarien, ohne Paketierungsstandards zu verwässern.
• Konfliktvermeidung durch Scope-Design: klare Trennung per OU/Gruppe/Filter und dokumentierte „Owner“ je Einstellungsdomäne; doppelte Richtlinien für denselben CSP/GPO-Bereich werden vermieden.