GPO Verarbeitung (XP & Windows Server 2003)

Alle Antworten

• 

  

  0

  Anmelden

  Hi neoen,
  
  zu 1)
  Es kommt auf die eingesetzten Einstellungen an: Wenn in jeder der angewendeten GPOs etwa "Administrative Templates" (also Registry Client Side Extension) Einstellungen konfiguriert sind, dann wird jede dieser Policies auch abgearbeitet. Zusätzlich jede andere CSE (Komponenten wie Folder Redirection, Internet Explorer Maintenance etc.), die in der veränderten Policy vorhanden sind.
  Optimierungspotential besteht also im Design der Policies selbst: Je weniger CSEs / Komponenten in einer Policy definiert wurden, umso sinnvoller und schneller kann die Policy Abarbeitung bei Änderungen sein. Du könntest also versuchen, die Policies "zusammenzuführen", wenn das die äußeren Umstände der Organisation zulassen.
  
  zu 2)
  Das ist der Grund, warum wir im Normalfall von WMI-Filtern abraten. WMI-Filter sind sehr "teuer" - wenn man sie vermeiden kann, sollte man es auch tun. Beschleunigen kannst Du die ganze Angelegenheit, indem Du eine Sicherheitsfilterung davor legst, da die Sicherheitsfilterung auf Gruppenrichtlinien vor der WMI-Filter Abarbeitung steht.
  Wenn dann jedoch ein Benutzer oder ein System Zugriffsrechte für "READ" und "APPLY" hat, wird der WMI-Filter in jedem Fall abgearbeitet werden, egal ob sich etwas an der Policy verändert hat oder nicht.
  
  Dieses Design (Punkt 1 und 2) ist in Windows 7 das selbe, es hat sich nichts in dieser Richtung verändert.
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  • Als Antwort markiert Fabian Müller [MSFT]Microsoft employee, Editor Donnerstag, 11. Februar 2010 09:23

  Montag, 1. Februar 2010 13:54

  Antworten

  |

  Zitieren

  Beantworter
• 

  

  0

  Anmelden

  Hi,
  
  Am 01.02.2010 14:39, schrieb neoen:
  > 1. Bei unserem Testsystem werden alle GPOs applied, auch wenn nur eine
  > einzige geändert worden ist.
  
  Dann habt ihr aber massiv dran rumgefummelt und das für jede
  Komponenten angeschaltet
  CompKonf\AdmVorl\Systme\Gruppenrichtlinien
  "Name der Komponente"
  -> Gruppenrichtlinienobjekte auch ohne Änderungen verarbeiten
  
  Oder wird reden von Sonderfällen, zB Scripte und einige GPPs die
  diesen Schalter schon per Default gesetzt haben.
  
  Wobei "Applied" vielleicht auch von der falsch verstanden wird, denn
  verarbeitet werden sie immer, die Frage ist nur, ob sie auch jedesmal
  übernommen werden.
  
  > 2. Die Abfrage, ob ein change einer GPO vorliegt, passiert im Ablauf ja
  > recht spät,
  
  Nein. Das ist das Erste nach dem die Infrastruktur geklärt ist.
  
  - DNS
  - Suche SRV Records
  - LDAP Port suchen/finden/ansprechen
  - Query nach Objekt, Auflösung des DN
  - anhand DN, Abfrage jeder OU/Domäne nach gPLink Einträgen
  - Danach Erstellung der Liste
  - pro Eintrag in der Liste gpt.ini runterladen
  
  > das heißt, es werden u.a. die WMI-Auswertungen für jedes
  > Objekt durchgeführt, bevor überhaupt bekannt ist, ob Änderungen
  > vorliegen und applied werden muss.
  
  Nö. Wer sagt das?
  
  WMI kommt erst nach dem erstellen der Liste, Auswerten des Counters,
  nach Klärung der Berechtigungen, ist erst an 3ter Stelle.
  
  > Gibt es hier Optimmierungsmöglichkeit?
  
  Ja.
  http://www.gruppenrichtlinien.de/Grundlagen/Anmeldeprozess.htm
  http://www.gruppenrichtlinien.de/Grundlagen/Ablauf_Anwendung_der_Gruppenrichtlinie.htm
  
  Tschö
  Mark
  --
  Mark Heitbrink - MVP Windows Server - Group Policy
  
  Homepage: www.gruppenrichtlinien.de - deutsch
  Discuss : www.freelists.org/list/gpupdate
  

  Montag, 1. Februar 2010 14:00

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Moin Mark, :-)
  
  > Dann habt ihr aber massiv dran rumgefummelt und das für jede
  > Komponenten angeschaltet
  > CompKonf\AdmVorl\Systme\Gruppenrichtlinien
  > "Name der Komponente"
  > -> Gruppenrichtlinienobjekte auch ohne Änderungen verarbeiten
  
  Das glaube ich in dem Fall nicht - vielmehr wird die CSE abgearbeitet, wenn in einer Policy mit dieser CSE eine Änderung durchgeführt wurde. Damit sind dann alle Policies betroffen, in der die CSE konfiguriert wurde (siehe mein Beitrag oben).
  
  > Nö. Wer sagt das?
  > WMI kommt erst nach dem erstellen der Liste, Auswerten des Counters,
  > nach Klärung der Berechtigungen, ist erst an 3ter Stelle.
  
  Ich sage das zum Beispiel  ;-) - aber in einem etwas anderen Kontext. Denn die Versionsnummer ist irrelevant für einen WMI-Filter. Der wird immer angewendet, wenn der SOM stimmt und die Security Filterung durchlaufen wurde. Da der WMI-Filter unabhängig von der Versionsnummer ist, wird er immer angewendet. Versionsnummer der Policy ist dabei egal.
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  Montag, 1. Februar 2010 14:20

  Antworten

  |

  Zitieren

  Beantworter
• 

  

  0

  Anmelden

  Hi,
  
  Am 01.02.2010 14:54, schrieb Fabian [MSFT]:
  > Das ist der Grund, warum wir im Normalfall von WMI-Filtern abraten.
  > WMI-Filter sind sehr "teuer" - wenn man sie vermeiden kann, sollte man
  > es auch tun.
  
  Naja, bei der Aussage ist aber auch eine ganze Menge
  "sagen - hören sagen - weiter sagen" enthalten.
  
  WMI ist Prozessorlastig und mit der Einführung (2003) waren die ersten
  P4 Prozessoren praktisch die Königsklasse und hatten damit sicherlich
  zu kämpfen, aber spätestens bei aktuellen CoreX Generationen ist das
  Thema wirklich nicht mehr kritisch.
  
  Ich habe letztens noch ein großes Netzwerk umgebaut und ca. 50
  Richtlinien auf Benutzerebene liegen in denen ich mich mit allen
  Mitteln der Kunst ausgetobt habe:
  - Sicherheitsfilter
  - WMI Filter
  - Item Level Targeting innerhalb von Richtlinien bis zum Abwinken,
  welche ja ebenfalls WMI Filter darstellen.
  
  Anmeldezeit für den Benutzer? 25-30 Sekunden.
  .... aber erst nachdem wir den Virenscanner optimiert haben. :-)
  
  - Virenscanner Fehlkonfig: Anmeldung über 1 Minute
  - Virenscanner optimiert: Anmeldung 40-45 Sekunden
  - Anmeldung ohne Virenscanner, also nur "GPO", denn Scripte wurden
  komplett von GPPs abgelöst, ist rasend schnell.
  
  Es ist logischerweise das Gesamtpaket, aber ich wehre mich ein wenig
  dagegen WMI immer so zu verteufeln. Man muss nur den Rest auch
  ordentlich gestalten und nicht immer "alles, volles Rohr"-Fahren und
  dann auch noch WMI draufsetzen.
  
  - Abschalten der nicht verwendete Objekte/Ziele
  - Vernünftiger Verwaltungsbereich
  - Saubere Sicherheitsfilter
  - Reihenfolge der CSE berücksichtigen
  - Anzahl der beteiligten CSE und damit Prozesse im Auge behalten, nicht
  allein die GPO Anzahl
  - Keine Doppel-Dreifach Konfigurationen und sich ständiges
  Widersprechen
  - Auf keinen Fall "... auch ohne Änderung" aktivieren
  - Kein Defaultverhalten eines Systems über GPO bestätigen
  - halbwegs aktuelle Hardware (max. 3-4 Jahre)
  etc.
  
  Fertsch.
  
  Tschö
  Mark
  --
  Mark Heitbrink - MVP Windows Server - Group Policy
  
  Homepage: www.gruppenrichtlinien.de - deutsch
  Discuss : www.freelists.org/list/gpupdate
  

  • Als Antwort markiert Fabian Müller [MSFT]Microsoft employee, Editor Donnerstag, 11. Februar 2010 09:23

  Montag, 1. Februar 2010 14:48

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Moin,
  
  ich gebe Dir in allen Punkten Deiner letzten Aussage uneingeschränkt Recht, außer bei der Aussage:
  
  > Naja, bei der Aussage ist aber auch eine ganze Menge
  > "sagen - hören sagen - weiter sagen" enthalten.
  
  Was ich gesagt habe, meine ich genauso, wie es da stand. Du hast Recht - die Situation hat sich stark mit der Hardware verbessert, jedoch sollte man nicht vergessen, daß der Trend in vielen Bereichen weg von "fetter Hardware" geht, wordurch das real wieder zu einem Problem werden kann. Außerdem ist es regelmäßig problematisch bei Terminalservern etc., da hier oft neben dem nicht optimal implementierten WMI-Zugriff der GPO-Engine auch die Platte wieder einen begrenzenden Faktor speilt.
  
  Außerdem werden die WMI-Filter bei jedem Anwenden der Policy durchlaufen, was die Sache nicht besser macht. Ich habe Fälle von (zugegebener Maßen etwas komplexeren) WMI-Filtern gesehen, die 20 Sekunden(!) Wartezeit nach sich zogen - und damit pro Filter den Start- Anmeldeprozess um diese Zeit nach hinten verlagerten. Und das übrigens bei aktueller Hardware.
  
  Und nicht umsonst habe ich "im Normalfall" geschrieben - es kommt (wie immer) drauf an... ;-)
  
  Wie gesagt: Group Policy WMI-Filter sind und bleiben teuer, auch wenn es diverse Optimierungsmöglichkeiten gibt. Und sie sind eben nicht so "effektiv" in Bezug auf die Policy Abarbeitung wie Sicherheitsfilterung oder Versionierung bzw. die angesprochene Ausrichtung von Policies an Management-Bereichen und CSEs.
  
  Viele Grüße
  Fabian
  
  

  ---

  http://blogs.technet.com/deds

  Montag, 1. Februar 2010 14:59

  Antworten

  |

  Zitieren

  Beantworter
• 

  

  0

  Anmelden

  Hi,
  
  Am 01.02.2010 15:20, schrieb Fabian [MSFT]:
  > Das glaube ich in dem Fall nicht - vielmehr wird die CSE
  > abgearbeitet, wenn in einer Policy mit dieser CSE eine Änderung
  > durchgeführt wurde. Damit sind dann alle Policies betroffen, in der
  > die CSE konfiguriert wurde
  
  Nein.
  Der Registry Wert "NoGPOListChanges" (Gruppenrichtlinienobjekte auch
  ohne Änderungen verarbeiten) würde das Verhalten in dieser Form so
  beeinflussen wie du es beschreibst.
  Der Normale Ablauf unterscheidet in Version pro GPO.
  
  Beispiel:
  10 GPOs mit AdmVorlagen Settings
  -> 10x registry.pol File, daß importiert wird.
  
  Jetzt änderst du den Counter einer GPO, was wird passieren?
  Er liest das eine registry.pol File neu ein, aber nicht die anderen 9.
  
  Nach deiner Erklärung würde er alle 120 verarbeiten, das tut er aber
  nicht.
  
  > > Nö. Wer sagt das?
  > > WMI kommt erst nach dem erstellen der Liste, Auswerten des Counters,
  > > nach Klärung der Berechtigungen, ist erst an 3ter Stelle.
  > Ich sage das zum Beispiel ;-) - aber in einem etwas anderen Kontext.
  
  Nein, du sagst das auch nicht.
  Du sagst nur, daß WMI jedes Mal läuft, ich sage, das es als "3tes"
  läuft. Es wird aber auf keinen Fall der WMI Filter vor der Version
  verarbeitet und das war mein "Nö."
  
  Ich gebe zu, das ist Erbsenzählerei, aber ich finde es wichtig.
  
  Tschö
  Mark
  --
  Mark Heitbrink - MVP Windows Server - Group Policy
  
  Homepage: www.gruppenrichtlinien.de - deutsch
  Discuss : www.freelists.org/list/gpupdate
  

  Montag, 1. Februar 2010 15:03

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hi,
  
  Am 01.02.2010 15:59, schrieb Fabian [MSFT]:
  > Was ich gesagt habe, meine ich genauso, wie es da stand. Du hast Recht -
  > die Situation hat sich stark mit der Hardware verbessert, [...]Ich habe
  > Fälle von (zugegebener Maßen etwas komplexeren) WMI-Filtern gesehen,
  > die 20 Sekunden(!) Wartezeit nach sich zogen [...]
  
  ok, Wie immer ein Problem der Pauschalisierung.
  Aber wenn ich sehe welche WMI Filter die Leute nutzen, dann ist das
  nichts kritisches. Kurze Hardware-Abfrage oder OS Version etc. das
  bringt keinen um.
  
  Tschö
  Mark
  --
  Mark Heitbrink - MVP Windows Server - Group Policy
  
  Homepage: www.gruppenrichtlinien.de - deutsch
  Discuss : www.freelists.org/list/gpupdate
  

  Montag, 1. Februar 2010 15:18

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Am 01.02.2010 16:03, schrieb Mark Heitbrink [MVP]:
  > Jetzt änderst du den Counter einer GPO, was wird passieren?
  > Er liest das eine registry.pol File neu ein, aber nicht die anderen 9.
  > Nach deiner Erklärung würde er alle 120 verarbeiten,
  
  10, nicht 120 ... tippfehler.
  
  --
  Mark Heitbrink - MVP Windows Server - Group Policy
  
  Homepage: www.gruppenrichtlinien.de - deutsch
  Discuss : www.freelists.org/list/gpupdate
  

  Montag, 1. Februar 2010 15:19

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hi Mark,
  
  jetzt drehe mir nicht das Wort im Munde um ;-).
  
  Meine Aussage dazu war ganz klar: Im Normalfall empfehlen wir, WMI-Filter zu vermeiden. Eine ganz klare "best practice" Aussage. Nicht mehr und nicht weniger.
  
  Und daß GPO WMI-Filter teuer sind oder sein können, wirst Du nicht bestreiten (und hast es ja auch nicht bestritten). Und bevor ich einen WMI-FIlter für die OS-Abfrage einsetze, versuche ich es erst mit Sicherheitsfilterung und dem Scope of Management, also der Verlinkung.
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  Montag, 1. Februar 2010 15:49

  Antworten

  |

  Zitieren

  Beantworter
• 

  

  0

  Anmelden

  Hi,
  
  > Nein.
  
  Doch. ;-)
  
  > Der Registry Wert "NoGPOListChanges" (Gruppenrichtlinienobjekte auch
  > ohne Änderungen verarbeiten) würde das Verhalten in dieser Form so
  > beeinflussen wie du es beschreibst.
  
  Nein, dieser Schlüssel bzw. Modus würde die CSE dazu bewegen, alle Policies auch ohne Änderungen zu verarbeiten. Das hat jedoch nichts mit dem Verhalten bei Änderungen zu tun.
  
  > Der Normale Ablauf unterscheidet in Version pro GPO.
  
  Nein, tut er eben nicht. Wie sollte denn sonst der RSOP gebildet werden, sobald eine Änderung an irgend einer Policy stattgefunden hat?
  Die CSEs haben Ihre Historie inkl. der Policies, die die jeweilige CSE aufrufen, in der GPO History. Am Beispiel der Registry CSE:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}
  
  Unterhalb des Schlüssels der konkreten CSE findest DU alle Policies, die diese CSE nutzen bzw. beim letzten Durchlauf genutzt haben. Ändert sich auch nur eine Versionsnummer innherhalb des CSE-Bereichs, werden alle Policies noch einmal verarbeitet. Ansonsten könnten Einstellungen im RSOP "fehlen".
  
  Ich habe leider keinen MS Link dazu finden können, aber der hier tut es für den Moment auch ;-) : http://207.46.16.252/en-us/magazine/2008.01.gpperf.aspx
  
  > Beispiel:
  > 10 GPOs mit AdmVorlagen Settings
  > -> 10x registry.pol File, daß importiert wird.
  
  > Jetzt änderst du den Counter einer GPO, was wird passieren?
  > Er liest das eine registry.pol File neu ein, aber nicht die anderen 9.
  
  > Nach deiner Erklärung würde er alle 120 verarbeiten, das tut er aber
  > nicht.
  
  Doch, genau das passiert.
  
  Und obendrein wäre mir übrigens auch kein Cache bekannt, der das lokal ermöglichen würde. Die NTUSER.pol hält zwar die angewendeten Einstellungen für die Registry CSE, Security Einstellungen kommen über die Secedit.sdb usw. usf., aber meines Wissens werden diese "Caches" nicht für diesen Prozess herangezogen.
  Wie auch immer, die Verarbeitung findet für die CSE komplett statt, unabhängig davon, ob es caches gibt oder nicht. Und das war ja unser Ausgangspunkt. ;-)
  
  Also, die Planung der Gruppenrichtlinien mit ihren CSE hat bei Änderungen von GPOs maßgeblichen EInfluß auf die Performance.
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  Montag, 1. Februar 2010 15:56

  Antworten

  |

  Zitieren

  Beantworter
• 

  

  0

  Anmelden

  Diese Thread-Anordnung macht mich noch einmal Wahnsinnig... *g*

  ---

  http://blogs.technet.com/deds

  Montag, 1. Februar 2010 15:57

  Antworten

  |

  Zitieren

  Beantworter
• 

  

  0

  Anmelden

  Hi,
  
  Am 01.02.2010 16:49, schrieb Fabian [MSFT]:
  > jetzt drehe mir nicht das Wort im Munde um ;-).
  
  Warum nicht? Es geht grad so gut :-)
  
  > Meine Aussage dazu war ganz klar: Im Normalfall empfehlen wir,
  
  Ich weiss, aber ich finds falsch. Man soll/kann/darf es ruhig
  öfter einsetzen. WMI ist ein prima Werkzeug, um eine Ausnahme in der
  Regel zu definieren, nachdem Scope und Sicherheitsfilter gelaufen sind.
  
  > Und daß GPO WMI-Filter teuer sind oder sein können, wirst Du nicht
  > bestreiten (und hast es ja auch nicht bestritten). Und bevor ich einen
  > WMI-FIlter für die OS-Abfrage einsetze, versuche ich es erst mit
  > Sicherheitsfilterung und dem Scope of Management, also der Verlinkung.
  
  Das gibt die Struktur in den meisnte Fällen nicht her. Da wird wild
  XP/2003 und 7 in einen OU geworfen und kein Mensch hat überhaupt
  Computergruppen für OS eingerichtet.
  
  Wenn man WMI nach "Best Practise" nutzt, also tatsächlich als Filter,
  und damit nur als Ausnahmeregel und nicht als Pauschalwerkzeug, dann
  passiert da nichts.
  
  Tschö
  Mark
  --
  Mark Heitbrink - MVP Windows Server - Group Policy
  
  Homepage: www.gruppenrichtlinien.de - deutsch
  Discuss : www.freelists.org/list/gpupdate
  

  Montag, 1. Februar 2010 16:16

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hi,
  
  Am 01.02.2010 16:56, schrieb Fabian [MSFT]:
  > > Der Normale Ablauf unterscheidet in Version pro GPO.
  > Nein, tut er eben nicht.
  
  Dann ist euer Schaubild: Determining CSEs to Call falsch, daß
  seit 4 oder 5 (?) Jahren im Technet liegt.
  http://technet.microsoft.com/en-us/library/cc784268%28WS.10%29.aspx
  
  -> Process for each GPO in List
  ^^^^
  -> GPO Changes -> Yes -> Process Extension
  -> No -> Nothing
  
  | Check the version number listed in the GPO against its recorded
  | version history in the registry to determine whether the GPO needs
  | reprocessing.
  
  
  und ehrlich gesagt, würde deine Aussage keinen Sinn ergeben. Ich
  importiere ja nicht übertriebenerweise 80 registry.pol Dateien, nur
  weil ich den Bildschrimschoner von 15 auf 10 Minuten stelle.
  Dann kann ich ja gleich, wie unter NT4, jedes mal alles importieren,
  da sich eine Einstellung bestimmt geändert hat.
  
  Auch, wenn du es sagst, glaube ich es erst mal nicht.
  
  Aber da du mich jetzt massiv verunsichert hast, 2 Dinge:
  1. Ich habe das mal als Frage an die PG weitergeleitet :-)
  2. Ich hol nen Wireshark raus.
  
  > Wie sollte denn sonst der RSOP gebildet werden, sobald eine Änderung
  > an irgend einer Policy stattgefunden hat?
  
  Wie, wie soll das gebildet werden? Das ist doch eh nur Information im
  WMI Store. Ich muss ja nur die Werte überschreiben die sich ändern und
  dann die Summe erneut ausgeben. ??
  
  Tschö
  Mark
  --
  Mark Heitbrink - MVP Windows Server - Group Policy
  
  Homepage: www.gruppenrichtlinien.de - deutsch
  Discuss : www.freelists.org/list/gpupdate
  

  Montag, 1. Februar 2010 16:43

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  N'Abend Mark,
  
  ich glaube wir verwirren den TO hier gerade ein wenig, aber letztendlich dient unsere fruchtbare Diskussion ja der Frage, was Einfluß auf die Performance hat. Ich hoffe neoen meldet sich hier trotzdem noch einmal zurück. ;-)
  
  > Dann ist euer Schaubild: Determining CSEs to Call falsch, daß
  > seit 4 oder 5 (?) Jahren im Technet liegt.
  > http://technet.microsoft.com/en-us/library/cc784268%28WS.10%29.aspx
  
  > -> Process for each GPO in List
  > ^^^^
  > -> GPO Changes -> Yes -> Process Extension
  > -> No -> Nothing
  >
  > | Check the version number listed in the GPO against its recorded
  > | version history in the registry to determine whether the GPO needs
  > | reprocessing.
  
  Warum ist es falsch? Es sagt aus, daß bei einer GPO-Änderung die CSE verarbeitet wird. Und das passiert wie beschrieben für alle GPOs, die diese CSE ansprechen bzw. konfigurieren.
  
  > und ehrlich gesagt, würde deine Aussage keinen Sinn ergeben. Ich
  > importiere ja nicht übertriebenerweise 80 registry.pol Dateien, nur
  > weil ich den Bildschrimschoner von 15 auf 10 Minuten stelle.
  > Dann kann ich ja gleich, wie unter NT4, jedes mal alles importieren,
  > da sich eine Einstellung bestimmt geändert hat.
  
  Nein, da gibt es schon noch Unterschiede. ;-) Aber was bleibt Dir anderes übrig als der komplette Import?
  
  Die Alternative wäre, zum Beispiel bei Windows 7 ungefähr 3.000 einzelne Einstellungen pro Policy in einer Datenbank auf dem Client zu pflegen. Das beudeutet, daß Du bei 50 GPOs pro Benutzer oder Client angewendeten Policies insgesamt 150.000 Einträge vorhalten müßtest. Und daraus müßte dann jeweils der RSOP errechnet werden. Der Managementaufwand wäre enorm hoch - mal abgesehen von der Rechenzeit bzw. von der WMI-DB Last auf Terminalservern o.ä.
  
  > Auch, wenn du es sagst, glaube ich es erst mal nicht.
  
  Das steht Dir natürlich frei und ist auch gut so. Man kann ja nicht jedem alles glauben. ;-))
  
  > Aber da du mich jetzt massiv verunsichert hast, 2 Dinge:
  > 1. Ich habe das mal als Frage an die PG weitergeleitet :-)
  > 2. Ich hol nen Wireshark raus.
  
  Ja, mach das ruhig. Dann klärt sich die Sache sicher bald auf. :-)
  
  > Wie, wie soll das gebildet werden? Das ist doch eh nur Information im
  > WMI Store. Ich muss ja nur die Werte überschreiben die sich ändern und
  > dann die Summe erneut ausgeben. ??
  
  Nein, im RSOP Teil der WMI-Datenbank stehen ja nur die angewendeten Einstellungen und nicht etwa alle Einstellungen, die auf dem Wege zum finalen RSOP angewendet wurden. Sonst wäre das wie oben beschrieben eine echt heftige Anzahl an Einträgen pro Benutzer / Client.
  
  Daher existiert keine "Historie" der Einstellungen auf dem Client und somit keine Möglichkeit, einen alten Wert aus der Datenbank zurück zu schreiben, sollte sich ein Wert mit höherer Priorität verändert haben bzw. in diesem konkreten Fall entfernt worden sein. Beim Entfernen einer Einstellung, die vorher die höchste PPriorität hatte, würde in diesem Fall ein Setting fehlen - und um das zu vermeiden, wird ein neuer RSOP mittels neuer CSE Verarbeitung alle Policies generiert.
  
  Viele Grüße und einen angenehmen Feierabend,
  Fabian
  
  
  
  

  ---

  http://blogs.technet.com/deds

  Montag, 1. Februar 2010 17:18

  Antworten

  |

  Zitieren

  Beantworter
• 

  

  0

  Anmelden

  Hi,
  
  Am 01.02.2010 18:18, schrieb Fabian [MSFT]:
  > > | Check the version number listed in the GPO against its recorded
  > > | version history in the registry to determine whether the GPO needs
  > > | reprocessing.
  > Warum ist es falsch?
  
  Weil es *die GPO* nennt und es so darstellt, das pro GPO der Counter
  abgefragt wird und nur dies dann verarbeitet wird.
  
  > Aber was bleibt Dir anderes übrig als der komplette Import?
  
  .... mich auf den Boden werfen und mit den Fäusten trommeln?
  
  > [...] Beim Entfernen einer Einstellung, die vorher die höchste PPriorität
  > hatte, würde in diesem Fall ein Setting fehlen - und um das zu
  > vermeiden, wird ein neuer RSOP mittels neuer CSE Verarbeitung alle
  > Policies generiert.
  
  Ich bin schockiert, aber aus Gründen der Hirarchie/Reihenfolge macht es
  tatsächlich (leider) Sinn. Ansonsten hätte ich im Ablauf ein Problem.
  Eine Einstellung, die von einer nachfolgenden Richtlinie überschrieben
  wird "gewinnt" aufeinmal wieder, weil sie als geänderte auf einmal die
  ist, die den Wert schreibt. Verdammt.
  
  .... ich geh jetzt mal ein wenig kotzen. Danach werde ich noch ne Stunde
  bitterlich weinen und danach einen Punkt zu meiner "GPO-8-Wish"-Liste
  hinzufügen. Das kann man optimieren ...
  
  Du hast gerade ein Teil meines Fundaments pulverisiert, aber das ist ok,
  der Neubau war fällig. Ich habe über das Thema seit x Jahren nicht mehr
  nachgedacht, da ich es schon längst unter "Selbstverstädnis" abgelegt
  hatte. Ich finde "mein" Konstrukt aber immer noch sinnvoller, auch wenn
  ich nicht weiss, wie ich das technisch umsetzen könnte :-)
  
  Merci!
  
  Tschö
  Mark
  --
  Mark Heitbrink - MVP Windows Server - Group Policy
  
  Homepage: www.gruppenrichtlinien.de - deutsch
  Discuss : www.freelists.org/list/gpupdate
  

  Montag, 1. Februar 2010 17:56

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  N'Abend,
  
  > Weil es *die GPO* nennt und es so darstellt, das pro GPO der Counter
  > abgefragt wird und nur dies dann verarbeitet wird.
  
  Na ja, stimmt ja auch so lange, bis irgend eine GPO dann mal als geändert gilt. Und genau in diesem Fall startet dann das gesamte CSE processing.
  
  > .... mich auf den Boden werfen und mit den Fäusten trommeln?
  
  *ggg* Das kenne ich. ;-)
  
  > Ich bin schockiert, aber aus Gründen der Hirarchie/Reihenfolge macht es
  > tatsächlich (leider) Sinn.
  
  Puh, konnte ich doch noch ein Argument finden, welches Dich überzeugen konnte? :-)
  
  > Du hast gerade ein Teil meines Fundaments pulverisiert [...]
  
  Das lag mir absolut fern. ;-)
  
  > Ich finde "mein" Konstrukt aber immer noch sinnvoller, auch wenn
  > ich nicht weiss, wie ich das technisch umsetzen könnte :-)
  
  Da gebe ich Dir absolut Recht. Vom Design her gibt es diverse Themen, die man persönlich gern anders gelöst hätte. Das Problem ist nur, daß sich dann bei jedem Schritt in eine andere Richtung wieder unterschiedliche weitere Probleme in den Weg stellen, so daß am Ende das bestehende Design doch wieder sinnvoll erscheint. Aber man darf gespannt sein, ob Deine Windows 8 Wunschliste etwas an dem Verhalten ändert. ;-)
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  Montag, 1. Februar 2010 19:54

  Antworten

  |

  Zitieren

  Beantworter
• 

  

  0

  Anmelden

  Hallo zusammen,
  
  hätte nicht gedacht, dass ich eine so wilde Diskussion verursachen würde. ;-) Danke für eure ausfürhlichen Beiträge, ich denke, ich blicke nun sehr viel besser durch!
  Eine kleine Frage hätte ich allerdings noch, wenn es euch nichts ausmacht: Wenn ich z.B. 10 GPOs habe, die alle den gleichen WMI-Filter haben, wird er dann auch 10 mal ausgeführt?
  
  Danke schon einmal und viele Grüße,
  neoen

  Dienstag, 9. Februar 2010 13:10

  Antworten

  |

  Zitieren
• 

  

  0

  Anmelden

  Hi,
  
  hier geht es mit der WMI Frage weiter :-) : http://social.technet.microsoft.com/Forums/de-DE/active_directoryde/thread/a7ff09b6-0d2c-4720-a5f7-9fe87cc64ca1
  
  Viele Grüße
  Fabian

  ---

  http://blogs.technet.com/deds

  Donnerstag, 11. Februar 2010 09:23

  Antworten

  |

  Zitieren

  Beantworter