Designfrage zu GPOs

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

Änderungen an Default GPOs sind doch eh meist wischendruchschnellmal-Pfusch. Eine extra GPO kostet nix und ist überischtlicher.

Wieso das?

Alle Alle? Admin, DC, ...

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

Sofern ich den TO nicht falsch verstanden habe, ist das derselbe Punkt wie der erste.

Moin @jsysde
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.

Sinnvoll. Auch hier geht es um Verarbeitungszeit. Beim Hochfahren eines Rechners wird somit der Benutzerteil komplett ignoriert. Anderenfalls wird er trotzdem verarbeitet.

Wenn es speziell nur bestimmte Sites betrifft, macht es durch aus Sinn.

Versuchen wir zu vermeiden, da es meiner Ansicht nach potenzielle Fehlerquellen sind.


Gruß,
Dani

Moin
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.

Wieso mehr Einstellungen? Die Anzahl der Einstellungen in einer GPO werden durchs aufteilen nicht mehr.

Da lege ich dir folgenden Arikel ans Herz. Damit hast du die Basics schon mal erledigt.

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 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.

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.

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.

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.

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.

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.

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.

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.

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