13
Designfrage zu GPOs
Moin moin zusammen.
Ich wollte gern mal eure Meinungen zum Thema GPO-Design hören, aktuell gegeben sei ein AD mit mehreren DCs, verteilt über mehrere physikalische Standorte, die per Site-to-Site-VPN sternförmig miteinander verbunden sind. Innerhalb des ADs gibt es pro Standort OUs, die die jeweiligen Computer- und Benutzerkonten enthalten; zusätzlich außerhalb davon eine OU, in der die Server abgelegt sind (DCs bleiben im Default-Container).
Verteilt werden per GPO Netzlaufwerke und -drucker (GPP), Shortcuts, Files sowie Office- und andere Einstellungen (AutoPlay, Point-and-Print usw.)
Sub-OUs bei den Servern, weil hier RDS-Hosts dabei sind und GPOs mit Loopback direkt auf diese Sub-OUs verlinkt sind.
Folgende Fragen drängen sich mir gerade auf:
- Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
- Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
- Verlinkung auf AD-Sites oder auf Domain-Level mit ILT für die GPPs (also z.B .Drucker StandortA nur verbinden, wenn User sich auch an StandortA befindet)?
- WMI-Filter: Hatte ich mal, um XP-Systeme zu filtern. Lange Threads im Netz zum Thema Performance - wie macht ihr das, WMI-Filter im Einsatz?
- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Bin mal gespannt auf eure Antworten.
Ich weiß, sehr individuelles Thema, aber vielleicht zeichnet sich ja ein Best Practice ab - ist btw nicht so, dass GPOs bei uns generell Probleme machen würden, klappt eigentlich alles. Allerdings würde ich gern einiges konsolidieren und auch an der Verlinkung gern etwas schrauben, daher wäre der ein oder andere Schubser "von außerhalb" sicherlich nicht verkehrt.
Danke für euer Hirnschmalz.
Cheers,
jsysde
Ich wollte gern mal eure Meinungen zum Thema GPO-Design hören, aktuell gegeben sei ein AD mit mehreren DCs, verteilt über mehrere physikalische Standorte, die per Site-to-Site-VPN sternförmig miteinander verbunden sind. Innerhalb des ADs gibt es pro Standort OUs, die die jeweiligen Computer- und Benutzerkonten enthalten; zusätzlich außerhalb davon eine OU, in der die Server abgelegt sind (DCs bleiben im Default-Container).
Verteilt werden per GPO Netzlaufwerke und -drucker (GPP), Shortcuts, Files sowie Office- und andere Einstellungen (AutoPlay, Point-and-Print usw.)
Sub-OUs bei den Servern, weil hier RDS-Hosts dabei sind und GPOs mit Loopback direkt auf diese Sub-OUs verlinkt sind.
Folgende Fragen drängen sich mir gerade auf:
- Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
- Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
- Verlinkung auf AD-Sites oder auf Domain-Level mit ILT für die GPPs (also z.B .Drucker StandortA nur verbinden, wenn User sich auch an StandortA befindet)?
- WMI-Filter: Hatte ich mal, um XP-Systeme zu filtern. Lange Threads im Netz zum Thema Performance - wie macht ihr das, WMI-Filter im Einsatz?
- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Bin mal gespannt auf eure Antworten.
Ich weiß, sehr individuelles Thema, aber vielleicht zeichnet sich ja ein Best Practice ab - ist btw nicht so, dass GPOs bei uns generell Probleme machen würden, klappt eigentlich alles. Allerdings würde ich gern einiges konsolidieren und auch an der Verlinkung gern etwas schrauben, daher wäre der ein oder andere Schubser "von außerhalb" sicherlich nicht verkehrt.
Danke für euer Hirnschmalz.
Cheers,
jsysde
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: 291920
Url: https://administrator.de/contentid/291920
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
13 Kommentare
Neuester Kommentar
Moin
Grüße,
Tiberius
Folgende Fragen drängen sich mir gerade auf:
- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
Als Faustregel habe ich gelernt, dass man pro Einstellung eine eigene GPO haben sollte.- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
Beibehalten- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Was genau meinst du?Grüße,
Tiberius
Hi,
interessiert mich auch.
hab ich auch so. Ich finde man findet einzelne Einstellungen so leichter wieder und kann sie auch gezielt deaktivieren. Ausnahme sind Einstellungen für bestimmte Software - zb CAD - hier gibt es ein paar größere Einstellungs-Pakete.
In it-administrator gab es einmal einen Beitrag über GPO Management. Dort wuden auch viele GPOs mit wenig Einstellungen empfohlen. Performancetechnisch macht das keinen Unterschied mehr.
Mit "Einstellungen" meine ich ein paar GPO Settings. zb off-w-templates, off-ol-autoarchive und nicht eine große Office GPO
Wieso das?
sg Dirm
interessiert mich auch.
- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
Als Faustregel habe ich gelernt, dass man pro Einstellung eine eigene GPO haben sollte.In it-administrator gab es einmal einen Beitrag über GPO Management. Dort wuden auch viele GPOs mit wenig Einstellungen empfohlen. Performancetechnisch macht das keinen Unterschied mehr.
Mit "Einstellungen" meine ich ein paar GPO Settings. zb off-w-templates, off-ol-autoarchive und nicht eine große Office GPO
- Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
Änderungen an Default GPOs sind doch eh meist wischendruchschnellmal-Pfusch. Eine extra GPO kostet nix und ist überischtlicher.- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
Beibehalten- Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
Alle Alle? Admin, DC, ...- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
zur GPO verteilung? Hier finde ich die Verlinkung auf GPO basis auch übersichtlicher. Die Gesamteliste der GPOs kann ich mir ja sowieso anzeigen lassen.sg Dirm
Zitat von @Dirmhirn:
Wieso das?
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
BeibehaltenSofern ich den TO nicht falsch verstanden habe, ist das derselbe Punkt wie der erste.
Moin @jsysde
Gruß,
Dani
Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
Ja. Nur wenn es gar nicht anders geht etwas ändern. Auf jeden Fall 101% dokumentieren, falls der Microsoft Support benötigt wird. Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
Wir legen pro Bereich (Computer und Benutzer) und Anwendung jeweils separate Gruppenrichtlinienobjekte an.Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
Bei uns sind Geräte und Benutzer in einem eigenen OU-Baum abgelegt. Ob es auf oberste Ebene ablegt wird, hängt davon ab, wie viele Computer bzw. Benutzer nicht betroffen sind. Schließlich erhöht sich dadurch die gesamte Ausführungszeit. Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
Sinnvoll. Auch hier geht es um Verarbeitungszeit. Beim Hochfahren eines Rechners wird somit der Benutzerteil komplett ignoriert. Anderenfalls wird er trotzdem verarbeitet.Verlinkung auf AD-Sites oder auf Domain-Level mit ILT für die GPPs (also z.B .Drucker StandortA nur verbinden, wenn User sich auch an StandortA befindet)?
Wenn es speziell nur bestimmte Sites betrifft, macht es durch aus Sinn.Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Versuchen wir zu vermeiden, da es meiner Ansicht nach potenzielle Fehlerquellen sind.Gruß,
Dani
Moin.
Aktuell ist das aber gar nicht mehr möglich, weil ich dann >100 GPOs habe, was die Verwaltung absolut unmöglich macht.
Daher kombiniere ich "verwandte" Einstellungen aktuell in nur einer GPO und filtere dann per ILT. Nicht elegant, aber praxisnah.
Cheers,
jsysde
Zitat von @TlBERlUS:
Als Faustregel habe ich gelernt, dass man pro Einstellung eine eigene GPO haben sollte.
Das habe ich auch mal gelernt. Muss 2003/2004 gewesen sein, als ich meinen MCSE für Server 2003 gemacht habe.Als Faustregel habe ich gelernt, dass man pro Einstellung eine eigene GPO haben sollte.
Aktuell ist das aber gar nicht mehr möglich, weil ich dann >100 GPOs habe, was die Verwaltung absolut unmöglich macht.
Daher kombiniere ich "verwandte" Einstellungen aktuell in nur einer GPO und filtere dann per ILT. Nicht elegant, aber praxisnah.
Cheers,
jsysde
Moin.
Wenige GPOs heisst weniger Overhead, dafür viele Einstellungen, die angewendet werden müssen + evtl. noch etliche Filter (ILT). Wie messe ich die Performance und erhalte belastbare Ergebnisse?
Viele "Roaming User", die heute hier, morgen dort sind. Ich möchte denen immer einen standort-spezifischen Drucker installieren und alle anderen Drucker löschen. Je nach Drucker/Treiber dauert der Aufruf des Druck-Dialogs (egal, aus welcher Anwendung) recht lange, weil der Drucker nicht erreichbar ist (Sternförmige Vernetzung der Standorte; nicht jeder Drucker ist von jedem Standort aus erreichbar).
Cheers,
jsysde
Zitat von @Dani:
Ja. Nur wenn es gar nicht anders geht etwas ändern. Auf jeden Fall 101% dokumentieren, falls der Microsoft Support benötigt wird.
Du kannst nicht zufällig ein Tool zur ausführlichen Dokumentation empfehlen? Nur so am Rande... Ja. Nur wenn es gar nicht anders geht etwas ändern. Auf jeden Fall 101% dokumentieren, falls der Microsoft Support benötigt wird.
Wir legen pro Bereich (Computer und Benutzer) und Anwendung jeweils separate Gruppenrichtlinienobjekte an.
Bei uns sind Geräte und Benutzer in einem eigenen OU-Baum abgelegt. Ob es auf oberste Ebene ablegt wird, hängt davon ab, wie viele Computer bzw. Benutzer nicht betroffen sind. Schließlich erhöht sich dadurch die gesamte Ausführungszeit.
Genau da möchte ich mal einhaken:Bei uns sind Geräte und Benutzer in einem eigenen OU-Baum abgelegt. Ob es auf oberste Ebene ablegt wird, hängt davon ab, wie viele Computer bzw. Benutzer nicht betroffen sind. Schließlich erhöht sich dadurch die gesamte Ausführungszeit.
Wenige GPOs heisst weniger Overhead, dafür viele Einstellungen, die angewendet werden müssen + evtl. noch etliche Filter (ILT). Wie messe ich die Performance und erhalte belastbare Ergebnisse?
Sinnvoll. Auch hier geht es um Verarbeitungszeit. Beim Hochfahren eines Rechners wird somit der Benutzerteil komplett ignoriert. Anderenfalls wird er trotzdem verarbeitet.
Das war mein Grundgedanke, die Einstellungen User/Computer nicht innerhalb einer GPO zu mischen; hat sich (subjektiv!) auch schon ausgezahlt, da beim Hochfahren die Policies schneller angewendet werden (wir haben Verbose-Mode aktiv, damit der User mehr sieht als "Please wait...").Wenn es speziell nur bestimmte Sites betrifft, macht es durch aus Sinn.
Hmm... Es geht um alle Sites bzw. um die Zuweisung von Druckern im Speziellen.Viele "Roaming User", die heute hier, morgen dort sind. Ich möchte denen immer einen standort-spezifischen Drucker installieren und alle anderen Drucker löschen. Je nach Drucker/Treiber dauert der Aufruf des Druck-Dialogs (egal, aus welcher Anwendung) recht lange, weil der Drucker nicht erreichbar ist (Sternförmige Vernetzung der Standorte; nicht jeder Drucker ist von jedem Standort aus erreichbar).
Cheers,
jsysde
Moin
Bevor ein Admin eine Änderung überhaupt durchführt, startet er eine geplante Aufgabe. Diese legt von allen GPOs eine Bericht an. Er kann auf das Sicherungsziel jederzeit nachschauen, was vor seiner Änderung für Werte gesetzt waren. Gelöscht werden kann aber nichts. Reicht für unsere Zwecke bisher locker aus. Alternativ würde mir Dokusnap noch einfallen. Da sind die Jungs von Vertrags/Inventarisierung und Lizenzverwaltung scharf drauf.
Gruß,
Dani
Gruß,
Dani
Du kannst nicht zufällig ein Tool zur ausführlichen Dokumentation empfehlen? Nur so am Rande...
Ein Tool direkt nicht... wir nutzen dazu GPMC Skripts von Microsoft. Im Detail müsste ich nochmals nachlesen.Bevor ein Admin eine Änderung überhaupt durchführt, startet er eine geplante Aufgabe. Diese legt von allen GPOs eine Bericht an. Er kann auf das Sicherungsziel jederzeit nachschauen, was vor seiner Änderung für Werte gesetzt waren. Gelöscht werden kann aber nichts.
Reicht für unsere Zwecke bisher locker aus. Alternativ würde mir Dokusnap noch einfallen. Da sind die Jungs von Vertrags/Inventarisierung und Lizenzverwaltung scharf drauf. Wenige GPOs heisst weniger Overhead, dafür viele Einstellungen, die angewendet werden müssen + evtl. noch etliche Filter (ILT).
Wieso mehr Einstellungen? Die Anzahl der Einstellungen in einer GPO werden durchs aufteilen nicht mehr. Wie messe ich die Performance und erhalte belastbare Ergebnisse?
Da lege ich dir folgenden Arikel ans Herz. Damit hast du die Basics schon mal erledigt.Viele "Roaming User", die heute hier, morgen dort sind. Ich möchte denen immer einen standort-spezifischen Drucker installieren und alle anderen Drucker löschen. Je nach Drucker/Treiber dauert der Aufruf des Druck-Dialogs (egal, aus welcher Anwendung) recht lange, weil der Drucker nicht erreichbar ist (Sternförmige Vernetzung der Standorte; nicht jeder Drucker ist von jedem Standort aus erreichbar).
Ist so schon realisiert oder geht es um die Grundidee je nach Standort einen definierten Drucker zur Verfügung zustellen?Gruß,
Dani
Gruß,
Dani
Hi,
frage 10 Erperten und Du bekommst 100 Meinungen ...
Ich glaube, hier gibt es nicht wirklich die eine Best Practice. Das hängt immer von der konkreten Umgebung, den konkreten Anforderungen und - nicht zu vergessen - von den Fähigkeiten des Admins, welche dieses betreuen müssen, ab.
(Zu letzterem: Ich habe auch schon simpleste Einstellungen "super-simpel" abgebildet (zu Deutsch: "idiotensicher"), um zu erreichen, dass auch wirklich alle Kollegen da noch durchblicken. Und das ist nicht mal "böse" gemeint gewesen.)
Hier mal mein Standpunkt:
Ich selbst erstelle meistens größere, themenbezogene Basis-GPO, welche Einstellungen enthalten, die für alle oder die meisten der Benutzer und/oder Computer gelten sollen (z.B. "globale Office 2010 Einstellungen für Benutzer"), und welche ich dann auch für alle Benutzer und/oder Computer filtere. Zusätzlich erstelle ich GPO mit speziellen, vom Standard abweichenden Einstellungen, welche ich dann nur für die betreffenden Benutzer und/oder Computer filtere (z.B. "zentraler Office-Vorlagen-Pfad für Buchhaltung"). Hier muss man dann halt die GPO-Vererbung entsprechend designen.
Ob man diese GPO nun auch nach Einstellungen Nur-für-Computer und Nur-für-Benutzer trennt, das ist "Ansichtssache". Es hat keinen Einfluss auf die Verabeitungsgeschwindigkeit, da ein Computer eh immer nur die Bereiche "Computerkonfiguration" und ein Benutzer eh immer nur die Bereiche "Benutzerkonfiguration" der GPOs laden und verarbeiten wird.
Wenn man aber A-G-DL-P lebt, dann hat man i.A. schon alle entsprechende Rollen im AD abgebildet (Globale Gruppen), über welche man auch die GPO filtern kann. Welchen Sinn sollte es machen, z.B. eine Gruppe (Rolle) "Buchaltung" zu haben und dann noch mal eine Gruppe z.B. "GPO für Buchhaltung"
anzulegen und über diese die GPO zu filtern, wenn doch höchstwahrscheinlich die Mitglieder beider Gruppen deckungsgleich sind?
E.
frage 10 Erperten und Du bekommst 100 Meinungen ...
Ich glaube, hier gibt es nicht wirklich die eine Best Practice. Das hängt immer von der konkreten Umgebung, den konkreten Anforderungen und - nicht zu vergessen - von den Fähigkeiten des Admins, welche dieses betreuen müssen, ab.
(Zu letzterem: Ich habe auch schon simpleste Einstellungen "super-simpel" abgebildet (zu Deutsch: "idiotensicher"), um zu erreichen, dass auch wirklich alle Kollegen da noch durchblicken. Und das ist nicht mal "böse" gemeint gewesen.)
Hier mal mein Standpunkt:
- Default-GPOs möglichst unangetastet lassen, ist das noch sinnvoll?
Ich nutze diese nur für ganz wenige Basis-Einstellungen, welche i.A. "sowieso" für alle Benutzer und/oder Computer der Domäne gelten sollen.- Viele GPOs mit jeweils wenigen Einstellungen oder wenige GPOs mit möglichst vielen Einstellungen?
Beide Systeme haben Ihre Vor- und Nachteile. Wie so oft wird auch hier wohl der Mittelweg der günstigste sein.Ich selbst erstelle meistens größere, themenbezogene Basis-GPO, welche Einstellungen enthalten, die für alle oder die meisten der Benutzer und/oder Computer gelten sollen (z.B. "globale Office 2010 Einstellungen für Benutzer"), und welche ich dann auch für alle Benutzer und/oder Computer filtere. Zusätzlich erstelle ich GPO mit speziellen, vom Standard abweichenden Einstellungen, welche ich dann nur für die betreffenden Benutzer und/oder Computer filtere (z.B. "zentraler Office-Vorlagen-Pfad für Buchhaltung"). Hier muss man dann halt die GPO-Vererbung entsprechend designen.
- Bisher: OUs enthalten entweder Computer- oder User-Settings, der jeweils nicht benutzte Teil ist deaktiviert. Sinnvoll oder Einstellungen mischen besser?
Wenn eine GPO keine Einstellungen für Computer oder Benutzer enthält, dann sollte man sehr wohl den nicht benötigten Bereich deaktivieren. Der Effekt ist, dass beim GPO Collect solche GPO gar nicht erst bei der Filterung berücksichtigt werden. Somit landen dann auch keine leeren GPO in der Verarbeitungsliste, welche nicht nur die Verarbeitung unnötigt verzögern würden, sondern auch den Admin bei der Fehlersuche ablenken (z.B. wenn man das GPresult auswertet). Dies wirkt sich vor allem beim Startup und/oder Login an WAN-Standorten aus, an welchen kein DC vor Ort vorhanden ist.Ob man diese GPO nun auch nach Einstellungen Nur-für-Computer und Nur-für-Benutzer trennt, das ist "Ansichtssache". Es hat keinen Einfluss auf die Verabeitungsgeschwindigkeit, da ein Computer eh immer nur die Bereiche "Computerkonfiguration" und ein Benutzer eh immer nur die Bereiche "Benutzerkonfiguration" der GPOs laden und verarbeiten wird.
- Verlinkung von GPOs, die für alle User/alle Computer gelten sollen => 1x auf Domain-Ebene oder mehrfach auf OU-Ebene?
Wie oft und wo eine GPO im AD verlinkt ist, ist für die Verabeitung vollkommen irrelevant. Interessant ist nur, wie die Admins damit zurecht kommen und dass man eine GPO nicht mehrmals für einen Benutzer und/oder Computer im Vererbungsbaum verlinkt. Ich handhabe das immer so: So weit oben wie nötig, soweit unten wie möglich.- Verlinkung auf AD-Sites oder auf Domain-Level mit ILT für die GPPs (also z.B .Drucker StandortA nur verbinden, wenn User sich auch an StandortA befindet)?
Die Filterung einer GPO über das AD-Standortobjekt ist schneller als die Filterung der einzelnen GPP-Einstellungen über ITL. Wenn eine GPO nur Einstellungen enthält, welche nur beim Startup oder Login an einem bestimmten Standort gelten, dann erstelle ich einen AD-Standort und hänge dort die GPOs - ohne ITL für "Standort" - dran.- WMI-Filter: Hatte ich mal, um XP-Systeme zu filtern. Lange Threads im Netz zum Thema Performance - wie macht ihr das, WMI-Filter im Einsatz?
Für Einstellungen, welche nicht über die GPP erfolgen sondern über klassische Richtlinien (und welche auch nicht auf GPP umgestellt werden können), und welche man weiterhin dynamisch von bestimmten Begebenheiten abhängig filtern will oder muss, wird man auch weiterhin die GPO über WMI-Filter filtern müssen.- Sicherheitsfilterung: Gruppen bauen und dort eintragen oder anders lösen?
Wie ist diese Frage gemeint? Meinst Du, extra Gruppen für die Filterung von GPO anlegen und benutzen? Das kann notwendig sein, wenn es noch keine entsprechenden Gruppen gibt.Wenn man aber A-G-DL-P lebt, dann hat man i.A. schon alle entsprechende Rollen im AD abgebildet (Globale Gruppen), über welche man auch die GPO filtern kann. Welchen Sinn sollte es machen, z.B. eine Gruppe (Rolle) "Buchaltung" zu haben und dann noch mal eine Gruppe z.B. "GPO für Buchhaltung"
anzulegen und über diese die GPO zu filtern, wenn doch höchstwahrscheinlich die Mitglieder beider Gruppen deckungsgleich sind?
E.
Moin.
Cheers,
jsysde
Zitat von @Dani:
Ein Tool direkt nicht... wir nutzen dazu GPMC Skripts von Microsoft. Im Detail müsste ich nochmals nachlesen.
Bevor ein Admin eine Änderung überhaupt durchführt, startet er eine geplante Aufgabe. Diese legt von allen GPOs eine Bericht an. Er kann auf das Sicherungsziel jederzeit nachschauen, was vor seiner Änderung für Werte gesetzt waren. Gelöscht werden kann aber nichts.
Läuft hier ähnlich. Mir ging es aber eher um die Dokumentation der Einstellungen innerhalb der GPOs - klar, ich kann alle GPOs in Word oder Excel auflisten und kommentieren oder eben die HTML-Ausgabe aus der GPMC samt Kommentaren irgendwo in der Doku ablegen. Aber irgendwie ist das alles nicht so, wie ich es mir wünschen würde, zu viel "Handarbeit"....Ein Tool direkt nicht... wir nutzen dazu GPMC Skripts von Microsoft. Im Detail müsste ich nochmals nachlesen.
Bevor ein Admin eine Änderung überhaupt durchführt, startet er eine geplante Aufgabe. Diese legt von allen GPOs eine Bericht an. Er kann auf das Sicherungsziel jederzeit nachschauen, was vor seiner Änderung für Werte gesetzt waren. Gelöscht werden kann aber nichts.
Da lege ich dir folgenden Arikel ans Herz. Damit hast du die Basics schon mal erledigt.
Danke, soweit war mir das schon bekannt. Wenn's damit getan ist, kann ich mich beruhigt auf die Seite drehen und weiterschlafen. Ist so schon realisiert oder geht es um die Grundidee je nach Standort einen definierten Drucker zur Verfügung zustellen?
Teilweise läuft es schon so, Test-Ballon halt. Klappt eigentlich auch recht zuverlässig. Finde es nur unübersichtlich, vor allem, da die Verlinkung auf eine AD-Site in den Eigenschaften einer GPO nicht angezeigt wird; man könnte also meinen, die GPO wäre nirgendwo hin verlinkt...Cheers,
jsysde
Moin.
Ist mir bewusst - deswegen frage ich ja hier.
Bin also nicht völlig auf der falschen Fährte...
Ich habe aktuell genau einen WMI-Filter im Einsatz und der filtert auf Server-/Desktop-OS. Vielleicht kann ich mit weiteren WMI-Filtern gewisse GPOs noch weiter eingrenzen? Mir fällt nur auf Anhieb nix mehr ein....
Meine Frage zielte eher darauf, ob es außer evtl. Redundanzen und der höheren Komplexität für den Admin anderweitige, negative Auswirkungen auf die GPO/deren Verarbeitung hat? Stichwort: Objekt ist Mitglied in zu vielen Gruppen, die im Token nicht berücksichtigt werden usw.... ifmember.exe macht ja auch bei 100 Gruppenmitgliedschaften Schluss....
Cheers,
jsysde
Ist mir bewusst - deswegen frage ich ja hier.
Ich handhabe das immer so: So weit oben wie nötig, soweit unten wie möglich.
Dito. Zumindest versuche ich mich daran zu halten. Die Verlinkung auf AD-Sites bildet da natürlich ne Ausnahme zur Regel.Die Filterung einer GPO über das AD-Standortobjekt ist schneller als die Filterung der einzelnen GPP-Einstellungen über ITL.
Danke - das hatte ich gehofft. Bin also nicht völlig auf der falschen Fährte...
Wenn eine GPO nur Einstellungen enthält, welche nur beim Startup oder Login an einem bestimmten Standort gelten, dann erstelle ich einen AD-Standort und hänge dort die GPOs - ohne ITL für "Standort" - dran.
...denn genau da will ich ja eigentlich hin. Das weniger Filter == mehr Performance bedeuten, war mir schon klar und ist ja auch nur logisch.Für Einstellungen, welche nicht über die GPP erfolgen sondern über klassische Richtlinien (und welche auch nicht auf GPP umgestellt werden können), und welche man weiterhin dynamisch von bestimmten Begebenheiten abhängig filtern will oder muss, wird man auch weiterhin die GPO über WMI-Filter filtern müssen.
Haste mal ein Beispiel aus der Praxis?Ich habe aktuell genau einen WMI-Filter im Einsatz und der filtert auf Server-/Desktop-OS. Vielleicht kann ich mit weiteren WMI-Filtern gewisse GPOs noch weiter eingrenzen? Mir fällt nur auf Anhieb nix mehr ein....
Wie ist diese Frage gemeint? Meinst Du, extra Gruppen für die Filterung von GPO anlegen und benutzen? Das kann notwendig sein, wenn es noch keine entsprechenden Gruppen gibt.
Wenn man aber A-G-DL-P lebt, dann hat man i.A. schon alle entsprechende Rollen im AD abgebildet (Globale Gruppen), über welche man auch die GPO filtern kann. Welchen Sinn sollte es machen, z.B. eine Gruppe (Rolle) "Buchaltung" zu haben und dann noch mal eine Gruppe z.B. "GPO für Buchhaltung"
anzulegen und über diese die GPO zu filtern, wenn doch höchstwahrscheinlich die Mitglieder beider Gruppen deckungsgleich sind?
Ok, deckungsgleiche Gruppen sind natürlich Käse. Unsere "gewachsene Struktur" beinhaltet aber leider etliche Gruppen, die eben nicht A-G-DL-P entsprechend, sondern mal "einfach so, irgendwie" dahingeklatscht wurden und immer noch produktiv eingesetzt werden; teilweise abenteuerlich, wo die überall auftauchen...Wenn man aber A-G-DL-P lebt, dann hat man i.A. schon alle entsprechende Rollen im AD abgebildet (Globale Gruppen), über welche man auch die GPO filtern kann. Welchen Sinn sollte es machen, z.B. eine Gruppe (Rolle) "Buchaltung" zu haben und dann noch mal eine Gruppe z.B. "GPO für Buchhaltung"
anzulegen und über diese die GPO zu filtern, wenn doch höchstwahrscheinlich die Mitglieder beider Gruppen deckungsgleich sind?
Meine Frage zielte eher darauf, ob es außer evtl. Redundanzen und der höheren Komplexität für den Admin anderweitige, negative Auswirkungen auf die GPO/deren Verarbeitung hat? Stichwort: Objekt ist Mitglied in zu vielen Gruppen, die im Token nicht berücksichtigt werden usw.... ifmember.exe macht ja auch bei 100 Gruppenmitgliedschaften Schluss....
Cheers,
jsysde
Das Sitzungstoken eines Benutzers kann bis zu 1015 Gruppen-SID enthalten. Dazu muss man aber ggf. die max. Tokengröße erhöhen. (--> MaxTokenSize)
Die Schattenseite eines konsequenten AGDLP-Modells ist genau diese u.U. sehr hohe Anzahl an verschachtelen Gruppen beim Zugriff auf manche Server oder Dienste. Wenn man es übertreibt kann das auch dazu führen, dass einige GPO nicht angewendet werden. Das hat aber nichts mit der Anzahl der GPO und/oder deren Verlinkungen zu tun, sondern allein mit der beschränkten Tokengröße. Es sei denn, man legt für jede GPO eine Gruppe zum Filtern an. Dann würde die Gruppenanzahl mit der Anzahl der für einen Benutzer geltenden GPOs natürlich steigen. Du siehst spätestens hier, dass es Nonsens ist, extra Gruppen nur für die Zuordnung von GPOs zu erstellen. Eine GPO erstelle ich für eine bestimmte Gruppe von Benutzern oder Computern. Wenn diese nicht bereits in AD-Gruppen gruppiert sind, dann sollte man das im Zusammenhang mit der neuen GPO natürlich tun. Aber auch nur dann, wenn erforderlich.
Bsp: Gruppen "Buchhaltung" und "Lager". Beide haben keine Überschneidungen in den Mitgliedern. Für beide soll eine GPO gelten. Statt jetzt eine neue Gruppe für die Filterung dieser GPO zu erstellen, besser die beiden vorhandenen Gruppen benutzen.
Wenn eine GPO z.B. nur für 2 Computer gilt, dann kann man deren Konten auch einzeln hinzfügen. Das machen wir z.B. bei der Steuerung der lokalen Administratoren einzelner Server so. Oder man verschiebt beide Computerobjekte in eine dedizierte OU und hängt die GPO an diese OU mit Standardfilter für "autentifizierte Benutzer". Das geht auch.
Alles andere ist Bast Practice speziell auf Eure Umgebung und Eure Arbeitsweise bezogen. Und diese könnt Ihr Euch nur selbst erarbeiten. Wichtig ist nur, dass Ihr Eure Verfahren auch als definierte Prozesse niederschreibt. "Gelebte Standards", welche nur als Idee im Raum stehen, aber nirgend verbindlich festgeschrieben sind, neigen meiner Erfahrung nach dazu, ständig "angepasst" oder "ausgelegt" zu werden. X-fache Sonderlocken sind damit vorprogrammiert.
Die Schattenseite eines konsequenten AGDLP-Modells ist genau diese u.U. sehr hohe Anzahl an verschachtelen Gruppen beim Zugriff auf manche Server oder Dienste. Wenn man es übertreibt kann das auch dazu führen, dass einige GPO nicht angewendet werden. Das hat aber nichts mit der Anzahl der GPO und/oder deren Verlinkungen zu tun, sondern allein mit der beschränkten Tokengröße. Es sei denn, man legt für jede GPO eine Gruppe zum Filtern an. Dann würde die Gruppenanzahl mit der Anzahl der für einen Benutzer geltenden GPOs natürlich steigen. Du siehst spätestens hier, dass es Nonsens ist, extra Gruppen nur für die Zuordnung von GPOs zu erstellen. Eine GPO erstelle ich für eine bestimmte Gruppe von Benutzern oder Computern. Wenn diese nicht bereits in AD-Gruppen gruppiert sind, dann sollte man das im Zusammenhang mit der neuen GPO natürlich tun. Aber auch nur dann, wenn erforderlich.
Bsp: Gruppen "Buchhaltung" und "Lager". Beide haben keine Überschneidungen in den Mitgliedern. Für beide soll eine GPO gelten. Statt jetzt eine neue Gruppe für die Filterung dieser GPO zu erstellen, besser die beiden vorhandenen Gruppen benutzen.
Wenn eine GPO z.B. nur für 2 Computer gilt, dann kann man deren Konten auch einzeln hinzfügen. Das machen wir z.B. bei der Steuerung der lokalen Administratoren einzelner Server so. Oder man verschiebt beide Computerobjekte in eine dedizierte OU und hängt die GPO an diese OU mit Standardfilter für "autentifizierte Benutzer". Das geht auch.
Alles andere ist Bast Practice speziell auf Eure Umgebung und Eure Arbeitsweise bezogen. Und diese könnt Ihr Euch nur selbst erarbeiten. Wichtig ist nur, dass Ihr Eure Verfahren auch als definierte Prozesse niederschreibt. "Gelebte Standards", welche nur als Idee im Raum stehen, aber nirgend verbindlich festgeschrieben sind, neigen meiner Erfahrung nach dazu, ständig "angepasst" oder "ausgelegt" zu werden. X-fache Sonderlocken sind damit vorprogrammiert.
Guten Morgen,
wir machen das Printermapping hauptsächlich clientbasiert. So bekommt der Benutzer den Drucker, der am nächsten steht.
Bei der Anmeldung wird per Skript eine CSV mit clientname,Printserver, Drucker share und default j/n durchpflügt und con2prt gefüttert.
Bei Notebooks muss man allerdings allerdings mehrere Einträge machen, weil dort der Client wandert und nicht der Benutzer.
Dieser setzt dann manuell den Standard Drucker.
Es ist übrigens egal, ob in der CSV 10 oder 1000000000 stehen. Die Anmeldedauer verlängert sich dadurch nicht. Einzig die Anzahl der Hits beeinflusst sie... Natürlich.
Gruß,
JMcClane
wir machen das Printermapping hauptsächlich clientbasiert. So bekommt der Benutzer den Drucker, der am nächsten steht.
Bei der Anmeldung wird per Skript eine CSV mit clientname,Printserver, Drucker share und default j/n durchpflügt und con2prt gefüttert.
Bei Notebooks muss man allerdings allerdings mehrere Einträge machen, weil dort der Client wandert und nicht der Benutzer.
Dieser setzt dann manuell den Standard Drucker.
Es ist übrigens egal, ob in der CSV 10 oder 1000000000 stehen. Die Anmeldedauer verlängert sich dadurch nicht. Einzig die Anzahl der Hits beeinflusst sie... Natürlich.
Gruß,
JMcClane
N'Abend.
Cheers,
jsysde
Zitat von @emeriks:
Das Sitzungstoken eines Benutzers kann bis zu 1015 Gruppen-SID enthalten. Dazu muss man aber ggf. die max. Tokengröße erhöhen. (--> MaxTokenSize)
Schon richtig - aber nicht alle Tools (ifmember.exe z.B.) kommen damit klar und auch die Filterung innerhalb einer GPP dauert ein wenig (wird zwar gecached, aber beim ersten Mal müssen halt alle Mitgliedschaften geprüft werden). Hinzu kommt, dass unsere "alte" NetApp ein Problem mit verschachtelten/zu vielen Gruppen hat (anderes Kapitel, ich weiß, und zeitlich nur noch begrenzt vorhanden).Das Sitzungstoken eines Benutzers kann bis zu 1015 Gruppen-SID enthalten. Dazu muss man aber ggf. die max. Tokengröße erhöhen. (--> MaxTokenSize)
Das hat aber nichts mit der Anzahl der GPO und/oder deren Verlinkungen zu tun, sondern allein mit der beschränkten Tokengröße. Es sei denn, man legt für jede GPO eine Gruppe zum Filtern an. Dann würde die Gruppenanzahl mit der Anzahl der für einen Benutzer geltenden GPOs natürlich steigen.
Ist klar. Und wie oben schon beschrieben, kommen manche Tools/Appliance schon mit der Standardgröße des Tokens nicht zurecht...Du siehst spätestens hier, dass es Nonsens ist, extra Gruppen nur für die Zuordnung von GPOs zu erstellen. Eine GPO erstelle ich für eine bestimmte Gruppe von Benutzern oder Computern. Wenn diese nicht bereits in AD-Gruppen gruppiert sind, dann sollte man das im Zusammenhang mit der neuen GPO natürlich tun. Aber auch nur dann, wenn erforderlich.
Da, genau da, will ich hin. Allerdings muss ich dafür > 1.500 Gruppen "durchpflügen" und neu organisieren. Und das möglichst, ohne Fehler dabei zu machen, da die Gruppen (Universal oder Global Security) teils als Mailverteiler und gleichzeitig für NTFS-Berechtigungen, RDP etc. genutzt werden. Da eine Differenzierung auf dieser Ebene nicht mehr möglich war/ist, musste ich eben Gruppen definieren, um GPOs darauf zu filtern....Wichtig ist nur, dass Ihr Eure Verfahren auch als definierte Prozesse niederschreibt. "Gelebte Standards", welche nur als Idee im Raum stehen, aber nirgend verbindlich festgeschrieben sind, neigen meiner Erfahrung nach dazu, ständig "angepasst" oder "ausgelegt" zu werden. X-fache Sonderlocken sind damit vorprogrammiert.
Sehr, sehr wahr.... Cheers,
jsysde
