Richtlinien werden gecached vs GPO Caching - Mythos #3
Richtlinien werden gecached? Nein!
Immer wieder taucht die Floskel auf, das Richtlinien gecached werden und die Personen verbinden damit die Idee, das Werte am Client "irgendwie" bevorratet werden.
Richtlinien sind importierte Werte und immer aktiv, solange keiner was anderes definiert. Es gibt keinen Cache. Punkt.
Wären Richtlinien gecached, wären sie flüchtig und nach Neustart/Reboot oder Sitzungsende nicht mehr vorhanden. Der Begriff ist schlicht falsch und hat nichts mit der Technik zu tun. Vermeidet ihn bitte.
Der Computer oder Benutzer übernimmt die Richtlinien und schreibt die Werte je nach Komponente (Client Side Extension) in den definierten Speicherort der CSE. Das kann die Registry sein, das kann eine Sicherheitsdatenbank sein, das kann eine kopierte Datei sein etc.
Diese Werte bleiben "für immer" erhalten und zwar solange, bis ein Domänen Controller kontaktiert wird, der neuere Informationen zu dem Wert hat. Solange die Änderung nicht authorisiert ist, solange ist da nichs flüchtiges an Richtlinien. Natürlich sind die Werte auch gültig, wenn der Client offline startet oder Zuhause eingeschaltet wird. Die Werte sind da und aktiv. Kein Cache, kein Zauberwerk. Der Schalter ist an oder der Schalter ist aus. Fertig.
GPO Caching
GPO Caching ist kein Cache der Werte, sondern ein Cache der zu übernehmenden Richtlinien (GPOList) aus dem Sysvol des AD auf dem lokalen Client. Mit diesem im Hintergrund erstellten Speicher kann eine Verarbeitung der Richtlinien unter einer langsamen Verbindung performanter gestaltet werden. Der Client holt sich praktisch nicht die Daten life aus dem AD, sondern aus seinem Lokalen Cache. Der Nachteil ist, das der Cache unter Umständen veraltet ist. Er wird nur im Hintergrund aktualisiert und es braucht ein gpupdate, gpupdate /force zur Laufzeit, bis die Kopie der neuen Richtlinien aus dem SYSVOL am Client ankommen und der Cache aktuell ist.
Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinie
Zwischenspeichern von Gruppenrichtlinien konfigurieren
GPO SYSVOL Cache Speicherort:
C:\Windows\System32\GroupPolicy\DataStore\0\sysvol\name-eurer.dom\Policies
Wann wird der lokale GPO Cache des SYSVOLs verwendet?
Aus dem Explain: Wenn Sie diese Richtlinieneinstellung aktivieren oder nicht konfigurieren, werden Richtlinieninformationen von der Gruppenrichtlinie nach jeder Hintergrundverarbeitungssitzung zwischengespeichert [...] Wenn die Gruppenrichtlinie im synchronen Vordergrundmodus ausgeführt wird, wird auf diesen Cache verwiesen, um eine schnellere Ausführung zu ermöglichen.
Die Antwort der Frage wirft direkt Fragen auf, es braucht mehr Antworten:
- Per Default ist der Cache aktiv. Er wird aktuell gehalten, aber kaum verwendet.
- Der unmanipulierte Rechner Start ist asynchron, solange es nicht von einer GPO oder CSE anders verlangt wird.
- Bei jedem gpupdate Prozess zur laufenden Sitzung wird der Cache aktualisiert. Praktisch alle 90 Minuten +-30 (Zeiten können individuell abweichen) oder manuell ausgelöst.
- Der Cache wird nur bei einem SYNCHRONEN Start/Anmelde Prozess verwendet.
- Synchron heisst, der im Hintergrund laufende gpupdate Prozess hat festgestellt, das eine CSE ihren Job VOR Sitzungserstellung ausführen muss. Die Meldung kennt ihr von gpupdate /force, das euch mitteilt, das neugestartet werden muss oder der User sich erneut anmelden soll. Synchron = Zeitlich aufeinander abgestimmt. Erst GPO, GPO Verarbeitung, Sitzungserstellung, dann Explorer Start und andere Jobs.
- Bekannte Kanditaten für sogenannte reine Vordergrund Verarbeitungen sind: Ordnerumleitung und Softwareverteilung (GPSI) und ein paar weitere, die keiner benutzt (IPsec, DiskQuota etc).
- Skripte stellen einen Sonderfall dar. Sie laufen nur im Vordergrund, erzwingen aber keinen Synchronen Prozess im obigen Sinne.
ACHTUNG! Wer hat aus XP Zeiten die Richtlinie aktiviert?
Computerkonfiguration\Administrative Vorlagen\System\Anmelden
Beim Start des Computer und bei der Anmelding immer auf das Netzwerk warten = Aktiviert
[...] Mit dieser Richtlinieneinstellung wird festgelegt, ob die Gruppenrichtlinienverarbeitung synchron erfolgt [...]
Diese Richtlinie setzt "SyncForegroundPolicy" = "1" und damit ist JEDER START! des Rechner synchron im Sinne der Verwendung des GPO Cachings.
Fehlerfalle, Beispiel Scenario:
Der Administrator ändert einige Werte der GPO und erwartet nach Neustart Änderungen am Client. Der Administrator ist ungeduldig und hat zum Test den Rechner direkt neugestartet. Dummerweise ohne den gpupdate Hintergrund Prozess abzuwarten. Dadurch ist der lokale Cache noch nicht aktualisiert worden. Durch "SyncForegroundPolicy" = "1" muss der Client seine veraltete Lokale Version lesen.
Es benötigt entweder Zeit und warten, oder ein manuelles gpupdate und dann reboot. Das händisch ausgeführte gpupdate ist technisch ein Hintergrundprozess. Dieser aktualisiert den Cache und beim Reboot werden jetzt die lokal aktualisierten/aktuellen Richtlinien angewendet.
Storch bringt Kinder Phänomen:
Im obigen Beispiel macht der Administrator dann irgendwann ein "gpupdate /force" und stellt fest: Jetzt gehts. Der Lerneffekt ist, immer ein gpudpate /force machen, weil es sonst nicht geht. Tatsächlich hätte er nur auf das Update Interval warten müssen, welches er durch gpupdate selber ausgelöst hat. Oder er sollte die XP Richtlinie wegwerfen.
Wer die Problem umgehen möchte hat 2 Möglichkeiten: Entweder die Richtlinie des GPO Cachings explizit deaktivieren oder die Warten auf das Netzwerk nicht konfigurieren oder deaktivieren.
Lokale Gruppenrichtlinie, eine kleine Besonderheit:
Werden Lokale Richtlinien in einem AD verwendet, dann kommen diese ohne Kontakt zum Domänen Controller nicht zum Einsatz. Der normalen Ablauf der Richtlinien erfolgt nach L-S-D-OU (Lokal, Site, Domäne, OU, Unter OU, Unter Unter OU usw.). Es kommt zu einem Merge aller Richtlinien nach dem Prinzip Last Writer Wins. Theoretisch kann ein Benutzer mit lokalen Administratorrechten Werte in seiner Lokalen Gruppenrichtlinien definieren, die denen der Firma widersprechen. Dieses gilt es zu verhindern. Ist der Client mit dem AD verbunden, dann kann ein Richtlinien Editor im AD mit seinen Domänen Einstellungen immer gegensteuern und aufgrund von LSDOU und Last Writer Wins, den Wert negieren. Ohne AD/DC kann der Wert nicht korrigiert werden, das AD kann nicht gegensteuern, sodass der GPO Prozess ohne AD/DC die Lokale Richtlinie ignoriert.