Troubleshooting von Fehlern bei der Verarbeitung von Gruppenrichtlinien in einer Active Directory-Domäne

Mitglieder einer AD-Domäne (Active Directory) können beim Anwenden der Gruppenrichtlinie aus verschiedenen Gründen Probleme haben. In diesem Artikel werden einige der gängigsten Aspekte beschrieben und es werden Richtlinien für das Troubleshooting der zugrunde liegenden Probleme bereitgestellt.
 
Allgemeines Troubleshooting
Der erste Schritt bei der Behebung dieser Probleme sollte die Ermittlung ihres Ausmaßes sein. Wenn nur ein Computer die Gruppenrichtlinie nicht verarbeiten kann, ist das Problem wahrscheinlich auf eine Fehlfunktion oder Fehlkonfiguration dieses Computers begründet. Wenn das Problem weiter verbreitet ist, besteht das Problem möglicherweise auf einem Domain Controller (DC) oder in AD selbst.

Wenn nur ein Computer betroffen ist, führen Sie gpupdate /force auf dem betroffenen Computer vor dem weiteren Troubleshooting aus. Dadurch wird sichergestellt, dass der Fehler nicht durch ein temporäres Netzwerkproblem verursacht wurde, das inzwischen behoben worden ist.

Wenn ein Computer die Gruppenrichtlinie nicht verarbeiten kann, erzeugt er in der Regel einen oder mehrere Userenv-Fehler im Anwendungsprotokoll. Häufige Ereignis-ID-Nummern sind 1030, 1053, 1054 und 1058. Die Beschreibungen der einzelnen Fehler auf einer betroffenen Computer sollten einen Überblick über das zugrunde liegende Problem geben.

DNS-Probleme
Die häufigste Ursache für Gruppenrichtlinienfehler (und zahlreiche andere Probleme in AD) ist ein Problem mit der Namensauflösung. Wenn die Userenv-Fehler auf einer betroffenen Computer die Formulierung „Netzwerkpfad nicht gefunden“ oder „Domänencontroller kann nicht gefunden werden“ beinhalten, ist das DNS möglicherweise verantwortlich. Im folgenden finden Sie einige Tipps zum Troubleshooting für diese Art von Problem:

• Öffnen Sie eine Eingabeaufforderung auf einem betroffenen Computer und führen Sie nslookup domain aus (z. B.nslookup mydomain.local). Mit diesem Befehl werden die IP-Adressen aller DCs in der Domäne zurückgegeben. Wenn andere Adressen zurückgegeben werden, werden in DNS wahrscheinlich ungültige Datensätze angezeigt. Der Befehl nslookup kann auch verwendet werden, um die Namen der einzelnen DCs in ihre IP-Adressen aufzulösen.
• Führen Sie ipconfig /all auf einem betroffenen Computer aus und überprüfen Sie, ob die Option für die Verwendung interner DNS-Server konfiguriert ist. Die Verwendung falscher DNS-Server ist die Hauptursache für DNS-Probleme in einer Domäne, die problemlos behoben werden können. Alle mit der Domäne verbundenen Computer dürfen nur interne DNS-Server verwenden, die in der Regel DCs sind.
• Wenn der betroffene Computer anscheinend die richtigen DNS-Server verwendet, überprüfen Sie die DNS-Konsole auf einem DC, um zu überprüfen, ob die richtigen Datensätze vorhanden sind. Überprüfen Sie, ob jeder DC über zwei A-Datensätze (Host) in der Forward-Lookup-Zone der Domäne verfügt: eine mit dem Hostname des DC und einen mit demselben Namen wie der übergeordnete Ordner. Beide Datensätze müssen die IP-Adresse des Domänencontrollers enthalten.
• Sobald ein DNS-Problem behoben wurde, führen Sie ipconfig /flushdns auf allen betroffenen Computern aus. Dadurch werden alle ungültigen Daten aus dem Resolver-Cache auf diesen Computern gelöscht.

Secure-Channel-Probleme
Diese Art von Problem tritt auf, wenn das lokal gespeicherte Computerkontopasswort eines Domänen-verbundenen Computers nicht mit seinem Passwort in AD übereinstimmt. Ein Secure-Channel-Problem verhindert, dass sich ein Computer bei einem DC authentifiziert. Es tritt oft als „Zugriff verweigert“-Fehler auf, wenn dieser Computer versucht, auf Domänenressourcen zuzugreifen, einschließlich Updates von Gruppenrichtlinien. Natürlich sind nicht alle „Zugriff verweigert“-Ereignisse auf Secure-Channel-Probleme zurückzuführen, aber wenn ein betroffener Computer Userenv-Fehler in seinem Anwendungsprotokoll mit „Zugriff verweigert“ in ihrer Beschreibung hat, ist es sinnvoll, Secure Channel zu testen.

• Der Befehl nltest kann verwendet werden, um Secure Channel auf einem Domänenmitglied zu testen (und ggf. zurückzusetzen).
• Der netdom Befehl kann Secure Channel zudem testen und zurücksetzen.
• Das PowerShell-Cmdlet Test-ComputerSecureChannel bietet eine weitere Möglichkeit zum Testen oder Zurücksetzen von Secure Channel.
• Das Entfernen des betroffenen Computers aus der Domäne, das Zurücksetzen seines AD-Computerkontos und sein erneutes Hinzufügen zur Domäne löst das Zurückzusetzen von Secure Channel aus. Dies ist jedoch nicht immer machbar.

Probleme mit SYSVOL
Vorlagendateien für Gruppenrichtlinien werden in der SYSVOL-Freigabe auf allen DCs in der Domäne gespeichert. Die SYSVOL-Daten werden auf den DCs mithilfe des File Replication System (FRS) oder Distributed File System Replication (DFSR) repliziert. Wenn die SYSVOL-Freigabe auf einem DC nicht vorhanden ist, deutet dies in der Regel auf ein Problem mit der SYSVOL-Replikation hin.

Zeitabweichung
Standardmäßig erfordert die Kerberos-Authentifizierung, dass die Uhren von mit der Domäne verbundenen Computern sich alle innerhalb eines Zeitraums von fünf Minuten befinden. Wird dieser Schwellenwert überschritten, führt das zu einem Authentifizierungsfehler, der wiederum die Verarbeitung von Gruppenrichtlinien verhindert. Alle Geräte in der Domäne sollte so konfiguriert werden, dass sich die Uhr mit AD synchronisiert, mit einer Ausnahme. Der DC, der die FSMO-Rolle des PDC-Emulators enthält, ist die maßgebliche Zeitquelle für die Domäne. Daher ist es der einzige Computer in einer Domäne, der mit einer externen Quelle synchronisiert werden sollte, z. B. einem öffentlichen NTP-Server.

Weitere Informationen zur Konfiguration des Windows-Zeitdienstes finden Sie hier.

Gruppenrichtliniendateien
Eine oder mehrere Gruppenrichtliniendateien wurden möglicherweise von ihrem Speicherort in SYSVOL gelöscht. Überprüfen Sie dies, indem Sie zu SYSVOL\domain\Policies im Datei-Explorer navigieren und nach jenen Dateien suchen, die in Userenv-Fehlern erwähnt werden. Die Dateien für jedes GPO befinden sich in einem Unterordner des Ordners Policies. Jeder Unterordner wird nach dem hexadezimalen Globally Unique Identifier (GUID) des Gruppenrichtlinienobjekts benannt, dessen Dateien er enthält.

Wenn festgestellt wird, dass auf allen DCs die Richtliniendateien fehlen, können sie aus einem Backup wiederhergestellt werden. Wenn die Dateien „Domain-Standard-Policy“ oder „Domain Controller-Standard-Policy“ fehlen und kein Backup verfügbar ist, können mit dem Befehl dcgpofix beide Policies auf ihre Standardeinstellungen zurückgesetzt werden.

Weitere Informationen zu dcgpofix finden Sie hier.