Von Gruppenrichtlinien zu Intune – Wie Microsoft die Windows-Verwaltung über 25 Jahre neu gedacht hat

Warum zentrale Verwaltung mehr ist als nur Komfort

Die Verwaltung von IT-Systemen war schon immer weit mehr als die Installation eines Betriebssystems oder die Bereitstellung neuer Hardware. Mit jeder zusätzlichen Arbeitsstation stieg der Aufwand für Administrator:innen, Konfigurationen konsistent zu halten, Sicherheitsrichtlinien durchzusetzen und Änderungen nachvollziehbar umzusetzen. Solange Unternehmen nur wenige Computer betrieben, ließen sich viele Aufgaben noch manuell erledigen. Mit dem rasanten Wachstum von Windows-Netzwerken in den 1990er Jahren wurde dieser Ansatz jedoch zunehmend unpraktikabel.

Gleichzeitig entwickelten sich Unternehmensnetzwerke von isolierten Arbeitsplatzrechnern zu komplexen Infrastrukturen mit Servern, Benutzerkonten, Dateifreigaben und gemeinsam genutzten Anwendungen. Jede Abweichung in der Konfiguration konnte zu Sicherheitsproblemen, erhöhtem Supportaufwand oder Einschränkungen im täglichen Betrieb führen. Die zentrale Verwaltung von Computern entwickelte sich deshalb von einer hilfreichen Funktion zu einer grundlegenden Voraussetzung für einen wirtschaftlichen und sicheren IT-Betrieb.

Mehr als ein Verwaltungswerkzeug

Vor diesem Hintergrund entstand eine zentrale Fragestellung, die Microsoft bis heute begleitet: Wie lassen sich tausende Windows-Geräte zentral, sicher und konsistent verwalten – unabhängig davon, wie groß eine Organisation ist?

Die Antwort auf diese Frage hat sich in den vergangenen drei Jahrzehnten mehrfach verändert. Während zunächst einfache Systemrichtlinien ausreichten, entstand mit Windows 2000 und Active Directory eine vollständig neue Architektur für Identitäten, Ressourcen und Richtlinien. Gruppenrichtlinien wurden dabei zu einem der wichtigsten Werkzeuge der Windows-Administration und prägten den Betrieb von Unternehmensnetzwerken über mehr als zwei Jahrzehnte.

Doch auch diese Erfolgsgeschichte blieb nicht unverändert. Mobile Endgeräte, Homeoffice, Cloud-Dienste und hybride Arbeitsmodelle stellten die ursprünglichen Annahmen über Unternehmensnetzwerke zunehmend infrage. Microsoft reagierte darauf nicht mit einer Weiterentwicklung der Gruppenrichtlinien allein, sondern mit neuen Verwaltungsmodellen rund um Microsoft Intune und Entra ID.

Eine Reise durch drei Jahrzehnte Windows-Verwaltung

Dieser Beitrag zeichnet die Entwicklung der zentralen Windows-Verwaltung von den ersten Systemrichtlinien (System Policies) unter Windows NT über die Einführung von Active Directory und Gruppenrichtlinien bis hin zu modernen Cloud-Management-Plattformen nach. Dabei steht nicht die Beschreibung einzelner Funktionen im Mittelpunkt. Stattdessen wird erläutert, welche Herausforderungen die jeweilige Technologie lösen sollte, warum bestimmte Architekturentscheidungen getroffen wurden und weshalb viele der damaligen Grundprinzipien bis heute Bestand haben.

Gerade diese historische Einordnung hilft dabei, aktuelle Technologien wie Microsoft Intune oder Entra ID besser zu verstehen. Viele ihrer Konzepte wirken auf den ersten Blick neu, bauen jedoch auf Ideen auf, die Microsoft bereits zur Einführung von Active Directory entwickelt hat. Die Werkzeuge haben sich verändert – das grundlegende Ziel einer zentralen, sicheren und konsistenten Verwaltung von Endgeräten ist dagegen bis heute unverändert geblieben.

Die ersten Schritte – Systemrichtlinien und die Grenzen von Windows NT

Eine Frage stelle ich in Seminaren zu Gruppenrichtlinien gerne ganz an den Anfang: Wer legt eigentlich die erste Sicherheitsebene eines frisch installierten Windows-Systems fest? Die naheliegende Antwort lautet häufig: die Administrator:innen!

Tatsächlich beginnt die Sicherheitskonfiguration jedoch schon früher. Microsoft liefert Windows mit einer Reihe vordefinierter Berechtigungen, Benutzerrechte und Sicherheitseinstellungen aus. Diese Ausgangskonfiguration bildet zunächst die Basis, auf der Unternehmen ihre eigenen Anforderungen umsetzen.

In älteren Windows-Versionen wurde dieses Prinzip auch technisch sehr sichtbar. Microsoft dokumentiert beispielsweise für frühere Windows-Generationen die Datei Setup security.inf. Sie wurde während der Installation erstellt und repräsentierte die dabei angewendeten Standardsicherheitseinstellungen des jeweiligen Systems. Dazu gehörten unter anderem Berechtigungen auf Dateien und Verzeichnisse.

Der entscheidende Punkt reicht jedoch über eine einzelne INF-Datei hinaus: Ein Betriebssystem startet nicht sicherheitspolitisch bei null. Der Hersteller trifft bereits mit der Entwicklung Entscheidungen darüber, welche Benutzer:innen welche Aktionen durchführen dürfen und welche Systembereiche geschützt werden müssen.

Diese Grundeinstellungen sind auch nicht statisch. Sie verändern sich mit technischen Entwicklungen, neuen Bedrohungen und veränderten Nutzungsszenarien. Genau das lässt sich an einem unscheinbaren Beispiel besonders gut nachvollziehen.

Wenn Mobilität Sicherheitsannahmen verändert

Systemzeit und Zeitzone erscheinen zunächst wie banale Einstellungen. Sicherheitstechnisch besteht zwischen beiden jedoch ein wichtiger Unterschied. Änderungen der Systemzeit können Protokolle, Dateizeitstempel oder andere zeitabhängige Vorgänge beeinflussen. Microsoft empfiehlt deshalb bis heute, das Recht zur Änderung der Systemzeit auf Benutzer:innen mit einem tatsächlichen administrativen Bedarf zu beschränken.

Historisch waren Systemzeit und Zeitzone enger miteinander verbunden. Erst mit Windows Vista führte Microsoft mit SeTimeZonePrivilege ein eigenes Benutzerrecht zum Ändern der Zeitzone ein. Dadurch ließ sich die Zeitzone anpassen, ohne gleichzeitig das wesentlich sicherheitskritischere Recht zur Veränderung der eigentlichen Systemzeit zu vergeben. Microsoft dokumentiert dieses separate Privileg ausdrücklich als seit Windows Vista verfügbar.

Das klingt zunächst nach einer kleinen technischen Veränderung. Tatsächlich spiegelt sie jedoch einen Wandel der Arbeitswelt wider. Stationäre PCs zu NT-Zeiten wechselten nur selten ihre geografische Position. Bei mobilen Computern ist eine Änderung der Zeitzone dagegen ein vollkommen normales Nutzungsszenario. Damit wird ein grundlegendes Prinzip sichtbar: Sicherheitseinstellungen entstehen immer im Kontext ihrer Zeit. Was in einer weitgehend stationären IT-Umgebung sinnvoll war, kann mit zunehmender Mobilität neu bewertet werden.

Von der Basissicherheit zur Unternehmensrichtlinie

Die von Microsoft vorgegebene Ausgangskonfiguration kann allerdings nur einen allgemeinen Rahmen bilden. Zwei Unternehmen können dasselbe Betriebssystem einsetzen und dennoch vollkommen unterschiedliche Anforderungen an dessen Absicherung haben. Ein Arbeitsplatz in einer Verwaltung benötigt möglicherweise andere Einschränkungen als ein Entwicklungsrechner. Ein öffentlich zugängliches Terminal muss wesentlich stärker begrenzt werden als ein administrativer Arbeitsplatz. Gleichzeitig können interne Sicherheitsvorgaben festlegen, welche Benutzerrechte erlaubt sind, welche Funktionen deaktiviert werden müssen oder welche Konfigurationen verbindlich gelten.

Bei einigen wenigen Computern ließe sich eine solche Konfiguration noch manuell umsetzen. Bereits bei einigen Dutzend Geräten wird dieser Ansatz jedoch problematisch. Bei hunderten oder tausenden Systemen ist er praktisch nicht mehr beherrschbar. Zwar ließen sich Sicherheitseinstellungen auch exportieren und auf andere Systeme übertragen. Doch eine reine Kopie lokaler Konfigurationen löst das eigentliche Verwaltungsproblem nicht. Änderungen müssten weiterhin verteilt, Versionsstände kontrolliert und Abweichungen erkannt werden.

Damit entstand bereits in der Windows-NT-Ära der 1990er Jahre eine Frage, die die Windows-Verwaltung bis heute begleitet: Wie lässt sich eine gewünschte Konfiguration nicht nur einmal verteilen, sondern zentral und reproduzierbar für eine große Anzahl von Systemen festlegen? Eine der ersten Antworten darauf waren die Systemrichtlinien (System Policies).

Unternehmensnetze der Windows-NT-Ära

Um die Bedeutung der Systemrichtlinien einordnen zu können, lohnt sich ein Blick auf die damalige Netzwerkarchitektur. Windows NT 4.0 kannte bereits Domänen und damit eine zentrale Benutzer- und Computerverwaltung. Die Architektur unterschied sich jedoch grundlegend von dem später mit Windows 2000 eingeführten Active Directory.

In einer klassischen NT-Domäne existierte ein Primary Domain Controller (PDC) als maßgebliche Instanz für die Domänendatenbank. Zusätzliche Backup Domain Controller (BDC) hielten replizierte schreibgeschützte Kopien dieser Informationen vor. Das Modell bot damit bereits eine zentrale Authentifizierung, besaß jedoch noch nicht die später mit Active Directory eingeführte hierarchische Struktur aus Gesamtstrukturen, Domänen, Standorten und Organisationseinheiten. Auf die Entwicklung dieser Architektur und ihre Bedeutung für moderne Unternehmensnetzwerke gehe ich im Blogbeitrag Von Windows NT bis Windows Server 2025: Wie Microsoft das Unternehmensnetzwerk neu erfand ausführlicher ein. Im Zusammenhang mit Systemrichtlinien ist zunächst vor allem wichtig, dass Windows NT zwar Benutzer:innen zentral authentifizieren konnte, für die zentrale und flexible Verwaltung von Arbeitsplatzkonfigurationen jedoch noch keine vergleichbare Architektur zur Verfügung stand.

Gerade für die Desktop-Verwaltung entstand dadurch eine interessante Situation: Benutzer:innen ließen sich zentral authentifizieren, die Konfiguration ihrer Arbeitsplätze blieb jedoch wesentlich schwieriger zu standardisieren. Microsoft beschäftigte sich deshalb bereits vor Windows 2000 intensiv mit den Betriebskosten verteilter Windows-Arbeitsplätze. Im Jahr 1997 stellte das Unternehmen beispielsweise das Zero Administration Kit for Windows NT Workstation 4.0 vor. Microsoft beschrieb dessen Ziel ausdrücklich als zentralisierte Konfiguration von Desktops und die Einschränkung lokaler Änderungen. Technische Grundlage waren unter anderem die damals vorhandenen Systemrichtlinien und Benutzerprofile. Der Name Zero Administration war ambitioniert. Das zugrunde liegende Problem war jedoch sehr real.

Systemrichtlinien – Richtlinien für Windows NT

Mit den Systemrichtlinien konnten Administrator:innen erstmals zahlreiche Einstellungen für Benutzer:innen und Computer zentral vorgeben. Technisch basierte das Konzept stark auf der Windows-Registrierung. Für die Erstellung kam der System Policy Editor, besser bekannt über die ausführbare Datei Poledit.exe, zum Einsatz. Administrative Vorlagendateien im .adm-Format beschrieben, welche Einstellungen der Editor zur Verfügung stellte und welche Registrierungsschlüssel beziehungsweise Werte damit verbunden waren. Microsoft dokumentierte später ausdrücklich, dass Systemrichtlinien mithilfe dieses Editors und administrativer Vorlagen erstellt wurden.

Bereits mit den Systemrichtlinien standen Administrator:innen überraschend umfangreiche Konfigurationsmöglichkeiten zur Verfügung. Je nach eingesetzten administrativen Vorlagen konnten unter Windows NT etwa 120 bis 130 Richtlinieneinstellungen definiert werden. Diese ließen sich nicht nur einzelnen Benutzer:innen oder Computern zuweisen, sondern auch Benutzergruppen sowie standardmäßigen Benutzer- und Computerkonfigurationen. Für die damalige Zeit stellte dies einen erheblichen Fortschritt dar, da sich erstmals eine größere Anzahl von Windows-Arbeitsplätzen mit einer gemeinsamen Richtliniendatei konsistent konfigurieren ließ. Verglichen mit den mehreren tausend Richtlinieneinstellungen heutiger Gruppenrichtlinien oder den umfangreichen Konfigurationsmöglichkeiten von Microsoft Intune wirkt dieser Funktionsumfang zwar überschaubar. Ende der 1990er Jahre markierten rund 120 zentrale Richtlinien jedoch einen bedeutenden Schritt auf dem Weg von der manuellen Einzelkonfiguration hin zu einer standardisierten und zentral verwalteten Windows-Umgebung.

Nach der Konfiguration entstand eine Richtliniendatei mit dem Namen NTConfig.pol.

Damit war ein wichtiger Schritt erreicht: Administrator:innen mussten Einstellungen nicht mehr auf jedem Arbeitsplatz einzeln vornehmen. Stattdessen konnten sie eine gemeinsame Richtliniendatei bereitstellen, aus der Windows während der Anmeldung die für das jeweilige System und Benutzerkonto relevanten Einstellungen ermittelte. Aus heutiger Sicht wirkt das Prinzip bereits erstaunlich vertraut. Die zentrale Idee von Policy-based Management war damit vorhanden. Die spätere Umsetzung über Active Directory und Gruppenrichtlinien sollte allerdings wesentlich leistungsfähiger werden.

NTConfig.pol und NETLOGON

Damit die Richtlinie die Arbeitsstationen erreichte, nutzte Windows NT eine bereits vorhandene Infrastruktur: die NETLOGON-Freigabe der Domänencontroller. Die Datei NTConfig.pol wurde typischerweise auf der NETLOGON-Freigabe des Primary Domain Controllers abgelegt. Der Directory Replicator Service replizierte die Inhalte anschließend auf die Backup Domain Controller. Meldete sich ein Windows-NT-System an der Domäne an, konnte es die dort bereitgestellte Richtliniendatei abrufen und die jeweils relevanten Einstellungen anwenden. Damit verband Microsoft mehrere bereits vorhandene Komponenten: Domänenanmeldung → NETLOGON → NTConfig.pol → Registry-Konfiguration.

Für die damalige Zeit war das ein erheblicher Fortschritt. Änderungen konnten zentral vorbereitet und anschließend bei der Anmeldung auf viele Systeme übertragen werden. Gleichzeitig zeigt diese Architektur bereits einen Unterschied zu modernen Gruppenrichtlinien: Die Richtlinie war im Wesentlichen eine zentral bereitgestellte Datei. Es existierte noch keine Active-Directory-Struktur, an deren verschiedene Ebenen eigenständige Richtlinienobjekte verknüpft werden konnten. Genau darin lag später eine der entscheidenden Grenzen.

Einmal und nie wieder

Die zentrale Bereitstellung einer Richtliniendatei über NETLOGON war für die damalige Zeit zweifellos ein großer Fortschritt. Gleichzeitig offenbarte dieses Verfahren jedoch eine grundlegende Schwäche der Systemrichtlinien: Die Richtlinien wurden nur einmal eingelesen und angewendet. Während der Benutzeranmeldung beziehungsweise des Systemstarts übernahm Windows die in der Datei NTConfig.pol definierten Einstellungen und schrieb sie in die Registrierung des lokalen Systems. Anschließend spielte die Richtliniendatei bis zum nächsten Neustart oder einer erneuten Anmeldung keine Rolle mehr.

Diese Vorgehensweise hatte weitreichende Konsequenzen. Änderten Benutzer:innen oder eine Anwendung später dieselben Registrierungseinträge durch den Import einer REG-Datei oder eine lokale Konfigurationsänderung, erkannte Windows diese Abweichung nicht. Es erfolgte weder eine regelmäßige Konsistenzprüfung noch wurden die ursprünglich vorgegebenen Einstellungen automatisch wiederhergestellt. Die Systemrichtlinien definierten somit keinen dauerhaft überwachten Soll-Zustand, sondern setzten die gewünschte Konfiguration lediglich zu einem bestimmten Zeitpunkt.

Auch administrative Änderungen erwiesen sich dadurch als vergleichsweise aufwendig. Wurde die Datei NTConfig.pol angepasst, mussten die betroffenen Systeme zunächst neu gestartet oder Benutzer:innen erneut angemeldet werden, bevor die geänderten Richtlinien wirksam wurden. Eine Aktualisierung während des laufenden Betriebs war mit den Systemrichtlinien nicht vorgesehen.

In meinen Seminaren beschreibe ich diesen Unterschied häufig anhand zweier Begriffe: Dauerhaftigkeit und Dynamik. Systemrichtlinien waren nur eingeschränkt dauerhaft, da ihre Einstellungen nach der einmaligen Anwendung vergleichsweise leicht überschrieben werden konnten. Gleichzeitig fehlte ihnen die Dynamik moderner Verwaltungslösungen. Änderungen an den Richtlinien wurden weder kontinuierlich ausgewertet noch automatisch auf bereits laufende Systeme übertragen.

Gerade diese beiden Eigenschaften sollten später zu den zentralen Entwicklungszielen der Gruppenrichtlinien werden. Mit Active Directory führte Microsoft nicht nur eine neue Verwaltungsarchitektur ein, sondern etablierte erstmals einen Mechanismus, der Richtlinien regelmäßig überprüfte, Änderungen automatisch übernahm und den gewünschten Konfigurationszustand dauerhaft durchsetzen konnte. Aus einer einmaligen Konfiguration wurde damit ein kontinuierlich überwachtes und verwaltetes Richtlinienmodell.

Richtlinien mit Langzeitwirkung: das ‚Tattooing‘

Ein weiteres Problem lag in der Art, wie Systemrichtlinien Einstellungen auf den Zielsystemen umsetzten. Viele System-Policy-Einstellungen schrieben ihre Werte unmittelbar in die Windows-Registrierung. Wurde eine Richtlinie später nicht mehr angewendet, bedeutete dies jedoch nicht automatisch, dass der zuvor gesetzte Registrierungswert wieder entfernt wurde. Die Konfiguration blieb auf dem Computer bestehen, bis sie ausdrücklich durch eine andere Einstellung überschrieben oder manuell geändert wurde. Für dieses Verhalten etablierte sich der Begriff Tattooing.

Microsoft beschreibt diesen Unterschied später ausdrücklich: Systemrichtlinien schrieben ihre Einstellungen direkt in die entsprechenden Registry-Bereiche. Diese blieben so lange erhalten, bis sie durch eine andere Konfiguration ersetzt wurden. Erst die mit Active Directory eingeführten Gruppenrichtlinien verfolgten einen deutlich stärker kontrollierten Ansatz, bei dem Richtlinien regelmäßig überprüft und erneut angewendet werden konnten.

Für Administrator:innen hatte dieses Verhalten spürbare Auswirkungen im täglichen Betrieb. Wurde eine Richtlinie nicht mehr benötigt, genügte es häufig nicht, sie einfach aus der Datei NTConfig.pol zu entfernen. Da die ursprünglichen Registrierungswerte bereits dauerhaft auf den Clients gespeichert waren, mussten diese zunächst gezielt durch eine Konter-Richtlinie oder eine gegenteilige Konfiguration überschrieben werden. Erst nachdem alle betroffenen Systeme den neuen Wert übernommen hatten, konnte die ursprüngliche Richtlinie entfernt werden. Andernfalls blieben die zuvor gesetzten Einstellungen dauerhaft auf den Clients erhalten.

Dieses Vorgehen erhöhte nicht nur den Verwaltungsaufwand, sondern machte Änderungen auch fehleranfällig. Administrator:innen mussten stets bedenken, welche Auswirkungen das Entfernen einer Richtlinie auf bereits konfigurierte Systeme hatte und ob zuvor eine Rücksetzung der betroffenen Registrierungswerte erforderlich war.

Damit zeigte sich bereits Ende der 1990er Jahre ein grundlegendes Problem zentraler Verwaltung: Es genügt nicht, einen gewünschten Zustand einmalig zu setzen. Ein Verwaltungssystem muss ebenso zuverlässig steuern können, was geschieht, wenn eine Richtlinie geändert oder wieder aufgehoben wird. Genau diese Anforderung wurde später zu einem wesentlichen Entwurfsziel der Gruppenrichtlinien unter Active Directory.

Die flache Domäne begrenzt die Richtlinienstruktur

Noch schwerer wog die Struktur der NT-Domäne selbst. Systemrichtlinien verfügten über keine hierarchische Richtlinienarchitektur. Microsoft nennt genau diesen Punkt in der späteren Sicherheitsdokumentation als wesentlichen Unterschied zu Active-Directory-Gruppenrichtlinien. Aufgrund des flachen NT-Domänenmodells ließen sich keine überlagernden Richtlinien entlang einer Organisationsstruktur definieren.

Das bedeutete beispielsweise, dass ein Unternehmen nicht einfach eine Struktur wie Unternehmen → Deutschland → Vertrieb → Außendienst abbilden und auf jeder Ebene ergänzende Richtlinien anwenden konnte. Stattdessen mussten Einstellungen über Benutzer, Gruppen, Computer sowie Standarddefinitionen organisiert werden. Je größer und differenzierter ein Unternehmen wurde, desto schwieriger wurde die Verwaltung dieses Modells

Auch die Delegation stieß an Grenzen. Moderne Szenarien, in denen eine zentrale IT grundlegende Sicherheitsrichtlinien vorgibt und einzelne Fachbereiche zusätzliche Einstellungen innerhalb ihrer Organisationseinheiten verwalten, ließen sich mit dem NT-Modell nicht vergleichbar abbilden. Hier wird deutlich: Das Problem lag weniger im Policy Editor selbst als in der Architektur, in die er eingebettet war.

Zentralisiert – aber noch nicht wirklich hierarchisch

Systemrichtlinien waren deshalb keineswegs eine primitive oder bedeutungslose Vorstufe der Gruppenrichtlinien. Im Gegenteil: Sie etablierten bereits mehrere grundlegende Ideen, die bis heute wichtig geblieben sind. Konfigurationen sollten zentral definiert werden. Benutzer:innen und Computer konnten unterschiedlich behandelt werden. Administrative Vorlagen abstrahierten Registry-Einstellungen. Und Richtlinien wurden automatisiert im Rahmen einer zentralen Infrastruktur verteilt.

Doch das Modell zeigte gleichzeitig deutlich seine Grenzen:

• Es fehlte eine echte hierarchische Organisationsstruktur
• Richtlinien ließen sich nicht flexibel an unterschiedliche Ebenen einer Unternehmensstruktur binden
• Änderungen konnten durch direkt gesetzte Registry-Werte dauerhaft auf Clients zurückbleiben
• Verteilung und Replikation hingen von einer vergleichsweise einfachen dateibasierten Infrastruktur ab
• Mit steigender Anzahl von Benutzer:innen, Computern und unterschiedlichen Anforderungen nahm die Komplexität erheblich zu

Microsoft selbst arbeitete Mitte der 1990er Jahre bereits intensiv daran, die Kosten der Desktop-Verwaltung zu reduzieren. Das Zero Administration Kit von 1997 zeigt, wie stark dieses Thema strategisch bereits gewichtet wurde. Die Systemrichtlinien hatten damit gezeigt, dass zentrale, richtlinienbasierte Verwaltung funktionierte. Zugleich machten ihre Grenzen sichtbar, dass dafür langfristig mehr erforderlich war als eine gemeinsame Richtlinien-Datei.

Mit Windows 2000 sollte Microsoft deshalb nicht einfach einen neuen Policy Editor vorstellen. Stattdessen entstand mit Active Directory eine neue Verzeichnis- und Verwaltungsarchitektur – und innerhalb dieser Architektur erhielten Richtlinien eine völlig neue Bedeutung.

Active Directory und Gruppenrichtlinien – Eine neue Architektur entsteht

Die aufgezeigten Schwächen der Systemrichtlinien ließen sich nicht allein durch zusätzliche Einstellungen oder einen komfortableren Policy Editor beheben. Das eigentliche Problem lag tiefer. Windows NT konnte Benutzer:innen zentral authentifizieren und Richtlinien über eine Domäne verteilen. Es fehlte jedoch eine Verzeichnisstruktur, mit der sich Benutzerkonten, Computerkonten, organisatorische Zuständigkeiten und unterschiedliche Konfigurationsanforderungen flexibel miteinander verbinden ließen.

Mit Windows 2000 führte Microsoft deshalb Active Directory ein. Aus der vergleichsweise flachen Domänenstruktur von Windows NT entstand ein hierarchisches Verzeichnis, in dem Benutzer:innen, Computer, Gruppen und weitere Ressourcen als Objekte verwaltet werden konnten. Microsoft beschreibt Active Directory Domain Services rückblickend als eine mit Windows 2000 eingeführte Lösung, mit der Unternehmen unterschiedliche lokale Infrastrukturkomponenten und Systeme über eine gemeinsame Identität verwalten konnten.

Dieser Architekturwechsel bildete zugleich die Voraussetzung für ein vollkommen neues Richtlinienmodell. Eine Richtlinie musste nun nicht mehr als einzelne Datei für eine gesamte NT-Domäne verstanden werden. Stattdessen konnte sie als eigenständiges Objekt innerhalb einer hierarchisch strukturierten Verwaltungsumgebung existieren. Genau hier beginnt die Geschichte der Group Policy Objects, kurz GPOs.

Organisationseinheiten schaffen eine Verwaltungshierarchie

Eine der wichtigsten Neuerungen von Active Directory waren die Organizational Units, kurz OUs. Mit ihnen konnten Administrator:innen Objekte innerhalb einer Domäne hierarchisch organisieren. Eine solche Struktur musste nicht zwangsläufig die physische Netzwerkstruktur abbilden. Vielmehr konnte sie sich an administrativen Anforderungen, Standorten, Gerätetypen oder organisatorischen Zuständigkeiten orientieren.

Interessanterweise versuchte Microsoft zu Beginn der Einführung von Active Directory, den Begriff im deutschsprachigen Raum als Organisationseinheiten (OEs) zu etablieren. In älteren deutschsprachigen Büchern und Fachartikeln taucht dieses Akronym gelegentlich noch auf. Durchgesetzt hat es sich jedoch nie. Bereits Ende der 1990er und Anfang der 2000er Jahre orientierte sich die IT-Welt zunehmend an englischsprachiger Terminologie, sodass sich OU schnell als allgemein akzeptierte Bezeichnung etablierte.

Diese Entwicklung lässt sich auch an einer persönlichen Erinnerung festmachen. Anfang der 2000er Jahre hielt ich ein Firmenseminar über Microsoft Exchange und SharePoint. Nach der Veranstaltung nahm mich der IT-Leiter beiseite und bat mich, künftig möglichst auf die vielen englischen Produkt- und Fachbegriffe zu verzichten. Heute wirkt eine solche Bitte beinahe ungewöhnlich. Begriffe wie Exchange, SharePoint, Active Directory, OU oder Group Policy gehören längst selbstverständlich zum Sprachgebrauch der meisten IT-Abteilungen. Damals befand sich diese Entwicklung jedoch noch mitten im Wandel.

Damit entstand etwas, das unter Windows NT in dieser Form fehlte: ein fein gegliederter Verwaltungsraum. Beispielsweise konnten Computer einer Organisation in unterschiedlichen OUs für Arbeitsplatzsysteme, Notebooks, administrative Systeme oder Server organisiert werden. Ebenso ließen sich Benutzerkonten anhand geeigneter administrativer Kriterien strukturieren. Gleichzeitig konnte die Administration einzelner OUs an andere Personen oder Gruppen delegiert werden. Microsoft bezeichnet die OU bis heute als die niedrigste Ebene der Active-Directory-Hierarchie, an die Gruppenrichtlinien direkt gebunden werden können, und empfiehlt, das OU-Design sowohl an Delegationsanforderungen als auch an der geplanten Anwendung von Gruppenrichtlinien auszurichten. Damit waren Organisationseinheiten weit mehr als Ordner für Benutzer- und Computerobjekte. Sie wurden zu einem zentralen Bestandteil des Verwaltungsmodells.

Aus einer Policy-Datei wird ein Group Policy Object

Mit Active Directory änderte Microsoft auch das Verständnis einer Richtlinie grundlegend. Statt einer zentralen Datei wie NTConfig.pol existierten nun eigenständige Group Policy Objects (GPOs). Ein GPO enthält eine Sammlung von Richtlinieneinstellungen, Sicherheitsinformationen und Angaben darüber, in welchem administrativen Kontext diese Einstellungen verwendet werden können. Technisch besteht ein domänenbasiertes GPO aus zwei eng miteinander verbundenen Komponenten: dem Group Policy Container (GPC) in Active Directory und dem Group Policy Template (GPT) innerhalb des Verzeichnisses SYSVOL.

Diese Architektur werden wir im nächsten Kapitel noch detaillierter betrachten. Für den grundlegenden Unterschied zu den Systemrichtlinien ist zunächst ein anderer Aspekt entscheidend: Das Richtlinienobjekt und sein Anwendungsbereich wurden voneinander getrennt. Ein GPO existiert zunächst unabhängig davon, wo es eingesetzt wird. Erst durch eine Verknüpfung wird bestimmt, auf welchen Teil der Active-Directory-Struktur es wirken soll. Microsoft sieht dafür drei wesentliche Ebenen vor: Standort → Domäne → Organisationseinheit. GPOs können an diesen Ebenen verknüpft und innerhalb verschachtelter OUs weitervererbt werden. Damit wurde Richtlinienverwaltung erstmals wirklich hierarchisch.

Eine Richtlinie kann an mehreren Stellen wirken

Die Trennung zwischen GPO und GPO-Verknüpfung ist eines der wichtigsten Architekturprinzipien der Gruppenrichtlinien und sorgt bis heute gelegentlich für Missverständnisse.

Ein Group Policy Object ist nicht selbst Bestandteil einer bestimmten Organisationseinheit. Es wird in Active Directory als eigenständiges Objekt gespeichert. An einem Standort, einer Domäne oder einer OU befindet sich lediglich eine Verknüpfung auf dieses GPO.

Dadurch kann dasselbe Richtlinienobjekt an mehreren Stellen eingesetzt werden, ohne seine Einstellungen mehrfach pflegen zu müssen. Eine unternehmensweit gültige Sicherheitskonfiguration kann beispielsweise auf mehrere geeignete Organisationseinheiten wirken, während ergänzende Richtlinien nur für bestimmte Systeme gelten.

Ebenso wichtig ist die Vererbung. GPOs, die auf einer übergeordneten Ebene verknüpft sind, wirken grundsätzlich auch auf darunterliegende Organisationseinheiten. Microsoft weist deshalb darauf hin, dass eine durchdachte OU-Struktur die Duplizierung von Gruppenrichtlinien reduziert und die zentrale Verwaltung vereinfacht. Damit wandelte sich das Richtlinienmodell von einer zentral verteilten Datei zu einem kombinierbaren und hierarchisch auswertbaren System von Richtlinienobjekten.

Von der Unternehmensrichtlinie zur zusammengesetzten Konfiguration

Durch die mögliche Existenz mehrere GPOs und deren flexibler Verknüpfung entstand ein weiterer fundamentaler Unterschied zu NTConfig.pol: Ein Windows-System musste nun nicht mehr nur eine einzelne Richtliniendatei auswerten können.

Stattdessen konnte die tatsächlich wirksame Konfiguration aus mehreren Group Policy Objects entstehen. Das System ermittelt dazu, welche Richtlinien aufgrund des Active-Directory-Standorts, der Domäne und der jeweiligen OU-Hierarchie relevant sind. Bei verschachtelten Organisationseinheiten werden auch die übergeordneten Ebenen berücksichtigt. Eine Organisation konnte dadurch beispielsweise eine allgemeine Sicherheitsrichtlinie auf Domänenebene definieren, zusätzliche Einstellungen für alle Arbeitsplatzrechner festlegen und innerhalb einer darunterliegenden OU weitere Anforderungen für besonders geschützte Systeme ergänzen.

Die entscheidende Neuerung lag somit nicht darin, dass Microsoft lediglich mehr Konfigurationsmöglichkeiten bereitstellte. Active Directory ermöglichte erstmals, mehrere administrative Ebenen zu einer resultierenden Konfiguration zusammenzuführen. Später kamen weitere Möglichkeiten zur Steuerung dieses Geltungsbereichs hinzu beziehungsweise gewannen an Bedeutung, etwa Sicherheitsfilter und WMI-Filter. Das Grundprinzip blieb jedoch unverändert: Nicht eine einzelne Datei entscheidet über die Konfiguration eines Systems, sondern dessen Position und Kontext innerhalb einer verwalteten Infrastruktur.

Computer und Benutzer werden getrennt betrachtet

Ein weiteres zentrales Architekturprinzip war die klare Trennung zwischen Computer Configuration und User Configuration. Diese Unterscheidung erscheint heute so selbstverständlich, dass ihre Bedeutung leicht unterschätzt wird. Active Directory verwaltet sowohl Benutzer:innen als auch Computer als eigenständige Objekte. Gruppenrichtlinien können deshalb unabhängig voneinander Einstellungen für das System und für die daran angemeldete Person bereitstellen.

Computerrichtlinien gelten unabhängig davon, wer sich an einem System anmeldet. Sie eignen sich beispielsweise für Sicherheits-, Firewall- oder betriebssystembezogene Einstellungen. Benutzerrichtlinien wirken dagegen im Kontext des jeweiligen Benutzerkontos und können dessen Arbeitsumgebung beeinflussen. Microsoft beschreibt diese Trennung bis heute als grundlegendes Element des Group-Policy-Modells.

Dadurch konnte ein Computer beispielsweise eine unternehmensweit definierte Sicherheitskonfiguration erhalten, während eine darauf arbeitende Person gleichzeitig Einstellungen entsprechend ihrer eigenen Position innerhalb von Active Directory bekam. Gerät und Identität wurden damit zu zwei getrennt verwaltbaren Richtlinienkontexten. Dieses Prinzip wird uns später erneut begegnen, wenn wir den Übergang zu Entra ID und Microsoft Intune betrachten.

Zwei Zeitpunkte, zwei Richtlinienkontexte

Die Trennung von Computer- und Benutzerkonfiguration beeinflusste auch die Verarbeitung der Richtlinien. Beim Start eines Computers bestimmt der Group-Policy-Mechanismus zunächst die für das Computerobjekt relevanten GPOs. Maßgeblich sind unter anderem dessen Standort, Domäne und die Organisationseinheit, in der sich das Computerobjekt befindet. Bei der anschließenden Benutzeranmeldung erfolgt eine entsprechende Auswertung für das Benutzerobjekt. Damit entstand ein wesentlich differenzierteres Modell als bei den früheren Systemrichtlinien.

Noch wichtiger war jedoch eine zweite Neuerung: Gruppenrichtlinien blieben nicht auf diese beiden Verarbeitungspunkte beschränkt. Windows führt zusätzlich eine periodische Aktualisierung im Hintergrund durch. Richtlinien können somit während des laufenden Betriebs erneut ausgewertet und Änderungen übernommen werden. Microsoft unterscheidet bis heute zwischen der initialen Verarbeitung beim Systemstart beziehungsweise bei der Anmeldung und dem anschließenden Background Refresh. Damit können wir zwei Begriffe aus dem vorherigen Kapitel wieder aufgreifen: Dauerhaftigkeit und Dynamik. Genau an diesen beiden Punkten unterschied sich Gruppenrichtlinien grundlegend von den Systemrichtlinien.

Aus ‚einmal setzen‘ wird ‚regelmäßig überprüfen‘

Unter Windows NT übernahm NTConfig.pol während des Systemstarts Einstellungen einmalig zu einem bestimmten Zeitpunkt. Anschließende Änderungen konnten den vorgegebenen Zustand verändern, ohne dass die Richtlinieninfrastruktur unmittelbar darauf reagieren musste.

Das Group-Policy-Modell verfolgte einen anderen Ansatz. Richtlinien werden nicht nur beim Systemstart und bei der Benutzeranmeldung verarbeitet, sondern anschließend auch regelmäßig im Hintergrund aktualisiert. Microsoft beschreibt diese Background Policy Refresh ausdrücklich als festen Bestandteil des Verarbeitungsmodells. Standardmäßig erfolgt die Hintergrundaktualisierung auf Clientbetriebssystemen alle 90 Minuten, ergänzt um einen zufälligen Versatz von bis zu 30 Minuten, um Lastspitzen auf Domänencontrollern zu vermeiden. Auf Domänencontrollern beträgt das Aktualisierungsintervall dagegen standardmäßig fünf Minuten. Kritische Sicherheitseinstellungen, beispielsweise Kontorichtlinien, werden unabhängig davon bei jeder Aktualisierung erneut überprüft und bei Bedarf durchgesetzt.

Damit wurde die zentrale Konfiguration wesentlich dauerhafter. Gleichzeitig gewann sie erheblich an Dynamik, weil Änderungen an Gruppenrichtlinien nicht mehr grundsätzlich einen manuellen Eingriff an jedem einzelnen System voraussetzten. Administrator:innen konnten neue oder geänderte Richtlinien zentral bereitstellen und mussten lediglich die nächste automatische Hintergrundaktualisierung abwarten. Sollte eine sofortige Übernahme erforderlich sein, ließ sich diese zusätzlich über den Befehl gpupdate beziehungsweise gpupdate /force anstoßen.

Dabei sollte man den Mechanismus nicht mit einer permanenten Echtzeitüberwachung verwechseln. Gruppenrichtlinien kontrollieren nicht sekündlich jeden konfigurierten Wert. Vielmehr wertet Windows die relevanten Richtlinien zu definierten Verarbeitungszeitpunkten und während regelmäßiger Hintergrundaktualisierungen erneut aus. Gerade diese Unterscheidung ist wichtig: Gruppenrichtlinien waren kein modernes Desired-State-Configuration-System im heutigen Sinne. Dennoch stellten sie gegenüber den einmalig angewendeten Systemrichtlinien einen entscheidenden Schritt in Richtung kontinuierlicher zentraler Konfigurationsverwaltung dar.

Die Organisation bestimmt nicht mehr die Richtliniendatei

Der Paradigmenwechsel gegenüber Windows NT lässt sich deshalb nicht auf ein einzelnes technisches Merkmal reduzieren. Unter Windows NT lautete das Grundprinzip vereinfacht: Eine Domäne stellt eine zentrale Richtliniendatei bereit. Mit Active Directory wurde daraus: Die Position eines Benutzer- oder Computerobjekts innerhalb einer hierarchischen Verzeichnisstruktur bestimmt gemeinsam mit verknüpften Richtlinien, welche Konfiguration gelten soll.

Diese Veränderung hatte enorme Auswirkungen auf die Administration. Unternehmen konnten grundlegende Richtlinien zentral definieren und gleichzeitig unterschiedliche Anforderungen einzelner Bereiche berücksichtigen. Zuständigkeiten ließen sich delegieren. Richtlinien konnten wiederverwendet und miteinander kombiniert werden. Benutzer:innen- und Computeranforderungen ließen sich getrennt verwalten.

Vor allem aber wurde die Organisationsstruktur selbst zu einem Bestandteil des Konfigurationsmodells. Das erklärt auch, warum ein gutes OU-Design später zu einem der wichtigsten Themen bei der Planung von Active Directory wurde. Microsoft betont bis heute ausdrücklich den Zusammenhang zwischen OU-Struktur, administrativer Delegation und effizienter Gruppenrichtlinienverwaltung.

Von rund 120 Richtlinien zu einer erweiterbaren Plattform

Auch der Umfang der zentral steuerbaren Konfiguration nahm mit dem neuen Modell erheblich zu. Während die früheren Systemrichtlinien mit ihren rund 120 bis 130 Einstellungen noch vergleichsweise überschaubar waren, entwickelte Microsoft Group Policy zu einer erweiterbaren Verwaltungsplattform.

Das ist ein wichtiger Unterschied. Gruppenrichtlinien bestehen nicht lediglich aus einer großen Sammlung von Registry-Einstellungen. Die zentrale Group-Policy-Infrastruktur ermittelt, welche Richtlinien gelten, und stellt deren Daten dem jeweiligen Computer zur Verfügung. Spezialisierte Client Side Extensions, kurz CSEs, übernehmen anschließend die Verarbeitung der unterschiedlichen Einstellungsarten. Microsoft beschreibt diese Erweiterungen als eigenständige Komponenten, die jeweils die für sie bestimmten Richtliniendaten interpretieren und umsetzen.

Dadurch konnten später völlig unterschiedliche Funktionen in dieselbe Verwaltungsarchitektur integriert werden. Administrative Vorlagen, Sicherheitseinstellungen, Skripte, Softwareinstallation und weitere Mechanismen ließen sich unter dem gemeinsamen Dach der Gruppenrichtlinien verwalten. Genau diese Erweiterbarkeit ist einer der Gründe, warum sich Gruppenrichtlinien über mehr als zwei Jahrzehnte weiterentwickeln konnte.

Ein Fundament, das bis heute trägt

Mit Windows 2000 führte Microsoft somit nicht einfach den Nachfolger von Poledit.exe und NTConfig.pol ein. Vielmehr entstanden mit Active Directory und den Gruppenrichtlinien zwei eng miteinander verzahnte Technologien, die gemeinsam eine völlig neue Architektur für die zentrale Verwaltung von Windows-Umgebungen bildeten. Die eigentliche Innovation bestand dabei nicht in einer größeren Anzahl von Richtlinieneinstellungen, sondern in einem grundlegend neuen Verwaltungsmodell. Eine hierarchische Verzeichnisstruktur, eigenständige und wiederverwendbare Richtlinienobjekte, deren Verknüpfung mit administrativen Ebenen sowie die Vererbung und Kombination mehrerer Richtlinien ermöglichten erstmals eine flexible und zugleich skalierbare Administration. Ergänzt wurde dieses Konzept durch die konsequente Trennung von Benutzer- und Computerkonfiguration, eine regelmäßige Richtlinienverarbeitung sowie eine erweiterbare Clientarchitektur.

Viele dieser Prinzipien erscheinen heute selbstverständlich. Um die Jahrtausendwende bedeuteten sie jedoch einen fundamentalen Wandel gegenüber der Windows-NT-Welt. Die zentrale Windows-Verwaltung bestand nicht länger aus der Verteilung einer einzelnen Konfigurationsdatei, sondern wurde zu einem integralen Bestandteil einer verzeichnisgestützten, hierarchischen und dynamischen Verwaltungsarchitektur. Zahlreiche Grundideen, die Microsoft damals entwickelte, prägen die Verwaltung von Windows-Systemen bis heute und finden sich – wenn auch in anderer Form – selbst in modernen Cloud-Verwaltungsplattformen wie Microsoft Intune oder Entra ID wieder.

Im nächsten Kapitel lohnt sich deshalb ein Blick unter die Oberfläche. Erst die technische Architektur aus Group Policy Container (GPC), Group Policy Template (GPT), SYSVOL, Client Side Extensions (CSEs) und administrativen Vorlagen (ADMX und ADML) erklärt, warum Gruppenrichtlinien auch mehr als 25 Jahre nach ihrer Einführung noch immer zu den tragenden Säulen vieler Windows-Infrastrukturen gehören.

Ein persönlicher Blick auf einen Paradigmenwechsel

Wer den Wandel der Windows-Administration über mehrere Jahrzehnte begleitet hat, verbindet mit der Einführung von Active Directory häufig ganz unterschiedliche Erinnerungen. Für viele Administrator:innen, die bereits Windows NT-Domänen betrieben hatten, war insbesondere die neue hierarchische Struktur ein echter Paradigmenwechsel. Microsoft stellte Organisationseinheiten, Delegation und hierarchische Verwaltung damals immer wieder als einen der größten Vorteile von Active Directory heraus. Entsprechend interessant ist heute die Entwicklung hin zu Microsoft Entra ID. Dort existiert eine vergleichbare Hierarchie aus Organisationseinheiten nicht mehr. Manche langjährige Active-Directory-Administrator:innen schmunzeln deshalb mit dem Gedanken: Eigentlich sind wir wieder bei einer deutlich flacheren Struktur angekommen.

Auf den ersten Blick könnte daraus der Eindruck entstehen, Active Directory sei rückblickend ein gescheitertes Konzept gewesen. Tatsächlich trifft eher das Gegenteil zu. Active Directory war die passende Antwort auf die Anforderungen seiner Zeit. Vor 25 Jahren standen stationäre Arbeitsplatzrechner, klar abgegrenzte Unternehmensnetzwerke und zentral betriebene Rechenzentren im Mittelpunkt. Heute prägen Cloud-Dienste, Homeoffice, mobile Endgeräte und Bring Your Own Device (BYOD) die Unternehmens-IT. Mit den Rahmenbedingungen haben sich folgerichtig auch die Anforderungen an Identitäts- und Gerätemanagement verändert.

Eine zweite interessante Beobachtung stammt aus derselben Zeit. Viele erfahrene Novell Certified Administrators (CNAs) und Novell Certified Engineers (CNEs) betrachteten Active Directory anfangs durchaus kritisch. Mit der Novell Directory Services (NDS) existierte bereits seit den frühen 1990er Jahren ein hierarchischer Verzeichnisdienst, der zahlreiche Konzepte vorwegnahm, die Microsoft erst mit Windows 2000 einführte. Nicht wenige Novell-Administrator:innen empfanden Active Directory daher zunächst als einen vergleichsweise späten Nachzügler oder als vereinfachte Umsetzung bereits bekannter Ideen. Als sich Windows Server in den folgenden Jahren zunehmend als Standardplattform etablierte, blieb bei manchen erfahrenen CNEs deshalb eine gewisse Wehmut zurück. Weniger aus technischen Gründen, sondern weil mit NDS eine über Jahre vertraute Verwaltungswelt verschwand.

Rückblickend zeigt sich jedoch, dass weder Active Directory noch NDS isoliert betrachtet werden sollten. Beide Systeme spiegeln die Anforderungen ihrer jeweiligen Zeit wider. Die Entwicklung moderner Cloud-Verzeichnisdienste wie Entra ID verdeutlicht vielmehr, dass sich Identitäts- und Richtlinienverwaltung kontinuierlich weiterentwickeln. Nicht, weil frühere Konzepte falsch waren, sondern weil sich die IT-Landschaft grundlegend verändert hat.

Warum Gruppenrichtlinien bis heute erfolgreich sind

Wer die Gruppenrichtlinienverwaltung zum ersten Mal öffnet, sieht vor allem eines: sehr viele Einstellungen. Dadurch entsteht leicht der Eindruck, Gruppenrichtlinien seien im Kern lediglich ein großer Konfigurationseditor für Windows. Tatsächlich liegt die eigentliche Stärke an einer anderen Stelle. Microsoft entwickelte Gruppenrichtlinien als erweiterbare Verwaltungsarchitektur. Die zentrale Infrastruktur ermittelt, welche Richtlinien für einen Computer oder ein Benutzerkonto relevant sind, stellt die notwendigen Informationen bereit und übergibt deren Verarbeitung anschließend an spezialisierte Komponenten.

Diese Trennung ist entscheidend für die Langlebigkeit des Konzepts. Neue Windows-Versionen konnten zusätzliche Einstellungen und Verarbeitungskomponenten erhalten, ohne dass Microsoft das gesamte Gruppenrichtlinienmodell neu entwickeln musste. Auch Anwendungen von Microsoft und Drittanbietern ließen sich später in dieses Modell integrieren. Genau darin liegt eines der wichtigsten Architekturprinzipien: Die Gruppenrichtlinieninfrastruktur muss nicht jede einzelne Einstellung selbst verstehen. Sie organisiert vielmehr den Geltungsbereich, die Bereitstellung und die Verarbeitung. Spezialkomponenten kümmern sich anschließend darum, wie eine konkrete Einstellung auf dem Zielsystem umgesetzt wird. Diese Arbeitsteilung bildet bis heute das Fundament der Gruppenrichtlinien.

Ein GPO lebt in zwei Welten

Besonders deutlich wird diese Architektur beim Aufbau eines Group Policy Objects. Ein domänenbasiertes GPO befindet sich nämlich nicht vollständig an einem einzelnen Speicherort. Microsoft teilt es in zwei miteinander verbundene Komponenten auf: den Group Policy Container (GPC) und das Group Policy Template (GPT).

Der Group Policy Container befindet sich in Active Directory. Dort werden Metadaten des GPO gespeichert, beispielsweise Versionsinformationen, Statusangaben und weitere Eigenschaften. Jedes GPO besitzt dabei eine eindeutige GUID, über die seine Bestandteile miteinander verbunden werden. Das Group Policy Template liegt dagegen im Dateisystem innerhalb von SYSVOL. Dort befinden sich diejenigen Daten, die sich sinnvoll als Dateien ablegen lassen. Dazu gehören beispielsweise Skripte, Sicherheitseinstellungen und weitere richtlinienbezogene Dateien.

Vereinfacht lässt sich daher sagen:

• GPC = Active-Directory-Anteil
• GPT = Dateisystem-Anteil

Für Administrator:innen erscheint beides in der Gruppenrichtlinienverwaltung als ein einziges GPO. Unter der Oberfläche arbeiten jedoch zwei unterschiedliche Speicher- und Replikationsmechanismen zusammen.

Der Group Policy Container im Active Directory

Der Group Policy Container bildet den verzeichnisbasierten Teil des GPO. Er wird innerhalb der Domäne unterhalb des Containers CN=Policies,CN=System gespeichert. Dort befinden sich nicht die vollständigen Richtliniendaten, sondern vor allem Informationen, die Active Directory zur Verwaltung des Richtlinienobjekts benötigt. Microsoft nennt unter anderem Versionsinformationen, den Status des GPO und weitere Komponenteneinstellungen. Damit profitiert das GPO unmittelbar von der Active-Directory-Architektur. Der GPC wird gemeinsam mit anderen Verzeichnisobjekten über die reguläre AD-Replikation zwischen Domänencontrollern verteilt.

Diese Konstruktion erklärt auch, warum eine Gruppenrichtlinie weit mehr ist als ein Satz von Dateien in SYSVOL. Active Directory kennt das GPO als eigenes Objekt und kann deshalb Berechtigungen, Verknüpfungen und weitere Eigenschaften damit verbinden. Das wiederum schafft die Grundlage für zentrale Verwaltungsfunktionen wie Delegation und Security Filtering. Der GPC repräsentiert somit gewissermaßen die administrative Identität einer Gruppenrichtlinie innerhalb des Verzeichnisdienstes.

Das Group Policy Template liefert die eigentlichen Dateien

Der zweite Bestandteil ist das Group Policy Template. Für jedes domänenbasierte GPO existiert innerhalb von SYSVOL ein eigener Ordner, dessen Name der GUID des jeweiligen GPO entspricht. Dort liegen die dateibasierten Bestandteile der Richtlinie. Historisch gehörten dazu beispielsweise administrative Vorlagen im ADM-Format, Skripte, Sicherheitsinformationen sowie Daten für Softwareinstallationen. Microsoft beschreibt das GPT ausdrücklich als Dateisystemordner innerhalb des Policies-Unterverzeichnisses von SYSVOL.

Die Trennung zwischen GPC und GPT wirkt zunächst unnötig kompliziert. Tatsächlich ist sie jedoch logisch: Active Directory eignet sich hervorragend zur Speicherung strukturierter Verzeichnisinformationen, Berechtigungen und Objektbeziehungen. Für Skripte, Installationsinformationen oder andere Dateien ist dagegen ein repliziertes Dateisystem wesentlich besser geeignet. Microsoft kombinierte daher beide Welten. Damit entstand eine Architektur, die sowohl die Vorteile eines Verzeichnisdienstes als auch die eines Dateisystems nutzen konnte.

SYSVOL: das Dateisystem hinter den Gruppenrichtlinien

Der Name SYSVOL begegnet Administrator häufig erst dann bewusst, wenn etwas nicht funktioniert. Dabei ist das System Volume ein elementarer Bestandteil jeder Active-Directory-Domäne.

SYSVOL wird von den Domänencontrollern gemeinsam bereitgestellt und enthält unter anderem den Dateianteil der domänenbasierten Gruppenrichtlinien. Damit ein Client eine Richtlinie vollständig verarbeiten kann, müssen sowohl die Informationen im Active Directory als auch die zugehörigen Dateien innerhalb von SYSVOL verfügbar und konsistent sein. Microsoft weist ausdrücklich darauf hin, dass Gruppenrichtlinien von einer funktionierenden SYSVOL-Replikation abhängig sind.

Historisch replizierte Microsoft SYSVOL zunächst mit dem File Replication Service (FRS). Später übernahm Distributed File System Replication (DFSR) diese Aufgabe und ersetzte FRS schrittweise als Replikationsmechanismus für SYSVOL. Für ältere Active-Directory-Umgebungen stellt Microsoft ein Migrationsverfahren von FRS zu DFSR bereit; nach der Migration ist eine Rückkehr zu FRS nicht vorgesehen. Historisch ist diese Unterscheidung vor allem deshalb interessant, weil Domänen mit einem Domänenfunktionslevel ab Windows Server 2016 FRS für die SYSVOL-Replikation nicht mehr unterstützen. Moderne Active-Directory-Umgebungen setzen daher ausschließlich auf DFSR. Für die Praxis bedeutet das: Wer heute eine neue Active-Directory-Gesamtstruktur auf Basis aktueller Windows-Server-Versionen aufbaut, wird FRS nicht mehr begegnen. Das Thema besitzt heute vor allem historische Relevanz und spielt lediglich bei der Migration oder Modernisierung älterer Domänen noch eine Rolle.

Damit arbeiten bei einem GPO zwei Replikationswelten zusammen: Der GPC folgt der Active-Directory-Replikation, der GPT-Anteil der SYSVOL-Replikation.

Wenn GPC und GPT nicht zusammenpassen

Die Zweiteilung hat Vorteile, bringt jedoch auch eine wichtige Anforderung mit sich: Beide Bestandteile müssen zueinander passen. Ein GPO besitzt deshalb Versionsinformationen, anhand derer Windows erkennen kann, ob Active-Directory- und SYSVOL-Anteil konsistent sind. Microsoft weist in seiner Group-Policy-Dokumentation darauf hin, dass Richtlinieneinstellungen nur korrekt verarbeitet werden können, wenn GPC und GPT synchron vorliegen.

Genau hier entstehen in der Praxis Fehlerbilder, die erfahrenen Administrator:innen bekannt vorkommen dürften: Ein GPO wurde geändert, doch ein bestimmter Domänencontroller besitzt noch nicht den aktuellen SYSVOL-Inhalt. Oder die AD-Replikation funktioniert, während DFSR Probleme meldet. Für die Fehlersuche reicht es deshalb nicht immer aus, nur die Gruppenrichtlinienverwaltung zu betrachten. Administrator:innen müssen gegebenenfalls sowohl die Active-Directory-Replikation als auch SYSVOL beziehungsweise DFSR überprüfen.

Das ist zugleich ein schönes Beispiel dafür, wie wichtig Architekturverständnis im Alltag ist. Wer weiß, dass ein GPO technisch aus zwei Teilen besteht, kann viele vermeintlich rätselhafte Fehler wesentlich schneller einordnen.

Die Group-Policy-Infrastruktur verteilt, die CSE verarbeitet

Noch wichtiger für die Erweiterbarkeit ist ein zweites Architekturprinzip: die Client Side Extensions, kurz CSEs. Die zentrale Group-Policy-Infrastruktur ermittelt zunächst, welche GPOs auf einen Computer- oder Benutzerobjekt angewendet werden müssen. Sie interpretiert jedoch nicht selbst jede darin enthaltene Einstellung. Stattdessen übergibt sie die relevanten Informationen an spezialisierte Client Side Extensions.

Eine CSE ist damit eine eigenständige Komponente, die für einen bestimmten Richtlinientyp zuständig ist. Microsoft beschreibt ausdrücklich, dass jede Erweiterung ihre Richtliniendaten in einem eigenen Format verwaltet und die Group-Policy-Infrastruktur deren inhaltliche Details nicht kennen muss. Das lässt sich mit einem Paketdienst vergleichen: Gruppenrichtlinien sorgen dafür, dass das richtige Paket am richtigen System ankommt. Was sich darin befindet und wie damit umzugehen ist, entscheidet anschließend die zuständige Erweiterung. Gerade diese Trennung machte Gruppenrichtlinien außergewöhnlich flexibel.

Viele Aufgaben, eine gemeinsame Infrastruktur

Client Side Extensions ermöglichen es, vollkommen unterschiedliche Verwaltungsaufgaben unter demselben Dach abzubilden. So existieren beziehungsweise existierten spezialisierte Erweiterungen unter anderem für Registry-basierte Richtlinien, Sicherheitseinstellungen, Skripte, Ordnerumleitung, Softwareinstallation und weitere Bereiche. Die Security Settings Extension übernimmt beispielsweise die Verarbeitung sicherheitsbezogener Richtlinien.

Mit den später eingeführten Group Policy Preferences wurde dieses Modell noch einmal deutlich erweitert. Microsoft dokumentiert allein für die Preferences 20 Client Side Extensions. Dazu gehören unter anderem Erweiterungen für Netzlaufwerke, Dateien, Ordner, lokale Benutzer und Gruppen, Drucker, Registry-Einträge, geplante Aufgaben und Verknüpfungen.

Damit erklärt sich auch, warum ein Fehler bei der Gruppenrichtlinienverarbeitung nicht automatisch bedeutet, dass Gruppenrichtlinien insgesamt nicht funktionieren. Möglicherweise wurde das GPO korrekt ermittelt und geladen, während lediglich eine bestimmte CSE ihre Aufgabe nicht erfolgreich ausführen konnte. Für die Fehleranalyse ist diese Unterscheidung bis heute von großer Bedeutung.

Erweiterbarkeit als Erfolgsrezept

Die CSE-Architektur beantwortet eine der zentralen Fragen dieses Kapitels: Warum konnte eine Technologie aus dem Jahr 2000 so lange relevant bleiben? – Weil Microsoft nicht jede zukünftige Verwaltungsfunktion vorhersehen musste. Neue Funktionen konnten über zusätzliche Richtlinieneinstellungen und passende Erweiterungen in die bestehende Infrastruktur eingebunden werden. Ein schönes Beispiel dafür war die ‚klassische‘ Microsoft Local Administrator Password Solution (LAPS): Die ursprüngliche Version wurde als Group-Policy-CSE umgesetzt und bei den normalen Gruppenrichtlinienaktualisierungen aufgerufen.

Die Infrastruktur blieb dabei weitgehend dieselbe: Active Directory bestimmte den Geltungsbereich, Gruppenrichtlinien lieferten die Einstellungen und die zuständige Erweiterung setzte sie auf dem Client um. Das ist ein wesentliches Merkmal guter Softwarearchitektur. Ein System muss nicht alle zukünftigen Anforderungen bereits kennen. Es muss vielmehr so aufgebaut sein, dass es erweitert werden kann, ohne sein grundlegendes Funktionsmodell zu verändern. Genau das gelang Microsoft bei den Gruppenrichtlinien bemerkenswert gut.

Administrative Vorlagen sind keine Gruppenrichtlinien

Ein weiterer Begriff wird im administrativen Alltag häufig beinahe synonym mit Gruppenrichtlinien verwendet: Administrative Templates. Das führt gelegentlich zu einem Missverständnis. Eine ADMX-Datei ist selbst keine Gruppenrichtlinie. Sie beschreibt vielmehr, welche Registry-basierten Einstellungen im Group Policy Editor angeboten werden, welche Werte eingegeben werden können und wie diese Einstellungen administrativ dargestellt werden. Dieses Detail wird später beim Übergang zu Microsoft Intune besonders wichtig.

Administrative Vorlagen bilden gewissermaßen die Beschreibungsschicht zwischen einer technischen Registry-Einstellung und der Oberfläche, mit der Administrator diese konfigurieren. Dadurch muss niemand für jede Einstellung wissen, welcher Registry-Schlüssel und welcher konkrete Wert dahinterstehen. Die Vorlage übersetzt die technische Implementierung in eine verständliche administrative Richtlinie.

Dieses Prinzip existierte bereits mit den früheren ADM-Dateien. Mit Windows Vista und den nachfolgenden Windows-Versionen setzte Microsoft dann auf das XML-basierte Format ADMX und ADML. Microsoft dokumentiert diese Dateien bis heute als Grundlage für die Verwaltung Registry-basierter Richtlinieneinstellungen. citeturn389969view0

ADMX und ADML trennen Technik und Sprache

Auch innerhalb der administrativen Vorlagen setzte Microsoft auf Trennung. Die ADMX-Datei enthält die sprachunabhängige technische Definition einer Richtlinie. Dort werden unter anderem Kategorien, Richtlinien und die zugehörige Konfigurationslogik beschrieben. Die ADML-Dateien enthalten dagegen sprachabhängige Texte für die Darstellung im Editor. Microsoft beschreibt ADMX ausdrücklich als sprachneutral und ADML als sprachspezifisch. Damit kann dieselbe technische Vorlage in unterschiedlichen Sprachversionen der Verwaltungskonsole verwendet werden.

Beispielsweise kann eine Organisation denselben Satz an ADMX-Dateien einsetzen, während Administrator:innen die Richtlinien in deutscher oder englischer Sprache angezeigt bekommen, sofern die passenden ADML-Dateien vorhanden sind.

Auch dies wirkt auf den ersten Blick wie ein kleines Detail. Für international tätige Unternehmen und Softwarehersteller war diese Trennung jedoch ein erheblicher Fortschritt. Vor allem beseitigte sie eine Schwäche des früheren ADM-Modells: Sprach- und Definitionsinformationen mussten nicht länger in jedem einzelnen GPO redundant gespeichert werden.

Der Central Store beendet die Vorlagenvervielfachung

Bei älteren ADM-basierten Gruppenrichtlinien wurden verwendete Vorlagendateien innerhalb der jeweiligen GPOs gespeichert. Dadurch konnten identische ADM-Dateien vielfach innerhalb von SYSVOL vorhanden sein und entsprechend zusätzlichen Speicher- und Replikationsbedarf verursachen.

Mit ADMX änderte Microsoft dieses Modell. Moderne GPOs speichern die administrativen Vorlagen nicht mehr als redundante Kopie innerhalb jedes Richtlinienobjekts. Stattdessen können Unternehmen einen Central Store unterhalb von SYSVOL bereitstellen. Die Group-Policy-Werkzeuge greifen dann zentral auf die dort vorhandenen ADMX- und ADML-Dateien zu. Microsoft empfiehlt dieses Vorgehen ausdrücklich, um eine einheitliche Verwaltung aktueller administrativer Vorlagen sicherzustellen.

Ohne einen Central Store greift die jeweilige Gruppenrichtlinienverwaltungskonsole dagegen auf die lokal installierten ADMX- und ADML-Dateien des Verwaltungsrechners zurück. Das kann insbesondere in Umgebungen mit unterschiedlichen Windows-Versionen oder verschieden aktualisierten Administrationsarbeitsplätzen zu Inkonsistenzen führen. Neue Richtlinieneinstellungen werden dann möglicherweise nur auf einzelnen Verwaltungsrechnern angezeigt, während sie auf anderen Systemen noch fehlen. Im ungünstigsten Fall bearbeiten zwei Administrator:innen dasselbe Gruppenrichtlinienobjekt mit unterschiedlichen ADMX-Versionen und erhalten dadurch nicht dieselbe Sicht auf die verfügbaren Einstellungen.

Der Central Store sorgt deshalb nicht nur für eine geringere Anzahl redundanter Vorlagendateien, sondern vor allem für einen einheitlichen Definitionsstand innerhalb der gesamten Active-Directory-Umgebung. Alle Administrator:innen arbeiten unabhängig vom verwendeten Verwaltungsrechner mit denselben administrativen Vorlagen. Das vereinfacht die Zusammenarbeit, reduziert Fehlkonfigurationen und erleichtert gleichzeitig die Einführung neuer Windows-Versionen oder aktualisierter ADMX-Dateien.

Typischerweise befindet sich der Central Store unter: \\<Domäne>\SYSVOL\<Domäne>\Policies\PolicyDefinitions. Da der Central Store innerhalb von SYSVOL liegt, wird er auf die Domänencontroller repliziert. So arbeiten Administrator unabhängig vom verwendeten Verwaltungsrechner mit einem gemeinsamen Satz administrativer Vorlagen. Gerade in größeren Umgebungen schafft dies Konsistenz. Gleichzeitig wird deutlich, dass auch administrative Vorlagen selbst gepflegt und versioniert werden müssen.

ADMX als Brücke in die moderne Verwaltung

Die Langlebigkeit des ADMX-Konzepts zeigt sich besonders deutlich außerhalb klassischer Gruppenrichtlinien. Microsoft verwendet ADMX-basierte Einstellungen heute auch in Microsoft Intune. Administrative Templates und der Settings Catalog können zahlreiche Einstellungen abbilden, deren Definitionen aus derselben ADMX-Welt stammen. Microsoft dokumentiert ausdrücklich die Verwendung von ADMX-Vorlagen für Windows-Geräte innerhalb von Intune. Das ist für die Entwicklungsgeschichte dieses Beitrags ein wichtiger Punkt. ADMX ist nicht an Active Directory gebunden. Die Gruppenrichtlinie stellt einen Mechanismus dar, mit dem solche Einstellungen in einer klassischen Domänenumgebung bereitgestellt werden. Intune verwendet für moderne Geräteverwaltung andere Transport- und Verarbeitungstechnologien, kann jedoch dieselben oder vergleichbare Richtliniendefinitionen nutzen.

Gleichzeitig befindet sich auch diese Verwaltungsebene im Wandel. Microsoft migriert die klassischen Windows-Konfigurationsprofile schrittweise auf die Unified Settings Platform (USP) und empfiehlt für neue Richtlinien den Settings Catalog. Seit dem Intune-Release 2412 können keine neuen Windows-Administrative-Templates-Konfigurationsprofile mehr erstellt werden. Bereits vorhandene Profile bleiben jedoch erhalten und lassen sich weiterhin bearbeiten. Auch der Import eigener ADMX-Vorlagen – beispielsweise für Anwendungen wie Google Chrome oder Mozilla Firefox – wird weiterhin unterstützt.

Damit zeigt sich erneut ein zentrales Architekturprinzip: Die Beschreibung einer Einstellung und der Mechanismus ihrer Bereitstellung sind zwei unterschiedliche Dinge. Während ADMX weiterhin als Definitionsformat eine wichtige Rolle spielt, entwickelt Microsoft die eigentliche Verwaltung konsequent in Richtung Settings Catalog, Configuration Service Provider (CSPs) und der Unified Settings Platform weiter. Die Zukunft liegt damit weniger in neuen ADMX-basierten Konfigurationsprofilen als in einer einheitlichen, cloudnativen Verwaltungsschicht.

Delegation: Nicht jede Administration braucht Domain Admin

Eine skalierbare Verwaltungsarchitektur muss nicht nur viele Computer beherrschen. Sie muss auch viele Administrator und unterschiedliche Zuständigkeiten unterstützen. Auch hier spielt die Trennung verschiedener Group-Policy-Komponenten ihre Stärke aus. Über die Group Policy Management Console (GPMC) können administrative Aufgaben gezielt delegiert werden. Microsoft unterstützt beispielsweise die getrennte Vergabe von Berechtigungen zum Erstellen von GPOs, zum Bearbeiten bestimmter Richtlinienobjekte oder zum Verknüpfen von GPOs mit Standorten, Domänen und Organisationseinheiten.

Damit muss eine Person, die Gruppenrichtlinien für eine bestimmte OU betreut, nicht automatisch weitreichende administrative Berechtigungen für die gesamte Domäne erhalten. Gerade in größeren Unternehmen ist diese Trennung entscheidend. Eine zentrale IT kann beispielsweise grundlegende Sicherheitsrichtlinien kontrollieren, während delegierte Teams innerhalb klar definierter Bereiche zusätzliche Konfigurationen verwalten. Das entspricht dem Prinzip der geringstmöglichen Berechtigungen und reduziert zugleich organisatorische Abhängigkeiten.

Verknüpfen ist eine andere Berechtigung als Bearbeiten

Ein besonders interessantes Detail der Delegationsarchitektur ist die Trennung zwischen Inhalt und Geltungsbereich. Eine Person kann das Recht erhalten, ein bestimmtes GPO zu bearbeiten, ohne es zwangsläufig an einer OU verknüpfen zu dürfen. Umgekehrt kann die Berechtigung zur Verknüpfung eines vorhandenen GPO delegiert werden, ohne gleichzeitig dessen Inhalt verändern zu können. Microsoft führt diese Aufgaben in der GPMC ausdrücklich als separat delegierbare Berechtigungen.

Diese Trennung ist sicherheitstechnisch ausgesprochen sinnvoll. Denn die Möglichkeit, eine Richtlinie zu bearbeiten, und die Möglichkeit, ihren Anwendungsbereich zu verändern, stellen zwei unterschiedliche administrative Verantwortlichkeiten dar. So könnte beispielsweise ein zentrales Security-Team ein gehärtetes GPO erstellen und dessen Inhalt kontrollieren. Ein regionales Administrationsteam erhält dagegen lediglich das Recht, dieses freigegebene GPO mit den dafür vorgesehenen Organisationseinheiten zu verknüpfen. Damit lässt sich Verantwortung verteilen, ohne die zentrale Kontrolle über sicherheitskritische Richtlinien aufzugeben.

Skalierbarkeit bedeutet mehr als viele Computer

Wenn über Skalierbarkeit gesprochen wird, denken viele zunächst an die Anzahl verwalteter Geräte. Bei Gruppenrichtlinien reicht der Begriff jedoch weiter. Die Architektur skaliert auf mehreren Ebenen gleichzeitig. Active Directory strukturiert Benutzer- und Computerobjekte. GPOs können wiederverwendet und miteinander kombiniert werden. Verknüpfungen definieren den administrativen Geltungsbereich. CSEs erweitern die Funktionalität. ADMX-Dateien abstrahieren neue Einstellungen. Delegation verteilt administrative Verantwortlichkeiten. Diese einzelnen Mechanismen greifen ineinander.

Gerade deshalb konnten Gruppenrichtlinien sowohl in kleineren Domänen als auch in sehr großen Unternehmensumgebungen eingesetzt werden. Entscheidend ist allerdings eine saubere Planung. Eine technisch skalierbare Plattform schützt nicht vor einer schlecht strukturierten OU-Landschaft, unübersichtlichen GPO-Verknüpfungen oder widersprüchlichen Richtlinien.

Die vorab formulierte Regel ‚Think before you link‘ bleibt deshalb bestehen. Technische Skalierbarkeit schafft Möglichkeiten. Administrative Disziplin entscheidet darüber, ob diese Möglichkeiten langfristig beherrschbar bleiben.

Die eigentliche Stärke liegt in der Trennung der Verantwortlichkeiten

Betrachtet man die Architektur als Ganzes, wird deutlich, warum Gruppenrichtlinien eine außergewöhnliche Lebensdauer erreicht haben. Der GPC verwaltet die verzeichnisbezogenen Informationen. Das GPT stellt dateibasierte Richtliniendaten bereit. SYSVOL sorgt für deren Verfügbarkeit auf den Domänencontrollern. Client Side Extensions verarbeiten unterschiedliche Einstellungstypen. ADMX- und ADML-Dateien beschreiben Registry-basierte Konfigurationen unabhängig von der konkreten Richtlinieninfrastruktur. Die GPMC ermöglicht schließlich eine delegierbare Administration. Keine einzelne dieser Komponenten muss sämtliche Aufgaben übernehmen.

Gerade diese Trennung der Verantwortlichkeiten macht die Architektur flexibel und erweiterbar. Neue Einstellungen können hinzukommen, Vorlagen lassen sich aktualisieren, zusätzliche Client Side Extensions können neue Funktionen bereitstellen und administrative Zuständigkeiten können sich verändern, ohne das grundlegende Modell neu erfinden zu müssen. Das erklärt einen großen Teil des Erfolgs von Gruppenrichtlinien: Microsoft entwickelte keine starre Sammlung von Einstellungen, sondern ein Framework, das über Jahrzehnte mit Windows wachsen konnte.

Mehr als 25 Jahre und noch immer relevant

Die technische Basis der Gruppenrichtlinien stammt aus einer IT-Welt, in der Windows 2000, klassische Unternehmensnetzwerke und lokale Domänen den Alltag bestimmten. Dennoch gehören GPOs auch unter aktuellen Windows-Server-Versionen weiterhin zum regulären Verwaltungsmodell. Microsoft dokumentiert Gruppenrichtlinien auch für Windows Server 2025 weiterhin als maßgeblichen Bestandteil von Active Directory Domain Services.

Das bedeutet nicht, dass sich seit Windows 2000 nichts verändert hätte. FRS wurde durch DFSR abgelöst, ADM entwickelte sich zu ADMX und ADML, zahlreiche Client Side Extensions kamen hinzu und die Anzahl verfügbarer Einstellungen wuchs erheblich. Das grundlegende Architekturprinzip blieb jedoch erstaunlich stabil. Genau darin liegt die eigentliche Erfolgsgeschichte: Gruppenrichtlinien konnten sich verändern, ohne die grundlegende Architektur aufgeben zu müssen.

Im nächsten Kapitel verschiebt sich deshalb die Perspektive. Statt weiter unter die technische Oberfläche zu schauen, betrachten wir die Umgebung, für die diese Architektur ursprünglich entworfen wurde. Denn ihre Stärken lassen sich nur vollständig verstehen, wenn man sich vergegenwärtigt, wie Unternehmens-IT über viele Jahre organisiert war: Die Domäne bildete das Zentrum, der Arbeitsplatz befand sich im Unternehmensnetz und ein Domänencontroller war normalerweise nicht weit entfernt.

Als die Domäne das Zentrum der IT war

Um die Erfolgsgeschichte der Gruppenrichtlinien vollständig zu verstehen, reicht ein Blick auf ihre Architektur allein nicht aus. Ebenso wichtig ist die Umgebung, für die Microsoft dieses Verwaltungsmodell entwickelt hatte.

In den frühen 2000er Jahren war der typische Unternehmensarbeitsplatz vergleichsweise klar definiert. Der Computer gehörte dem Unternehmen, stand meist dauerhaft an einem Arbeitsplatz im Büro und war über Ethernet mit dem lokalen Netzwerk verbunden. Notebooks existierten selbstverständlich bereits, spielten in vielen Organisationen jedoch noch eine deutlich geringere Rolle als heute. Smartphones, Tablets und vollständig cloudverwaltete Endgeräte gehörten noch nicht zum administrativen Alltag. Damit war auch die Position eines Computers vergleichsweise vorhersehbar: Er befand sich im Unternehmensnetzwerk.

Diese scheinbar banale Feststellung ist für die Gruppenrichtlinienarchitektur von entscheidender Bedeutung. Ein domänengebundener Windows-Computer konnte davon ausgehen, dass DNS, ein Domänencontroller und SYSVOL normalerweise erreichbar waren. Genau auf dieser Annahme bauten viele Funktionen von Active Directory auf. Microsoft musste also kein Verwaltungsmodell für Geräte entwickeln, die möglicherweise monatelang keinen Kontakt zur Unternehmensinfrastruktur hatten. Die Infrastruktur kam gewissermaßen zum Arbeitsplatz, weil sich der Arbeitsplatz innerhalb dieser Infrastruktur befand.

Die Domäne war mehr als eine Benutzerverwaltung

Active Directory übernahm in dieser Welt eine zentrale Rolle. Die Domäne stellte nicht nur Benutzerkonten und Kennwörter bereit. Sie verband Identität, Computer, Authentifizierung, Namensauflösung und Konfiguration zu einer gemeinsamen Verwaltungsumgebung. Ein Arbeitsplatzrechner wurde der Domäne hinzugefügt und erhielt dadurch selbst eine Identität innerhalb von Active Directory. Benutzer meldeten sich mit Domänenkonten an. Gruppen regelten den Zugriff auf Ressourcen. Gruppenrichtlinien definierten die Konfiguration der Systeme. Diese enge Verzahnung machte die Domäne zum organisatorischen Mittelpunkt der Windows-Infrastruktur.

Dabei spielte DNS eine fundamentale Rolle. Active Directory Domain Services nutzt DNS, damit Clients geeignete Domänencontroller finden können. Microsoft beschreibt die Namensauflösung deshalb ausdrücklich als Voraussetzung dafür, dass Clients Domänencontroller lokalisieren und Domänencontroller untereinander kommunizieren können. War DNS korrekt konfiguriert und befand sich der Client im Unternehmensnetz, ergab sich ein weitgehend geschlossenes System: Der Computer konnte die Domäne finden, sich authentifizieren und anschließend die für ihn vorgesehenen Richtlinien beziehen.

Der Domänencontroller war normalerweise erreichbar

Für Gruppenrichtlinien ist der Kontakt zu einem Domänencontroller von zentraler Bedeutung. Der Client muss zunächst ermitteln, welche Richtlinien aufgrund seiner Position innerhalb von Active Directory gelten. Anschließend benötigt er Zugriff auf die zugehörigen Richtliniendaten. In klassischen Unternehmensnetzen war diese Erreichbarkeit normalerweise kein außergewöhnlicher Zustand, sondern die Regel.

Active Directory unterstützt dafür ein eigenes Standortkonzept. Sites repräsentieren Netzwerkbereiche und helfen Clients dabei, einen möglichst nahe gelegenen Domänencontroller zu verwenden. Microsoft beschreibt ausdrücklich, wie Domänencontroller Standortinformationen nutzen, um Clients auf einen Domänencontroller innerhalb beziehungsweise in der Nähe ihres eigenen Standorts hinzuweisen.

In einer größeren Organisation konnte deshalb beispielsweise eine Niederlassung einen eigenen Domänencontroller besitzen. Benutzer und Computer am Standort arbeiteten mit diesem lokalen System, während Active Directory die notwendigen Informationen zwischen den Standorten replizierte. Das reduzierte WAN-Verkehr und Antwortzeiten und machte die Infrastruktur gegenüber einzelnen Netzwerkproblemen robuster.

Nähe war ein Bestandteil der Architektur

Diese Standortorientierung verdeutlicht einen weiteren Unterschied zur heutigen Cloud-Welt. Klassische Active-Directory-Architekturen versuchten, zentrale Dienste möglichst nah an die verwalteten Systeme zu bringen. Deshalb entstanden Domänencontroller an unterschiedlichen Unternehmensstandorten, lokale DNS-Dienste, Dateiserver und häufig auch weitere Infrastrukturkomponenten direkt vor Ort.

Das Netzwerk war damit nicht nur ein Transportmedium. Seine Struktur beeinflusste unmittelbar die Architektur des Verzeichnisdienstes. Ein Client in Dortmund sollte möglichst auch einen Domänencontroller in Dortmund verwenden und nicht über eine langsame WAN-Verbindung einen Server an einem weit entfernten Standort kontaktieren. Active Directory Sites and Services machte diese physische beziehungsweise topologische Struktur für den Verzeichnisdienst sichtbar.

Auch Gruppenrichtlinien profitierte davon. LDAP-Abfragen gegen Active Directory und der Zugriff auf SYSVOL konnten über einen geeigneten Domänencontroller am eigenen Standort erfolgen. Gruppenrichtlinien waren deshalb eng mit einer Vorstellung von Unternehmens-IT verbunden, in der Netzwerktopologie und Verwaltungsarchitektur gemeinsam geplant wurden.

Vertrauen begann mit der Domänenmitgliedschaft

Mit dem Beitritt eines Computers zur Domäne entstand eine dauerhafte Vertrauensbeziehung zwischen dem Gerät und Active Directory. Der Computer erhielt ein eigenes Konto und konnte sich gegenüber einem Domänencontroller authentifizieren. Damit entstand eine wichtige Grundlage für die zentrale Verwaltung: Die Infrastruktur wusste nicht nur, wer sich anmeldete, sondern auch, an welchem verwalteten Computer diese Anmeldung erfolgte.

Das ermöglichte jene Trennung von Benutzer- und Computerrichtlinien, die bereits im vorherigen Kapitel eine zentrale Rolle spielte. Ein System konnte unabhängig von der angemeldeten Person bestimmte Sicherheitsvorgaben erhalten. Gleichzeitig ließen sich weitere Einstellungen abhängig vom Benutzerkonto anwenden.

Dieses Vertrauensmodell war eng mit der Domäne verknüpft. Kerberos beziehungsweise NTLM, LDAP, DNS und weitere Active-Directory-Dienste bildeten gemeinsam eine Infrastruktur, in der Identität und Netzwerkumgebung eng miteinander verbunden waren. Dass Microsoft Entra Domain Services auch heute noch genau diese klassischen Fähigkeiten wie Domain Join, LDAP, Kerberos, NTLM und Gruppenrichtlinien bereitstellt, zeigt, wie eng diese Dienste technisch zusammengehören.

Vertrauen durch das Netzwerk

Aus heutiger Sicht lohnt eine weitere Einordnung. Klassische Unternehmensnetze wurden häufig nach einem deutlich stärker perimeterorientierten Sicherheitsmodell aufgebaut als moderne Zero-Trust-Architekturen. Ein Gerät innerhalb des Unternehmensnetzes befand sich zunächst in einer Umgebung, die als administrativ kontrolliert galt. Das bedeutete nicht, dass intern jedes System automatisch vertrauenswürdig war. Firewalls, Berechtigungen, Netzwerksegmentierung und Authentifizierung waren selbstverständlich auch damals wichtige Bestandteile einer mehrschichtigen Sicherheitsarchitektur.

Dennoch spielte der Standort innerhalb des Unternehmensnetzes eine wesentlich größere Rolle für die Sicherheitsarchitektur als heute. Viele zentrale Dienste wie Dateifreigaben, Verwaltungswerkzeuge, Anwendungsserver und insbesondere Domänencontroller waren ausschließlich innerhalb des Unternehmensnetzes erreichbar. Ein Computer, der Mitglied der Domäne war und sich innerhalb dieses Netzes befand, erfüllte damit bereits wesentliche Voraussetzungen für den Zugriff auf zentrale Unternehmensressourcen.

Dieses Sicherheitsmodell wird rückblickend häufig als Castle-and-Moat-Modell beschrieben. Das Unternehmensnetz bildete die Burg, während Firewalls und andere Perimeterschutzmechanismen den Burggraben darstellten. Solange sich ein verwaltetes System innerhalb dieses geschützten Bereichs bewegte, konnten Active Directory und Gruppenrichtlinien ihre Stärken nahezu ideal ausspielen. Auf die Entwicklung dieses Sicherheitsmodells sowie den späteren Übergang zum Zero-Trust-Ansatz gehe ich im Blogbeitrag Moderne Microsoft Security-Architektur in der Praxis – Zero Trust, Identity, Cloud und Operations ganzheitlich denken ausführlicher ein.

Für das Verständnis der Gruppenrichtlinien genügt an dieser Stelle jedoch eine zentrale Erkenntnis: Netzwerk und Verwaltung bildeten weitgehend denselben Vertrauensraum. Die Richtlinieninfrastruktur befand sich dort, wo sich auch die verwalteten Computer aufhielten. Genau diese Annahme prägte die Architektur der Gruppenrichtlinien über viele Jahre hinweg.

Ein geschlossener Regelkreis

Unter diesen Bedingungen konnten Gruppenrichtlinien ihre Stärken besonders gut ausspielen. Ein Unternehmenscomputer wurde gestartet, stellte eine Netzwerkverbindung her und fand über DNS einen geeigneten Domänencontroller. Anschließend konnte Windows den Computer authentifizieren, die relevanten GPOs bestimmen und die erforderlichen Daten aus Active Directory und SYSVOL beziehen.

Bei der Benutzeranmeldung wiederholte sich dieser Prozess im entsprechenden Benutzerkontext. Während des laufenden Betriebs sorgte die Hintergrundaktualisierung anschließend dafür, dass Änderungen an den Richtlinien mit einer gewissen Verzögerung auf den Clients ankamen. Damit entstand praktisch ein geschlossener Verwaltungskreislauf: Unternehmensgerät → Unternehmensnetz → Domänencontroller → Richtlinie → Unternehmensgerät

Solange alle Elemente dieses Kreislaufs verfügbar waren, funktionierte die zentrale Verwaltung zuverlässig und weitgehend automatisch. Genau darin lag eine der größten Stärken der Gruppenrichtlinien: Sie mussten die Netzwerkgrenzen des Unternehmens nicht überwinden, weil sich die verwalteten Geräte normalerweise innerhalb dieser Grenzen befanden.

Wenn das Netzwerk beim Start noch nicht bereitsteht

Wie stark Gruppenrichtlinien von dieser Infrastruktur abhängig sind, zeigt sich besonders gut, wenn eine ihrer grundlegenden Annahmen nicht erfüllt wird. Microsoft dokumentiert beispielsweise Fehlerbilder, bei denen ein Client während des Systemstarts noch keine funktionierende Netzwerkverbindung besitzt. In diesem Fall kann Windows keinen Domänencontroller lokalisieren und die Gruppenrichtlinienverarbeitung schlägt zunächst fehl. Sobald die Netzwerkverbindung später verfügbar ist, kann die Hintergrundaktualisierung die Richtlinien erneut verarbeiten.

Dieses Verhalten ist architektonisch konsequent. Gruppenrichtlinien setzen für die Aktualisierung domänenbasierter Richtlinien voraus, dass ein Domänencontroller erreichbar ist. Microsoft nennt fehlende Netzwerkverbindungen zu einem Domänencontroller deshalb auch heute noch ausdrücklich als mögliche Ursache fehlgeschlagener Richtlinienverarbeitung.

In klassischen kabelgebundenen Unternehmensnetzen trat dieses Problem vergleichsweise selten auf. Mit WLAN, mobilen Computern, VPN-Verbindungen und später Homeoffice-Szenarien gewann es jedoch zunehmend an Bedeutung. Damit deutete sich bereits eine Veränderung an, die das ursprüngliche Verwaltungsmodell langfristig herausfordern sollte.

Offline bedeutete nicht automatisch unbrauchbar

Allerdings wäre es falsch, daraus zu schließen, dass ein domänengebundener Computer ohne Domänencontroller grundsätzlich nicht funktionierte. Windows konnte bereits bekannte Benutzeranmeldungen zwischenspeichern. Ein Notebook konnte deshalb beispielsweise auch außerhalb des Unternehmensnetzes verwendet werden, obwohl während der Anmeldung kein Domänencontroller erreichbar war. Ebenso blieben bereits angewendete Gruppenrichtlinieneinstellungen auf dem System wirksam.

Der entscheidende Unterschied lag vielmehr bei der Aktualisierung. Ohne Verbindung zur Domäne konnten neue Richtlinien nicht abgerufen, Änderungen nicht verarbeitet und bestimmte domänenabhängige Vorgänge nicht unmittelbar durchgeführt werden. Erst wenn wieder eine Verbindung zum Unternehmensnetz beziehungsweise über VPN zur Domäne bestand, konnte die zentrale Verwaltung den Client erneut erreichen.

Für gelegentlich mobile Notebooks war dieses Modell durchaus ausreichend. Problematisch wurde es erst, als außerhalb des Unternehmensnetzes nicht länger die Ausnahme, sondern zunehmend der Normalzustand wurde.

VPN verlängerte die Domäne nach außen

Mit der zunehmenden Verbreitung von Notebooks gewann deshalb Virtual Private Networking an Bedeutung. Ein VPN ermöglichte gewissermaßen, das interne Unternehmensnetz bis zu einem entfernten Arbeitsplatz zu verlängern. Sobald die Verbindung bestand, konnte ein mobiles System wieder auf interne DNS-Dienste, Domänencontroller, Dateiserver und andere Ressourcen zugreifen.

Aus Sicht der klassischen Windows-Verwaltung war das ausgesprochen praktisch. Statt die Verwaltungsarchitektur grundsätzlich zu verändern, stellte man dem entfernten Computer wieder einen Weg in das vertraute Unternehmensnetz bereit. Damit ließen sich auch Gruppenrichtlinien außerhalb des Büros weiterverwenden.

Das Modell hatte jedoch Grenzen. War das VPN erst nach der Benutzeranmeldung verfügbar, konnten bestimmte Vorgänge der Start- oder Anmeldephase nicht in derselben Weise verarbeitet werden wie bei einem permanent verbundenen Arbeitsplatz. Auch heutige Microsoft-Dokumentationen zeigen, dass bestimmte Änderungen in Active-Directory-Umgebungen über einzelne VPN-Konfigurationen verzögert wirksam werden können. Das Grundprinzip blieb jedoch erhalten: Für zentrale Verwaltung wurde der entfernte Computer wieder mit der Domäne verbunden.

Warum Gruppenrichtlinien nahezu ideal funktionierten

Betrachtet man die damaligen Rahmenbedingungen zusammen, wird der außerordentliche Erfolg der Gruppenrichtlinien verständlich. Microsoft konnte von mehreren relativ stabilen Annahmen ausgehen. Das Unternehmen kontrollierte den Windows-Client. Der Computer gehörte in der Regel der Organisation. Er war Mitglied einer Domäne. Ein Domänencontroller war im Unternehmensnetz erreichbar. DNS führte den Client zuverlässig zur richtigen Infrastruktur. Benutzer:innen arbeiteten überwiegend mit Windows, und das Gerät verbrachte den größten Teil seiner Betriebszeit innerhalb oder zumindest in Reichweite des Unternehmensnetzes.

Unter diesen Voraussetzungen waren Gruppenrichtlinien nahezu ideal. Die Richtlinien mussten keinen eigenen Internetdienst betreiben, keine heterogene Gerätewelt beherrschen und keine Clients verwalten, die möglicherweise niemals einen physischen Unternehmensstandort sahen. Die gesamte Verwaltungsarchitektur konnte sich auf ein weitgehend kontrolliertes Ökosystem stützen.

Gerade deshalb sollte man Gruppenrichtlinien aus heutiger Sicht nicht vorschnell als technisch überholt einordnen. Sie lösen die Aufgabe, für die sie entwickelt wurden, noch immer ausgesprochen gut.

Nicht die Technologie änderte sich zuerst, sondern die Umgebung

Der entscheidende Wandel begann deshalb nicht mit einer plötzlichen Schwäche der Gruppenrichtlinien. Vielmehr änderten sich schrittweise ihre Rahmenbedingungen. Notebooks wurden selbstverständlich. WLAN löste einen Teil der kabelgebundenen Infrastruktur ab. Mitarbeiter:innen arbeiteten unterwegs oder von zu Hause. Anwendungen wanderten in die Cloud. Smartphones und Tablets wurden zu produktiven Arbeitsgeräten. BYOD stellte schließlich sogar die Annahme infrage, dass jedes verwaltete Gerät dem Unternehmen gehören müsse.

Damit veränderte sich auch die Antwort auf eine Frage, die uns durch diesen Beitrag begleitet: Wo befindet sich eigentlich der Computer? Zu Beginn der Group-Policy-Ära war die Antwort meistens einfach: im Unternehmen und in der Domäne. Später lautete sie immer häufiger: irgendwo außerhalb, aber hoffentlich über VPN erreichbar. Heute kann ein Gerät schließlich auf einem anderen Kontinent stehen und dennoch vollständig verwaltet werden, obwohl es niemals einen Domänencontroller oder das klassische Unternehmensnetzwerk gesehen hat.

Genau an diesem Punkt geraten die ursprünglichen Annahmen der Active-Directory- und Group-Policy-Architektur unter Druck. Nicht weil diese Architektur schlecht entworfen wurde, sondern weil sie für eine andere IT-Welt entstanden ist. Damit beginnt der nächste große Wandel der Windows-Verwaltung.

Eine neue Arbeitswelt verändert die Anforderungen

Die klassische Active-Directory-Architektur ging von einer vergleichsweise stabilen Welt aus. Computer gehörten dem Unternehmen, liefen überwiegend unter Windows und befanden sich regelmäßig im Unternehmensnetz. Domänencontroller, DNS und SYSVOL waren erreichbar, während mobile Arbeit eher eine Ergänzung zum normalen Büroarbeitsplatz darstellte.

Keine dieser Annahmen verschwand über Nacht. Vielmehr lösten sie sich Schritt für Schritt auf. Notebooks wurden zum Standardarbeitsplatz. WLAN und mobile Datennetze ermöglichten Arbeit unabhängig vom Schreibtisch. Unternehmensanwendungen wanderten aus dem eigenen Rechenzentrum in die Cloud. Smartphones und Tablets entwickelten sich zu produktiven Arbeitsgeräten. Gleichzeitig begannen Beschäftigte, auch private Hardware für dienstliche Aufgaben einzusetzen.

Wie grundlegend sich dieser Wandel über vier Jahrzehnte vollzogen hat, habe ich im Blogbeitrag Eine Reise durch vier Jahrzehnte Digitalisierung aus einer persönlichen Perspektive beschrieben. Dort stehen die technischen Entwicklungen und ihre Auswirkungen auf den Alltag im Mittelpunkt. Für die Gruppenrichtlinien ist vor allem entscheidend, dass sich dadurch die Rahmenbedingungen der Unternehmens-IT grundlegend verändert haben.

Aus einer relativ homogenen und vorhersehbaren Infrastruktur entwickelte sich eine Arbeitswelt, in der Person, Gerät, Anwendung und Daten nicht mehr zwangsläufig am gleichen Ort liegen. Damit änderte sich auch die zentrale Frage der Geräteverwaltung. Es genügte nicht mehr, einen Computer zuverlässig erst dann zu konfigurieren, sobald er Kontakt zur Domäne hatte. Unternehmen benötigten zunehmend Verwaltungsmodelle, die Geräte unabhängig von ihrem Standort erreichen konnten. Nicht die Gruppenrichtlinien hatten sich verändert. Die Umgebung, für die sie geschaffen worden waren, tat es.

Der Computer verlässt das Unternehmensnetz

Notebooks gehörten zu den ersten Geräten, die das klassische Verwaltungsmodell herausforderten. Solange sie regelmäßig an einen Unternehmensstandort zurückkehrten oder über VPN mit der Domäne verbunden wurden, ließ sich die bestehende Active-Directory-Infrastruktur weiterhin nutzen.

Mit zunehmender Mobilität wurden diese Kontakte jedoch unregelmäßiger. Ein Computer konnte morgens im Unternehmen betrieben werden, nachmittags bei einem Kunden und am folgenden Tag im Homeoffice. Bereits angewendete Gruppenrichtlinien blieben zwar erhalten, neue oder geänderte Einstellungen benötigten für ihre reguläre domänenbasierte Verarbeitung weiterhin die notwendige Verbindung zur Active-Directory-Infrastruktur.

Damit wandelte sich Mobilität von einer technischen Sonderanforderung zu einer grundsätzlichen administrativen Herausforderung. IBM beschreibt eine mobile Workforce entsprechend als Belegschaft, die nicht mehr an einen zentralen physischen Arbeitsort gebunden ist und über Notebooks, Smartphones und andere mobile Technologien verbunden bleibt. Für die Geräteverwaltung ergab sich daraus eine neue Anforderung: Nicht das Gerät sollte zur Verwaltungsinfrastruktur zurückkehren müssen. Die Verwaltung musste das Gerät dort erreichen können, wo es sich gerade befand. Dieser Perspektivwechsel bereitete den Boden für Mobile Device Management und später cloudbasierte Endpoint-Management-Plattformen.

Homeoffice verändert mehr als nur den Arbeitsort

Homeoffice wird häufig vor allem als organisatorische Veränderung betrachtet. Aus Sicht der IT-Architektur verschiebt sich jedoch wesentlich mehr. Der Arbeitsplatz befindet sich nun außerhalb des klassischen Netzwerkperimeters. Die Internetverbindung gehört nicht dem Unternehmen. Der lokale Router wird nicht von der IT-Abteilung administriert. Gleichzeitig erwarten Benutzer dennoch Zugriff auf E-Mail, Dateien, Anwendungen, Kollaborationsplattformen und andere Unternehmensressourcen.

VPN konnte diese Distanz zunächst überbrücken. Technisch verlängerte es das Unternehmensnetz bis zum entfernten Client und ermöglichte damit weiterhin den Zugriff auf Domänencontroller und interne Dienste. Doch dieser Ansatz skaliert nur begrenzt als universelles Architekturmodell. Muss ein Gerät zunächst einen Tunnel in das Unternehmensnetz aufbauen, damit es konfiguriert, geprüft oder aktualisiert werden kann, bleibt die zentrale Verwaltung letztlich weiterhin vom klassischen Netzwerk abhängig.

Cloudbasierte Verwaltungsmodelle drehen dieses Prinzip um: Ein Gerät benötigt keinen Weg in das Unternehmensnetz, sondern lediglich eine Internetverbindung zum jeweiligen Verwaltungsdienst. Damit wird der geografische Standort zunehmend irrelevant. Ein verwalteter Computer kann im Firmengebäude, im Homeoffice oder auf einer Geschäftsreise betrieben werden und dennoch dieselbe zentrale Verwaltungsplattform erreichen.

Cloud Computing trennt Anwendung und Unternehmensnetz

Parallel zur Mobilisierung der Endgeräte veränderte Cloud Computing die andere Seite der Verbindung. Traditionell lagen viele Unternehmensanwendungen dort, wo auch Active Directory und die Arbeitsplatzsysteme angesiedelt waren: innerhalb des Unternehmensnetzes. Wer auf einen Dateiserver, eine Fachanwendung oder einen Exchange Server zugreifen wollte, musste typischerweise zunächst Zugang zu diesem Netzwerk besitzen.

Cloud-Dienste durchbrechen dieses Modell. Microsoft 365, Software-as-a-Service-Angebote und andere cloudbasierte Anwendungen werden über das Internet bereitgestellt. Damit befindet sich die Anwendung plötzlich nicht mehr hinter derselben Netzwerkgrenze wie Benutzerkonto und Endgerät. Das wiederum hat weitreichende Folgen für die Sicherheitsarchitektur. Wenn eine Ressource ohnehin über das Internet erreichbar ist, kann allein die Zugehörigkeit eines Geräts zum internen Netzwerk kaum noch als zentrales Entscheidungskriterium dienen. Stattdessen gewinnen andere Informationen an Bedeutung:

• Wer greift zu?
• Welches Gerät wird verwendet?
• Ist dieses Gerät verwaltet und sicher konfiguriert?
• Unter welchen Bedingungen findet der Zugriff statt?

Damit verschiebt sich der Schwerpunkt schrittweise vom Netzwerk hin zu Identität und Gerätezustand. Genau an diesem Punkt beginnen sich klassische Domänenverwaltung und modernes Endpoint Management konzeptionell voneinander zu entfernen.

Das Smartphone verändert die Erwartung an Verwaltung

Eine weitere Herausforderung entstand mit Smartphones und Tablets. Ein iPhone oder Android-Smartphone lässt sich nicht sinnvoll wie ein klassischer domänengebundener Windows-Arbeitsplatz behandeln. Das Gerät kennt weder die klassische Active-Directory-Mitgliedschaft noch den Group-Policy-Mechanismus eines Windows-Clients.

Trotzdem verarbeitet es möglicherweise hochsensible Unternehmensinformationen. E-Mails werden gelesen, Teams-Besprechungen durchgeführt, Dokumente geöffnet und Daten mit Cloud-Diensten synchronisiert. Aus Sicht der Informationssicherheit ist das Smartphone damit längst kein bloßes Telefon mehr, sondern ein vollwertiger Unternehmensendpunkt.

Für diese Geräteklasse entstand Mobile Device Management (MDM). Statt eine permanente Verbindung zur internen Domäne vorauszusetzen, registriert sich ein Gerät bei einem Verwaltungsdienst und erhält darüber Konfigurations-, Sicherheits- und Compliance-Vorgaben. Microsoft Intune unterstützt dieses Modell heute über zahlreiche Plattformen hinweg. Dazu gehören unter anderem Windows, macOS, iOS und iPadOS, Android sowie Linux. Der Begriff Mobile Device Management beschreibt deshalb längst nicht mehr ausschließlich die Verwaltung von Mobiltelefonen. Er markiert vielmehr einen grundlegenden Wechsel des Verwaltungsmodells.

Bring Your Own Device stellt eine weitere Grundannahme infrage

Mit Bring Your Own Device, kurz BYOD, fiel schließlich eine weitere bisher selbstverständliche Annahme: Nicht jedes Gerät, auf dem Unternehmensdaten verarbeitet werden, gehört auch dem Unternehmen. IBM definiert BYOD als organisatorisches Modell, bei dem Beschäftigte und andere autorisierte Personen ihre eigenen Notebooks, Smartphones oder andere persönliche Geräte für berufliche Aufgaben und den Zugriff auf Unternehmensdaten einsetzen dürfen.

Aus Sicht klassischer Gruppenrichtlinien ist dieses Szenario problematisch. Ein privates Smartphone wird nicht Mitglied einer Active-Directory-Domäne. Auch ein privater Windows-Rechner sollte nicht zwangsläufig vollständig in die interne Verwaltungsstruktur eines Unternehmens aufgenommen werden.

Damit entsteht eine wesentlich differenziertere Frage: Wie viel Verwaltung ist notwendig und wie viel Verwaltung ist auf einem privaten Gerät überhaupt angemessen? Moderne Endpoint-Management-Plattformen müssen deshalb zwischen unternehmenseigenen und persönlichen Geräten unterscheiden können. Intune führt diese Eigentumsinformation ausdrücklich als Eigenschaft eines verwalteten Geräts und unterscheidet zwischen Personal und Corporate. Damit wird deutlich: Geräteverwaltung muss heute nicht nur technische, sondern auch organisatorische Grenzen berücksichtigen.

Unternehmensdaten schützen, ohne das Privatgerät zu übernehmen

BYOD verschärft einen weiteren Zielkonflikt. Ein Unternehmen besitzt ein berechtigtes Interesse daran, seine Daten zu schützen. Gleichzeitig gehört das Endgerät einer Privatperson. Eine vollständige Geräteverwaltung ist deshalb nicht in jedem Szenario angemessen oder notwendig. Moderne Verwaltungsplattformen unterscheiden zunehmend zwischen Device Management und Application Management. Statt das gesamte Gerät zu kontrollieren, kann die Administration beispielsweise bestimmte Unternehmensanwendungen und deren Daten schützen.

Das ist konzeptionell weit von der klassischen Gruppenrichtlinie entfernt. Gruppenrichtlinien gehen grundsätzlich von einem Windows-System aus, das administrativ zur Organisation gehört und entsprechend umfassend konfiguriert werden darf. In BYOD-Szenarien muss dagegen sehr genau unterschieden werden, welcher Bereich der Organisation gehört und welcher privat bleibt.

Microsoft dokumentiert deshalb auch für Intune unterschiedliche Enrollment- und Verwaltungsmodelle für persönliche und unternehmenseigene Geräte. Beispielsweise können persönliche wie auch organisationseigene Android-Geräte registriert und mit Richtlinien versehen werden. Damit verschiebt sich die zentrale Fragestellung erneut: Nicht mehr Wie konfiguriere ich den Computer?, sondern Welche Unternehmensressourcen muss ich auf welchem Gerät unter welchen Bedingungen kontrollieren?

Aus Windows-Verwaltung wird Endpoint Management

Die zunehmende Plattformvielfalt stellt schließlich eine der sichtbarsten Grenzen klassischer Gruppenrichtlinien dar: Gruppenrichtlinien sind untrennbar mit Windows und Active Directory verbunden. Über viele Jahre war das vollkommen ausreichend, weil Windows in den meisten Unternehmen die dominierende Clientplattform darstellte.

Mit der zunehmenden Verbreitung unterschiedlicher Endgeräte änderte sich jedoch nicht nur die technische Landschaft, sondern auch die Aufgabe der zentralen Verwaltung. Statt ausschließlich Windows-Computer zu konfigurieren, mussten nun unterschiedlichste Gerätetypen über eine gemeinsame Plattform verwaltet und abgesichert werden. Microsoft Intune verfolgt genau diesen plattformübergreifenden Ansatz und stellt eine einheitliche Verwaltungsoberfläche für unterschiedliche Endgeräte bereit.

Damit verändert sich auch die Terminologie. Aus dem klassischen Desktop Management und späteren Mobile Device Management entwickelte sich zunehmend Unified Endpoint Management (UEM). IBM beschreibt UEM als Ansatz, mit dem IT- und Security-Teams Endgeräte unabhängig von Betriebssystem und Standort möglichst konsistent verwalten und absichern können. Das eigentliche Ziel hat sich dabei kaum verändert: Endgeräte sollen zentral konfiguriert, abgesichert und verwaltet werden. Neu ist jedoch, dass diese Aufgabe heute nicht mehr auf eine einzelne Plattform beschränkt ist, sondern unterschiedlichste Geräte und Betriebssysteme gleichermaßen umfasst.

Eine Richtlinie kann nicht mehr überall gleich aussehen

Plattformvielfalt bringt allerdings eine wichtige Konsequenz mit sich: Zentrale Verwaltung bedeutet nicht mehr zwangsläufig identische technische Umsetzung. Eine Kennwortrichtlinie, Festplattenverschlüsselung oder Firewall-Konfiguration kann unter Windows anders implementiert sein als unter macOS oder einem mobilen Betriebssystem. Die Verwaltungsplattform muss deshalb ein gemeinsames administratives Ziel auf unterschiedliche technische Mechanismen der jeweiligen Plattformen abbilden.

Genau hier unterscheidet sich modernes Endpoint Management grundlegend von der klassischen Group-Policy-Welt. Bei einer Gruppenrichtlinie kontrolliert Microsoft nahezu die gesamte Kette: Active Directory, Windows, den Gruppenrichtlinien-Client und die zugehörigen Client Side Extensions. In einer plattformübergreifenden Umgebung muss die Verwaltungsplattform dagegen mit den Management-Schnittstellen unterschiedlicher Betriebssystemhersteller arbeiten.

Das erklärt, warum Intune nicht einfach eine im Internet erreichbare GPMC sein kann. Die zu lösende Aufgabe ist größer geworden. Microsoft beschreibt Intune heute entsprechend als cloudbasierten Dienst für Endpoint Management, der Geräte, Anwendungen und organisatorische Daten über unterschiedliche Plattformen hinweg verwaltet und schützt. Damit wird aus Windows-Konfiguration zunehmend plattformübergreifende Governance für Endpunkte.

Der Netzwerkstandort verliert seine Sonderstellung

Mit Mobilität, Cloud Computing und BYOD verändert sich schließlich auch die Sicherheitsarchitektur. Im klassischen Castle-and-Moat-Modell besaß der Standort eines Geräts innerhalb des Unternehmensnetzes eine besondere Bedeutung. Moderne Arbeitsmodelle machen diese Grenze zunehmend unbrauchbar: Benutzer:innen befinden sich außerhalb des Unternehmens, Cloud-Anwendungen ebenfalls und selbst die verwendeten Geräte gehören möglicherweise nicht zur Organisation.

Ein Sicherheitsmodell kann unter diesen Voraussetzungen nicht mehr voraussetzen, dass eine Anfrage allein deshalb vertrauenswürdiger ist, weil sie aus einem bestimmten Netzwerk stammt. Damit gewinnt Zero Trust zunehmend an Bedeutung. Microsoft formuliert dafür drei zentrale Prinzipien: Verify explicitly, Use least privilege access und Assume breach. Jede Zugriffsanfrage soll anhand verfügbarer Signale ausdrücklich authentifiziert und autorisiert werden, Berechtigungen sollen auf das notwendige Minimum begrenzt bleiben und die Architektur soll grundsätzlich davon ausgehen, dass eine Kompromittierung jederzeit möglich ist.

Wer sich intensiver mit den Konzepten und Prinzipien von Zero Trust beschäftigen möchte, findet eine ausführliche Einordnung im Blogbeitrag Moderne Microsoft Security-Architektur in der Praxis – Zero Trust, Identity, Cloud und Operations ganzheitlich denken. Dort betrachte ich die Entwicklung vom klassischen Castle-and-Moat-Modell hin zu modernen, identitätszentrierten Sicherheitsarchitekturen deutlich ausführlicher.

Für die weitere Entwicklung der Geräteverwaltung genügt an dieser Stelle jedoch eine zentrale Erkenntnis: Vertrauen wird nicht mehr primär aus dem Standort abgeleitet, sondern kontinuierlich anhand von Identität, Gerätezustand, Kontext und Risiko bewertet.

Das Gerät wird selbst zum Sicherheitssignal

Damit verändert sich auch die Bedeutung der Geräteverwaltung. In der klassischen Active-Directory-Welt war das Gerät vor allem ein Objekt, auf das Konfigurationen angewendet wurden. In modernen Zero-Trust-Architekturen liefert sein Zustand zusätzlich Informationen für Zugriffsentscheidungen.

• Ist das Betriebssystem aktuell?
• Ist das Gerät verschlüsselt?
• Entspricht es den Sicherheitsvorgaben?
• Ist es überhaupt verwaltet?

Intune kann solche Anforderungen über Compliance Policies abbilden. In Verbindung mit Conditional Access kann ein Gerät, das definierte Anforderungen nicht erfüllt, vom Zugriff auf Unternehmensressourcen ausgeschlossen werden, bis der gewünschte Zustand wieder erreicht ist. Microsoft dokumentiert beispielsweise die Möglichkeit, zulässige Betriebssystemversionen über Compliance Policies zu definieren und nicht konforme Geräte anschließend über Conditional Access zu blockieren.

Damit bekommt zentrale Konfiguration eine zusätzliche Aufgabe. Eine Richtlinie sorgt nicht mehr ausschließlich dafür, dass eine bestimmte Einstellung gesetzt wird. Die Verwaltung kann zugleich feststellen, ob ein Gerät den erwarteten Sicherheitszustand erreicht, und diese Information für weitere Entscheidungen bereitstellen. Das ist ein grundlegender konzeptioneller Schritt über klassische Gruppenrichtlinien hinaus.

Zero Trust ersetzt nicht einfach die Domäne

Dabei wäre es zu kurz gegriffen, Zero Trust als direkten Nachfolger von Active Directory oder Gruppenrichtlinien zu betrachten. Zero Trust ist zunächst ein Sicherheitsmodell und keine einzelne Verwaltungstechnologie. Microsoft beschreibt ausdrücklich die Prinzipien explizit überprüfen, geringstmögliche Berechtigungen und von einer Kompromittierung ausgehen. Identitäten, Endpunkte, Anwendungen, Daten und Infrastruktur werden innerhalb dieses Modells zu unterschiedlichen Sicherheitssäulen.

Gruppenrichtlinien können sogar einen Beitrag zu einer Zero-Trust-Architektur leisten, indem sie beispielsweise domänengebundene Systeme härten und sicher konfigurieren. Was sich verändert, ist die Vorstellung von implizitem Vertrauen. Ein Gerät soll nicht allein deshalb weitreichenden Zugriff erhalten, weil es Mitglied einer Domäne ist oder sich innerhalb des Unternehmensnetzes befindet. Stattdessen werden zusätzliche Signale einbezogen. Hier ist vor allem entscheidend, was dieser Wandel für die Geräteverwaltung bedeutet: Konfiguration und Zugriffsentscheidung wachsen zunehmend zusammen.

Die Domäne wird vom Mittelpunkt zu einem Bestandteil

All diese Entwicklungen bedeuten nicht, dass Active Directory plötzlich überflüssig wird. In vielen Unternehmen bleibt die klassische Domäne weiterhin elementar. Server, Anwendungen, Dateidienste, Kerberos-basierte Authentifizierung und zahlreiche bestehende Unternehmenssysteme hängen weiterhin von Active Directory ab. Ihre Rolle verändert sich jedoch.

In der klassischen IT-Welt bildete Active Directory häufig den Mittelpunkt, um den nahezu alle anderen Komponenten organisiert wurden. In hybriden Architekturen wird die lokale Domäne zunehmend eine von mehreren Identitäts- und Verwaltungsplattformen. Daneben treten Microsoft Entra ID, Intune, SaaS-Anwendungen und Cloud-Dienste. Diese Koexistenz ist kein Sonderfall. Microsoft bietet mit Microsoft Entra Hybrid Join ausdrücklich ein Modell, bei dem Geräte gleichzeitig Mitglied des lokalen Active Directory und in Microsoft Entra registriert sind.

In diesem Zusammenhang zeigt sich: Der Wandel erfolgt nicht zwangsläufig durch einen abrupten Austausch der alten gegen eine neue Welt. Viel häufiger entsteht zunächst eine hybride Übergangsarchitektur, in der beide Modelle nebeneinander existieren und miteinander verbunden werden.

Vom ‚Wo?‘ zum ‚Wer, womit und unter welchen Bedingungen?‘

Mit dieser sich ändernden Struktur verändert sich eine Frage, die uns seit Beginn dieses Beitrags begleitet. In der klassischen Active-Directory-Welt lautete sie: Wo befindet sich der Computer? Die Antwort entschied darüber, ob der Client einen Domänencontroller erreichen, Gruppenrichtlinien aktualisieren und interne Ressourcen nutzen konnte.

In einer modernen Cloud- und Zero-Trust-Architektur reicht diese Frage nicht mehr aus. Nun müssen weitere Fragen beantwortet werden:

• Wer greift auf eine Ressource zu?
• Welches Gerät wird verwendet?Wird dieses Gerät von der Organisation verwaltet?
• Entspricht es den Sicherheitsanforderungen? Von welchem Standort erfolgt der Zugriff?
• Welche Anwendung wird verwendet und welches Risiko besteht in diesem Moment?

Genau diese Veränderung markiert den eigentlichen Paradigmenwechsel. Der Standort verschwindet nicht als Sicherheitsinformation. Microsoft führt ihn auch im Zero-Trust-Modell weiterhin als mögliches Signal. Er ist jedoch nur noch einer von mehreren Faktoren. Aus einem netzwerkzentrierten Vertrauensmodell wird damit zunehmend ein identitäts-, geräte- und kontextorientiertes Sicherheitsmodell.

Die ursprüngliche Aufgabe ist größer geworden

Damit lässt sich auch die Ausgangsfrage dieses Beitrags neu formulieren. Ende der 1990er Jahre lautete sie im Wesentlichen: Wie lassen sich tausende Windows-Computer innerhalb eines Unternehmens zentral, sicher und konsistent konfigurieren? Gruppenrichtlinien lieferten darauf eine ausgesprochen überzeugende Antwort.

Heute lautet die Aufgabe eher: Wie lassen sich Benutzer:innen, Anwendungen, Daten und Endgeräte unterschiedlicher Hersteller sicher verwalten, wenn sie sich jederzeit an nahezu jedem Ort befinden können und nicht jedes Gerät der Organisation gehört? Diese Frage ist nicht nur umfangreicher. Sie beruht auf vollkommen anderen Rahmenbedingungen.

Genau deshalb wäre die Aussage ‚Gruppenrichtlinien reichen nicht mehr aus‘ zu oberflächlich. Gruppenrichtlinien erfüllen ihre ursprüngliche Aufgabe weiterhin ausgesprochen gut. Nur ist diese ursprüngliche Aufgabe inzwischen Teil eines wesentlich größeren Verwaltungs- und Sicherheitsmodells geworden. Microsoft benötigte deshalb keine bloße Cloud-Version der GPO. Das Unternehmen benötigte eine Architektur, die Geräte über das Internet erreichen, verschiedene Plattformen verwalten, persönliche und unternehmenseigene Geräte unterscheiden und ihren Sicherheitszustand in Zugriffsentscheidungen einbeziehen konnte.

Damit kommen wir zu Microsoft Intune. Und genau hier wird sich im nächsten Kapitel zeigen, warum Intune anders denken muss als Gruppenrichtlinien.

Warum Intune anders arbeitet als Gruppenrichtlinien

Nach mehr als zwei Jahrzehnten Gruppenrichtlinien liegt ein Gedanke zunächst nahe: Wenn Microsoft Geräte heute über Intune verwaltet, handelt es sich dabei im Grunde um Gruppenrichtlinien aus der Cloud. Genau diese Vorstellung greift jedoch zu kurz.

Group Policy und Intune verfolgen zwar ähnliche Ziele. Beide sollen Geräte zentral konfigurieren, Sicherheitsvorgaben durchsetzen und administrative Standards vereinheitlichen. Die technische Umsetzung unterscheidet sich jedoch grundlegend. Gruppenrichtlinien entstanden für eine Welt aus Active Directory, Domänenmitgliedschaft, DNS, LDAP und SYSVOL. Intune wurde dagegen als cloudbasierte Endpoint-Management-Plattform für Geräte entwickelt, die sich an nahezu jedem Ort befinden können und nicht zwangsläufig Mitglied einer klassischen Active-Directory-Domäne sind. Microsoft beschreibt Intune entsprechend als cloudbasierten Dienst zur Verwaltung und Absicherung von Geräten und Anwendungen.

Damit ändert sich nicht nur der Transportweg einer Richtlinie. Die gesamte Beziehung zwischen Gerät, Identität und Verwaltungsdienst wird neu organisiert. Die Gruppenrichtlinie fragt sinngemäß: Welche Richtlinien gelten aufgrund meiner Position innerhalb des Active Directory? Intune fragt dagegen: Welches verwaltete Gerät oder welche Identität gehört zu welcher Zielgruppe und welche Cloud-Richtlinien wurden dieser Zielgruppe zugewiesen?

MDM statt LDAP und SYSVOL

Der vielleicht wichtigste Architekturunterschied liegt im Kommunikationsmodell. Ein klassischer Domänenclient ermittelt über Active Directory die für ihn relevanten Gruppenrichtlinien. Dafür kommuniziert er mit einem Domänencontroller, wertet die entsprechenden GPO-Verknüpfungen aus und greift anschließend auf die notwendigen Richtliniendaten in Active Directory und SYSVOL zu.

Intune verwendet diesen Mechanismus nicht. Ein registriertes Gerät kommuniziert stattdessen mit einem Mobile Device Management Service, kurz MDM. Unter Windows integriert Microsoft diesen Verwaltungsweg direkt in das Betriebssystem. Die Registrierung kann dabei eng mit einer Geräteidentität in Microsoft Entra ID verbunden werden. Microsoft dokumentiert ausdrücklich unterschiedliche MDM-Registrierungsmodelle, die Microsoft-Entra-Benutzer- und Geräteidentitäten verwenden. Damit benötigt ein cloudverwaltetes Gerät weder LDAP-Abfragen gegen einen lokalen Domänencontroller noch Zugriff auf SYSVOL. Es benötigt in erster Linie eine Verbindung zum Internet und zu den entsprechenden Cloud-Endpunkten.

Aus dem lokalen Verwaltungsmodell Client → Domänencontroller → Active Directory und SYSVOL wird damit vereinfacht Endpoint → Cloud Management Service → Richtlinie.

Entra ID liefert die Identität, Intune die Verwaltung

Microsoft Entra ID und Microsoft Intune werden häufig gemeinsam genannt, erfüllen jedoch unterschiedliche Aufgaben. Entra ID stellt unter anderem die Identität von Benutzer:innen und Geräten bereit. Ein Geräteobjekt in Entra ID ähnelt konzeptionell anderen Verzeichnisobjekten wie Benutzer, Gruppen oder Anwendungen und liefert Informationen, die für Zugriffs- und Verwaltungsentscheidungen genutzt werden können. Microsoft unterscheidet dabei zwischen Microsoft Entra registered, Microsoft Entra joined und Microsoft Entra hybrid joined Geräten.

Intune übernimmt dagegen die Verwaltung des Endpunkts. Ein Windows-Gerät kann beispielsweise beim Microsoft-Entra-Join automatisch in Intune registriert werden, sofern die entsprechende MDM-Autoenrollment-Konfiguration eingerichtet wurde. Microsoft dokumentiert diesen Zusammenhang ausdrücklich: Windows-Geräte können beim Registrieren oder Beitreten zu Microsoft Entra ID automatisch in Intune aufgenommen werden.

Diese Trennung ähnelt in gewisser Weise einem bekannten Prinzip aus Active Directory. Dort existieren ebenfalls Identität und Konfiguration als unterschiedliche Ebenen. Die Umsetzung ist jedoch neu: Entra ID beantwortet primär die Frage #Wer oder was ist dieses Gerät?‘ Intune beantwortet die Frage ‚Wie soll dieses Gerät verwaltet werden?‘

Configuration Service Provider bilden die Schnittstelle zum Betriebssystem

Damit Intune Einstellungen auf einem Windows-System umsetzen kann, benötigt das Betriebssystem definierte Verwaltungsschnittstellen. Eine zentrale Rolle übernehmen dabei die Configuration Service Provider, kurz CSPs.

CSPs stellen standardisierte Konfigurationsschnittstellen innerhalb von Windows bereit. Unterschiedliche CSPs sind für verschiedene Bereiche des Betriebssystems zuständig und stellen entsprechende Einstellungen für das MDM-Management bereit. Das Prinzip ähnelt in gewisser Weise den Client Side Extensions der Gruppenrichtlinien, sollte jedoch nicht mit ihnen gleichgesetzt werden. Bei Group Policy erhält eine CSE die für sie bestimmten Richtliniendaten und verarbeitet diese lokal. In der MDM-Welt stellt ein CSP dagegen eine definierte Schnittstelle bereit, über die ein Verwaltungsdienst Konfigurationswerte lesen, setzen oder entfernen kann.

Damit ist die Kommunikation stärker schnittstellenorientiert. Intune muss beispielsweise nicht wissen, wie Windows intern eine bestimmte Funktion implementiert. Entscheidend ist, dass Windows über einen geeigneten CSP eine unterstützte Management-Schnittstelle bereitstellt. Genau dieses Modell ermöglicht es Microsoft, neue Einstellungen in Windows für modernes Management verfügbar zu machen, ohne sie zwangsläufig zunächst als klassische Gruppenrichtlinie implementieren zu müssen.

Aus GPOs werden Configuration Profiles

Auch die organisatorische Struktur verändert sich. In Active Directory werden Einstellungen in einem Group Policy Object zusammengefasst und anschließend mit Sites, Domänen oder OUs verknüpft. Intune verwendet stattdessen Configuration Profiles beziehungsweise Konfigurationsrichtlinien. Administrator wählen zunächst eine Zielplattform und einen geeigneten Profiltyp beziehungsweise eine Sammlung von Einstellungen aus. Anschließend wird diese Richtlinie Benutzer- oder Gerätegruppen zugewiesen. Microsoft beschreibt die Erstellung von Device Configuration Profiles entsprechend als Auswahl einer Plattform, Konfiguration der gewünschten Einstellungen und anschließende Zuweisung. citeturn632349search15

Die entscheidende Veränderung lautet: Nicht die Position eines Objekts in einer OU-Hierarchie bestimmt primär die Richtlinie, sondern seine Zugehörigkeit zu einer Zielgruppe. Damit verschwindet das hierarchische Vererbungsmodell der klassischen Gruppenrichtlinien. Statt Standort → Domäne → OU → untergeordnete OU stehen nun Zuweisungen an Benutzer- und Gerätegruppen im Mittelpunkt. Die Architektur wird damit flacher, zugleich aber wesentlich flexibler für dynamische und cloudbasierte Geräteszenarien.

Das Comeback der flachen Struktur

An dieser Stelle dürfte das bereits erwähnte Schmunzeln mancher Active-Directory-Administrator alter Schule wieder verständlich werden. Mit Windows 2000 hatte Microsoft die hierarchische Struktur von Active Directory als entscheidenden Fortschritt gegenüber den flachen Windows-NT-Domänen etabliert. Ein Vierteljahrhundert später arbeitet die moderne Cloud-Verwaltung wieder deutlich weniger hierarchisch.

Entra ID kennt keine Organisationseinheiten, die mit klassischen Active-Directory-OUs vergleichbar wären. Auch Intune benötigt keine Baumstruktur aus Standorten, Domänen und verschachtelten Organisationseinheiten. Auf den ersten Blick wirkt das tatsächlich wie ein Schritt zurück. Tatsächlich gilt jedoch erneut: Alles zu seiner Zeit. Die OU-Hierarchie löste das Problem einer lokalen Unternehmensstruktur, in der Administrator:innen Geräte- und Benutzerkonten anhand organisatorischer Einheiten verwalten und Zuständigkeiten delegieren mussten. Cloud-Verwaltung muss dagegen Geräte erreichen, deren Position innerhalb eines Unternehmensnetzes möglicherweise überhaupt keine Bedeutung mehr besitzt.

Das Verwaltungsmodell wurde also nicht flacher, weil die alte Hierarchie grundsätzlich falsch war. Es wurde flacher, weil sich die zu lösende Aufgabe verändert hat.

Der Settings Catalog wird zum zentralen Werkzeug

Mit der wachsenden Anzahl moderner Konfigurationsmöglichkeiten benötigte Intune eine Möglichkeit, Einstellungen übersichtlich und zentral bereitzustellen. Dafür dient heute insbesondere der Settings Catalog. Microsoft stellt darüber eine große Sammlung konfigurierbarer Einstellungen bereit, die nach Kategorien durchsucht und zu eigenen Richtlinien zusammengestellt werden können. Die resultierenden Richtlinien lassen sich anschließend exportieren und wieder importieren, beispielsweise als JSON-Dateien.

Der Settings Catalog erinnert auf den ersten Blick stark an den Gruppenrichtlinieneditor: Administrator:innen suchen eine Einstellung, konfigurieren sie und weisen die daraus entstehende Richtlinie anschließend den gewünschten Geräten oder Benutzer:innen zu. Unter der Oberfläche bleibt die Architektur jedoch eine andere.

Der Settings Catalog ist keine Oberfläche für GPOs und verwendet kein GPC/GPT-Modell. Vielmehr stellt er unterschiedliche vom modernen Windows-Management unterstützte Einstellungen in einer gemeinsamen administrativen Oberfläche zusammen. Damit übernimmt er zunehmend die Rolle eines zentralen Konfigurationskatalogs innerhalb von Intune.

ADMX lebt weiter, aber nicht als GPO

Interessanterweise begegnet uns dabei eine Technologie wieder, die bereits vorab eine wichtige Rolle spielte: ADMX. Microsoft stellt zahlreiche ADMX-basierte Einstellungen innerhalb des Settings Catalog bereit und erlaubt zusätzlich den Import eigener beziehungsweise herstellerspezifischer ADMX- und ADML-Dateien. Nach dem Import können daraus Konfigurationsrichtlinien erstellt und verwalteten Windows-Geräten zugewiesen werden. Gerade daran lässt sich der Unterschied zwischen Definition und Bereitstellung hervorragend erkennen.

Eine ADMX-Datei kann dieselbe Windows-Einstellung beschreiben wie in einer klassischen Gruppenrichtlinie. Ihre Bereitstellung erfolgt in Intune jedoch nicht über Active Directory, GPC, GPT und SYSVOL. Stattdessen wird sie in das moderne MDM-Modell eingebettet. ADMX ist somit eine Brücke zwischen beiden Verwaltungswelten, aber kein Beleg dafür, dass Intune intern mit Gruppenrichtlinien arbeitet.

Group Policy Analytics schlägt die Brücke

Für Unternehmen mit langjährig gewachsenen Active-Directory-Umgebungen stellt sich allerdings eine sehr praktische Frage: Was geschieht mit den vorhandenen GPOs? Microsoft stellt dafür Group Policy Analytics in Intune bereit. Administrator können bestehende lokale GPOs exportieren und in Intune importieren. Der Dienst analysiert anschließend, welche enthaltenen Einstellungen über modernes MDM unterstützt werden, welche nicht verfügbar beziehungsweise veraltet sind und welche sich für eine Migration eignen. Das Werkzeug ist damit kein Konverter, der ein vollständiges GPO automatisch in eine identische Cloud-GPO verwandelt. Vielmehr beantwortet es eine wesentlich wichtigere Frage: Welche Teile meiner bisherigen Richtlinienstrategie ergeben in einer cloudbasierten Verwaltungswelt überhaupt noch Sinn?

Microsoft weist ausdrücklich darauf hin, dass manche Einstellungen auf cloudnativen Endpunkten keinen sinnvollen Gegenpart besitzen. Das ist für eine Migration entscheidend. Nicht alles, was über zwanzig Jahre in einer GPO gesammelt wurde, sollte zwangsläufig in Intune nachgebildet werden.

Migrieren bedeutet nicht kopieren

Nach der Analyse können unterstützte Einstellungen aus importierten GPOs in eine Settings-Catalog-Richtlinie überführt werden. Microsoft stellt hierfür eine entsprechende Migrationsfunktion bereit. Gerade hier lohnt jedoch Zurückhaltung. Microsoft empfiehlt bei der Planung cloudnativer Endpunkte ausdrücklich, bestehende GPOs zwar als Referenz zu analysieren, neue Richtlinien aber grundsätzlich anhand der heutigen Anforderungen zu entwerfen, statt historische GPO-Strukturen einfach unverändert in Intune zu übertragen.

Das ist eine ausgesprochen wichtige Empfehlung. Eine über viele Jahre gewachsene Gruppenrichtlinienumgebung enthält häufig Einstellungen, die aus früheren Windows-Versionen, alten Sicherheitsanforderungen oder längst abgeschalteten Anwendungen stammen. Eine Cloud-Migration bietet deshalb die Gelegenheit zur Bereinigung.

Die bessere Frage lautet daher nicht: ‚Wie bekomme ich meine 200 GPOs nach Intune?‘, sondern: ‚Welche Konfiguration benötigt mein heutiger Endpoint tatsächlich?‘ Damit wird Migration von einer technischen Kopieraufgabe zu einer Architekturentscheidung.

Vererbung wird durch Zuweisung ersetzt

Auch das Modell der Richtlinienanwendung verändert sich grundlegend. Gruppenrichtlinien verwenden eine hierarchische Verarbeitung entlang von Standort, Domäne und OU. Mehrere GPOs wirken zusammen und ergeben daraus die effektive Konfiguration eines Clients.

Intune arbeitet dagegen stärker mit Assignments. Richtlinien werden Gruppen von Benutzer:innen oder Geräten zugewiesen. Dadurch können beispielsweise alle unternehmenseigenen Windows-Notebooks, bestimmte Benutzergruppen oder andere definierte Gerätekategorien gezielt erreicht werden.

Das ist insbesondere für dynamische Cloud-Szenarien attraktiv. Ein Computer muss nicht in eine bestimmte OU verschoben werden, damit eine Richtlinie greift. Entscheidend ist, dass er die für die Zuweisung definierten Kriterien erfüllt oder Mitglied der entsprechenden Gruppe ist.

Damit verändert sich auch das Denken der Administration. Aus ‚Wo befindet sich das Objekt?‘ wird ‚Welche Eigenschaften besitzt das Objekt und zu welcher Zielgruppe gehört es?‘ Das ist einer der grundlegenden Unterschiede zwischen klassischer Active-Directory-Verwaltung und modernem Endpoint Management.

Intune kennt mehr als nur Konfiguration

Eine weitere Differenz zu Gruppenrichtlinien liegt im Umfang der Plattform. Gruppenrichtlinien konzentrieren sich primär auf Konfiguration. Intune verbindet dagegen mehrere Verwaltungsaufgaben innerhalb eines Cloud-Dienstes. Microsoft beschreibt Intune unter anderem als Plattform zum Registrieren, Konfigurieren, Absichern und Aktualisieren von Geräten, zum Bereitstellen und Schützen von Anwendungen sowie zur Steuerung des Zugriffs auf Unternehmensressourcen.

Damit wird Endpoint Management breiter gedacht. Ein Gerät erhält nicht lediglich Einstellungen. Es kann gleichzeitig inventarisiert, mit Anwendungen versorgt, hinsichtlich seiner Compliance bewertet und in Zugriffsentscheidungen einbezogen werden. Gerade die Verbindung zu Microsoft Entra ID und Conditional Access führt dazu, dass Konfiguration und Zugriffskontrolle zunehmend zusammenwachsen. Hier überschreitet Intune deutlich die klassische Rolle einer Gruppenrichtlinie.

Hybride Geräte zeigen, dass beide Welten koexistieren können

Der Unterschied zwischen Gruppenrichtlinien und Intune bedeutet nicht zwangsläufig, dass sich Unternehmen sofort für eine der beiden Technologien entscheiden müssen. Microsoft unterstützt ausdrücklich hybride Szenarien. Ein Windows-Gerät kann weiterhin Mitglied einer lokalen Active-Directory-Domäne sein und gleichzeitig als Microsoft Entra hybrid joined in Entra ID registriert werden. Über eine Gruppenrichtlinie lässt sich sogar die automatische MDM-Registrierung solcher domänengebundenen Geräte auslösen.

Damit kann ein Gerät gleichzeitig klassische Gruppenrichtlinien und moderne Intune-Richtlinien erhalten. Gerade während einer Migration ist dieses Modell wichtig. Unternehmen können bestehende GPOs zunächst weiterverwenden und einzelne Konfigurationsbereiche schrittweise in Intune überführen. Das zeigt erneut, dass Microsoft den Übergang nicht als abrupten Austausch konzipiert hat. Die klassische und moderne Verwaltungswelt können über längere Zeit nebeneinander bestehen.

GPO und Intune im Architekturvergleich

Die Unterschiede lassen sich schließlich auf einige zentrale Architekturprinzipien verdichten.

Diese Gegenüberstellung zeigt den eigentlichen Kern des Kapitels. Intune verwendet einige bekannte Konzepte und kann sogar dieselben Windows-Einstellungen konfigurieren. Es tut dies jedoch über eine andere Control Plane. Deshalb ist Intune keine Cloud-GPO.

Warum Intune anders denken muss

Der Unterschied zwischen beiden Technologien lässt sich letztlich auf ihre jeweilige Ausgangsfrage reduzieren. Gruppenrichtlinien wurden für eine Welt entwickelt, in der ein Windows-Computer Mitglied einer Domäne war und regelmäßig einen Domänencontroller erreichen konnte. Intune wurde für eine Welt entwickelt, in der ein Endpoint möglicherweise nie einen Unternehmensstandort besucht, über das öffentliche Internet kommuniziert und nicht einmal Windows ausführen muss.

Die Aufgabe ist deshalb größer geworden. Nicht nur Windows-Einstellungen müssen verteilt werden. Geräte müssen registriert, identifiziert, inventarisiert, konfiguriert, mit Anwendungen versorgt, auf Compliance geprüft und bei Zugriffsentscheidungen berücksichtigt werden. Deshalb sollte die Frage nicht lauten: ‚Wo finde ich in Intune die Gruppenrichtlinien?‘, sondern: ‚Wie löst modernes Endpoint Management heute die Aufgaben, die früher überwiegend innerhalb der Domäne gelöst wurden?‘ Genau in dieser Perspektive liegt der Schlüssel zum Verständnis von Intune. Die Verwaltungsplattform hat sich verändert. Viele der grundlegenden Ziele sind jedoch erstaunlich vertraut geblieben.

Was geblieben ist – Die Grundideen leben weiter

Der Architekturvergleich zwischen Gruppenrichtlinien und Microsoft Intune zeigt deutliche Unterschiede. Active Directory, SYSVOL und Client Side Extensions stehen auf der einen Seite, cloudbasierte Verwaltungsdienste, MDM und Configuration Service Provider auf der anderen. Trotzdem wäre es falsch, daraus zwei vollständig getrennte Verwaltungswelten abzuleiten. Viele Grundideen, die den Erfolg der Gruppenrichtlinien ausgemacht haben, finden sich im modernen Endpoint Management wieder. Geräte sollen nicht individuell und manuell konfiguriert werden. Stattdessen definiert die Administration einen gewünschten Zustand und weist diesen einer größeren Gruppe von Endpunkten zu.

Auch Intune verfolgt genau diesen Ansatz. Microsoft beschreibt Device Configuration Profiles als zentral definierte Konfigurationen, die anschließend auf Geräte einer Organisation verteilt werden. Der konkrete technische Mechanismus hat sich verändert, das administrative Grundprinzip jedoch nicht. Damit bleibt eine der wichtigsten Erkenntnisse aus mehr als 25 Jahren Windows-Verwaltung bestehen: Skalierbare Administration entsteht nicht durch möglichst effiziente Einzelkonfiguration, sondern dadurch, Einzelkonfiguration konsequent zu vermeiden.

Richtlinien statt Einzelkonfiguration

Bereits die Systemrichtlinien der Windows-NT-Ära verfolgten diesen Gedanken. Gruppenrichtlinien entwickelten ihn anschließend zu einem umfangreichen, hierarchischen Verwaltungsmodell weiter. Intune setzt dieselbe Idee unter anderen technischen Rahmenbedingungen fort. Administrator:innen konfigurieren beispielsweise nicht auf jedem Notebook einzeln Microsoft Defender, BitLocker oder bestimmte Windows-Einstellungen. Stattdessen werden Richtlinien zentral erstellt und den entsprechenden Benutzer- oder Gerätegruppen zugewiesen.

Damit wandert die Verantwortung von einem einzelnen Gerät auf die Verwaltungsebene. Das ist mehr als eine Komfortfunktion. Zentral definierte Richtlinien schaffen Reproduzierbarkeit. Neue Geräte können dieselben Vorgaben erhalten wie bereits vorhandene Systeme. Änderungen müssen nicht auf jedem Endpoint wiederholt werden und lassen sich über eine zentrale Plattform nachvollziehen. Genau dieses Prinzip machte schon Gruppenrichtlinien so erfolgreich.

Der Unterschied liegt heute vor allem darin, wo die Richtlinie definiert wird, wie sie das Gerät erreicht und welche Plattformen damit verwaltet werden können. Die Philosophie bleibt dagegen nahezu unverändert: Nicht das einzelne Gerät entscheidet über seine Unternehmenskonfiguration. Die Organisation definiert den gewünschten administrativen Rahmen.

Standardisierung wird wichtiger, nicht unwichtiger

Je vielfältiger eine IT-Landschaft wird, desto größer wird die Bedeutung von Standards. In einer klassischen Active-Directory-Umgebung konnten Unternehmen beispielsweise festlegen, wie Windows-Firewall, Microsoft Defender, Browser oder Betriebssystemfunktionen konfiguriert werden sollten. Gruppenrichtlinien sorgten anschließend dafür, dass diese Vorgaben auf den entsprechenden Systemen umgesetzt wurden. Moderne Endpoint-Umgebungen erhöhen diese Herausforderung. Geräte befinden sich an unterschiedlichen Orten, verschiedene Betriebssysteme kommen zum Einsatz und neue Endpunkte können ohne klassischen Kontakt zur Unternehmensinfrastruktur bereitgestellt werden. Gerade deshalb können sich Organisationen weniger denn je auf manuelle Konfiguration verlassen.

Microsoft Intune stellt dafür heute umfangreiche Konfigurationsmöglichkeiten bereit. Allein der Settings Catalog umfasst tausende Einstellungen für unterschiedliche Plattformen und wird kontinuierlich erweitert, sobald Betriebssysteme neue Management-Schnittstellen bereitstellen. Damit wird zentrale Standardisierung nicht durch Cloud Management ersetzt. Cloud Management macht sie vielmehr noch wichtiger. Je weniger Kontrolle eine Organisation über den physischen Standort eines Endpunkts besitzt, desto wichtiger wird ein reproduzierbares administratives Regelwerk.

Aus technischen Einstellungen werden Unternehmensstandards

Dabei sollten Richtlinien nicht lediglich als Sammlung einzelner Schalter verstanden werden. Eine professionelle Verwaltungsstrategie übersetzt organisatorische Anforderungen in technische Standards. Die Vorgabe Unternehmensgeräte müssen verschlüsselt sein wird beispielsweise durch konkrete BitLocker-Einstellungen umgesetzt. Die Forderung nach einem gehärteten Browser führt zu definierten Microsoft-Edge-Konfigurationen. Vorgaben zum Schutz vor Schadsoftware werden in Einstellungen für Microsoft Defender übersetzt.

Genau hier liegt eine wichtige Gemeinsamkeit zwischen GPO und Intune. Beide Technologien bilden eine Abstraktionsschicht zwischen einer organisatorischen Anforderung und ihrer technischen Umsetzung auf dem Endpoint. Eine gute Richtlinienarchitektur beginnt deshalb nicht mit der Frage: ‚Welche Einstellung können wir konfigurieren?‘, sondern mit: ‚Welchen Zustand wollen wir erreichen und warum?‘ Erst daraus sollten konkrete technische Einstellungen entstehen. Dieses Prinzip ist unabhängig davon, ob die Umsetzung anschließend über Gruppenrichtlinien, Intune oder eine andere Plattform erfolgt.

Administrative Templates überleben den Architekturwechsel

Ein besonders anschauliches Beispiel für die Kontinuität zwischen klassischer und moderner Verwaltung sind die bereits ausführlich betrachteten Administrative Templates. ADMX-Dateien entstanden ursprünglich im Umfeld klassischer Gruppenrichtlinien. Dennoch können ADMX-basierte Einstellungen heute auch über Microsoft Intune bereitgestellt werden. Intune unterstützt sowohl zahlreiche integrierte administrative Einstellungen als auch den Import eigener beziehungsweise herstellerspezifischer ADMX- und ADML-Dateien.

Gerade daran wird deutlich, dass die Beschreibung einer Einstellung nicht an einen bestimmten Transportmechanismus gebunden sein muss. Eine Richtlinieneinstellung kann weiterhin über eine ADMX-Definition beschrieben werden, obwohl sie nicht mehr über Active Directory und SYSVOL verteilt wird. Damit überlebt ein wesentlicher Teil der klassischen Verwaltungslogik den Wechsel in die Cloud.

Gleichzeitig haben wir bereits gesehen, dass Microsoft den Settings Catalog und die Unified Settings Platform strategisch stärker in den Mittelpunkt rückt. ADMX bildet deshalb weniger die Zukunft der gesamten Intune-Architektur als vielmehr eine wichtige Brücke zwischen zwei Generationen der Windows-Verwaltung.

Bekanntes Wissen verliert nicht automatisch seinen Wert

Für Administrator:innen aus der klassischen Active-Directory-Welt ist dieser Zusammenhang besonders wichtig. Wer jahrelang mit Gruppenrichtlinien gearbeitet hat, beginnt bei Intune nicht bei null. Das Wissen darüber, welche Windows-Einstellungen sicherheitsrelevant sind, wie Konfigurationen strukturiert werden sollten, welche Seiteneffekte bestimmte Richtlinien besitzen oder warum unterschiedliche Einstellungen miteinander kollidieren können, bleibt wertvoll.

Lediglich die administrative Oberfläche und der Bereitstellungsmechanismus ändern sich. Auch Kenntnisse über Administrative Templates können weiterhin helfen, die Herkunft bestimmter Intune-Einstellungen zu verstehen. Der Wechsel von Gruppenrichtlinien zu Intune ist deshalb nicht gleichbedeutend mit dem Austausch des gesamten bisherigen Wissens. Vielmehr verändert sich der architektonische Kontext, in dem dieses Wissen eingesetzt wird. Gerade erfahrene GPO-Administrator:innen besitzen damit eine gute Ausgangsbasis für Modern Management, sofern sie bereit sind, die neuen Zuweisungs-, MDM- und Cloud-Mechanismen nicht einfach in alte Denkmuster zu pressen.

Security Baselines machen aus Einzelrichtlinien ein Sicherheitsmodell

Besonders deutlich wird die Weiterentwicklung des Richtliniengedankens bei den Security Baselines. Anstatt hunderte sicherheitsrelevante Einstellungen einzeln auszuwählen, stellt Microsoft vorkonfigurierte Sammlungen empfohlener Sicherheitswerte bereit. Eine Security Baseline besteht aus zahlreichen Device-Configuration-Einstellungen, deren Standardwerte von den jeweils zuständigen Microsoft-Sicherheitsteams empfohlen werden. Unternehmen können diese Baselines übernehmen und anschließend an ihre eigenen Anforderungen anpassen. Damit verschiebt sich die Administration erneut eine Ebene nach oben. Die zentrale Frage lautet nicht mehr: ‚Welchen Wert sollte diese einzelne Richtlinie besitzen?‘, sondern: ‚Welche Sicherheitskonfiguration empfiehlt Microsoft für diesen Produkttyp und an welchen Stellen müssen wir davon bewusst abweichen?‘

Security Baselines sind damit eine logische Weiterentwicklung der Standardisierungsidee. Sie ersetzen nicht das Verständnis einzelner Einstellungen. Sie schaffen jedoch einen nachvollziehbaren Ausgangspunkt für eine konsistente Sicherheitskonfiguration. Gerade in großen Umgebungen kann dies den Aufwand erheblich reduzieren und zugleich verhindern, dass sicherheitskritische Einstellungen versehentlich übersehen werden.

Eine Baseline ist kein unveränderliches Dogma

Security Baselines sollten allerdings nicht mit einer universell passenden Sicherheitskonfiguration verwechselt werden. Microsoft erlaubt ausdrücklich, die enthaltenen Einstellungen an die Anforderungen einer Organisation anzupassen. Das ist wichtig, denn Sicherheit entsteht immer im jeweiligen Nutzungskontext. Eine Einstellung, die für einen administrativen Hochsicherheitsarbeitsplatz sinnvoll ist, kann auf einem Gerät für spezielle Produktionssoftware zu funktionalen Problemen führen. Ebenso können regulatorische Anforderungen strengere Werte verlangen als eine allgemeine Herstellerempfehlung.

Professionelles Baseline Management bedeutet deshalb nicht, eine Vorlage ungeprüft auszurollen. Es bedeutet vielmehr, einen dokumentierten Ausgangspunkt zu verwenden, Abweichungen bewusst zu entscheiden und die daraus entstehende Zielkonfiguration konsistent umzusetzen. Damit begegnet uns erneut ein bekanntes Prinzip aus der GPO-Welt. Die Qualität einer Richtlinienumgebung hängt nicht von der Anzahl konfigurierter Einstellungen ab, sondern davon, ob diese Einstellungen einer nachvollziehbaren administrativen Strategie folgen.

Vom Erzwingen zur Bewertung

Moderne Verwaltung geht an einer Stelle jedoch über klassische Gruppenrichtlinien hinaus. Eine GPO versucht vor allem, Einstellungen auf einem Windows-System durchzusetzen. Intune kann zusätzlich bewerten, ob ein Gerät bestimmte Anforderungen erfüllt. Über Compliance Policies lassen sich Regeln und Bedingungen definieren, anhand derer der Zustand verwalteter Geräte bewertet wird. Erfüllt ein Endpoint diese Anforderungen nicht, erhält er einen entsprechenden Compliance-Status. Damit entsteht neben der Konfiguration eine zweite Ebene: Konfiguration legt fest, wie ein Gerät eingestellt werden soll. Compliance bewertet, ob ein Gerät den erwarteten Zustand tatsächlich erfüllt.

Diese Unterscheidung wird besonders relevant, wenn der Compliance-Status anschließend über Microsoft Entra Conditional Access in eine Zugriffsentscheidung einfließt. Damit entwickelt sich die klassische Richtlinienidee weiter. Aus der zentralen Konfiguration eines Endpunkts entsteht zunehmend ein Regelkreis aus Konfigurieren, Bewerten und Reagieren.

Automatisierung ist kein neues Ziel

Auch Automatisierung gehört keineswegs erst zur Cloud-Ära. Bereits Gruppenrichtlinien automatisierten eine enorme Zahl administrativer Aufgaben. Netzlaufwerke konnten verbunden, Registry-Einstellungen gesetzt, Skripte ausgeführt, Software verteilt und Sicherheitseinstellungen angewendet werden. Der entscheidende Erfolg bestand darin, dass diese Aufgaben nicht mehr einzeln von Administrator:innen ausgeführt werden mussten.

Intune setzt diesen Gedanken fort und erweitert ihn. Neue Geräte können registriert, automatisch bestimmten Richtlinien zugeordnet, mit Anwendungen ausgestattet und anhand definierter Compliance-Regeln bewertet werden. Konfigurationen werden zentral verteilt und Änderungen anschließend über den Verwaltungsdienst synchronisiert. Damit bleibt das Ziel dasselbe: Wiederholbare Tätigkeiten sollen nicht von Menschen wiederholt werden müssen. Der Unterschied besteht im Umfang und in der Reichweite. Während Gruppenrichtlinien stark an die Domäne gekoppelt ist, kann cloudbasierte Automatisierung Endpunkte unabhängig von ihrem Standort erreichen.

Automatisierung wird zunehmend programmierbar

Moderne Plattformen erweitern dieses Prinzip zusätzlich durch Programmierschnittstellen. Intune lässt sich über Microsoft Graph in automatisierte Verwaltungsprozesse integrieren. Richtlinien, Gerätekonfigurationen und andere Verwaltungsobjekte können dadurch nicht nur über das Intune Admin Center, sondern auch programmatisch verarbeitet werden. Microsoft stellt entsprechende Intune-Ressourcen über Microsoft Graph bereit.

Damit verändert sich die Größenordnung möglicher Automatisierung. Administration kann zunehmend Teil von Infrastructure-as-Code-ähnlichen Prozessen, automatisierten Bereitstellungen oder zentralen Governance-Workflows werden. Auch hier gilt jedoch: Die Technologie ist neu, die Motivation nicht. Schon Gruppenrichtlinien sollten manuelle Arbeit reduzieren und Konfiguration reproduzierbar machen. Cloud-APIs setzen dieses Ziel lediglich auf einer weiteren Ebene fort. Aus automatisierter Richtlinienverarbeitung wird zunehmend eine automatisierbare Verwaltungsplattform.

Hybrid bedeutet nicht halbmodern

In der Realität erfolgt der Übergang zu moderner Geräteverwaltung selten auf einen Schlag. Viele Unternehmen besitzen erhebliche Investitionen in Active Directory, Gruppenrichtlinien und Configuration Manager. Gleichzeitig sollen neue Cloud-Funktionen genutzt werden. Microsoft unterstützt deshalb ausdrücklich parallele Verwaltungsmodelle. Beim Co-Management können Windows-Geräte gleichzeitig durch Configuration Manager und Microsoft Intune verwaltet werden. Bestimmte Workloads lassen sich dabei schrittweise in Richtung Intune verschieben, während andere weiterhin bei Configuration Manager verbleiben.

Auch Microsoft Entra Hybrid Join verbindet lokale Active-Directory-Mitgliedschaft mit einer Geräteidentität in Entra ID. Damit entsteht kein Übergang nach dem Muster: Gestern GPO, heute Intune. Vielmehr können klassische und moderne Verwaltungsmechanismen über längere Zeit nebeneinander bestehen. Gerade in großen Unternehmen ist das häufig keine Übergangsschwäche, sondern eine bewusste Architekturentscheidung.

Zwei Verwaltungsebenen verlangen klare Zuständigkeiten

Hybride Verwaltung bringt allerdings neue Herausforderungen mit sich. Wenn ein Gerät gleichzeitig Gruppenrichtlinien, Configuration Manager und Intune empfängt, muss klar definiert sein, welche Plattform für welchen Konfigurationsbereich zuständig ist. Andernfalls entsteht ein neues Problem: Nicht fehlende Verwaltung, sondern zu viele konkurrierende Verwaltungsinstanzen.

Eine Einstellung könnte beispielsweise über eine Gruppenrichtlinie einen bestimmten Wert erhalten und über Intune gleichzeitig anders konfiguriert werden. Solche Überschneidungen erhöhen die Komplexität der Fehleranalyse erheblich. Deshalb ist eine hybride Architektur nur dann langfristig beherrschbar, wenn Zuständigkeiten dokumentiert und Konfigurationen bewusst voneinander abgegrenzt werden. Microsoft verfolgt bei Co-Management genau diesen Ansatz. Einzelne Workloads können kontrolliert von Configuration Manager zu Intune verschoben werden, anstatt die gesamte Verwaltung gleichzeitig umzustellen.

In der Praxis hat sich darüber hinaus ein weiterer Grundsatz etabliert: Cloud first. Stehen für denselben Konfigurationsbereich sowohl eine klassische On-Premises-Verwaltung als auch eine moderne cloudbasierte Verwaltung zur Verfügung, sollte langfristig nur noch eine dieser Instanzen die fachliche Verantwortung übernehmen. Microsoft empfiehlt deshalb, Workloads schrittweise nach Intune zu verlagern und konkurrierende Konfigurationen nach Möglichkeit zu vermeiden.

Kommt es dennoch zu Überschneidungen, gilt bei zahlreichen modernen Verwaltungsfunktionen das Prinzip Cloud Policy wins beziehungsweise Cloud Policy takes precedence. Unterstützt eine Einstellung sowohl die klassische Gruppenrichtlinienverwaltung als auch die moderne MDM-Verwaltung, ist die cloudbasierte Richtlinie in vielen Fällen führend. Ziel dieses Verhaltens ist es, den schrittweisen Übergang in moderne Verwaltungsmodelle zu erleichtern und widersprüchliche Konfigurationen möglichst eindeutig aufzulösen. Unabhängig davon bleibt es jedoch eine bewährte Praxis, konkurrierende Richtlinien gar nicht erst entstehen zu lassen und für jeden Konfigurationsbereich eine eindeutige Verwaltungsinstanz festzulegen.

Evolution statt Ablösung

Betrachtet man die Entwicklung von Systemrichtlinien über Gruppenrichtlinien bis zu Microsoft Intune, fällt deshalb vor allem eines auf: Die grundlegenden Verwaltungsziele haben sich wesentlich weniger verändert als die Technologien zu ihrer Umsetzung. Konfiguration soll zentral erfolgen. Standards sollen reproduzierbar sein. Sicherheitsvorgaben sollen nicht von der manuellen Tätigkeit einzelner Administrator:innen abhängen. Vorlagen sollen Komplexität reduzieren. Automatisierung soll wiederkehrende Aufgaben übernehmen. Und unterschiedliche administrative Verantwortlichkeiten sollen in ein beherrschbares Gesamtmodell integriert werden.

Gruppenrichtlinien lösten diese Aufgaben für die klassische Active-Directory-Welt außergewöhnlich gut. Intune überträgt viele dieser Prinzipien auf eine Umgebung, in der Endpunkte über das Internet erreichbar sind, unterschiedliche Betriebssysteme einsetzen und ihr Sicherheitszustand unmittelbar in Zugriffsentscheidungen einfließen kann. Damit zeigt sich erneut: Microsoft hat die Grundidee zentraler Richtlinienverwaltung nicht aufgegeben. Das Unternehmen hat sie an eine neue technische Realität angepasst.

Was aus 25 Jahren Gruppenrichtlinien bleibt

Vielleicht liegt gerade darin die eigentliche Bedeutung der Gruppenrichtlinien für moderne Administrator:innen. GPOs sind nicht nur eine Technologie, die noch in vielen Active-Directory-Umgebungen eingesetzt wird. Sie haben auch Denkweisen etabliert, die weit über Active Directory hinausreichen. Richtlinien statt Einzelkonfiguration. Standardisierung statt individueller Systeme. Automatisierung statt wiederkehrender Handarbeit. Vorlagen statt unstrukturierter Einzeleinstellungen. Delegierte beziehungsweise klar abgegrenzte Verantwortung statt uneingeschränkter Administration. Diese Prinzipien finden sich heute in anderer technischer Form in Microsoft Intune wieder.

Die Control Plane hat sich verändert. Der Verwaltungsweg hat sich verändert. Selbst die Art, wie Geräte identifiziert und erreicht werden, hat sich verändert. Die grundlegende Erkenntnis ist dagegen geblieben: Professionelle Geräteverwaltung skaliert nur dann, wenn gewünschte Zustände zentral beschrieben, standardisiert verteilt und nachvollziehbar kontrolliert werden können. Genau deshalb sind Gruppenrichtlinien für das Verständnis von Modern Management auch dann noch relevant, wenn eine zukünftige Umgebung vollständig cloudnativ arbeitet.

Ausblick: Die Zukunft der Windows-Verwaltung

Wer die bisherige Entwicklung betrachtet, könnte zu einer einfachen Schlussfolgerung kommen: Auf Gruppenrichtlinien folgt Intune, auf Active Directory folgt Entra ID und irgendwann verschwindet die klassische Domäne vollständig. So geradlinig entwickelt sich Unternehmens-IT jedoch selten.

Auch im Jahr 2026 ist Active Directory Domain Services weiterhin ein regulärer Bestandteil von Windows Server. Microsoft unterstützt AD DS nicht nur, sondern hat die Plattform mit Windows Server 2025 erneut funktional, sicherheitstechnisch und hinsichtlich ihrer Skalierbarkeit weiterentwickelt. Windows Server 2025 besitzt sogar wieder eine neue Domänen- und Gesamtstrukturfunktionsebene. Das ist ein wichtiges Signal. Microsoft behandelt Active Directory nicht wie eine Technologie, die lediglich im Wartungsmodus weitergeführt wird. Gleichzeitig entwickelt das Unternehmen mit Microsoft Entra ID und Intune eine Verwaltungswelt, die ohne klassische Domänenmitgliedschaft auskommen kann.

Beide Entwicklungen finden parallel statt. Die Zukunft der Windows-Verwaltung lässt sich deshalb weniger mit Ablösung als mit einer zunehmenden Differenzierung der Aufgaben beschreiben.

Active Directory im Jahr 2026

Active Directory hat auch nach mehr als 25 Jahren Aufgaben, für die es weiterhin hervorragend geeignet ist. Unternehmensanwendungen verwenden Kerberos oder LDAP. Server benötigen klassische Maschinenidentitäten. Dateidienste greifen auf Benutzer:innen, Gruppen und Berechtigungen der Domäne zurück. Zahlreiche Fachanwendungen wurden für eine Active-Directory-basierte Infrastruktur entwickelt und lassen sich nicht ohne Weiteres auf ein reines Cloud-Identitätsmodell umstellen. Entsprechend unterstützt Microsoft AD DS auch unter Windows Server 2025 vollständig.

Der entscheidende Punkt ist jedoch: Active Directory muss nicht mehr zwangsläufig der Mittelpunkt jedes Verwaltungsprozesses sein. Ein Unternehmen kann beispielsweise weiterhin eine lokale Domäne für Server und bestehende Anwendungen betreiben, während neue Arbeitsplatzrechner Microsoft Entra joined sind und vollständig über Intune verwaltet werden. Damit verändert sich die Rolle des Verzeichnisdienstes. Aus der Plattform, um die nahezu die gesamte Unternehmens-IT organisiert wurde, wird zunehmend eine spezialisierte Infrastruktur für diejenigen Workloads, die ihre Funktionen tatsächlich benötigen.

Windows Server 2025 ist kein Abschiedssignal

Gerade Windows Server 2025 widerspricht der Vorstellung eines unmittelbar bevorstehenden Endes von Active Directory. Microsoft führte eine neue Windows Server 2025 Functional Level ein und erweiterte AD DS unter anderem um Verbesserungen hinsichtlich Skalierbarkeit und Sicherheit. Dazu gehört beispielsweise die optionale Unterstützung von 32-KB-Datenbankseiten. Darüber hinaus wurden verschiedene Sicherheitsmechanismen weitergehärtet. Beispielsweise schützt Windows Server 2025 vertrauliche Attribute stärker, indem bestimmte LDAP-Operationen nur noch über verschlüsselte Verbindungen zugelassen werden. Auch die Behandlung standardmäßiger Computerkonto-Kennwörter wurde verbessert.

Diese Entwicklungen sind bemerkenswert. Microsoft investiert weiterhin in eine Technologie, deren Grundarchitektur auf Windows 2000 zurückgeht, während parallel die Cloud-Identitätsplattform Entra ID kontinuierlich ausgebaut wird. Das wirkt nur dann widersprüchlich, wenn beide Systeme als direkte Konkurrenten betrachtet werden. Tatsächlich bedienen sie zunehmend unterschiedliche Anforderungen. Active Directory bleibt eine wesentliche Plattform für klassische und hybride Unternehmensressourcen. Entra ID übernimmt dagegen eine zentrale Rolle für cloudbasierte Identitäten, SaaS-Dienste und moderne Endpunkte.

Hybrid bleibt auf absehbare Zeit Realität

Der zunehmende Trend zu cloudnativen Endpunkten bedeutet jedoch nicht, dass hybride Verwaltungsmodelle kurzfristig an Bedeutung verlieren. Microsoft unterstützt weiterhin Microsoft Entra Hybrid Join. Dabei bleibt ein Windows-Gerät Mitglied des lokalen Active Directory und erhält zusätzlich eine Geräteidentität in Microsoft Entra ID. Auch Windows Autopilot unterstützt entsprechende hybride Bereitstellungsszenarien weiterhin. Damit können Unternehmen bestehende Abhängigkeiten von Active Directory erhalten und gleichzeitig Funktionen von Entra ID und Intune nutzen. Hybrid sollte allerdings nicht automatisch mit dem langfristigen Zielbild gleichgesetzt werden.

Die verschiedenen Hybrid-Szenarien sowie deren Auswirkungen auf Identität, Geräteverwaltung und Sicherheitsarchitektur habe ich im Beitrag Windows 11 im Modern Workplace: Identität, Geräteverwaltung und Sicherheit mit Entra ID und Intune ausführlich beleuchtet. Dort geht es insbesondere um die Frage, wie sich klassische Active-Directory-Infrastrukturen schrittweise mit Microsoft Entra ID und Intune verbinden lassen und welche Hybridmodelle sich für unterschiedliche Ausgangssituationen eignen.

Microsoft empfiehlt inzwischen ausdrücklich, neue cloudnative Endpunkte bevorzugt mit Microsoft Entra Join bereitzustellen. Für vollständig cloudnative Endpunkte betrachtet Microsoft Entra Hybrid Join typischerweise nicht als bevorzugte Option, weil weiterhin eine Verbindung zur lokalen Active-Directory-Infrastruktur benötigt wird. Damit erhält Hybrid eine differenzierte Rolle: Für bestehende Abhängigkeiten ist es weiterhin wertvoll. Für neue, vollständig cloudnative Geräte soll diese Abhängigkeit dagegen möglichst gar nicht erst entstehen.

Cloud-native bedeutet mehr als ‚ohne Domänencontroller‘

Microsoft beschreibt einen cloudnativen Windows-Endpunkt als Gerät, das Microsoft Entra joined, in Microsoft Intune registriert und vollständig aus der Cloud verwaltet wird. Eine klassische Active-Directory-Domänenmitgliedschaft oder lokale Verwaltungsinfrastruktur ist dafür nicht erforderlich. Das ist weit mehr als der Austausch einer Gruppenrichtlinie gegen ein Intune-Konfigurationsprofil.

Vielmehr verschiebt sich die gesamte Verwaltungsarchitektur. Microsoft Entra ID übernimmt die Geräteidentität, während Intune die zentrale Verwaltung bereitstellt. Für neue cloudnative Endpunkte empfiehlt Microsoft deshalb ausdrücklich den Microsoft Entra Join, da hierfür keine Verbindung zu lokalen Domänencontrollern oder anderen On-Premises-Diensten erforderlich ist.

Damit verändert sich eine über Jahrzehnte selbstverständliche Grundannahme der Windows-Verwaltung: Ein Unternehmenscomputer muss nicht mehr Mitglied einer klassischen Active-Directory-Domäne sein, um zentral verwaltet, abgesichert und vollständig in die Unternehmens-IT integriert zu werden.

Cloud-native ist trotzdem kein universelles Zielbild

Das bedeutet allerdings nicht, dass jedes Unternehmen kurzfristig vollständig cloudnativ werden sollte. Die technische Möglichkeit allein beseitigt keine bestehenden Abhängigkeiten. Lokale Dateiserver, Kerberos-basierte Anwendungen, Produktionssysteme, ältere Fachsoftware oder andere Infrastrukturkomponenten können weiterhin Active Directory voraussetzen. Auch regulatorische, organisatorische oder betriebliche Anforderungen können lokale Dienste erforderlich machen.

Die sinnvollere Frage lautet deshalb nicht: ‚Wann können wir Active Directory abschalten?‘, sondern: ‚Welche Dienste benötigen Active Directory tatsächlich noch und welche neuen Workloads können unabhängig davon aufgebaut werden?‘ Diese Betrachtung verhindert, dass historische Architekturentscheidungen automatisch auf neue Systeme übertragen werden.

Gerade bei neuen Endpunkten empfiehlt Microsoft inzwischen, bestehende On-Premises-Abhängigkeiten kritisch zu prüfen und Cloud-native Management als eigenständiges Zielbild zu betrachten. Damit entsteht häufig kein großer Migrationstag, sondern ein schrittweiser Wandel: Neue Geräte werden cloudnativ bereitgestellt, während ältere Systeme und Server zunächst weiterhin die klassische Infrastruktur nutzen.

Greenfield und Brownfield entwickeln sich unterschiedlich

Dadurch entstehen zwei sehr unterschiedliche Ausgangssituationen. In der IT-Architektur werden dafür häufig die Begriffe Greenfield und Brownfield verwendet. Greenfield bezeichnet vereinfacht eine Umgebung, die weitgehend ohne technische Altlasten neu aufgebaut werden kann. Brownfield beschreibt dagegen eine gewachsene Infrastruktur, bei der bestehende Systeme, Anwendungen, Prozesse und Abhängigkeiten berücksichtigt und weiterentwickelt werden müssen.

Eine neu gegründete Organisation kann heute beispielsweise von Beginn an mit Microsoft Entra ID, Intune, Microsoft 365 und SaaS-Anwendungen arbeiten. Vielleicht existiert dort niemals ein klassischer Domänencontroller. Das wäre ein typisches Greenfield-Szenario. Ein Unternehmen mit 20 oder 30 Jahren IT-Geschichte befindet sich dagegen eher auf der Brownfield-Seite. Dort existieren häufig mehrere Generationen von Anwendungen, Servern, Dateidiensten und Verwaltungsprozessen. Manche davon lassen sich problemlos modernisieren, andere bleiben aus technischen oder wirtschaftlichen Gründen noch viele Jahre bestehen.

Beide Organisationen verwenden möglicherweise Windows. Dennoch benötigen sie vollkommen unterschiedliche Architekturen und entsprechend unterschiedliche Übergangszeiten. Für ein Greenfield-Unternehmen ist Cloud-native möglicherweise der natürliche Ausgangspunkt. Für eine gewachsene Brownfield-Umgebung kann ein hybrides Modell dagegen über Jahre hinweg die wirtschaftlich und technisch sinnvollste Lösung bleiben. Das ist keine Rückständigkeit, sondern das Ergebnis unterschiedlicher technischer Abhängigkeiten. Die Zukunft der Windows-Verwaltung wird deshalb vermutlich nicht aus einem einzigen Microsoft-Referenzmodell bestehen, sondern aus mehreren Betriebsmodellen, die abhängig von Workload, Lebenszyklus und Unternehmensgeschichte nebeneinander existieren.

Gruppenrichtlinien verschwinden ebenfalls nicht plötzlich

Dasselbe gilt für die Gruppenrichtlinien. Solange Windows-Computer und insbesondere Windows-Server Mitglied einer klassischen Active-Directory-Domäne sind, bleiben GPOs ein leistungsfähiges Werkzeug für deren zentrale Konfiguration. Microsoft dokumentiert Group Policy weiterhin als Bestandteil aktueller Windows-Server- und AD-DS-Umgebungen. Gleichzeitig verschiebt sich bei neuen Clientbereitstellungen der Schwerpunkt zunehmend in Richtung Intune und Settings Catalog.

Daraus ergibt sich eine natürliche Arbeitsteilung. Bestehende Serverlandschaften und klassische Domänenclients können weiterhin über Gruppenrichtlinien verwaltet werden. Neue cloudnative Endpunkte erhalten ihre Konfiguration dagegen über Intune. Entscheidend ist deshalb weniger, welches Werkzeug gewinnt. Viel wichtiger ist eine nachvollziehbare Verwaltungsstrategie. Ein Unternehmen sollte wissen, welche Control Plane für welchen Endpoint und welchen Konfigurationsbereich zuständig ist. Damit kehren wir zu einer Erkenntnis des vorherigen Kapitels zurück: Technische Koexistenz ist vergleichsweise einfach. Saubere Governance bleibt die eigentliche Herausforderung.

Windows Declared Configuration: Aus dem Ausblick wird Technik

Die im vorherigen Exkurs beschriebene Entwicklung hin zu deklarativen Verwaltungsmodellen ist längst mehr als eine theoretische Zukunftsperspektive. Mit Windows Declared Configuration, kurz WinDC, verfolgt Microsoft bereits ein entsprechendes Modell für Windows-Geräte und bezeichnet es ausdrücklich als Desired State Device Configuration Model. Statt einzelne Konfigurationsoperationen nacheinander auszuführen, beschreibt die Verwaltung den gewünschten Zustand einer Ressource. Dieser Zielzustand wird an den Windows-Client übermittelt, der anschließend dafür verantwortlich ist, ihn herzustellen und aufrechtzuerhalten. Die zentrale Verwaltung muss damit nicht mehr jeden technischen Schritt detailliert orchestrieren, sondern kann stärker das erwartete Ergebnis definieren.

Technisch bedeutet dieser Ansatz keinen vollständigen Bruch mit der bisherigen Geräteverwaltung. Windows Declared Configuration baut weiterhin auf OMA-DM und SyncML auf. Microsoft ersetzt die vorhandene MDM-Architektur also nicht, sondern erweitert sie um eine deklarative Konfigurationsschicht. Auch darin zeigt sich ein Muster der bisherigen Entwicklung: Neue Verwaltungsmodelle entstehen häufig auf bestehenden technischen Grundlagen und entwickeln deren Möglichkeiten weiter.

Damit erhält die zuvor beschriebene Entwicklung eine konkrete technische Entsprechung. Systemrichtlinien setzten Einstellungen zu bestimmten Zeitpunkten. Gruppenrichtlinien ergänzten regelmäßige Verarbeitung und Wiederanwendung. MDM ermöglichte die Verwaltung internetbasierter Endpunkte. Deklarative Verfahren abstrahieren diese Mechanismen weiter und rücken den gewünschten Zustand selbst in den Mittelpunkt. Bei tausenden möglichen Einstellungen und unterschiedlichen Plattformen wird es zunehmend schwieriger, Geräteverwaltung ausschließlich als Summe einzelner Konfigurationsschritte zu verstehen. Entscheidend wird damit zunehmend der definierte Zielzustand und weniger jeder einzelne technische Schritt auf dem Weg dorthin.

Koexistenz statt Ablösung

Betrachtet man Active Directory, Gruppenrichtlinien, Entra ID, Intune und deklarative Verwaltung gemeinsam, zeichnet sich deshalb kein harter Technologieschnitt ab. Vielmehr entsteht eine mehrschichtige Verwaltungslandschaft. Active Directory bleibt dort relevant, wo klassische Domänenfunktionen benötigt werden. Gruppenrichtlinien verwalten weiterhin entsprechende Windows-Systeme. Entra ID übernimmt cloudbasierte Identitäten und Gerätebeziehungen. Intune wird zur zentralen Control Plane für moderne Endpunkte. Deklarative Verfahren entwickeln dieses Managementmodell in Richtung gewünschter Zustände weiter. Diese Ebenen können über Jahre gleichzeitig existieren.

Microsoft selbst unterstützt diese Koexistenz weiterhin, modernisiert Active Directory mit Windows Server 2025 und empfiehlt gleichzeitig Microsoft Entra Join als bevorzugtes Identitätsmodell für neue cloudnative Endpunkte. Gerade darin liegt vielleicht die wichtigste Erkenntnis für die kommenden Jahre: Die Zukunft besteht nicht darin, möglichst schnell alles Alte zu ersetzen. Sie besteht darin, für neue Anforderungen nicht automatisch alte Architekturentscheidungen zu wiederholen.

Aus ‚Wo befindet sich der Computer?‘ wird ‚Welchen Zustand erwarten wir?‘

Damit verändert sich auch ein letztes Mal die Leitfrage dieses Beitrags. Unter Windows NT lautete sie im Grunde: Wie verteilen wir eine Konfiguration auf unsere Computer? Mit Active Directory wurde daraus: Wo befindet sich das Objekt innerhalb unserer Verwaltungsstruktur und welche Richtlinien gelten dort? Mit Intune rückte eine andere Frage in den Mittelpunkt: Welches Gerät beziehungsweise welche Identität gehört zu welcher Zielgruppe und welche Anforderungen gelten dafür? Deklarative Verwaltung führt schließlich zu einer nochmals abstrakteren Perspektive: Welchen Zustand erwarten wir von diesem Endpunkt?

Genau diese Entwicklung zeigt, wie weit sich die Windows-Verwaltung seit den ersten System Policies verändert hat.  Die Werkzeuge, Protokolle und Plattformen wechseln. Das grundlegende Ziel bleibt jedoch bemerkenswert konstant: Geräte müssen zentral beschrieben, sicher konfiguriert und ihr Zustand nachvollziehbar kontrolliert werden können. Die Zukunft der Windows-Verwaltung wird deshalb vermutlich weniger durch die Frage geprägt sein, ob GPO oder Intune „gewinnt“. Entscheidend wird vielmehr sein, wie gut Unternehmen klassische und moderne Verwaltungsmodelle voneinander abgrenzen, schrittweise modernisieren und zu einer konsistenten Gesamtarchitektur verbinden.

Eine Architektur, die Generationen geprägt hat

Am Anfang dieses Beitrags stand eine vergleichsweise einfache Frage: Wie lassen sich dutzende, hunderte oder tausende Windows-Computer zentral, sicher und konsistent verwalten? Die Antworten darauf haben sich in den vergangenen drei Jahrzehnten erheblich verändert. Unter Windows NT boten Systemrichtlinien mit ihren rund 120 bis 130 Einstellungen erstmals die Möglichkeit, Konfigurationen zentral vorzugeben. NTConfig.pol, Poledit.exe und NETLOGON wirken aus heutiger Perspektive ausgesprochen einfach. Für die damalige Unternehmens-IT waren sie jedoch ein wichtiger Schritt weg von der individuellen Konfiguration einzelner Systeme.

Mit Windows 2000 veränderte Microsoft anschließend nicht nur die Richtlinienverwaltung, sondern deren gesamte Architektur. Active Directory schuf einen hierarchischen Verwaltungsraum aus Gesamtstrukturen, Domänen, Standorten und Organisationseinheiten. Gruppenrichtlinien wurden zu eigenständigen Objekten, konnten verknüpft, kombiniert und vererbt werden. Regelmäßige Aktualisierungen erhöhten Dauerhaftigkeit und Dynamik, während Client Side Extensions und Administrative Templates eine erweiterbare Architektur bereitstellten. Aus einer zentral bereitgestellten Richtliniendatei war eine umfassende Richtlinien-Infrastruktur geworden.

Gruppenrichtlinien waren eine Antwort auf ihre Zeit

Der langfristige Erfolg dieser Architektur lässt sich kaum von den Rahmenbedingungen ihrer Entstehungszeit trennen. Arbeitsplatzcomputer gehörten dem Unternehmen, standen überwiegend im Unternehmensnetz und hatten regelmäßig Kontakt zu einem Domänencontroller. Windows dominierte den Unternehmensdesktop. Identität, Geräteverwaltung, Anwendungen und Daten befanden sich häufig innerhalb desselben administrativen Vertrauensraums. Für genau diese Welt waren Active Directory und Gruppenrichtlinien hervorragend geeignet. Das erklärt zugleich, warum es zu kurz greift, Gruppenrichtlinien aus heutiger Perspektive als veraltet zu betrachten. Gruppenrichtlinien lösen ihre ursprüngliche Aufgabe auch 2026 noch ausgesprochen gut. Die Anforderungen an moderne Geräteverwaltung reichen inzwischen jedoch weit über diese ursprüngliche Aufgabe hinaus.

Homeoffice, Cloud Computing, BYOD, mobile Endgeräte und unterschiedliche Betriebssysteme haben die Grenzen des klassischen Unternehmensnetzes aufgelöst. Ein Gerät kann heute vollständig verwaltet werden, obwohl es niemals Mitglied einer lokalen Active-Directory-Domäne war und möglicherweise niemals das Unternehmensnetz betreten wird. Nicht die Gruppenrichtlinien sind daran gescheitert. Die Welt, für die sie entwickelt wurden, ist größer geworden.

Warum Gruppenrichtlinien weiterhin relevant bleiben

Deshalb verschwinden Gruppenrichtlinien auch nicht einfach mit der Einführung von Microsoft Intune. Active Directory bleibt insbesondere in gewachsenen Unternehmensumgebungen, bei Serverinfrastrukturen, klassischen Windows-Anwendungen und zahlreichen Kerberos- oder LDAP-basierten Diensten relevant. Windows Server 2025 unterstreicht dies deutlich: Microsoft entwickelt Active Directory Domain Services weiterhin funktional und sicherheitstechnisch weiter.

Wo Windows-Systeme Mitglied einer klassischen Domäne bleiben, besitzen auch Gruppenrichtlinien weiterhin einen klaren Anwendungsbereich. Sie sind tief in Windows und Active Directory integriert, skalierbar, erweiterbar und über Jahrzehnte betrieblich erprobt. Ihre Bedeutung geht jedoch über den praktischen Einsatz bestehender GPOs hinaus. Gruppenrichtlinien haben Generationen von Administrator:innen gelehrt, Konfiguration nicht als Eigenschaft einzelner Computer zu betrachten, sondern als zentral definierte, standardisierte und reproduzierbare Vorgabe. Diese Denkweise hat die Windows-Verwaltung nachhaltig geprägt.

Intune ist keine GPO in der Cloud

Gerade deshalb führt auch die häufig gestellte Frage nach dem Nachfolger der Gruppenrichtlinien in die falsche Richtung. Microsoft Intune ist keine Gruppenrichtlinienverwaltung, die Microsoft lediglich in ein Rechenzentrum verschoben hat. Intune entstand unter vollkommen anderen Voraussetzungen. Geräte müssen über das Internet erreichbar sein, unterschiedliche Plattformen sollen verwaltet werden und eine klassische Domänenmitgliedschaft darf keine zwingende Voraussetzung mehr darstellen.

Entsprechend unterscheiden sich die Architekturen grundlegend. An die Stelle von LDAP, SYSVOL und Client Side Extensions treten MDM-Protokolle, Configuration Service Provider und cloudbasierte Verwaltungsdienste. Entra ID stellt moderne Geräte- und Benutzeridentitäten bereit, während Intune Konfiguration, Compliance und weitere Endpoint-Management-Funktionen zusammenführt.

Trotzdem begegnen uns viele bekannte Grundideen erneut. Richtlinien ersetzen Einzelkonfiguration. Standards schaffen reproduzierbare Systeme. Administrative Templates beschreiben Einstellungen. Security Baselines bündeln Empfehlungen. Automatisierung reduziert wiederkehrende Arbeit. Microsoft hat die Grundidee zentraler Richtlinienverwaltung nicht aufgegeben. Das Unternehmen hat sie an eine neue technische Realität angepasst.

Weiterentwicklung statt einfacher Ablösung

In diesem Sinne lässt sich Intune durchaus als Weiterentwicklung verstehen, allerdings nicht als nächste Version der Gruppenrichtlinien. Weiterentwickelt wurde vielmehr die Idee zentraler Geräteverwaltung. GPOs beantworten diese Aufgabe innerhalb einer verzeichnisgestützten Windows-Domäne. Intune überträgt sie auf internetbasierte, mobile und plattformübergreifende Endpunkte. Compliance und Conditional Access erweitern die reine Konfiguration zusätzlich um die Bewertung des Gerätezustands und dessen Einbeziehung in Zugriffsentscheidungen.

Mit deklarativen Verwaltungsmodellen zeichnet sich bereits die nächste Entwicklungsstufe ab. Statt immer mehr einzelne Einstellungen und Verarbeitungsschritte zu orchestrieren, rückt zunehmend der gewünschte Zustand eines Endpunkts in den Mittelpunkt. Damit setzt sich ein Muster fort, das uns durch den gesamten Beitrag begleitet hat: Neue Technologien ersetzen ihre Vorgänger nicht zwangsläufig vollständig. Vielmehr reagieren sie auf Anforderungen, für die bestehende Architekturen ursprünglich nicht geschaffen wurden.

Koexistenz ist kein Widerspruch

Deshalb dürfte die Windows-Verwaltung noch lange aus mehreren Welten bestehen. Ein neuer cloudnativer Arbeitsplatz kann mit Microsoft Entra ID und Intune vollständig ohne klassische Domänenmitgliedschaft auskommen. Gleichzeitig kann im selben Unternehmen eine Serverlandschaft existieren, die weiterhin Active Directory und Gruppenrichtlinien benötigt. In Brownfield-Umgebungen kommen hybride Modelle hinzu, während Greenfield-Organisationen möglicherweise niemals einen eigenen Domänencontroller betreiben werden.

Keine dieser Architekturen ist allein aufgrund ihres Alters moderner oder rückständiger. Entscheidend ist vielmehr, ob sie zu den jeweiligen Anforderungen passt. Problematisch wird es erst, wenn historische Architekturentscheidungen ungeprüft auf neue Anforderungen übertragen werden oder moderne Technologien allein deshalb eingeführt werden, weil sie neuer sind. Modernisierung bedeutet nicht, möglichst viel Bestehendes zu ersetzen. Sie bedeutet, für eine konkrete Aufgabe die passende Architektur zu wählen.

Von NTConfig.pol zum gewünschten Zustand

Blicken wir noch einmal auf die gesamte Entwicklung zurück, ist die Strecke bemerkenswert. Aus einer zentral bereitgestellten NTConfig.pol wurde mit Active Directory eine hierarchische Richtlinienarchitektur. Aus der Bindung an Domäne und Unternehmensnetz entwickelte sich mit MDM und Intune eine cloudbasierte Verwaltung verteilter Endpunkte. Und aus der Konfiguration immer zahlreicherer Einzelrichtlinien entwickelt sich zunehmend die Idee, gewünschte Zustände deklarativ zu beschreiben.

Die Werkzeuge haben sich verändert. Die Protokolle haben sich verändert. Selbst die Vorstellung davon, wo sich ein Unternehmenscomputer befinden muss, hat sich grundlegend verändert. Das administrative Ziel ist dagegen erstaunlich konstant geblieben: Professionelle Geräteverwaltung skaliert nur dann, wenn gewünschte Zustände zentral beschrieben, standardisiert verteilt und nachvollziehbar kontrolliert werden können.

Vor rund 30 Jahren waren Systemrichtlinien Microsofts erste Antwort auf diese Herausforderung. Gruppenrichtlinien machten daraus eine Architektur, die Generationen von Windows-Administrator:innen geprägt hat. Intune überträgt viele ihrer Grundideen in eine neue technische Welt. Und vermutlich wird auch die nächste Generation der Geräteverwaltung wieder versuchen, dieselbe alte Frage unter neuen Voraussetzungen zu beantworten: Wie verwalten wir tausende Endpunkte möglichst zentral, sicher und konsistent?

Quellenangaben

(Abgerufen am 13.08.2026)