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

Endlosschleife bei GPP - 0x8007000d Die Daten sind unzulässig

Group Policy Preferences basieren auf XML Dateien.

Bei der Anwendung der Einstellungen der Preferences werden diese XML Dateien gelesen. 

Die primären XML Dateien befinden sich in der sysvol Freigabe auf dem jeweiligen Domaincontroller.

\\domain.local\sysvol\domain.local\Policies\{GUID}\Machine\Preferences
\\domain.local\sysvol\domain.local\Policies\{GUID}\User\Preferences

In seltenen Fällen kann es vorkommen, dass diese XML Dateien beschädigt und korrupt werden. Den genauen Hintergrund zu dieser Tatsache nennt Microsoft nicht.

Ist das File erst einmal defekt, so lässt sich die Policy nicht mehr anwenden.

Im Eventlog erscheinen folgende (oder ähnliche) Fehlermeldungen:

Fehler beim Anwenden der "Group Policy Files"-Einstellungen. Die "Group Policy Files"-Einstellungen besitzen möglicherweise eine eigene Protokolldatei.

...

Eventid 8194: 0x8007000d Die Daten sind unzulässig

Aktiviert man das Debug-Logging des gpsvc, so lässt sich die GUID und der Name der jeweiligen Policy ermitteln und die betreffende Richtlinie kann gelöscht werden. In den meisten Fällen ist dies ausreichend.

Um die Einstellungen von gelöschten Policies zu revidieren,
werden jedoch zusätzlich auf jedem Computer History-Files erzeugt.

%allusersprofile%\Microsoft\Group Policy\History\{GUID}\Machine\Preferences
%allusersprofile%\Microsoft\Group Policy\History\{GUID}\SID\Preferences

Ist jedoch auch dieses History-File defekt, so wird auch nach der Löschung der Policy (innerhalb der GPMC) weiterhin ein Fehler erzeugt.
Dieser Fehler wird im Eventlog wie folgt vermerkt:

Die clientseitige Erweiterung konnte die Richtlinieneinstellungen für " " nicht  entfernen Computer, da ein Fehler mit Fehlercode "0x8007000d Die Daten sind unzulässig." Weitere Details finden Sie in der Ablaufverfolgungsdatei. aufgetreten ist.

Der Name der Policy kann nicht mehr ermittelt werden. Im gpsvc.log ist folgender Fehler ersichtlich:

2012-06-06 13:56:13.786 [pid=0x408,tid=0x3e48] GPH : C:\ProgramData\Microsoft\Group Policy\History\{GUID}\Machine\Preferences\Files\Files.xml

2012-06-06 13:56:13.786 [pid=0x408,tid=0x3e48] GPH data file : C:\ProgramData\Microsoft\Group Policy\History\{GUID}\Machine\Preferences\Files\Files.xml

2012-06-06 13:56:13.787 [pid=0x408,tid=0x3e48] Completed parse of GPH XML. [ hr = 0x8007000d "Die Daten sind unzulässig." ]

2012-06-06 13:56:13.788 [pid=0x408,tid=0x3e48] Completed remove GPH. [ hr = 0x8007000d "Die Daten sind unzulässig." ]

2012-06-06 13:56:13.793 [pid=0x408,tid=0x5e8] Leaving ProcessGroupPolicyExFiles() returned 0x8007000d

So lange das History-File nicht gelöscht wird, tritt bei jedem GPO Zyklus dieser Fehler erneut auf. Es muss also manuell das History-File gelöscht werden.
Microsoft verhält sich bedeckt und merkt nur an:

"However, some history files are corrupted or unreadable. Therefore, the corresponding Group Policy preferences are not applied successfully."

quelle:

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

Nach dem das File bzw. das gesamte GUID Verzeichnis auf dem Client gelöscht wurde, tritt dieser Fehler nicht mehr auf.

PS:
Teilweise lässt sich der ursprüngliche Fehler (0x8007000d Die Daten sind unzulässig) durch ein simples Kopieren der Gruppenrichtlinie beheben.

Das gpsvc-logging aktivieren

Heute wird es kurz und bündig, aber dennoch wichtig.

Für die erweiterte Fehlersuche lässt sich seit Windows Vista eine separate Logdatei generieren, die gpsvc.log.

Um dieses Logging zu aktivieren, müssen einige Schritte durchgeführt werden.

1. Einen Ordner mit dem Namen "usermode" in %windir%\debug anlegen

2. Die folgende .reg Datei ausführen

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics]
"GPsvcDebugLevel"=dword:00030002
 

Anschließend wird eine Logdatei in %windir%\debug angelegt.

Hier noch die Datei zum Deaktivieren:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics]
"GPsvcDebugLevel"=-
 

Für eine komfortable Auswertung dieser Datei kann der Policy Reporter verwendet werden:

http://www.sysprosoft.com/policyreporter.shtml

Der benötigte Dienst ist nicht vorhanden - Was jetzt?

Eine Frage die immer wieder in verschiedenen Foren auftaucht. 

Man möchte z.B. den Starttyp eines Dienstes verändern, jedoch wird der benötigte Dienst in der GPMC (bzw. dem GP Management Editor) nicht angezeigt.

Stellen wir uns also z.B. vor, wir möchten den Starttyp des Dienstes "Bluetooth Support Service" auf "Automatisch" setzen. Im GP Management Editor (den wir von einem Server 2008 R2 starten) fehlt jedoch dieser Dienst:

Die Lösung des Problems ist relativ simpel.

Einfach irgendeinen vorhandenen Dienst auswählen.
In diesem Beispiel "Block Level Backup Engine Service".

Jetzt die gewünschten Einstellungen setzen.

Anschließend muss die erzeugte .inf Datei manuell bearbeitet werden.

Dazu zu \\domain.local\sysvol\domain.local\Policies\{GUID}\Machine\Microsoft\Windows NT\SecEdit wechseln.

Hier die Datei "GptTmpl.inf" bearbeiten.

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Service General Setting]
"wbengine",2,""

Der Dienstname muss von "wbengine" auf "bthserv" geändert werden.

Wichtig hierbei, es muss der tatsächliche Dienstname verwendet werden, nicht der Anzeigename.

Anschließend wird der Dienst im GP Management Editor angezeigt.

Alternativ können Dienste auch über Group Policy Preferences konfiguriert werden. Jedoch kann hierbei die Sicherheit (die ACLs) des Dienstes nicht bearbeitet werden.

Update 21.08.2012

Vielen Dank an "bttr" für den Hinweis.

Zusätzlich zu der vorgestellten Methode gibt es noch einen alternativen Workaround. 

Mit dem "sc" - Tool kann auf dem Client (auf dem die Policy per GPMC verwaltet wird) ein temporärer Dienst angelegt werden.

sc create Foo binPath= Bar

Nachdem die Policy konfiguriert wurde, kann der Dienst wieder entfernt werden.

sc delete Foo

"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 ...