Jump to content

Fehler bei der Verarbeitung der Benutzer-/Gruppenrichtlinie


mroth
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

bei uns tritt sporadisch unter Windows 10 folgender GroupPolicy (Microsoft-Windows-GroupPolicy)-Fehler auf.

Z.B. in einer Testreihe nach 40x Neustarts mit zusätzlichem "gpupdate  /force".

Mal wird die Computer- und Benutzerrichtlinie nicht übernommen, mal nur eine der beiden.

 

 

Ereignisanzeige/Administrative Ereignisse

---

Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\server.local\SysVol\server.local\Policies\{E4A43680-18A6-4B4B-8E48-ECCFAE3C48C6}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann: 

a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller. 

b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert). 

c) Der DFS-Client (Distributed File System) wurde deaktiviert.

---

 

Vielleicht kann mir ja jemand weiterhelfen.

 

Gruß,

mroth

Link zu diesem Kommentar

Moin,

 

was heißt

 

in einer Testreihe nach 40x Neustarts mit zusätzlichem "gpupdate  /force".

 

Startet ihr laufend direkt hintereinander neu? Und bei 40 Neustarts kommt einmal der Fehler? Oder wie?

Bleibt der Fehler dann bestehen, oder behebt er sich von selbst?

Gibt es um das Event herum weitere Meldungen?

 

Gruß, Nils

Link zu diesem Kommentar

Wir führen die Updates der Richtlinien nur beim Systemstart durch oder eben manuell mittels gpupdate, jedoch nicht automatisch im laufendem Betrieb.

In der Testreihe wurden somit 80x die Richtlinien übernommen 40x beim Systemstart und 40x zusätzlich mittels gpupdate.

Der Fehler bleibt danach vielleicht für 2-3 weitere Updates der Richtlinien bestehen und verschwindet dann von selbst wieder.

 

 

Sofort danach kommt noch 2x folgender Eintrag, ist allerdings nicht jedes mal der Fall

 

Die Ressourceneinträge für Host (A oder AAAA) konnten für den Netzwerkadapter
 mit folgenden Einstellungen nicht registriert werden:
 
   Adaptername : {122BC4B5-8012-4CE1-A887-5A15BDB53F40}
   Hostname : PC003
   Primäres Domänensuffix : server.local
   DNS-Serverliste : 
      192.168.100.1, 192.168.100.19
   Server, an den das Update gesendet wurde : 192.168.100.1:53
   IP-Adresse(n) :
     192.168.202.3
 
 Diese Ressourceneinträge konnten nicht registriert werden, weil der DNS-Server die Updateanforderung verweigert hat. Mögliche Ursachen sind: (a) Sie sind nicht dazu berechtigt den adapterspezifischen DNS-Domänenname zu aktualisieren. ( B) Der autorisierende DNS-Server unterstützt das Protokoll für das dynamische DNS-Update nicht.
 
 Wenden Sie sich an den DNS-Server- oder Netzwerksystemadministrator, um die Ressourceneinträge für den DNS-Host (A oder AAAA) mit dem spezifischen DNS-Domänennamen und IP-Adressen für diesen Adapter zu registrieren.
bearbeitet von mroth
Link zu diesem Kommentar

Moin,

 

Wir führen die Updates der Richtlinien nur beim Systemstart durch oder eben manuell mittels gpupdate, jedoch nicht automatisch im laufendem Betrieb.

 

warum dies? Nur während des Tests oder auch in Produktion? In beiden Fällen: Wozu soll das gut sein?

Was ist das Ziel eurer Testreihe? Was wollt ihr rausfinden?

 

Die Symptomatik klingt nach Netzwerkproblemen, dazu passt auch, dass es nach kurzer Zeit verschwindet. Um Näheres zu sagen, müsste man sich das alles mal in Ruhe ansehen. Möglicherweise provoziert ihr die Probleme auch durch euer Testverfahren.

 

Gruß, Nils

Link zu diesem Kommentar

Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\server.local\SysVol\server.local\Policies\{E4A43680-18A6-4B4B-8E48-ECCFAE3C48C6}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich.

Repariere die Sysvol-Replikation.

https://support.microsoft.com/en-us/kb/290762 (NTFRS)

https://support.microsoft.com/en-us/kb/2218556 (DFSR)

Link zu diesem Kommentar
  • 4 Monate später...

Hallo,

 

Ich grabe nochmal dieses alte Thema aus, da ich ehrlich gesagt noch immer Probleme damit habe.

In der Zwischenzeit habe ich versucht den Fehler weiter zu analysieren.

Ein Ping auf den domain suffix dauert einige Sekunden bis er unter Windows ausgeführt wird.

Unter Linux antwortet der DNS-Server sofort abwechselnd mit zwei IPs (Round Robin).

 

Trage Ich eine IP zu server.local in die hosts-Datei des Windows-Clients ein, können die GPOs erfolgreich übernommen werden.

Danach werden Netzlaufwerke zuverlässig eingebunden und auch der Ping wird sofort ausgeführt.

 

Desweiteren habe ich getestet die zeroconf (LLMNR) Namensauflösung auszuschalten und den dns-cache zu deaktivieren (net stop dnscache).

 

C:\Users\Hans Mustermann>ping server.local

<an dieser Stelle vergehen einige Sekunden bis der Befehl ausgeführt wird>

Ping wird ausgeführt für server.local [192.168.100.1] mit 32 Bytes Daten:
Antwort von 192.168.100.1: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.100.1: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.100.1: Bytes=32 Zeit<1ms TTL=128

 

Über eine zündende Idee, wie man hier weiterkommen könnte würde ich mich freuen.

Link zu diesem Kommentar

Danke für die Antwort, die Clients haben beide die richtigen DNS-Server eingetragen.

Vielleicht helfen ja auch die Einstellungen des DNS-Servers.

 

Wir haben zwei AD/DNS-Server:

192.168.100.1 und 192.168.100.19

 

DNS-Manager:

(identisch mit übergeordnetem Ordner) Autoritätssprung (SOA) ads01.server.local hostmaster.server.local

(identisch mit übergeordnetem Ordner) Nameserver (NS) ads01.server.local

(identisch mit übergeordnetem Ordner) Nameserver (NS) ads02.server.local

(identisch mit übergeordnetem Ordner) Host (A) 192.168.100.1

(identisch mit übergeordnetem Ordner) Host (A) 192.168.100.19

 

Wenn ich sie beide DNS-Server abwechselnd manuell einzeln beim Netzwerkadapter eintrage, bekomme ich bei beiden das selbe Fehlerbild.

Der Ping auf das dns suffix mit Round Robin ist langsam.

Ein Ping auf einen einzelnen Host wird hingegen sofort durchgeführt.

 

So richtig kann ich das Verhalten auch nicht nachvollziehen, da Windows ja zusätzlich auch einen DNS Cache besitzt.

Dies passiert auch nur unter Windows, unter Linux ohne DNS-Cache wird sofort aufgelöst.

Link zu diesem Kommentar

Naja, Linux hat out of the box keinen.

Natürlich gibt es auch dort entsprechende Services, welche man installieren kann.

Ich wollte das auch wirklich nur benennen, da ich die DNS-Server somit auch einmal außerhalb von Windows getestet habe.

Die Windows Server - DNS-Dienste können also schnell antworten.

 

Ich weiß momentan ehrlich gesagt nicht woran es liegen könnte. ^^

Ich kenne mich auch nicht gut genug aus um zu wissen, ob dies jetzt ein Client-Problem ist, ein Kombinationsproblem oder ein Server-Konfigurationsproblem.

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...