Fehler bei der Verarbeitung der Benutzer-/Gruppenrichtlinie

[mroth 1]

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

[Sunny61 811]

Habt ihr den Schnellstart deaktiviert? Wenn nein, hol das nach und du kannst dir in Zukunft das /force sparen. Einfach nur ein gpupdate aufrufen und anschließend neu starten.

[mroth 1]

Der Schnellstart ist bereits bei allen Rechnern deaktiviert.

[NilsK 2.971]

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

[mroth 1]

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 15. Dezember 2017 von mroth

[NilsK 2.971]

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

[daabm 1.376]

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)

[mroth 1]

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.

[NilsK 2.971]

Moin,

 

wenn der Ping mehrere Sekunden zur Ausführung braucht, dann klemmt die Namensauflösung. Vermutlich ist nicht der richtige DNS-Server beim Client eingetragen bzw, mindestens einer, der den Namen nicht auflösen kann.

 

Gruß, Nils

 

[mroth 1]

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.

[NorbertFe 2.105]

vor 16 Minuten schrieb mroth:

da Windows ja zusätzlich auch einen DNS Cache besitzt.

Welches OS denn bitteschön nicht? Auch ein Linux wird ja wohl einen local resolver haben.

[mroth 1]

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.

 

[daabm 1.376]

Ich würd ja mal mit "nslookup <domain>" anfangen - wer antwortet?