Erste Hilfe:

 

Eine kleine Hilfe für die ersten Probleme mit Richtlinien

 

 

Antwortversuch auf die Frage: „Ich habe eine Richtlinie erstellt, aber sie wird nicht angewendet. Warum?“

 

Grundsätzlich hat man an dieser Stelle dass Problem, dass es von Umgebung zu Umgebung sehr viele Ursachen haben kann, sodass hier nur ein paar Kontroll- und Prüfmechanismen angesprochen werden können um das Problem oder Fehler zu finden.

 

Der wohl häufigste Grund, dass die Richtlinien nicht zu Anwendung kommen liegt an einem falsch konfigurierten DNS, oder dass die Clients diesen nicht eingetragen haben. Siehe Grundlagen.

 

 

Checkliste:

-          Überprüfung DNS Eintrag im Client und DNS Serverkonfiguration
=> Der DNS Server, der die SRV Records der Domäne hält MUSS! als erster DNS bei den Clients und Server eingetragen sein
 

-          Fehler im Event-Log?
=> wenn, dann sollten userenv + scecli im Eventlog auftauchen, wobei die Source selber schon eine kleine Hilfe bietet.
userenv = Userenvironment
scecli = Security Client
Über diesen beiden Einträge lässt sich das Problem ein wenig eingrenzen, denn anhand der Quelle kann man erkennen, ob das Problem eher Benutzer oder Computerspezifisch ansiedeln muss.
 

-          Ist der Benutzer/Computer in der richtigen OU auf der die Richtlinie angewendet wird?
Der so genannte Verwaltungsbereich einer Richtlinie muss gegeben sein. Das zu treffende Ziel muss auch von der Richtlinie erreicht werden können, also von daher gilt es hier einen genauen Blick auf die Hierarchie und Struktur der Richtlinie und deren Wirkungsbereich zu werfen.
 

-          Wird versucht die Richtlinie auf eine Sicherheitsgruppe anzuwenden? Dieses Vorgehen wird in dieser Form nicht unterstützt.
Aber trotzdem kann einen dieser Punkt Probleme bereiten, da über das Recht "Richtlinien - Lesen" und "Richtlinie - übernehmen" innerhalb der Richtlinie auf Benutzer/Computer und Sicherheitsgruppenebene "gefiltert" werden kann, wer diese Richtlinie anwendet, auch wenn das Objekt ansonsten innerhalb des Verwaltungsbereiches der Richtlinie steht.

 

-          Einen "Klassiker" bei XP Clients stellt das geänderte Bootverhalten von XP gegenüber zu W2K dar. Damit der Benutzer das Gefühl bekommt, daß System würde wesentlich schneller starten, wird die Explorerschnittstelle schon gestartet, obwohl noch nicht alle Dienste zur Verfügung stehen. Diese werden nachgeladen. Dummerweise gilt das auch für die Netzwerktreiber :-(
Zum Anmeldezeitpunkt ist das Netzwerk noch nicht bereit. Was dann zur Ursache hat, daß der Client mit "Cached Logon Credentials" arbeitet und effektiven Richtlinien nicht gelesen hat, obwohl im Startbildschirm "Sicherheitsrichtlinien werden übernommen ..." angezeigt wurde.

Abhilfe:
Computerkonfiguration \ Administrative Vorlagen \ System \ Anmeldung
"Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten"

Damit diese Richtlinie auch wirklich beim nächsten Mal aktiv ist, empfehle ich eine erzwungene Übernahme der Richtlinie in der Kommandozeile:
gpupdate /target:computer /force

 

-          Hilfe zur Fehlerdiagnose, Protokollierung aktivieren und in eine Datei schreiben.

"Aktivierung der Debugprotokollierung für die Benutzerumgebung"
http://support.microsoft.com/kb/221833

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
"UserEnvDebugLevel"= REG_DWORD

UserEnvDebugLevel kann folgende Werte aufweisen:
NONE 0x00000000
NORMAL 0x00000001
VERBOSE 0x00000002
LOGFILE 0x00010000
DEBUGGER 0x00020000

Der Standardwert ist NORMAL|LOGFILE (0x00010001).
Das Protokoll findet man dann unter: %SystemRoot%\Debug\UserMode\Userenv.log

Die Werte können auch kombiniert werden, weiteres dazu siehe KB Link.
 

-          Passen die Vererbungen der einzelnen Richtlinien? In welcher Reihenfolge werden sie angewendet und welche Richtlinien werden überhaupt angewendet.
Wurde an der Default Vererbung der Richtlinie manipuliert? Wurde mit "Kein Vorrang" oder "Vererbung deaktivieren" gearbeitet? Mehr dazu auf meiner Seite unter "Wie? Was? Wo?"

Hilfe bietet hier eine Programm aus dem Ressource Kit, das auch im freien Download erhältlich ist.

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpresult-o.asp

Aufruf am betreffenden PC als der jeweilige User in der Kommandozeile am Besten über „gpresult > result.txt“ Ausgabe des Bildschirmtextes in eine Datei.

 

Nettes Goodie:

Beim Einsatz mit einer XP Workstation sind 2 weitere Optionen für gpresult.exe zusätzlich verfügbar, die unter W2K nicht möglich sind.

 

Bei den Parametern /U und /S können nicht nur die aktuell lokalen Einstellungen abgefragt werden, sondern es kann auch ein Remote-System angegeben werden, bzw. ein anderer Benutzer. Somit bekommt man auch die Möglichkeit eine „Was passiert, wenn sich Benutzer X an Rechner Y anmeldet“ Situation schon vorab zu klären.

 

Aufruf: gpresult /u:benutzername /s:rechnername

Ab Windows XP stehen 2 weitere und meiner Meinung nach bessere Programme als gpresult zur Verfügung:
An der Xp Workstation gibt es das SnapIn rsop.msc => ResultanceSet of Policies. RSOP bietet eine grafische Oberfläche und wertet nicht nur die angewendeten Richtlinien aus, wie gpresult, sondern auch die einzelnen Werte innerhalb des Richtliniensatzes.
Für die Verwaltung der Gruppenrichtlinien im AD gibt es mittlerweile die GPMC, (siehe Downloadbereich). Auch diese bietet eine Möglichkeit zum Thema "Was wäre wenn ..." inkl. Auswertung der einzelnen Einstellungen.

 

-         Ein großes Problem kann in einen MultiDomainController AD natürlich die Replikation sein und dieses sollte in solchen Fällen sofort behoben werden, da die Probleme nicht nur die Richtlinien betreffen. Weitere Hilfe bei Problemen mit Replikationsproblemem oder mehreren Domänen bietet:

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp