Freitag, 31. August 2012

Group Policy Preferences ohne Verbindung zum DC - kann das gut gehen?

Was ist Item Level Targeting?

Eines der meist genutzten Features der Group Policy Preferences ist das "Item Level Targeting". Mithilfe des ILT lassen sich einzelne Elemente mit einer
großen Anzahl an vorgefertigten Filtern versehen.

Noch bevor es die Preferences gab, konnte nur unterschieden werden, 
ob die gesamte Richtlinie bzw. der Benutzer- oder Computeranteil für den jeweiligen Anwender bzw. Computer gültig ist.

Item Level Targeting geht hier einen Schritt weiter und filtert innerhalb einer bereits zutreffenden Richtlinie die einzelnen Elemente.


Eine Liste aller ILTs findet ihr hier:

http://technet.microsoft.com/en-us/library/cc733022.aspx


Wie kann ich mir diese Filter zunutze machen?

Hat man erst einmal die Logik hinter den ILTs verstanden, lassen sich relativ einfach selbst komplexe Filter bilden.

Typische Beispiele:
  • Alle Notebooks / alle Desktops
  • Filter auf die Betriebssystemversion
  • Filter auf Sicherheitsgruppen
  • Benutzerdefinierte LDAP Filter
  • WMI Filter
  • IP-Range Filter
Und nun ein typisches Szenario:

Eine relativ beliebter Filter ist des "IP Address Range Targeting".
Stellen wir uns zum Beispiel folgendes Szenario vor:
  • Wir möchten eine Umgebungsvariable "OFFICE" erzeugen
  • Diese Variable soll auf "YES" gesetzt werden, so lange der Rechner mit dem Firmennetzwerk verbunden ist
  • Ist der Rechner außerhalb des Firmennetzwerkes, soll die Variable auf "NO" gesetzt werden
Wir erzeugen folgende Policy.

Das erste Item setzt die Variable auf "YES":

Wir erzeugen ein Item Level Targeting:


Nun erzeugen wir das Item, dass die Variable auf "NO" setzt, sobald wir in einem anderen Netzwerk als 172.16.0.0 bzw. 172.17.0.0 sind:


Dass sollte es gewesen sein.

Und nun der Funktionstest:

Zuerst innerhalb des Firmennetzwerkes:



Die Variable wird wie erwartet auf "YES" gesetzt.

Nun der Test außerhalb des Firmennetzwerkes (192.168.0.0).
Der Rechner wird zusätzlich gebootet.


Die Variable steht wider Erwarten auf "YES".

Was ist hier also passiert?

Ein Blick ins gpsvc.log verrät:

GPSVC(3a4.414) 08:59:32:968 Wait for network connectivity timed out... proceeding to apply policy.
GPSVC(3a4.414) 08:59:33:234 NlaQueryNetSignatures returned 1 networks
GPSVC(3a4.414) 08:59:33:234 NlaGetIntranetCapability failed with 0x15
GPSVC(3a4.414) 08:59:33:234 There is no domain compartment


etwas später:


GPSVC(3a4.50c) 08:59:49:484 NlaGetIntranetCapability returned Not Ready error. Consider it as NOT intranet capable.
GPSVC(3a4.50c) 08:59:49:484 There is no connectivity

Der Policy Zyklus schlägt fehl.
Für die "normalen" Policies ist dies kaum von Bedeutung.

Bei den Preferences hat dies jedoch eine massive Auswirkung.

Die Policy wird nicht gelesen und es kann auch nicht auf das XML-File der Policy zugegriffen werden.

Im XML-File der Policy befinden sich ebenfalls die Item Level Targetings.

Die Variable wird nicht wie erwartet geändert.

Fazit:

Um Richtlinien korrekt anwenden zu können, benötigen wir also immer eine Verbindung zum Domaincontroller bzw. zum Firmennetzwerk.

Preferences die sich auf unterschiedliche Netzwerke beziehen, funktionieren nur dann, wenn aus diesen Netzwerken heraus ein Domaincontroller erreichbar ist.

Da viele Einstellungen die per Group Policy Preferences geschrieben werden, auch direkt vom Benutzer geändert werden können (Einstellungen die im Benutzeranteil der Policy definiert sind), hat man keine Kontrolle über diese Einstellungen wenn keine Verbindung zum DC besteht.

Wollen wir zum Beispiel einen Registrykey setzen, funktioniert das
perfekt solange der Benutzer sich innerhalb des Firmennetzwerkes befindet.

(selbst wenn der Benutzer den Key ändert, wird er beim nächsten Policy-Zyklus erneut gesetzt)

Verlässt er jedoch dieses Firmennetzwerk, so kann er den Key unter Umständen ändern und er wird erst dann erneut gesetzt, wenn der Benutzer wieder Kontakt zum Domänennetzwerk hat.

Dienstag, 7. August 2012

GPP und der Internet Explorer 9 - Das endlose Drama?

Man muss sich schon einmal fragen, was sich Microsoft dabei gedacht hat...

Mittels Group Policy Preferences lassen sich die Einstellungen des Internet Explorers steuern. Das funktioniert auch wunderbar, zumindest unter IE 5,6,7 und 8.

Kommt jedoch ein IE 9 ins Spiel, wird es kritisch.

Das Problem:

Beim Programmieren der GPMC von Windows 7 (Vista, Server 2008 und Server 2008 R2) gab es noch keinen IE 9.
Die Einstellungen der Preferences werden bekanntlich in XML Dateien gespeichert. Dort wird ein Eintrag erzeugt, der die maximal unterstützte Version des Internet Explorers angibt.


Folglich steht diese Version auf max="9.0.0.0" .
Was nichts anderes bedeutet, als Internet Explorer 8 - jedoch nicht Internet Explorer 9.

Auf Einzelheiten möchte ich hier nicht näher eingehen, dass
wurde bereits an anderer Stelle vielfach getan.


http://www.grouppolicy.biz/2011/03/how-to-enable-group-policy-preferences-support-for-ie9/


http://blogs.technet.com/b/asiasupp/archive/2011/03/30/internet-explorer-9-ie9-group-policy-preferences-gpp.aspx

Seit einiger Zeit hat Microsoft einen Hotfix bereitgestellt, der
dieses Verhalten ändert.
Jedoch muss dieser Hotfix auf jedem Client installiert werden,
der Preferences für den Internet Explorer bearbeiten soll.


http://support.microsoft.com/kb/2530309

Vorhandene Preferences werden nicht abgeändert.


Es gibt also zwei Lösungsansätze:

1. Manuelles Editieren der XML Datei
2. Hotfix "KB2530309" auf jedem Client installieren der Policies bearbeitet


Egal für welche Lösung man sich entscheidet, es bleibt immer ein Problem:

Sollte jemand eine Policy editieren (z.B. neue Items einfügen) bzw. eine neue Policy anlegen die GPP IE Settings enthält, wird unter Umständen wieder eine nicht kompatible InternetSettings.xml erzeugt (wenn z.B. dieser Computer den Hotfix nicht installiert hat).


Was mache ich jedoch wenn ich wissen möchte, welche Policy Einstellungen enthält, die nicht IE 9 konform sind?

Entweder:

Jede Policy manuell durchkämmen

Oder:

GPP Incompatible IE XML Finder


Ich habe mir einmal die Mühe gemacht dieses kleine Tool zu programmieren.


Das Progamm durchsucht das SYSVOL Verzeichnis nach allen InternetSettings.xml und wertet diese Dateien aus.

Es werden alle Policies angezeigt die nicht IE 9 konform sind (bzw. IE 10 konform). Sind in einer Policy mehrere Items enthalten die nicht konform sind, so wird diese Policy mehrfach angezeigt.




Die betreffenden Policies können dann mit der GPMC gefixed werden.

Bei diesem Tool handelt es sich noch um Version 1.0.

Solltet ihr Bugs entdecken, schreib mir schreibt einen Kommentar.

Das Programm benutzt ihr natürlich auf eure eigene Verantwortung.

Download


PS:
Unter Windows 8 bzw. Server 2012 ist das Verhalten nun endlich anders.

GPP unterstützen sowohl IE 9 als auch den IE10.



Erzeugt man ein Item für IE 10, so wird in das XML File
max="99.0.0.0" eingetragen. 


Die erzeugten Items sind dann automatisch mit zukünftigen IE Versionen kompatibel.


Update 12.09.2012

Zur Vollständigkeit, es gibt noch einen dritten Lösungsweg.


Im XML-File befindet sich ein Eintrag hidden="1".

Dadurch wird das Item Level Targeting nicht im GUI angezeigt.
Ihr könnt den Wert hidden auf 0 setzen.

Dann erscheint der Versionsfilter in der GUI:

Der Filter kann dort ebenfalls editiert werden.
Theoretisch kann er sogar komplett entfernt werden.


Das macht jedoch nur bedingt Sinn, da dann absolut keine Versionsprüfung mehr stattfindet. (weder für IE 8,9,10 noch für 5,6,7).


Update 01.08.2013:

Version 1.1 des "GPP Incompatible IE XML Finder" veröffentlicht.

- Domäne kann nun manuell ausgewählt werden

- Programm wird im Fehlerfalle nicht mehr beendet