Fachartikel

Troubleshooting von Gruppenrichtlinien (1)

Gruppenrichtlinien sind schon seit Windows NT ein ebenso mächtiges wie bewährtes Instrument der zentralen Konfigurationsverwaltung in Windows-Umgebungen. Trotz einiger Bemühungen seitens Microsoft und ihrer Marktbegleiter, alternative Verwaltungsmechanismen für Windows anzubieten, können wir getrost davon ausgehen, dass uns die GPOs noch eine ganze Weile erhalten bleiben werden. Umso wichtiger ist es, Probleme bei Gruppenrichtlinien und deren Anwendung rechtzeitig zu erkennen und zielgerichtet zu beheben. Im ersten Teil des Workhops beschäftigen wir uns vor allem mit dem "Resultant Set of Policy" und der Arbeit mit GPRESULT.EXE.
Funktioniert eine Gruppenrichtlinie nicht wie gedacht, kann das auf den Clients schnell zu Problemen führen.
Wenn irgendetwas im Bereich der Gruppenrichtlinien nicht stimmt, erkennen Sie das in der Regel nicht unmittelbar. Abgesehen von dem Teil mit Benutzer- und Maschinenskripten, dienen Gruppenrichtlinien der Erzwingung von Konfigurationsvorgaben. Es gibt in Windows jedoch leider keinen "Compliance-Indikator", der anzeigen würde, ob die momentane Konfiguration der vorgegebenen entspricht – und erst recht keinen, der die derzeitige Konfiguration unabhängig von der Anwendung der Gruppenrichtlinien untersuchen würde. Daher fallen Probleme mit Gruppenrichtlinien meist erst dadurch auf, dass die Benutzerumgebung "sich verstellt" oder Anwendungen sich anders verhalten als am Tag zuvor. Und weil Gruppenrichtlinien so mächtig sind und eine so zentrale Rolle spielen, sind natürlich gleich viele, wenn nicht gar alle User betroffen. Da sind gute Nerven und präzises, zielgerichtetes Handeln gefragt.

Probleme klassifizieren
Haben Sie ein Phänomen festgestellt, bei dem Sie die Gruppenrichtlinien als Ursache vermuten, müssen Sie es zunächst richtig klassifizieren. Ihr Problem wird in eine der folgenden Kategorien fallen:

  • Es werden offenbar die gewünschten Einstellungen auf die Endgeräte angewandt, sie haben aber dort nicht die erwartete Wirkung.
  • Mit der Anwendung der Gruppenrichtlinien auf die betroffenen Benutzer und Computer ist anscheinend alles in Ordnung, aber es kommen nicht die erwarteten Einstellungen auf den Endgeräten an.
  • Es werden nicht alle vorgesehenen Gruppenrichtlinien angewandt oder das Verhalten ist nicht einheitlich.
  • Es werden anscheinend gar keine Gruppenrichtlinien mehr angewandt.
Die Klassifizierung können Sie nach dieser Skala von oben nach unten oder von unten nach oben durchführen: Entweder Sie kennen das Zusammenspiel der aktuell betroffenen Applikation oder Windows-Funktion mit den Policy-Einstellungen und beginnen die Untersuchung damit, dass Sie direkt nachschauen, welche Werte an den relevanten Stellen in der Registry stehen (Beispiel: Bei Problemen mit WSUS könnte sich ein Blick auf die Werte im Schlüssel "HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Windows \ WindowsUpdate" lohnen). Oder Sie verlassen sich vorerst darauf, dass auf dem Endgerät alle empfangenen Policy-Einstellungen richtig interpretiert werden, und prüfen, ob der vorgesehene Satz an Richtlinien tatsächlich ausgeliefert wurde.

Was zu tun ist, wenn eine Applikation die korrekten Einstellungen falsch oder gar nicht verarbeitet, ist sehr individuell und nicht Gegenstand dieses Artikels. Alle anderen Fälle können mithilfe einer strukturierten Herangehensweise meistens schnell geklärt werden.
Überblick gewinnen mit RSoP
Das Werkzeug der Wahl, um die Erstklassifikation vorzunehmen, ist das "Resultant Set of Policy" (RSoP). In diesem können Sie sofort sehen, welche Richtlinien überhaupt für die Anwendung in Frage kamen (aus Bindungen an Domäne, OUs oder Sites), welche tatsächlich angewandt und welche abgelehnt wurden (und warum) sowie welche Einstellungen dabei herausgekommen sind. Hier spielen neben dem Ort der Bindung auch die Reihenfolge, die Loopback-Verarbeitung sowie die Erzwingung der Gruppenrichtlinien eine Rolle.

Zum RSoP gelangen Sie auf drei Wegen, in allen Fällen muss das betroffene System jedoch laufen. Wollen Sie die Benutzereinstellungen untersuchen, so muss der jeweilige Benutzer interaktiv angemeldet sein. Wenn der Benutzer nicht "greifbar" ist, können Sie immerhin die Daten seiner letzten Sitzung erhalten. Dafür muss er am betroffenen System ein vollständiges Benutzerprofil hinterlassen haben. Gerade bei der Erstdiagnose ist hier jedoch Vorsicht geboten, denn es könnte ja sein, dass zum Zeitpunkt seiner letzten Sitzung alles noch in Ordnung war.



Seite 1 von 2 Nächste Seite >>
9.03.2020/dr/ln/Evgenij Smirnov

Nachrichten

Alles Gute zum Sysadmin Day! [31.07.2020]

Die Redaktion des IT-Administrator wünscht allen Administratoren einen wunderbaren Sysadmin Day!  [mehr]

Innenansichten [31.07.2020]

Mit ObserveIT stellt Proofpoint seine neue cloudbasierte Plattform für das Insider Threat Management (ITM) vor. Das Produkt tritt an, um Unternehmen bei der Erkennung von Insiderrisiken und der beschleunigten Reaktion auf Vorfälle zu helfen. [mehr]

Heißgekühlt [29.07.2020]

Tipps & Tools

Windows-Insider-Programm ohne Konto nutzen [8.08.2020]

Lange Zeit war der Zugang zu den Windows-Vorabversionen, sogenannten "Insider-Builds", nur für Entwickler verfügbar. Seit 2014 haben alle Benutzer über das Windows-Insider-Programm die Möglichkeit, die Vorabversionen zu testen. Voraussetzung ist allerdings ein Microsoft-Konto, das nicht jeder eröffnen will. Mit dem Skript "OfflineInsiderEnroll" erhalten Sie die Insider-Builds auch ohne Registrierung. [mehr]

Download der Woche: Microsoft Remote Desktop für macOS [5.08.2020]

Wenn Sie mit einem Macbook arbeiten und Remotezugriff auf einen Windows-Rechner oder Workspace benötigen, kann "Microsoft Remote Desktop für macOS" weiterhelfen. In Version 10 der kostenfreien Software hat der Hersteller sich vor allem der Oberfläche gewidmet, um die Bedienung möglichst einfach zu gestalten. [mehr]

Buchbesprechung

Microsoft Office 365

von Markus Widl

Anzeigen