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
Hat man erst einmal die Logik hinter den ILTs verstanden, lassen sich relativ einfach selbst komplexe Filter bilden.
Typische Beispiele:
Eine relativ beliebter Filter ist des "IP Address Range Targeting".
Stellen wir uns zum Beispiel folgendes Szenario vor:
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".
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:
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.
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
Das erste Item setzt die Variable auf "YES":
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
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.
