Keinen Zugriff auf SYSVOL - eventuell Kerberos-Problem?
Mahlzeit,
ich könnte mal etwas Input brauchen. Ich habe hier eine VM (einziger Host für Exchange 2019), die mit den beiden DCs ihrer Domain im selben Subnetz hängt. Durch eine Umstellung ist mir aufgefallen, das gpupdate nicht mehr läuft. Die Ereignisanzeige meldet (ID 1058):
Tatsächlich ist es so das sich
Diverse
Firewall hängt nicht dazwischen, selbes Subnetz. Andere VMs haben das Problem nicht. Zu einem Neustart hatte ich bereits Gelegenheit, das hat aber nichts geändert. Uhrzeit ist synchron. Der Fehler besteht schon seit März, mir ist aber nicht klar, was sich da geändert haben könnte. Die beiden DCs sind die einzigen und auch DFS Root.
DFS / DNS
In 2024 haben wir unseren alten DC abgeschaltet (nach Migration). Eigentlich war ich mir sicher, alle Verweise auf den alten DC entfernt zu haben, war aber wohl nicht ganz so. Ich habe eben mit
noch Spuren des alten DCs gefunden und in der DFS-Verwaltung entfernt. DFS ist jetzt absolut sauber, dcdiag hat auch nichts zu meckern. DNS funktioniert, sonst hätte ich das Problem sicher öfter. Das habe ich allerdings erst nach dem Neustart gemacht.
Kerberos
Ich hatte bereits etwas zu Kerberos gelesen, leider finde ich das nicht wieder. Die KI hatte einige Ideen, unter anderem auch:
Leider hatte ich in besagter anderer Quelle etwas in der Art gelesen "Kerberos Ticket zurück gesetzt und dann gab es Exchange-Probleme". Obwohl ich das für vielversprechend halte, habe ich mich noch nicht getraut. Ich hatte diese Konstellation definitiv noch nicht allerdings lässt mich die Aufforderung zur Anmeldung glauben, das hier ein Windows-Login Problem die Ursache sein müsste.
Frage
Hat jemand Erfahrung mit Kerberos und klist purge? Ich würde das wohl heute Abend testen, eventuell mit Snapshot.
Gerne nehme ich noch andere Anregungen entgegen, mehr fällt mir aber dazu nicht ein.
ich könnte mal etwas Input brauchen. Ich habe hier eine VM (einziger Host für Exchange 2019), die mit den beiden DCs ihrer Domain im selben Subnetz hängt. Durch eine Umstellung ist mir aufgefallen, das gpupdate nicht mehr läuft. Die Ereignisanzeige meldet (ID 1058):
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\<FQDN>\SysVol\<FQDN>\Policies\{<GUID>}\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.Tatsächlich ist es so das sich
- \\<FQDN>\SYSVOL nicht aufrufen lässt,
- \\<DC1_NetBIOS_Name>\SYSVOL aufrufen lässt,
- \\<DC2_NetBIOS_Name>\SYSVOL aufrufen lässt,
- \\<DC1_NetBIOS_Name>.<FQDN>\SYSVOL Anmeldedaten anfordert und
- \\<DC2_NetBIOS_Name>.<FQDN>\SYSVOL Anmeldedaten anfordert.
Diverse
Firewall hängt nicht dazwischen, selbes Subnetz. Andere VMs haben das Problem nicht. Zu einem Neustart hatte ich bereits Gelegenheit, das hat aber nichts geändert. Uhrzeit ist synchron. Der Fehler besteht schon seit März, mir ist aber nicht klar, was sich da geändert haben könnte. Die beiden DCs sind die einzigen und auch DFS Root.
DFS / DNS
In 2024 haben wir unseren alten DC abgeschaltet (nach Migration). Eigentlich war ich mir sicher, alle Verweise auf den alten DC entfernt zu haben, war aber wohl nicht ganz so. Ich habe eben mit
dfsutil /pktinfonoch Spuren des alten DCs gefunden und in der DFS-Verwaltung entfernt. DFS ist jetzt absolut sauber, dcdiag hat auch nichts zu meckern. DNS funktioniert, sonst hätte ich das Problem sicher öfter. Das habe ich allerdings erst nach dem Neustart gemacht.
Kerberos
Ich hatte bereits etwas zu Kerberos gelesen, leider finde ich das nicht wieder. Die KI hatte einige Ideen, unter anderem auch:
klist purge
klist get krbtgt
nltest /sc_query:DOMAINLeider hatte ich in besagter anderer Quelle etwas in der Art gelesen "Kerberos Ticket zurück gesetzt und dann gab es Exchange-Probleme". Obwohl ich das für vielversprechend halte, habe ich mich noch nicht getraut. Ich hatte diese Konstellation definitiv noch nicht allerdings lässt mich die Aufforderung zur Anmeldung glauben, das hier ein Windows-Login Problem die Ursache sein müsste.
Frage
Hat jemand Erfahrung mit Kerberos und klist purge? Ich würde das wohl heute Abend testen, eventuell mit Snapshot.
Gerne nehme ich noch andere Anregungen entgegen, mehr fällt mir aber dazu nicht ein.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673415
Url: https://administrator.de/forum/sysvol-gruppenrichtlinie-kerberos-exchange-673415.html
Ausgedruckt am: 17.06.2025 um 23:06 Uhr
8 Kommentare
Neuester Kommentar
Hat jemand Erfahrung mit Kerberos und klist purge?
Nach erfolgreichem Anmelden gibt es ein neues Ticket. (Laufen täglich nach 10h bzw. nach 4(?) ab)Gruß
Stimmt, die 4 Tickets unter klist sind alle nicht sehr alt. Dann ist purge vermutlich unbedenklich? Allerdings wird das dann vermutlich auch nicht das Problem lösen...
Habe noch ein wenig getestet, der Ansatz mit Kerberos hat nichts geändert:
= alles gut
0x3e4 ist die LUID für SYSTEM-Kontext
und Neustarts
= keine Veränderung. Es sieht alles gut aus, nur gpupdate läuft nicht und auf \\<FQDN>\SYSVOL kann ich nach wie vor nicht zugreifen.
klist purge
klist get krbtgtnltest /sc_query:<DOMAIN>
nltest /sc_verify:<DOMAIN>= alles gut
klist -li 0x3e4 purgeund Neustarts
= keine Veränderung. Es sieht alles gut aus, nur gpupdate läuft nicht und auf \\<FQDN>\SYSVOL kann ich nach wie vor nicht zugreifen.
Such mal nach der und deaktiviere diese auf den DC/s (oder repariere sie).
Gruß
<GUID>Gruß
Die GUID vom Computerkonto? Bis jetzt hatte ich mich auf den SYSTEM-Account konzentriert, weil der gpupdate ausführt. Ich kann ja einen Exchange nicht einfach aus der Domain raus und wieder rein nehmen...
Moin,
Uhrzeit passt?
DNS-Suffix auf dem Netzwerkadapter evtl verbogen?
Namensauflösung auf den FQDN ist ein Round Robin auf die DCs. Ist da evtl noch ein falscher drin?
Gruß und viel Erfolg
Uhrzeit passt?
DNS-Suffix auf dem Netzwerkadapter evtl verbogen?
Namensauflösung auf den FQDN ist ein Round Robin auf die DCs. Ist da evtl noch ein falscher drin?
Gruß und viel Erfolg
Zitat von @ukulele-7:
Die GUID vom Computerkonto? Bis jetzt hatte ich mich auf den SYSTEM-Account konzentriert, weil der gpupdate ausführt. Ich kann ja einen Exchange nicht einfach aus der Domain raus und wieder rein nehmen...
Die GUID vom Computerkonto? Bis jetzt hatte ich mich auf den SYSTEM-Account konzentriert, weil der gpupdate ausführt. Ich kann ja einen Exchange nicht einfach aus der Domain raus und wieder rein nehmen...
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\<FQDN>\SysVol\<FQDN>\Policies\{<GUID>}\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:
jene GUID. Da funktioniert nur eine GPO nicht - diese mal zu testzwecken deaktivieren oder eben berichtigen(an allen DCs). Dann dürfte gpupdate wieder rennen.
Ja.
Tatsächlich kommen zwei Fehler hintereinander, unterschiedliche GUIDs. Habe die beiden mal raus gepickt und deaktiviert, dann kommen zwei andere GUIDs. Ebenfalls deaktiviert, wieder andere GUIDs. Er fängt mit den GPOs direkt an der Domain an, er scheint also der Reihe nach vorzugehen aber im Endeffekt kann er alle GUIDs nicht lesen. Daher vermute ich weiterhin ein allgemeines Zugriffsproblem auf dem gesamten SYSVOL Pfad.
Die GPOs werden vom Rest der Domäne auch einwandfrei gelesen.
DNS-Suffix auf dem Netzwerkadapter evtl verbogen?
Passt.Namensauflösung auf den FQDN ist ein Round Robin auf die DCs. Ist da evtl noch ein falscher drin?
Nein DNS spuckt immer die aktuellen DCs aus.Zitat von @shebang:
jene GUID. Da funktioniert nur eine GPO nicht - diese mal zu testzwecken deaktivieren oder eben berichtigen(an allen DCs). Dann dürfte gpupdate wieder rennen.
Gute Idee, leider nicht sehr ergiebig.jene GUID. Da funktioniert nur eine GPO nicht - diese mal zu testzwecken deaktivieren oder eben berichtigen(an allen DCs). Dann dürfte gpupdate wieder rennen.
Tatsächlich kommen zwei Fehler hintereinander, unterschiedliche GUIDs. Habe die beiden mal raus gepickt und deaktiviert, dann kommen zwei andere GUIDs. Ebenfalls deaktiviert, wieder andere GUIDs. Er fängt mit den GPOs direkt an der Domain an, er scheint also der Reihe nach vorzugehen aber im Endeffekt kann er alle GUIDs nicht lesen. Daher vermute ich weiterhin ein allgemeines Zugriffsproblem auf dem gesamten SYSVOL Pfad.
Die GPOs werden vom Rest der Domäne auch einwandfrei gelesen.
