9
GPO: Zentraler Speicher
Guten Tag zusammen,
ich beschäfte mich aktuell intensiv mit der GPO und deren Administierungsmöglichkeiten und stoße dabei gedanklich immer wieder auf folgende Frage:
Was ist der Unterschied, ob ein zentraler Speicher vorhanden ist oder nicht. Angenommen wir justieren die Einstellungen innerhalb der administrativen Vorlagen.
Frage 1:
Ich verstehe, dass wenn ein Zentraler Speicher vorhanden ist und ein Client eine GPO verarbeitet, er zunächst nachschaut, ob diese zentral verfügbar ist.
Falls Ja, liest er diese vom zentralen Speicher aus ein. Seine lokalen administrative Vorlagen lässt es außen vor.
Wenn nun aber kein zentraler Speicher vorhanden ist, dann liest der DC die administrativen Vorlagen vom GPO lokal bei sich aus. Bedeutet, dass einfach das der Client dann auf den lokalen Pfad des DCs der *.admx - Files zugreift?
Wenn wir nun zwei DCs hätten, wo sich Clients anmelden können....es kein zentralen Speicher gäbe...jedoch bei einem Client die lokalen *.admx-Files geupdatet worden und beim Anderen nicht -> Entsprechend unterschiedliche Administrative Vorlagen - Einstellungen geben -> Wodurch wir keine einheitliche Verarbeitung der Richtlinien bei unseren Clients hätten....
Antwort zu 1?
Damit es immer einen einheitlichen Standard der admx-File gibt, werden diese über die DCs im entsprechenden Verzeichnis repliziert. Bei der Verarbeitung der GPO spielt es für den Client keine Rolle, ob es einen zentralen Speicher vorhanden ist oder nicht. Seine eigenen lokalen administrativen Vorlagen werden nie genutzt, wenn er in einer Umgebung verwaltet wird, sondern nutzt die administrativen Vorlagen, an der entsprechend konfigurierten Stelle?
Unverständlichkeit:
Wenn kein zentraler Speicher vorhanden ist, würde der DC auf seine lokalen admin. Vorlagen zugreifen. Soweit so gut.
Anders müsste die Logik der der Verarbeitung des Clients zugehen, denn dieser sollte unter keinen Umständen, auf seine eigenen lokalen administrativen Vorlagen zugreifen. Also auch wenn der DC seine eigenen nutzt, sollte der Client auf jeden Fall diese Einstellungen nutzen.
Oder könnte es sein, dass er die vorgegeben lokalen administrativen Vorlagen des DCs die lokalen administrativen Vorlagen des Client überschreiben, und damit die "richtigen" konfigurierten Einstellungen herausgelesen werden.
Weil wenn man einen Client öffnet, der nicht vom CentralStore ausliest, steht dort dass der Client die GPOs lokal ausliest.
Kurzer Hintergrund der Geschichte:
Es geht darum dass ich Windows 11 per GPO verbieten möchte in der Domäne. Es sind aber nur die Hälfte der Clients auf 21H2
Und versuche erstmal die Grundmechanik zu verstehen :D
Aber eben ich hab überlegt, ob es einen Unterschied macht, ob man jetzt extra ggfs. einen CentralStore erzeugen sollte oder nicht.
Überdachte Antwort:
Da mehrere DCs im Einsatz sind, müssen die ADMX-Dateien überall gleichzeitig upgedatet werden, daher um den Verwaltungsaufwand zu reduzieren, würde ich es logischer und pflegeleichter und wie oben erklärt konsistenter finden, wenn man kurzer Hand einen zentralen Speicher definiert und darüber administriert.
Ich hoffe, dass ich es klar genug beschrieben habt und es nicht total out of space von der Beschreibung her klingt :D
Danke und schönen Tag wünsche ich euch
B33r3
Hoffe ihr könnt ein bisschen Licht ins Dunkeln bringen :D
ich beschäfte mich aktuell intensiv mit der GPO und deren Administierungsmöglichkeiten und stoße dabei gedanklich immer wieder auf folgende Frage:
Was ist der Unterschied, ob ein zentraler Speicher vorhanden ist oder nicht. Angenommen wir justieren die Einstellungen innerhalb der administrativen Vorlagen.
Frage 1:
Ich verstehe, dass wenn ein Zentraler Speicher vorhanden ist und ein Client eine GPO verarbeitet, er zunächst nachschaut, ob diese zentral verfügbar ist.
Falls Ja, liest er diese vom zentralen Speicher aus ein. Seine lokalen administrative Vorlagen lässt es außen vor.
Wenn nun aber kein zentraler Speicher vorhanden ist, dann liest der DC die administrativen Vorlagen vom GPO lokal bei sich aus. Bedeutet, dass einfach das der Client dann auf den lokalen Pfad des DCs der *.admx - Files zugreift?
Wenn wir nun zwei DCs hätten, wo sich Clients anmelden können....es kein zentralen Speicher gäbe...jedoch bei einem Client die lokalen *.admx-Files geupdatet worden und beim Anderen nicht -> Entsprechend unterschiedliche Administrative Vorlagen - Einstellungen geben -> Wodurch wir keine einheitliche Verarbeitung der Richtlinien bei unseren Clients hätten....
Antwort zu 1?
Damit es immer einen einheitlichen Standard der admx-File gibt, werden diese über die DCs im entsprechenden Verzeichnis repliziert. Bei der Verarbeitung der GPO spielt es für den Client keine Rolle, ob es einen zentralen Speicher vorhanden ist oder nicht. Seine eigenen lokalen administrativen Vorlagen werden nie genutzt, wenn er in einer Umgebung verwaltet wird, sondern nutzt die administrativen Vorlagen, an der entsprechend konfigurierten Stelle?
Unverständlichkeit:
Wenn kein zentraler Speicher vorhanden ist, würde der DC auf seine lokalen admin. Vorlagen zugreifen. Soweit so gut.
Anders müsste die Logik der der Verarbeitung des Clients zugehen, denn dieser sollte unter keinen Umständen, auf seine eigenen lokalen administrativen Vorlagen zugreifen. Also auch wenn der DC seine eigenen nutzt, sollte der Client auf jeden Fall diese Einstellungen nutzen.
Oder könnte es sein, dass er die vorgegeben lokalen administrativen Vorlagen des DCs die lokalen administrativen Vorlagen des Client überschreiben, und damit die "richtigen" konfigurierten Einstellungen herausgelesen werden.
Weil wenn man einen Client öffnet, der nicht vom CentralStore ausliest, steht dort dass der Client die GPOs lokal ausliest.
Kurzer Hintergrund der Geschichte:
Es geht darum dass ich Windows 11 per GPO verbieten möchte in der Domäne. Es sind aber nur die Hälfte der Clients auf 21H2
Und versuche erstmal die Grundmechanik zu verstehen :D
Aber eben ich hab überlegt, ob es einen Unterschied macht, ob man jetzt extra ggfs. einen CentralStore erzeugen sollte oder nicht.
Überdachte Antwort:
Da mehrere DCs im Einsatz sind, müssen die ADMX-Dateien überall gleichzeitig upgedatet werden, daher um den Verwaltungsaufwand zu reduzieren, würde ich es logischer und pflegeleichter und wie oben erklärt konsistenter finden, wenn man kurzer Hand einen zentralen Speicher definiert und darüber administriert.
Ich hoffe, dass ich es klar genug beschrieben habt und es nicht total out of space von der Beschreibung her klingt :D
Danke und schönen Tag wünsche ich euch
B33r3
Hoffe ihr könnt ein bisschen Licht ins Dunkeln bringen :D
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3027217304
Url: https://administrator.de/forum/gpo-zentraler-speicher-3027217304.html
Ausgedruckt am: 25.12.2024 um 16:12 Uhr
9 Kommentare
Neuester Kommentar
Die DCs syncronisieren die GPO. Welcher DC genutzt wird ist nicht unbedingt zufällig, das wird über Subnetze geregelt.
Die GPOs habe eine Versionierung. Auch eine lokale Kopie hat eine Version
Ansonsten gehört dieses Thema zu den Themen mit sehr vielen Missverständnissen und Märchen.
Die GPOs habe eine Versionierung. Auch eine lokale Kopie hat eine Version
Ansonsten gehört dieses Thema zu den Themen mit sehr vielen Missverständnissen und Märchen.
Edit:
Quelle: https://activedirectorypro.com/configure-group-policy-central-store/
Group Policy Central Store Benefits
1 Ensures all admins are using the same group policy template files
2 Loads the same template files from any computer
3 Makes it easier to manage and update template files by having only one location to update
4 Reduces template files in the sysvol and reduces replication traffic between domain controllers
Punkt 4 - Sysvol wird doch erst mit der Nutzung vom Zentralen Speicher genutzt? Wieso wird Replikationstraffic verringert, könnt ihr mir das plastischer erklären vielleicht? Das wäre super toll! Danke schon mal
Und um eine kleine Frage nochmal herauszukristalliseren, wird das admx File vom GPO-Client quasi einfach herausgelesen vom lokalen Pfad der administrativen Vorlagen bzw. vom zentralen Speicherpunkt des DCs? Ich schätze der Client greift nur zum Lesen drauf zu und mehr nicht? Seine eigenen lokalen ADMX. Dateien bleiben immer unangerührt, - richtig?
Quelle: https://activedirectorypro.com/configure-group-policy-central-store/
Group Policy Central Store Benefits
1 Ensures all admins are using the same group policy template files
2 Loads the same template files from any computer
3 Makes it easier to manage and update template files by having only one location to update
4 Reduces template files in the sysvol and reduces replication traffic between domain controllers
Punkt 4 - Sysvol wird doch erst mit der Nutzung vom Zentralen Speicher genutzt? Wieso wird Replikationstraffic verringert, könnt ihr mir das plastischer erklären vielleicht? Das wäre super toll! Danke schon mal
Und um eine kleine Frage nochmal herauszukristalliseren, wird das admx File vom GPO-Client quasi einfach herausgelesen vom lokalen Pfad der administrativen Vorlagen bzw. vom zentralen Speicherpunkt des DCs? Ich schätze der Client greift nur zum Lesen drauf zu und mehr nicht? Seine eigenen lokalen ADMX. Dateien bleiben immer unangerührt, - richtig?
Moin,
Einmal ausführlich, bevor ich auf deine Fragen genau eingehe:
Die Frage ist recht einfach. Wenn du keinen zentralen Speicher hast, dann nutzt jeder DC seinen lokalen Speicher. Hast du nun auf DC01 und auf DC02 unterschiedliche ADMX-Files hinterlegt, dann hast du entsprechend unterschiedliche Einstellungen, die du verwalten kannst. Beispiel: Printnightmare. Legst du die ADMX von https://www.faq-o-matic.net/2021/07/07/adm-und-admx-fr-cve-2021-34527-pr ... nur auf DC01 ab, dann hast du dort in der GPO die Konfigurationsmöglichkeit. Öffnest du die konfigurierte GPO nun auf dem DC02, dann sagt dir die GPO-Verwaltung, dass er einen Eintrag auf Grund der fehlenden ADMX nicht angezeigt werden kann.
Meldet sich jetzt ein Client an und ruft die GPO vom DC02 ab, so wird die Konfiguration dennoch korrekt ausgeführt. Diese wurde im Hintergrund synchronisiert, wie @2423392070 schon geschrieben hat.
Ein zentraler Speicher sorgt also nur dafür, dass du nicht händisch die ADMX-Dateien auf den DCs mehrfach aktualisieren musst, sondern überall die gleiche ADMX zur Verfügung hast. Auch hilft der zentrale Speicher dabei, wenn du die DCs irgendwann ersetzt. Neu installierte DC haben dann ja immer den Installationsstandard. Durch den zentralen Speicher haben auch die neuen DCs dann gleich deine aktuellen ADMX-Tempaltes zur Verfügung.
Wie du den Einrichtest, findest du hier: https://docs.microsoft.com/de-de/troubleshoot/windows-client/group-polic ...
Für deine Windows 10/11 Clients ist es völlig egal ob du mit einem Zentralen Speicher arbeitest oder nicht. Der Zentrale Speicher ist lediglich für die DCs interessant.
Die Clients holen sich ihre Einstellungen aus: \\Domäne\SYSVOL\LO.LOCAL\Policies\{GPO-ID}
Die DCs holen sich ihre Definitionen wenn vorhanden aus: \\Domäne\SYSVOL\LO.LOCAL\Policies\PolicyDefinitions
Ist der Order bei den DCs nicht vorhanden, greifen sie auf die lokalen zu. Die Clients greifen nicht auf die Policy-Definitions zu
Gruß
Doskias
Zitat von @blaub33r3:
Was ist der Unterschied, ob ein zentraler Speicher vorhanden ist oder nicht. Angenommen wir justieren die Einstellungen innerhalb der administrativen Vorlagen.
Was ist der Unterschied, ob ein zentraler Speicher vorhanden ist oder nicht. Angenommen wir justieren die Einstellungen innerhalb der administrativen Vorlagen.
Einmal ausführlich, bevor ich auf deine Fragen genau eingehe:
Die Frage ist recht einfach. Wenn du keinen zentralen Speicher hast, dann nutzt jeder DC seinen lokalen Speicher. Hast du nun auf DC01 und auf DC02 unterschiedliche ADMX-Files hinterlegt, dann hast du entsprechend unterschiedliche Einstellungen, die du verwalten kannst. Beispiel: Printnightmare. Legst du die ADMX von https://www.faq-o-matic.net/2021/07/07/adm-und-admx-fr-cve-2021-34527-pr ... nur auf DC01 ab, dann hast du dort in der GPO die Konfigurationsmöglichkeit. Öffnest du die konfigurierte GPO nun auf dem DC02, dann sagt dir die GPO-Verwaltung, dass er einen Eintrag auf Grund der fehlenden ADMX nicht angezeigt werden kann.
Meldet sich jetzt ein Client an und ruft die GPO vom DC02 ab, so wird die Konfiguration dennoch korrekt ausgeführt. Diese wurde im Hintergrund synchronisiert, wie @2423392070 schon geschrieben hat.
Ein zentraler Speicher sorgt also nur dafür, dass du nicht händisch die ADMX-Dateien auf den DCs mehrfach aktualisieren musst, sondern überall die gleiche ADMX zur Verfügung hast. Auch hilft der zentrale Speicher dabei, wenn du die DCs irgendwann ersetzt. Neu installierte DC haben dann ja immer den Installationsstandard. Durch den zentralen Speicher haben auch die neuen DCs dann gleich deine aktuellen ADMX-Tempaltes zur Verfügung.
Wie du den Einrichtest, findest du hier: https://docs.microsoft.com/de-de/troubleshoot/windows-client/group-polic ...
Für deine Windows 10/11 Clients ist es völlig egal ob du mit einem Zentralen Speicher arbeitest oder nicht. Der Zentrale Speicher ist lediglich für die DCs interessant.
Die Clients holen sich ihre Einstellungen aus: \\Domäne\SYSVOL\LO.LOCAL\Policies\{GPO-ID}
Die DCs holen sich ihre Definitionen wenn vorhanden aus: \\Domäne\SYSVOL\LO.LOCAL\Policies\PolicyDefinitions
Ist der Order bei den DCs nicht vorhanden, greifen sie auf die lokalen zu. Die Clients greifen nicht auf die Policy-Definitions zu
Kurzer Hintergrund der Geschichte:
Es geht darum dass ich Windows 11 per GPO verbieten möchte in der Domäne. Es sind aber nur die Hälfte der Clients auf 21H2
Und versuche erstmal die Grundmechanik zu verstehen :D
Aber eben ich hab überlegt, ob es einen Unterschied macht, ob man jetzt extra ggfs. einen CentralStore erzeugen sollte oder nicht.
Für das Update nicht Es geht darum dass ich Windows 11 per GPO verbieten möchte in der Domäne. Es sind aber nur die Hälfte der Clients auf 21H2
Und versuche erstmal die Grundmechanik zu verstehen :D
Aber eben ich hab überlegt, ob es einen Unterschied macht, ob man jetzt extra ggfs. einen CentralStore erzeugen sollte oder nicht.
Überdachte Antwort:
Da mehrere DCs im Einsatz sind, müssen die ADMX-Dateien überall gleichzeitig upgedatet werden, daher um den Verwaltungsaufwand zu reduzieren, würde ich es logischer und pflegeleichter und wie oben erklärt konsistenter finden, wenn man kurzer Hand einen zentralen Speicher definiert und darüber administriert.
Genau dafür ist der zentrale Speicher daDa mehrere DCs im Einsatz sind, müssen die ADMX-Dateien überall gleichzeitig upgedatet werden, daher um den Verwaltungsaufwand zu reduzieren, würde ich es logischer und pflegeleichter und wie oben erklärt konsistenter finden, wenn man kurzer Hand einen zentralen Speicher definiert und darüber administriert.
Gruß
Doskias
Zitat von @blaub33r3:
Und um eine kleine Frage nochmal herauszukristalliseren, wird das admx File vom GPO-Client quasi einfach herausgelesen vom lokalen Pfad der administrativen Vorlagen bzw. vom zentralen Speicherpunkt des DCs? Ich schätze der Client greift nur zum Lesen drauf zu und mehr nicht?
Und um eine kleine Frage nochmal herauszukristalliseren, wird das admx File vom GPO-Client quasi einfach herausgelesen vom lokalen Pfad der administrativen Vorlagen bzw. vom zentralen Speicherpunkt des DCs? Ich schätze der Client greift nur zum Lesen drauf zu und mehr nicht?
Nein. Der Client greift gar nicht auf die ADMX zu, weder die zentralen noch die lokalen . Der Client greift immer nur auf die erstellten GPOs zu und die machen im Prinzip nichts anderes als Registry-Werte zu setzen. Siehe: https://gpsearch.azurewebsites.net/
Das setzen der Werte kann der Client auch ohne die entsprechenden ADMX, daher benötigt er diese nicht. Die auf deinen Windows 10 und/oder 11 Clients vorhanden ADMX werden nur dann benötigt, wenn du am Client ein gpedit.msc öffnest, aber nicht für die Gruppenrichtlinien, die du am DC definierst.
Seine eigenen lokalen ADMX. Dateien bleiben immer unangerührt, - richtig?
Ja, die werden nicht verändert.Gruß
Doskias
Die Frage ist recht einfach. Wenn du keinen zentralen Speicher hast, dann nutzt jeder DC seinen lokalen Speicher. >Hast du nun auf DC01 und auf DC02 unterschiedliche ADMX-Files hinterlegt, dann hast du entsprechend >unterschiedliche Einstellungen, die du verwalten kannst. Beispiel: Printnightmare. Legst du die ADMX von >https://www.faq-o-matic.net/2021/07/07/adm-und-admx-fr-cve-2021-34527-pr ... nur auf DC01 ab, dann hast du >dort in der GPO die Konfigurationsmöglichkeit. Öffnest du die konfigurierte GPO nun auf dem DC02, dann sagt dir >die GPO-Verwaltung, dass er einen Eintrag auf Grund der fehlenden ADMX nicht angezeigt werden kann.
Ahhh super Beispiel um den Vorteil der Zentralität greifbar zu spüren! 😊
Meldet sich jetzt ein Client an und ruft die GPO vom DC02 ab, so wird die Konfiguration dennoch korrekt ausgeführt.
Diese wurde im Hintergrund synchronisiert, wie @2423392070 schon geschrieben hat.
Diese wurde im Hintergrund synchronisiert, wie @2423392070 schon geschrieben hat.
Was genau wurde im Hintergrund synchronisiert, ohne CentralStore wird nichts synchronisiert? Oder was genau macht der Client mit der funktionierenden Vorlage von DC01?
Okay, nun begreife ich es: Die Clients greifen in verwalteten Umgebung immer nur auf die GPO-Objekte zu, lesen entsprechend die Konfigurierungsstruktur heraus und justieren sich so selbst.
Lokale admx Dateien werden über gpedit ggfs zur lokalen Verwendung genutzt.
Ich hab gelesen man soll vorsichtig sein, wenn man die ADMX Files updatet, dass ggfs. die Client die GPOs nicht mehr richtig verarbeiten können, wenn ein zu alter Systemzustand besteht.
Die einzige Lösung dem 100% vorzubeugen wäre es also alles Client auf die entsprechende Windowsversion die mit den adminstrativen Vorlagen übereinstimmt hoch zu patchen...in meinem Fall auf 21H2?
Wenn das nicht möglich ist, sollte man pragmatisch vorher vom aktuellen Stand der PolicyDefinitions ein Backup erstellen, falls GPOs nicht richtig funktionieren solten?
(Z.B. Wäre es zu bedenklich die Updaterichtlinie Windows 11 zu blockieren einzustellen, wenn noch nicht alle Clients "21H2" hätten?
Denn die Richtlinie "Zielversion des Funktionsupdates auswählen" beinhaltet erst mit den November ADMX Templates die Möglichkeit das Windowssystem angeben zu können, vorher war es nur die Zielversion des Funktionsupdates....Momentchen, die Clients sollten das doch auf jeden Fall sauber herauslesen können, wenn es im GPO-Objekt drin steht, es handelt sich ja quasi nur um eine weitere Informationen, die der Client verarbeiten müsste. Die Frage wäre, ob bei älteren Systemen und anderen GPO Probleme auftauchen könnten, oder ist es eigentlich nicht doch abwärtskompatibel?)
Bei Problemen mit einzelnen GPO könnte man ggfs. die vorherigen dazugehörigen ADMX - Dateien vereinzelt zurücksichern, könnte ich mir vorstellen.
Das würde quasi eine funktionierende Mischung aus älteren und neueren ADMX Dateien entstehen lassen.
Wir sprechen jetzt nur von admx - Files von Windows und keine Drittanbieter ADMX-Files.
In der Bestpractive Anleitung von Microsoft wird offensichtlich nichts vermischt sondern einfach nur mit dem Versionstand gekennzeichnet. Genutzt wird aber nur immer ein spezifisches ADMX Pack der jeweiligen aktuellsten Version. Denn es wird nur ein Ordner der PolicyDefintions abgerufen von der GPO-Verwaltungskonsole.
Sind meine Bedenken - wie ich sie vermittelt bekam - bedenkenswert, oder arbeitet man sich pragmatisch voran, ohne zu viel Angst zu haben, dass alles im Vorfeld perfekt präventiv vorbereitet wird, dass kein Fehler erst zustande kommen müsste.
Dankeee nochmal für die sauberen und klaren Erklärungen
So in den Templates habe ich soeben nachgeschaut =>und die WindowsUpdate.admx gefunden, wenn ich nur zur Aktualisierung nutzen würde, dürfte es die niedrigste Wahrscheinlich an negativen Überraschungen geben, oder?
Was würde man davon halten, als erfahrener Administrator?
P.S. Ganz triviale Frage, die Zitate kann ich durch das Zeichen ">" kennzeichnen. Müsste doch funktionieren?
Zitat von @blaub33r3:
Was genau wurde im Hintergrund synchronisiert, ohne CentralStore wird nichts synchronisiert? Oder was genau macht der Client mit der funktionierenden Vorlage von DC01?
\\Domäne\SYSVOL\LO.LOCAL\Policies\{GPO-ID} wurde synchronisiert. Erstellst du auf eine DC die GPO wird diese auf die anderen repliziert. Da hier nur repliziert wird, welche Regkeys gesetzt werden, funktioniert dies auch ohne Replizierung der ADMX.Meldet sich jetzt ein Client an und ruft die GPO vom DC02 ab, so wird die Konfiguration dennoch korrekt ausgeführt.
Diese wurde im Hintergrund synchronisiert, wie @2423392070 schon geschrieben hat.
Diese wurde im Hintergrund synchronisiert, wie @2423392070 schon geschrieben hat.
Was genau wurde im Hintergrund synchronisiert, ohne CentralStore wird nichts synchronisiert? Oder was genau macht der Client mit der funktionierenden Vorlage von DC01?
Okay, nun begreife ich es: Die Clients greifen in verwalteten Umgebung immer nur auf die GPO-Objekte zu, lesen entsprechend die Konfigurierungsstruktur heraus und justieren sich so selbst.
Lokale admx Dateien werden über gpedit ggfs zur lokalen Verwendung genutzt.
Lokale admx Dateien werden über gpedit ggfs zur lokalen Verwendung genutzt.
Ich hab gelesen man soll vorsichtig sein, wenn man die ADMX Files updatet, dass ggfs. die Client die GPOs nicht mehr richtig verarbeiten können, wenn ein zu alter Systemzustand besteht.
Ja. Wenn du einen zu alten Client hast, dann kann es sein, dass du per ADMX Einstellungen erhältst, die du dann per GPO konfigurierst. Dein Windows 10 in der Version 1704 kann den Key aber nicht verarbeiten, da Windows 10 die Option erst ab 18.09 beinhaltet. Das steht bei de GPOs aber immer dabeiHier ein besiepil:
https://gpsearch.azurewebsites.net/#167
Supported On: Windows Server 2016 Version 1709, Windows 10 Version 1709, Windows Server 2016 Version 1703, Windows 10 Version 1703, Windows 10, Windows 8.1, Windows 8, and Windows 7 only
Die einzige Lösung dem 100% vorzubeugen wäre es also alles Client auf die entsprechende Windowsversion die mit den adminstrativen Vorlagen übereinstimmt hoch zu patchen...in meinem Fall auf 21H2?
Wie gesagt: Wenn die Version nicht stimmt, dann setz die GPO den Key zwar, aber das OS verarbeitet ihn nicht. Dann passiert einfach gar nichts. Genau so kann es dir aber passieren, dass du durch ein Update des OS auf einmal Keys nicht mehr funktionieren. Siehe Beispiel oben.Wenn das nicht möglich ist, sollte man pragmatisch vorher vom aktuellen Stand der PolicyDefinitions ein Backup erstellen, falls GPOs nicht richtig funktionieren solten?
Mach ich nie. Wieso nicht? Die DCs werden ja ohnehin täglich gesichert. Zur not hol ich die ADMX halt aus dem backup zurück. (Z.B. Wäre es zu bedenklich die Updaterichtlinie Windows 11 zu blockieren einzustellen, wenn noch nicht alle Clients "21H2" hätten?
Denn die Richtlinie "Zielversion des Funktionsupdates auswählen" beinhaltet erst mit den November ADMX Templates die Möglichkeit das Windowssystem angeben zu können, vorher war es nur die Zielversion des Funktionsupdates....Momentchen, die Clients sollten das doch auf jeden Fall sauber herauslesen können, wenn es im GPO-Objekt drin steht, es handelt sich ja quasi nur um eine weitere Informationen, die der Client verarbeiten müsste. Die Frage wäre, ob bei älteren Systemen und anderen GPO Probleme auftauchen könnten, oder ist es eigentlich nicht doch abwärtskompatibel?)
Auch hier: ja das ganze geht bei Windows 10. Die ADMX gibt dir hier nur die Möglichkeit an, das komfortabel einzustellen. Die entsprechenden Keys, die damit bedient werden, existieren schon länger. Um Ein Upgrade von 10 auf 11 zu verhindern, würde ich dir aber einen WSUS empfehlen.Denn die Richtlinie "Zielversion des Funktionsupdates auswählen" beinhaltet erst mit den November ADMX Templates die Möglichkeit das Windowssystem angeben zu können, vorher war es nur die Zielversion des Funktionsupdates....Momentchen, die Clients sollten das doch auf jeden Fall sauber herauslesen können, wenn es im GPO-Objekt drin steht, es handelt sich ja quasi nur um eine weitere Informationen, die der Client verarbeiten müsste. Die Frage wäre, ob bei älteren Systemen und anderen GPO Probleme auftauchen könnten, oder ist es eigentlich nicht doch abwärtskompatibel?)
Bei Problemen mit einzelnen GPO könnte man ggfs. die vorherigen dazugehörigen ADMX - Dateien vereinzelt zurücksichern, könnte ich mir vorstellen.
Das würde quasi eine funktionierende Mischung aus älteren und neueren ADMX Dateien entstehen lassen.
Wir sprechen jetzt nur von admx - Files von Windows und keine Drittanbieter ADMX-Files.
Nochmal: ADMX machen keine Probleme Das würde quasi eine funktionierende Mischung aus älteren und neueren ADMX Dateien entstehen lassen.
Wir sprechen jetzt nur von admx - Files von Windows und keine Drittanbieter ADMX-Files.
. ADMX bieten dir nur die graphische Oberfläche zum Konfigurieren. Die Probleme machen dann die konfigurierten GPOs. Hast du eine GPO erstellt, die Probleme macht und kopierst dann die alte ADMX zurück, bleibt deine fehlerhafte Einstellung weiterhin bestehen. Du nimmst dir ggf. nur die Möglichkeit den Fehler abzustellen, wenn die Option in der alten GPO noch nicht vorhanden war.Sind meine Bedenken - wie ich sie vermittelt bekam - bedenkenswert, oder arbeitet man sich pragmatisch voran, ohne zu viel Angst zu haben, dass alles im Vorfeld perfekt präventiv vorbereitet wird, dass kein Fehler erst zustande kommen müsste.
ich glaube deine Bedenken basieren darauf, dass du noch nicht 100% verstanden hast wofür die ADMX und der zentrale Speicher da sind. Das ist dir ja jetzt viel klarer, wie du schreibst. Hast du noch BEdenken?So in den Templates habe ich soeben nachgeschaut =>und die WindowsUpdate.admx gefunden, wenn ich nur zur Aktualisierung nutzen würde, dürfte es die niedrigste Wahrscheinlich an negativen Überraschungen geben, oder?
Du wirst keine Überraschung erleben. ;) Theoretisch kannst du die ADMX irgendwo bei dir ablegen und mit Notepadd++ öffnen und dir anschauen, was der Unterschied zur vorherigen ist.Was würde man davon halten, als erfahrener Administrator?
Ich tausche bei Bedarf nur die GPOs die mir fehlen.P.S. Ganz triviale Frage, die Zitate kann ich durch das Zeichen ">" kennzeichnen. Müsste doch funktionieren?
Ja, aber nach dem > muss ein Leerzeichen kommen ;)Gruß
Doskias
Hallo,
Nein, falsch! Ein Client guckt da nicht nach. Ein Client zieht sich die GPO aus dem AD, fertig. Das hat erstmal nichts mit den ADMX-Dateien zu tun. Die ADMX-Dateien sind nur für die Admins. Das sind Vorlagen, welche Registry-Key genau was tun und damit man nur noch in der Konsole klicken muß. Du könntest auch alle Keys von Hand in eine GPO schreiben, wenn Du möchtest, ohne ADMX-Vorlage. Die dienen nur der Arbeitserleichterung.
Du könntest deshalb auch die ADMX-Dateien einfach löschen, und die GPOs würden ohne Probleme weiter funktionieren. Die sind rein nur für die Management-Konsole da.
cu,
ipzipzap
Zitat von @blaub33r3:
Frage 1:
Ich verstehe, dass wenn ein Zentraler Speicher vorhanden ist und ein Client eine GPO verarbeitet, er zunächst nachschaut, ob diese zentral verfügbar ist.
Frage 1:
Ich verstehe, dass wenn ein Zentraler Speicher vorhanden ist und ein Client eine GPO verarbeitet, er zunächst nachschaut, ob diese zentral verfügbar ist.
Nein, falsch! Ein Client guckt da nicht nach. Ein Client zieht sich die GPO aus dem AD, fertig. Das hat erstmal nichts mit den ADMX-Dateien zu tun. Die ADMX-Dateien sind nur für die Admins. Das sind Vorlagen, welche Registry-Key genau was tun und damit man nur noch in der Konsole klicken muß. Du könntest auch alle Keys von Hand in eine GPO schreiben, wenn Du möchtest, ohne ADMX-Vorlage. Die dienen nur der Arbeitserleichterung.
Du könntest deshalb auch die ADMX-Dateien einfach löschen, und die GPOs würden ohne Probleme weiter funktionieren. Die sind rein nur für die Management-Konsole da.
cu,
ipzipzap
Okay super, jetzt mal kurz und knapp in einem Versuch:
Der Clients zieht sich die zu konfigurierenden Einstellungen aus den GPOs, die entsprechende Keys zur definierten Einstellungen enthalten. Diese GPOs liegen auf dem Pfad: \\Domäne\SYSVOL\LO.LOCAL\Policies\{GPO-ID}
ADMX. dienen zur Erleichterung der spezifischen Einstellungen innerhalb der jeweiligen GPO.
Damit die Einstellungen einheitlich erfolgen können, werden die ADMX über einen zentralen Speicherpunkt verwaltet -> CentralStore.
Merke:
Sollte es zu Fehler kommen, dann ja nicht die ursprüngliche .admx zurückgespielen, da sonst die Fährte des Fehler verwischt werden würde.
Ob es sinnvoll ist GPO komplett immer abzudaten -> darüber würde ich mir nächste Mal Gedanken machen.
https://www.microsoft.com/en-us/download/confirmation.aspx?id=55319
https://gpsearch.azurewebsites.net/#167 => GPO Check (Gültigkeitserreich für die BS-Versionen feststellen)
Stimmt Backups sind echt praktisch, in Situationen wo einem die Perlen förmlich herunterrinnen
WSUS habe ich geprüft, hier wird nichts abonniert bzgl. Windows 11
Die Clients ziehen sich es trotzdem wenn Sie zuhause sind über die Windows Server.
Dies möchte ich gerne verhindern
Ich werds mir gleich mal mitm Notepad intensiver anschauen
Danke für die ausführlichen Erklärungen, dass war echt hilfreich =)
Lovely Greetings, B33r3
Der Clients zieht sich die zu konfigurierenden Einstellungen aus den GPOs, die entsprechende Keys zur definierten Einstellungen enthalten. Diese GPOs liegen auf dem Pfad: \\Domäne\SYSVOL\LO.LOCAL\Policies\{GPO-ID}
ADMX. dienen zur Erleichterung der spezifischen Einstellungen innerhalb der jeweiligen GPO.
Damit die Einstellungen einheitlich erfolgen können, werden die ADMX über einen zentralen Speicherpunkt verwaltet -> CentralStore.
Merke:
Sollte es zu Fehler kommen, dann ja nicht die ursprüngliche .admx zurückgespielen, da sonst die Fährte des Fehler verwischt werden würde.
Ob es sinnvoll ist GPO komplett immer abzudaten -> darüber würde ich mir nächste Mal Gedanken machen.
https://www.microsoft.com/en-us/download/confirmation.aspx?id=55319
https://gpsearch.azurewebsites.net/#167 => GPO Check (Gültigkeitserreich für die BS-Versionen feststellen)
Stimmt Backups sind echt praktisch, in Situationen wo einem die Perlen förmlich herunterrinnen
Um Ein Upgrade von 10 auf 11 zu verhindern, würde ich dir aber einen WSUS empfehlen.
WSUS habe ich geprüft, hier wird nichts abonniert bzgl. Windows 11
Die Clients ziehen sich es trotzdem wenn Sie zuhause sind über die Windows Server.
Dies möchte ich gerne verhindern
Ich werds mir gleich mal mitm Notepad intensiver anschauen
Danke für die ausführlichen Erklärungen, dass war echt hilfreich =)
Lovely Greetings, B33r3
Zitat von @blaub33r3:
Um Ein Upgrade von 10 auf 11 zu verhindern, würde ich dir aber einen WSUS empfehlen.
WSUS habe ich geprüft, hier wird nichts abonniert bzgl. Windows 11 Achtung du darfst das nicht vermischen. Da bin ich kürzlich selbst drüber gefallen:
WSUS wird von Clients ignoriert
WSUS und Zielversion vertragen sich nicht.
Die Clients ziehen sich es trotzdem wenn Sie zuhause sind über die Windows Server.
Dies möchte ich gerne verhindern
Das verhinderst du mit der Richtlinie Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Updates überprüft werden. Der Name ist durch die Übersetzung kryptisch, zwingt die Rechner aber dazu, dass sie nicht die Windows-Update Server fragen, sondern ausschließlich deinen WSUS. Damit ist dann die Zielversion aus Windows Updates für Unternehmen auch unnötig.Dies möchte ich gerne verhindern
Gruß
Doskias
