Ein großes oder viele kleine GPOs?
Wolfgang Krietsch
GIbt es eigentlich eine Empfehlung, ob es "besser" (inwiefern?) ist,
wenige gro�e GPOs zu haben oder lieber viele kleine, die dann jeweils
nur wenige Einstellungen beinhalten? Oder ist das egal und man kann es
einfach so machen, wie man das am �berschtlichsten findet?
Ich neige dazu, unsere Richtlinien der �bersichtlichkeit aufzuteilen
in "Sicherheit", "Design" etc., bin aber etwas unsicher, ob das
technisch eine gute Entscheidung ist.
Zu ber�cksichtigen ist vielleicht noch, dass wir einige Au�enstellen
mit relativ lahmer DSL/VPN Anbindung haben.
Gr��e
woffi
Florian Frommherz [MVP]
Wolfgang Krietsch schrieb:
> GIbt es eigentlich eine Empfehlung, ob es "besser" (inwiefern?) ist,
> wenige gro�e GPOs zu haben oder lieber viele kleine, die dann jeweils
> nur wenige Einstellungen beinhalten? Oder ist das egal und man kann es
> einfach so machen, wie man das am �berschtlichsten findet?
Die Lade- und Verarbeitungszeit auf den Clientcomputern wird nicht von
der Anzahl der Gruppenrichtlinien sondern vielmehr von der Anzahl der
beteiligten Client Side Extensions (CSEs) bestimmt - also letztlich der
verschiedenen Client-Teile, die f�r das Abarbeiten der Richtlinien
ben�tigt werden. Die Anzahl der GPOs ist dann nur noch margial
entscheidend. Wenn du also 35 Einstellungen auf 7 CSEs verteilt
ausrollen willst/musst, spielt es keine Rolle, ob du die Einstellungen
auf viele kleine GPOs aufteilst oder wenige, gro�e.
In der Regel versuche ich den Leuten in kleineren Umgebungen
beizubringen, dass die �bersichtlichkeit und Administrierbarkeit
Designfaktor Nummer 1 sein sollten.
> Ich neige dazu, unsere Richtlinien der �bersichtlichkeit aufzuteilen
> in "Sicherheit", "Design" etc., bin aber etwas unsicher, ob das
> technisch eine gute Entscheidung ist.
Wenn deine Aufteilung f�r dich so aufgeht, ist das durchaus ein gutes
Konzept. Wenn du dadurch flexibel bist und trotzdem alle Szenarien
abdecken kannst, hast du eigentlich mit dem Konzept "gewonnen".
> Zu ber�cksichtigen ist vielleicht noch, dass wir einige Au�enstellen
> mit relativ lahmer DSL/VPN Anbindung haben.
Es werden ja nicht immer alle Gruppenrichtlinien neu geladen sondern nur
das "Delta" der ge�nderten Einstellungen. Aus diesem Grund solltest du
auch "gpupdate /force" und "Richtlinie immer anwenden, auch wenn sich
nichts ge�ndert hat"-GPO-Orgien vermeiden, dann leidet auch die
Bandbreite nicht sonderlich.
Wenn du an den Aussenstellen weitere DCs hast, die die
Gruppenrichtlinien replizieren, solltest du "SYSVOL bloat" beachten -
dann k�nnen mehrere GPOs wirklich st�rend sein, wenn stets alle
ADM-Dateien (pro GPO ~4MB) repliziert werden m�ssen. Hier schafft
"Central Store" Abhilfe, wenn m�glich:
http://www.gruppenrichtlinien.de/Vista/Central_Store_PolicyDefinitions.htm
Cheers,
Florian
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.
ANY advice you get on the Newsgroups should be tested thoroughly in your
lab.
Mark Heitbrink [MVP]
Am 18.11.2009 16:35, schrieb Wolfgang Krietsch:
> GIbt es eigentlich eine Empfehlung, ob es "besser" (inwiefern?) ist,
> wenige gro�e GPOs zu haben oder lieber viele kleine, die dann jeweils
> nur wenige Einstellungen beinhalten? Oder ist das egal und man kann es
> einfach so machen, wie man das am �berschtlichsten findet?
Ja. Performance ist kaum noch der Summe, der Filter, der beteiligten
Prozesse der verwendeten CSEs geschuldet, sondern dessen "was"
konfiguriert ist.
Wenn du per GPO eine 150MB Datei kopierst, dann ist es nicht die GPO
die als Prozess Zeit kostet.
Ich habe eine OU mit �ber 40 Richtlinien mit unterschiedlichsten
Einstlelungen und allen Filter, die du dir denken kannst.
Die Anmeldung dauert keine 25 Sekunden und da l�uft auch noch ein
Script mit ab.
Tsch�
Mark
--
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: www.gruppenrichtlinien.de - deutsch
Discuss : www.freelists.org/list/gpupdate