Donnerstag, 13. Dezember 2012

Drag & Drop von Preference Items funktioniert nicht mehr unter Windows 8

Heute wieder einmal ein Fehler, der zwar nicht gelöst werden kann, aber für den es zumindest einen Workaround gibt.

In den "Remote Server Administration Tools" (RSAT) unter Windows 8 oder Server 2012 ist ein Bug vorhanden, der das Importieren von GPP Items per Drag & Drop verhindert.

Exportieren und Importieren von Items

Exportieren:

Die betreffenden Elemente können einfach auf den Desktop gezogen werden. 


Danach wird dort eine XML Datei angelegt.


Diese Datei lässt sich dann editieren oder einfach nur als Sicherungskopie aufbewahren.


In gleicher Weise konnte man unter Windows 7 und Server 2008 R2
Elemente importieren.


Importieren:

Versucht man jedoch in den Windows NT 6.2 RSAT Elemente zu importieren, so erscheint das Drop-Symbol nicht:




Nach längerer Recherche scheint es so, also wäre schlichtweg nur ein
Drag-Event vorhanden, jedoch kein Drop-Event.
Dies scheint wohl in der Programmierung schief gelaufen zu sein.


Wann benötigt man den Import von XML Dateien?
  • Man möchte eine Sicherungskopie des Preference Item wiederherstellen 
  • Man möchte eine manuell editierte XML Datei importieren
  • Man benutzt reg2xml
Mittels reg2xml lassen sich .REG Dateien in .XML Registrierungselemente umwandeln. Die konvertierten XML Dateien werden dann per Drag & Drop in die GPMC eingefügt.

Wie lassen sich die XML Dateien importieren?


Workaround 1:


Die Datei per Kontextmenü kopieren und einfügen:



Workaround 2:


Der zweite Lösungsweg ist etwas umständlicher.


Zunächst muss ein Dummy-Element in der GPMC angelegt werden.
Dies ist wichtig für die Erzeugung der XML Datei und der Registrierung der jeweiligen CSE im AD Objekt der Policy.

Nun muss man per Explorer zur jeweiligen Policy navigieren.


Im Falle eines Registry-Items ist dies:


\\domain.local\SYSVOL\domain.local\Policies\{GUID}\machine\Preferences\Registry

bzw.


\\domain.local\SYSVOL\domain.local\Policies\{GUID}\user\Preferences\Registry

Dort befindet sich eine Registry.xml die ersetzt werden muss.

Weitere Information zu diesem Thema:

http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/2abf6cb1-d900-4d21-a59e-c9687c564b0d


Sonntag, 11. November 2012

User Shell Folders - Umgebungsvariablen umbauen mittels Group Policy Preferences

Group Policy Preferences bringen von Haus aus eine Menge von
Variablen mit. Drückt man die Taste "F3" in einem Textfeld, so erscheint die
 

Liste von verfügbaren GPP-Umgebungsvariablen:


Link zu allen GPP-Variablen



Zusätzlich können die vom System bereitgestellten "normalen" User- und Systemvariablen verwendet werden.
So gibt es in den GPP Variablen zum Beispiel keine Komponente für den Pfad
"C:\Program Files (x86)". Es kann die normale Variante "%ProgramFiles(x86)%" benutzt werden.


Teilweise ist dies aber nicht genug.
Dies gilt vor allem für die sogenannten User Shell Folders.


User Shell Folders


Diese USF befinden sich in der Registry unter:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders


In diesem Bereich werden Pfade zu Explorer Verzeichnissen gespeichert.

Mit ein paar einfachen Schritten lassen sich diese Schlüssel in Umgebungsvariablen umbauen, die dann für Group Policies oder auch allgemeine Zwecke benutzt werden können.

Umbau der USF mittels GPP

1. Schritt

Wir erzeugen eine neue Umgebungsvariable mittels GPP.


Zu finden unter:

Computer Configuration or User Configuration
   └ Preferences
      └ Windows Settings
         └ Environment

In unserem Beispiel handelt es sich um "User Configuration".
Als Wert weisen wir jedoch eine temporäre Variable "%TEMPVAR%" zu.


 
2. Schritt

Diese Variable muss nun gefüllt werden.
Hierbei hilft uns das "Item Level Targeting" kurz ILT.


Wir legen ein ILT auf Basis von "Registry Match Targeting" fest.

Als "Match type" wählen wir "Get value data".



Fertig.
Da zuerst die Filter überprüft werden, wird der betreffende Registrykey ausgelesen. Dieser wird in eine temporäre Variable geschrieben, %TEMPVAR%.
Diese Variable füllt dann unsere "richtige" Variable %LINKS%.


Known Folder GUIDs for File Dialog Custom Places

Auf diesem Wege lassen sich auch die Known Folder GUIDs umbauen.
Allerdings werden diese an unterschiedlichen Stellen in der Registry gespeichert.

Ein Teil davon landet unterhalb der USF. 

Der Großteil jedoch unter:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions


Inwieweit sich die KFGs in Variablen umbauen lassen, hängt von den gespeicherten Werten ab.

Fazit:

Mittels Item Level Targeting und der Environment CSE lassen sich sehr flexibel
Registrywerte in benutzbare Umgebungsvariablen umwandeln.

Montag, 5. November 2012

Windows 8: GPP Drive Mapping als Administrator schlägt fehl

*** Informationen zum Update KB2795944 siehe Ende des Posts ***

Unter Windows 8 und Server 2012 gibt es einen Bug, der das Mapping von Laufwerken fehlschlagen lässt.

Der Fehler tritt unter folgender Konstellation auf:
  • Die Laufwerke werden per GPP Drive Mapping gemappt
  • Als Betriebssystem wird Windows 8 oder Server 2012 eingesetzt
  • Das gemappte Laufwerk befindet sich in einem DFS-Namespace
  • Der DFS-Namespace läuft auf Windows Server 2008 R2, 2008 oder 2003
    (nicht 100%ig verifiziert)
  • Der Benutzer der sich anmeldet, ist Mitglied der lokalen Gruppe "Administrators" (SID S-1-5-32-544)
  • Die Option "Reconnect" im GPP Item ist aktiviert 
  • Der Fehler tritt selbst bei komplett deaktivierter UAC auf
Der Fehler äußert sich wie folgt:
  • Die Laufwerke werden nicht verbunden
  • Teilweise bei erster Übernahme der Policy wird jedoch das Laufwerk gemappt
  • Das Tracing der GPP Drive Maps CSE zeigt keine Fehler
  • Innerhalb des RSOP wird als Status der CSE "Pending" angezeigt


EnableLinkedConnections:

Einigen sollte ein ähnlicher Fehler bekannt sein, der im Zusammenhang mit der
Benutzerkontensteuerung und Anmeldeskripten auftritt.


http://support.microsoft.com/default.aspx?scid=kb;EN-US;937624

http://think-like-a-computer.com/2011/06/16/login-scrips-fail-map-drives/

Die Kurzfassung: Anmeldeskripte werden mit dem vollständigen Access-Token ausgeführt, insofern der Benutzer administrative Rechte auf dem Client hat.
Die Laufwerke werden folglich mit dem vollständigen Token gemappt.
Die Benutzersession (explorer.exe usw.) läuft jedoch unter dem gefilterten Token (welcher weniger Rechte besitzt).


Da beide Token eine unterschiedliche Logon-ID besitzen, schlägt der Zugriff auf die Laufwerke fehl.

Zitat Microsoft:
If a user is logged on to Windows Vista or to Windows 7, and if User Account Control is enabled, a program that uses the user’s filtered access token and a program that uses the user’s full administrator access token can run at the same time. Because LSA created the access tokens during two separate logon sessions, the access tokens contain separate logon IDs. 

Das Verhalten lässt sich mittels des Registry-Keys "EnableLinkedConnections" abstellen. Ein anderer Workaround ist das Skript "launchapp.wsf".

Zurück zu unserem Problem.
Da der Drive Mapping Fehler bei Windows 8 und Server 2012 auch bei komplett deaktivierter UAC auftritt, trifft das "
EnableLinkedConnections" Problem nicht zu.

Von einigen Usern wurden bereits Supportanfragen zu diesem Thema bei Microsoft eröffnet.
Der Fehler wurde auch von mir bei Microsoft eingereicht.
Nach langem Hin und Her lautet das Ergebnis:

By Design.


By Design ist bei Microsoft alles, was man nix fixen will bzw. was 
"so ist, wie es ist". Toll.

Wie ihr den Fehler dennoch umgehen könnt, erfahrt ihr hier:


Der Workaround

Im Item der Preference muss die Reconnect-Option deaktiviert werden:



Dies hat allerdings folgenden Nachteil:

User die sich ohne Netzwerkverbindung anmelden, erhalten keine Laufwerke.
Da die CSE "GPP Drive Maps" standardmäßig nur im Vordergrund ausgeführt werden kann, werden die Laufwerke erst dann wieder verbunden, wenn der Benutzer sich das nächste Mal mit Netzwerkverbindung anmeldet.

Dies ist insbesondere ein Nachteil für VPN Benutzer.


Zu hoffen bleibt, dass Microsoft die Auswirkungen dieses Bugs erkennt und eine "richtige" Lösung präsentiert.

Die Hoffnung stirbt zuletzt.

Update 13.02.2013:
Microsoft hat nun reagiert und ein Update bereitgestellt, welches den Fehler beheben soll.


Leider wird in der Beschreibung dieses Updates nicht weiter auf das Drive-Mapping Problem eingegangen.
Es handelt sich um ein "reguläres", nicht kritisches Update (als kein Hotfix), welches unter anderem auch per WSUS verfügbar ist.


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

Mittwoch, 26. September 2012

Geplante Aufgabe als SYSTEM ausführen - Fehler 0x80070534

Die CSE "Scheduled Tasks"

Die Group Policy CSE "Scheduled Tasks" bietet eine einfache Möglichkeit
Aufgaben per Richtlinie zu konfigurieren.





Die Tasks können entweder per Benutzerkonfiguration oder Computerkonfiguration erstellt werden.

Benutzt man die User-Config, so lässt sich die Aufgabe zum Beispiel als angemeldeter Benutzer ausführen.


Es können die Variablen "%LogonDomain%\%LogonUser%" benutzt werden.




Kennwort speichern?

Anders schaut es bei der Computerkonfiguration aus.
Hier muss explizit ein Benutzer angegeben werden:




Es kann ein lokaler Benutzer oder ein Domänenbenutzer verwendet werden.



Verteilt man "Geplante Aufgaben" per Group Policy Preferences,
so möchte man in der Regel jedoch nicht das Passwort in der Group Policy speichern. 



Die Begründung liefert unter anderem dieser Technet Blog:
To obscure the password from casual users, it is not stored as clear text in the XML source code of the preference item. However, the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it. Additionally, it can be read by the client in transit if the user has the necessary permissions.

Because passwords in preference items are not secured, we recommend that you carefully consider the security ramifications when deciding whether to store passwords in preference items. If you choose to use this feature, we recommend that you consider creating dedicated accounts for use with it and that you do not store administrative passwords in preference items.

quelle:
http://blogs.technet.com/b/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx


Welchen Account benutzen?

Welchen Account könnte man also benutzen, der ausreichend Rechte auf dem Computer hat, jedoch es nicht erfordert ein Passwort zu speichern?

Die Antwort:
SYSTEM


OK, nichts leichter als das.
Per Object-Picker auswählen und gut ist es!?





Eingetragen wird anschließend "BUILTIN\SYSTEM" im UI des
GPP Items.


Wie verhält sich der Client?

Gleich vorneweg, der Task wird niemals am Client erzeugt werden.
Aktiviert man das Tracing der CSE, so erhält man folgenden Fehler:

[ hr = 0x80070534 "Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt." ]


Der Benutzer "BUILTIN\SYSTEM" kann also nicht zugeordnet werden.


Nächster Versuch, manuelles eingeben des Benutzers "SYSTEM":




Das Policy Item lässt sich speichern.
Am Client schlägt allerdings der gleiche Fehler auf, 0x80070534.


Wie verhält es sich, wenn der Task manuell angelegt wird?

Aufgaben werden im XML Format bereitgestellt.
Wenn wir manuell einen Task erzeugen, kann dieser als XML Datei exportiert werden.


<Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
 </Principals>


Der User "SYSTEM" (genau genommen ist dies gar kein User, aber egal),
wird also mit seiner SID "S-1-5-18" eingetragen.


Schaut man sich allerdings das XML File der Policy an, wird er mit diesem Wert
hinzugefügt:

runAs="BUILTIN\SYSTEM"
Der Client kann dies nicht umsetzen und quittiert dies mit dem genannten Fehler.

Erzeugt man die Policy mit der SID, wird sie am Client übernommen.
Der Client übersetzt sogar die SID zum User "SYSTEM".




Fazit:

Sollen Tasks als Local System ausgeführt werden, so muss die SID als Benutzername verwendet werden.

Hier noch eine Liste der "Well-known security identifiers"

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



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

Freitag, 20. Juli 2012

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:

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.

Freitag, 29. Juni 2012

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

Donnerstag, 31. Mai 2012

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

Donnerstag, 12. April 2012

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


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!

Montag, 5. März 2012

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



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.

Mittwoch, 15. Februar 2012

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