Samstag, 31. Dezember 2011

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


2 Kommentare: