"Apply once and do not reapply" - aber so war das nicht gemeint!

Group Policy Preferences sind schon eine tolle Sache.
Mal eben schnell und flexibel ein paar Einstellungen verteilen.

Was aber wenn diese Einstellungen wirklich nur "Preferences" sein sollen?

Im übertragenen Sinne also "Voreinstellungen".

Auch das ist kein Problem.
In den Eigenschaften jedes Items lässt sich eine Checkbox aktivieren:
"Apply once and do not reapply".

Was passiert hier also?
Wie weiß der Client, dass dieses Item schon einmal angewendet wurde?

Das Geheimnis verbirgt sich in der dazugehörigen XML Datei.
Wird die Checkbox aktiviert, so wird in dieser Datei ein Eintrag erzeugt:

<Filters><FilterRunOnce hidden="1" not="0" bool="AND" id="{2B28F5C1-237A-4EDB-8318-F2B862493D89}"

Die genannte ID ist natürlich generiert und unterscheidet sich zwischen den
einzelnen Policies und Items.

Diese ID wird auf dem Client gespeichert:

HKCU\Software\Microsoft\Group Policy\Client\RunOnce

HKLM\Software\Microsoft\Group Policy\Client\RunOnce

Ist unter diesen Schlüsseln bereits die ID des Items enthalten,
wird es nicht erneut angewendet.


In einer perfekten Welt wäre hier der Artikel am Ende und alle wären glücklich. 

Aber das wäre natürlich zu einfach. Die RunOnce GUID bereitet mehr Probleme als vermutet.

Es gibt verschiedene Situationen bei denen es zu ungewünschten Effekten kommen kann:

Kopieren von Items:

 

Wird ein Item in der GUI kopiert, bleibt dummerweise die ID im XML File gleich, was zur Folge hat, dass das kopierte Item nicht angewendet wird.

Sollen also z.B. fünf Dateien kopiert werden und es wird ein Item angelegt und anschließend vier mal kopiert, so wird nur die erste Datei kopiert.
Die folgenden vier Dateien (Items) werden nicht kopiert, da bereits die ID hinter den genannten Registry-Keys hinterlegt sind.

Das genannte Verhalten habe ich bereits hier reklamiert:

http://social.technet.microsoft.com/Forums/nb-NO/winserverGP/thread/ab2fa3c8-3ad0-4068-8a99-da70f7f1f34e

Im Nachhinein musste ich feststellen, dass diese teilweise schon seit 2009 bekannt ist, jedoch immer noch keine Lösung seitens Microsoft vorliegt.

Item Level Targeting und RunOnce:

Erschwerend hinzu kommt, dass "Apply once and do not reapply" nicht wirklich mit Item Level Targeting (Zielgruppenadressierung) zusammen spielt.

Auch wenn die Bedingungen des ILT nicht erfüllt sind, wird die ID des RunOnce Filters in die Registry gespeichert.

Das Item wird also nie mehr angewendet, auch wenn die Bedingungen des Item Level Targeting irgendwann erfüllt sein sollten.

Fehlende Fehlerprüfung:

Auch hier wurde nicht (oder wenig) mitgedacht.

Selbst wenn das Item nicht korrekt angewendet werden konnte,
die ID wird auch dann in der Registrierung hinterlegt.

Besserung in Sicht:

Die gute Nachricht, zwei der drei Fehlerquellen werden mit SP1 für Windows 7 bzw. Server 2008 R2 beseitigt.

Verantwortlich hierfür ist dieser Hotfix:
http://support.microsoft.com/kb/2284538/en-us

Was bleibt, das Kopieren der Items.
Dieses erzeugt auch unter SP1 noch denselben Fehler.

Update 20.08.2012

Die gute Nachricht, unter Windows Server 2012 wird beim Kopieren von Items eine neue ID erzeugt!

GUID zu Name, Name zu GUID

Namen sind Schall und Rauch.

Das weiß jeder, der sich bereits einmal mit Active Directory, Datenbanken oder ähnlichen Systemen befasst hat.

Genauso ist es auch bei den Gruppenrichtlinien.

Der Anzeigename einer Richtlinie kann jederzeit geändert werden. 

Der Globally Unique Identifier (GUID) jedoch bleibt immer gleich.

Da der Mensch sich von Natur aus jedoch solche Zeichenfolgen nicht unbedingt merken kann, wird oftmals der Anzeigename benutzt.

Wie komme ich aber am schnellsten von der GUID auf den Namen?
Oder vom Namen auf die GUID der Richtlinie?


Microsoft selbst nennt einige Wege.
Einer davon, das Skript "search.vbs".

http://support.microsoft.com/kb/216359/en-us

Wo wird also der Name der GPO gespeichert?

Noch unter Windows 2000 Zeiten wurde der Name in der GPT.ini innerhalb des
GPT (Group Policy Template) gespeichert

Wir reden also von:

\\domain.local\sysvol\domain.local\Policies\{GUID}\GPT.ini

Ab Windows 2003 wird jedoch nur noch ein Dummy Name an dieser Stelle gespeichert. In der Regel displayName=Neues Gruppenrichtlinienobjekt.

(dies unterscheidet sich natürlich zwischen den Sprachversionen der GPMC).

Der eigentliche Name steht da wo er hingehört, im AD.

Zu finden unter:

CN=Policies,CN=System,DC=domain,DC=intern
Attributname: DisplayName

Was fällt uns also noch ein?

Die GPMC Sample Scripts.

Ja eine Möglichkeit.

Dort gibt es unter anderem ein Skript namens "ListAllGPOs.wsf".

 

Was gibt es noch?

Ja richtig PowerShell!

Dort gibt es ein cmdlet mit dem Namen "Get-GPO".

Problem nur, dieses Modul muss erst einmal importiert werden...

Ok, noch einmal einen Schritt zurück.

Im Prinzip lässt sich der Name bzw. die GUID mit jedem Tool ermitteln, dass LDAP spricht.

Was könnte man also benutzen das ohnehin schon an Bord ist?
dsquery! Jeder Server der das Feature "AD DS Snap-Ins and Command-Line Tools" installiert hat (was DCs logischerweise haben sollten :-) ) kann dsquery benutzen.

Um das Ganze abzukürzen, hier ein kleines Batchfile mit dem ihr nach Name oder GUID suchen könnt:

@echo off

:choice
cls
set /p gpname=Please enter name or GUID:
Echo
cls

Echo.
Echo List of GPOs
Echo.

Dsquery * domainroot -filter (objectCategory=groupPolicyContainer) -attr Name DisplayName -limit 0 | find "%gpname%" /i
Echo.

set /P c=Do you want to search again [ENTER/N]?
if /I "%c%" EQU "" goto :choice
 
rem Die letzte Zeile kann nach Bedarf weggelassen werden.
rem if /I "%c%" EQU "N" exit

Es erscheint dieser Prompt:

Danach das Ergebnis:

Old School, aber funktioniert.

The lies of GPOs! #6

#6

"In der GPMC gibt es keine Suchfunktion"

Kurz und knapp: Es gibt sie doch!
Leider versteckt sich diese Suche etwas:

Rechtsklick auf die Domäne > Suche

 

Danach erscheint dieser Dialog:

Was aber wenn ich eine bestimmte Einstellung suche?
 

Auch kein Problem. 

ADMX Vorlagen lassen sich durchsuchen. 

Rechtsklick > Filteroptionen

Anschließend kann beliebig gefiltert werden.

Leider muss man anmerken, dass keine dieser Methoden wirklich zeitgemäß ist. Was man vermisst ist eine "live-search", die Policies und Einstellungen sofort filtert ohne dass man in eine direkte Such- oder Filtermaske wechseln muss. Nunja, man kann nicht alles haben ...

CSEs die ohne Richtlinienänderung Einstellungen erneut setzen

Wie im vergangenen Post bereits angekündigt, werden Richtlinien unter gewissen Umständen auch ohne Änderung der Versionsnummer der Group Policy erneut angewendet.

Das Verhalten der Client Side Extensions wird jedoch auch durch einen Registrykey beeinflusst. Dieser Key nennt sich "NoGPOListChanges" und ist zu finden unter:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\GUID\

Existiert dieser Key nicht oder er ist auf 0x1 gesetzt,
werden die Einstellungen dieser CSE auch ohne Versionsänderungen erneut angewendet.
Ich habe mir einmal die Mühe gemacht, eine Liste zu erstellen, mit dem Standardverhalten der folgenden CSEs:

Name ohne Änderung angewendet Audit Policy Configuration Ja Deployed Printer Connections Ja Enterprise QoS Ja Folder Redirection Ja Group Policy Applications Ja Group Policy Data Sources Ja Group Policy Device Settings Ja Group Policy Drive Maps Ja Group Policy Environment Ja Group Policy Files Ja Group Policy Folder Options Ja Group Policy Folders Ja Group Policy Ini Files Ja Group Policy Internet Settings Ja Group Policy Local Users and Groups Ja Group Policy Network Options Ja Group Policy Network Shares Ja Group Policy Power Options Ja Group Policy Printers Ja Group Policy Regional Options Ja Group Policy Registry Ja Group Policy Scheduled Tasks Ja Group Policy Services Ja Group Policy Shortcuts Ja Group Policy Start Menu Settings Ja IP Security Ja Microsoft Offline Files Ja Software Installation Ja 802.3 Group Policy Nein CP Nein Internet Explorer Branding Nein Internet Explorer Machine Accelerators Nein Internet Explorer User Accelerators Nein Internet Explorer Zonemapping Nein Microsoft Disk Quota Nein QoS Packet Scheduler Nein Registry Nein Remote Desktop USB Redirection Nein Scripts Nein Security Nein TCPIP Nein Windows Search Group Policy Extension Nein Wireless Group Policy Nein

Die vollständige Liste incl. GUIDs der CSEs findet ihr hier:

https://skydrive.live.com/redir.aspx?cid=62a6d19ffda7f555&resid=62A6D19FFDA7F555!112&parid=62A6D19FFDA7F555!110

Nun muss nur noch definiert werden, was man hier unter "angewendet" versteht. Einige CSEs wie z.B. "Software Installation", "Folder Redirection" können bekanntlich nur im Vordergrund ausgeführt werden.

Wenn man also von "die Policy wurde erneut angewandt" spricht, so ist das nicht ganz korrekt. Die Einstellungen der CSE "Software Installation" werden also beim Background-Refresh erneut gezogen, die eigentliche Anwendung der Policy kann jedoch nur im Vordergrund erfolgen, d.h. beim nächsten Startup oder Logon.

The lies of GPOs! #5

#5

"Nur geänderte Gruppenrichtlinien werden erneut angewendet"

Jede Richtlinie speichert die aktuelle Version der Richtlinie an zwei Stellen.
Einmal im Active Directory und einmal in der gpt.ini.

Die gpt.ini liegt im Sysvol des Active Directory unter \\domain.intern\sysvol\domain.intern\Policies\{GUID}.

Es wird sowohl die Version der User- als auch Computerpolicy gespeichert.
Wie der gespeicherte Wert berechnet wird, lässt sich hier nachlesen:

http://blogs.technet.com/b/grouppolicy/archive/2007/12/14/understanding-the-gpo-version-number.aspx

Die allgemein verbreitete Meinung:
Policies werden nur dann erneut angewendet, wenn sich die Versionsnummer ändert.

Testumgebung:

OK, schauen wir uns das in einer Testumgebung einmal an.

In diesem Beispiel wurden drei GPOs angelegt.
In den Richtlinien wurde als Beispiel das Logging für GPOs aktiviert.

Beispiel gpo1:

In gpo2 wurde das Logging für "Datenquellenrichtlinien-Verarbeitung" aktiviert.
In gpo3 wurde das Logging für "Geräterichtlinienverarbeitung" aktiviert.

Wurden die Richtlinien bereits angewandt und wir führen ein "gpupdate" aus,
werden die Richtlinien nicht erneut angewendet.

Dies wird im gpsvc.log vermerkt:
GPSVC(3f0.1850) 12:46:19:400 ProcessGPOs: Processing extension Registrierung
GPSVC(3f0.1850) 12:46:19:400 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3f0.1850) 12:46:19:400 CompareGPOLists:  The lists are the same.
GPSVC(3f0.1850) 12:46:19:400 CheckGPOs: No GPO changes and no security group membership change and extension Registrierung has NoGPOChanges set.

Änderung an gpo1:

Wenn wir nun also gpo1 ändern, so sollte diese erneut angewendet werden.
Die Richtlinien gpo2 und gpo3 jedoch nicht.

Um es zunächst ohne Logfile zu überprüfen, ändere ich manuell mittels regedit alle Werte ab, die von den Policies gesetzt werden.

Per Policy werden diese Werte gesetzt:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
    LogLevel    REG_DWORD    0x2 von gpo1
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
    LogLevel    REG_DWORD    0x2 von gpo2
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
    LogLevel    REG_DWORD    0x2 von gpo3

Diese Werte ändere ich manuell per regedit auf:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x3
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x3
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x3

Wenn nun nur gpo1 erneut angewendet wird, sollte das Ergebnis wie folgt aussehen:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x2 durch die änderte gpo1 gesetzt
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x3 gleichbleibend, da gpo2 nicht verändert wurde
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x3 gleichbleibend, da gpo3 nicht verändert wurde

Das Ergebnis ist jedoch:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x2
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x2
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x2

D.h. es werden alle Policies erneut angewendet, obwohl nur Policy "gpo1" geändert wurde.

Zu erkennen ist das auch im gpsvc.log:
GPSVC(3b0.444) 15:58:28:765 ProcessGPOs: Processing extension Registrierung
GPSVC(3b0.444) 15:58:28:765 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3b0.444) 15:58:28:765 CompareGPOLists:  Different version numbers found

...

GPSVC(3b0.444) 15:58:28:859 ParseRegistryFile: Entering with <\\domain.intern\sysvol\domain.intern\Policies\{A52DB6EF-C428-4FA6-AC0E-C614891A9CC1}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:859 SetRegistryValue: LogLevel => 2  [OK]
...
<\\domain.intern\sysvol\domain.intern\Policies\{A8CD3DB6-5A58-4437-82EB-DDD14A062AA6}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:875 SetRegistryValue: LogLevel => 2  [OK]
...
<\\domain.intern\SysVol\domain.intern\Policies\{4F685E24-6F86-4088-B45C-E9BA66B06B6C}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:906 SetRegistryValue: LogLevel => 2  [OK]
...

Fazit:

In diesem Beispiel wurden also auch Policies angewandt, deren Versionsnummer sich nicht geändert hat (gpo2 und gpo3).

Das Geheimnis - Ändert sich eine GPO innerhalb einer CSE (Client Side Extension), so werden alle Policies, welche Einstellungen dieser CSE besitzen, erneut angewendet.

Habe ich also zum Beispiel 100 GPOs verlinkt, die Einstellungen innerhalb der "Administrative Vorlagen" beinhalten und ich ändere nur eine GPO von diesen, so werden die "Administrativen Vorlagen" von allen 100 Policies erneut angewendet!

Zusätzlich zu diesem Verhalten, lässt sich pro CSE einstellen, ob Einstellungen auch ohne Änderungen übernommen werden sollen.
Dieses Thema werde ich jedoch erst im nächsten Post behandeln.

The IP Address is not a valid DNS address ...

Diesmal ein Phänomen aus dem Bereich DHCP/DNS.
Beim Hinzufügen eines DNS Servers in den Bereichsoptionen des DHCP Servers erscheint folgende Fehlermeldung:

"The IP Address x.x.x.x is not a valid DNS address, do you still want to add it ?"

Bei dieser Fehlermeldung kommen einem erst einmal folgende Gedanken in den Sinn:

• Wurde eine falsche IP-Adresse angegeben?
• Ist der DNS Server vom DHCP Server aus erreichbar?
• Lassen sich Adressen per nslookup auflösen?
• Liegt eine Fehlkonfiguration am DNS Server vor?
• Blockiert eine Firewall ggf. den Netzwerkverkehr?

Nachdem alle diese Fragen geklärt sind und der Server aber sich dennoch nicht ohne Fehlermeldung hinzufügen lässt, stellt sich letztendlich noch die Frage:

• Wie ermittelt der DHCP Server ob es sich um einen gültigen DNS Server handelt? 

Gute Frage. Innerhalb der Technet-Pages finden sich keine relevanten Informationen. Auch sonst nur wenige Suchergebnisse die sich mit diesem Thema befassen.

Deshalb, schauen wir doch einmal was hier passiert.
Dazu hier ein Mitschnitt mittels WireShark:

Nach einer kurzen Analyse lässt sich feststellen, es wird folgende Abfrage ausgeführt: "Standard Query SOA".
Vermeintlich wird also der "Start of Authority" Eintrag abgefragt.
Ok, vielleicht fehlt dieser DNS Eintrag auf dem betreffenden Server.
Dies lässt sich per DNS SnapIn ermitteln oder per nslookup:

nslookup -type=soa domain.local dnsserver.domain.local

Auch das scheint nicht der Fehler zu sein.
Der SOA Record ist vorhanden. Fehlen ggf. noch andere DNS Einträge?
Die benötigten DNS-Records für das Active Directory lassen sich mittels
dnslint /ad prüfen:

http://support.microsoft.com/kb/321045/de
Auch hier, soweit keine Fehler ersichtlich.
Ok, nun also noch einmal ein Blick auf den WireShark Mitschnitt.

Recursion desired: Do query recursively.
Recursion available: Server can do recursive queries.

In einigen Mitschnitten erscheint auch:

Recursion available: Server can't do recursive queries.

Es scheint also eine Prüfung stattzufinden, ob der angegebene DNS Server
"recursion queries" durchführen kann.

Als "recursion query" bezeichnet man den Vorgang, wenn ein Client Anfragen an den DNS Server stellt, dieser die Anfragen aber nicht beantworten kann und deshalb die Anfragen an einen weiteren DNS Server weiterreicht.

Ok, nun sind wir also wieder einen Schritt weiter.

Üblicherweise werden die recursion queries and die "Root Hints" weitergegeben.
Zumindest dann, wenn keine Forwarder eingerichtet wurden.

Hier die Liste der default Root Hints:

Die recursion lässt sich auch direkt am DNS Server testen:

In diesem Falle schlägt diese, wie erwartet, fehl.
Ein Blick in die Firewall des Unternehmens verrät, dass diese Anfrage dort geblockt wird. Nachdem eine Ausnahmeregel definiert wurde, lässt sich der DNS Server ohne Fehler im DHCP Server hinzufügen.
Der recursion test ist ebenfalls erfolgreich.

Fazit:
Beim Hinzufügen eines DNS Servers prüft der DHCP Server (besser gesagt das DHCP Snap-In) ob der DNS Server "recursion queries" ausführen kann.
Hat der DNS Server keine Verbindung zu den Root Hints bzw. die Verbindung ist vorhanden aber die vorhandenen Firewall Richtlinien verhindern die Kommunikation, lässt sich der DNS Server nicht hinzufügen.

The lies of GPOs! #4

#4

"WMI Filter sind nicht performant"

Eine Aussage, zu der auch ich mich immer wieder hinreißen ließ.
Grundlage dieses Posts ist diese Diskussion aus dem Technet Group Policy Forum:

http://social.technet.microsoft.com/Forums/de-DE/gruppenrichtliniende/thread/0c9107c8-2282-4a1f-b5e5-1c9064709908

Vorneweg, die Aussage ist falsch.
Richtig müsste es lauten "einige WMI Filter sind nicht performant".

Aber zunächst, was ist ein WMI Filter?

Ein WMI Filter ist eine von verschiedenen Möglichkeiten, den Wirkungsbereich einer Gruppenrichtlinie zu beschränken.
Bei einfachen Ausgrenzungen wie einzelnen Computern und Benutzern lässt sich dies auch über eine Sicherheitsfilterung realisieren.

Was ist aber z.B. wenn die Richtlinie nur für alle Windows Server 2008 gelten soll?

In diesem Falle kann z.B. ein WMI Filter benutzt werden.
WMI = Windows Management Instrumentation

mehr Informationen:
http://www.microsoft.com/germany/technet/datenbank/articles/600682.mspx
http://blogs.technet.com/b/askperf/archive/2007/06/12/wmi-architecture-basics.aspx

Der funktionierende Filter für unser Beispiel wäre also:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE “6.0.%” AND ProductType <> “1”

Dieser Filter kann vorab getestet werden. Z.B. mit diesem PowerShell Befehl:

Get-WmiObject -query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '6.0.%' AND ProductType <> '1'"

Wird dieser Befehl nun beispielsweise auf einem Windows 7 System ausgeführt,
erhält man kein Ergebnis.
Für einen WMI Filter innerhalb einer GPO würde dies bedeuten, der WMI Filter liefert das Ergebnis "false".  Die Policy wird nicht angewendet.


Zeiten messen:

Nun aber zum eigentlichen Problem, die Ausführungszeit eines WMI Filters.
Diese lässt sich ebenfalls mit einem PowerShell Befehl ermitteln:

measure-command {Get-WmiObject -query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '6.0.%' AND ProductType <> '1'"} 

Der Output ist wie folgt:

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 80
Ticks             : 800080
TotalDays         : 9,26018518518518E-07
TotalHours        : 2,22244444444444E-05
TotalMinutes      : 0,00133346666666667
TotalSeconds      : 0,080008
TotalMilliseconds : 80,008

Dieser WMI Filter benötigt also in etwa 80 Millisekunden auf meinem Testgerät.

Weshalb also die Idee, ein WMI Filter könnte die Abarbeitung der Gruppenrichtlinien deutlich verlangsamen?

Die Aussage selbst stammt direkt von Microsoft:

"WMI filters can take significant time to evaluate, so they can slow down logon and startup time. The amount of time depends on the construction of the query."

"...  Also, there is no time-out for WMI filters. Use them only when necessary."

http://technet.microsoft.com/de-de/library/cc758471(WS.10).aspx

Diese Aussage ist allerdings nun schon einige Jahre alt und trifft auf moderne Systeme die mit Multi-Cores arbeiten nur noch bedingt zu.

Die Testumgebung:

Um reale Daten zu liefern, hat MVP Mark Heitbrink folgende Testumgebung benutzt (vielen Dank noch einmal an dieser Stelle):

• 200 GPOs
• 200 WMI Filter
• "select * from Win32_IP4RouteTable where Name like '192.168.22.%'"

Ergebnis:

Übernahme GPO Prozess mit 5 "Standard" GPOs: 0,6 - 0,7 Sekunden
Übernahme GPO Prozess mit 200 WMI GPOs: 4,3 - 4,7 Sekunden

Also eine Differenz von 3,5 - 4 Sekunden, also nahezu nichts.

langsamer Filter:

Welcher Filter kann also z.B. ein System ausbremsen?
Nehmen wir doch einmal diesen Filter:

measure-command {Get-WmiObject -query "Select * from Win32_Product where Name like '%Adobe Reader%'"}

Die Ausführung dauert auf meinem Testsystem 66 Sekunden.
(wohl gemerkt bei einem Intel Core i5)

Die schlechte Performance der Win32_Product Klasse ist bekannt.
In diesem Beispiel soll der Filter nach dem "Adobe Reader" suchen.
Ist dieser installiert, wird ein "true" zurückgegeben.

Damit die Abfrage Daten liefern kann, muss diese jedoch intern den MSI Provider benutzen. Dadurch wird ein Konsistenzcheck über alle installierten MSI Pakete ausgelöst, welcher eine Neukonfiguration und Reparaturinstallation aller Pakete startet. Je nach Anzahl der installierten MSI Pakete kann dies viel Zeit in Anspruch nehmen.

Dokumentiert ist dieses Verhalten unter diesem KB Artikel:
http://support.microsoft.com/kb/974524

Dieser Filter ist nur ein Beispiel, ein anderes wäre z.B. der WMI Provider für Active Directory. Dieser kann je nach Query ebenfalls längere Zeit in Anspruch nehmen.

Timeout?

Nun stellt sich also die Frage, gibt es einen Timeout bei der Abfrage von WMI Filtern (einer GPO)?
Gut, das hatten wir bereits geklärt oder?

"... Also, there is no time-out for WMI filters. Use them only when necessary."

Dies trifft aber ab Windows 6.0 SP2 und Windows 6.1 SP1 nicht mehr zu.
Hier wurde ein weiterer WMI Provider für GPO WMI Filter eingeführt, der alle WMI Abfragen die länger als 30s dauern mit "false" beantwortet.
Erkennbar ist dies im gpsvc.log:

GPSVC(424.49c) 12:34:17:615 ProcessGPO: Searching <cn={A865D64C-77CF-4BE5-B600-5712D1C932F9},cn=policies,cn=system,***>
GPSVC(424.49c) 12:34:17:615 ProcessGPO: Machine has access to this GPO.
GPSVC(424.49c) 12:34:17:615 FilterCheck: Found WMI Filter id of: <[***;{C7920CE4-D605-4A2E-9F1F-A3401000132E};0]>
GPSVC(424.49c) 12:34:47:585 FilterCheck: Evaluate returned error. hr=0x80041069

Leider konnte ich bisher keine offizielle Doku zu diesem Verhalten finden.
Ein weiterer Grund, den WMI Filter vorher zu messen und sorgsam auszuwählen.

Fazit:

WMI Filter sind nicht per se unperformant.
Es kommt auf den jeweiligen Filter an.
Als grober Anhaltspunkt kann der Filter vorher mittels dem PowerShell Befehl measure-command gemessen werden.

Tipp:

Die genauen Laufzeiten der WMI Filter sind im gpsvc.log erkennbar.
Das Logging kann per Registry aktiviert werden:

http://blogs.technet.com/b/deds/archive/2010/01/12/group-policy-debug-logging-gpsvc-log-in-windows-7-und-server-2008-r2.aspx

Um das Logfile vernünftig mit dem Policy Reporter von SysPro auszuwerten:
http://www.sysprosoft.com/policyreporter.shtml