22
GPO, welche auf DC1 erstellt, ist auf DC2 nicht lesbar seit heute
Moin Kollegen,
ich erstelle doch recht häufig GPOs, unter anderem gestern - da hat noch alles funktioniert.
Letzte Nacht wurden nun auch der zweite DC gepatcht mit den Februarupdates und Folgendes ist nun defekt:
Erstelle ich auf DC1 eine neue GPO (egal, ob leer oder nicht), dann wird diese wie erwartet in weniger als 15 Sekunden auf den 2. DC repliziert.
Jedoch kann der zweite DC diese GPO zwar sehen, aber nicht öffnen, Fehlermeldung:
Weitaus schlimmer ist aber, dass sogar bei bestehenden GPOs, welche ich auf DC1 ändere, zwar repliziert wird (GPO-Versionsnummer ehöht sich auch korrekt), aber die Änderungen auf DC2 nicht in der GPO erscheinen und auf den Clients auch nur dann übernommen werden, wenn sie sich an DC1 wenden (%logonserver%=DC1), während von DC2 der alte Stand verteilt wird.
Umgekehrt ist es genau so: was ich auf DC2 erstelle, wird auf DC1 unlesbar und von DC2 vorgenommene Änderungen kommen auf DC1 nicht mehr an, somit ist das Problem nicht auf einen DC zu begrenzen.
Ich habe Sicherungen der DCs und schätze, dass ich eine Lösung finden werde - diese Frage dient in erster Linie als Warnung.
Prüft das bitte nach, sofern ihr die Updates schon installiert habt.
Hier auf beiden DCs: Server 2016 1607
dcdiag ist top zufrieden
ich erstelle doch recht häufig GPOs, unter anderem gestern - da hat noch alles funktioniert.
Letzte Nacht wurden nun auch der zweite DC gepatcht mit den Februarupdates und Folgendes ist nun defekt:
Erstelle ich auf DC1 eine neue GPO (egal, ob leer oder nicht), dann wird diese wie erwartet in weniger als 15 Sekunden auf den 2. DC repliziert.
Jedoch kann der zweite DC diese GPO zwar sehen, aber nicht öffnen, Fehlermeldung:
Umgekehrt ist es genau so: was ich auf DC2 erstelle, wird auf DC1 unlesbar und von DC2 vorgenommene Änderungen kommen auf DC1 nicht mehr an, somit ist das Problem nicht auf einen DC zu begrenzen.
Ich habe Sicherungen der DCs und schätze, dass ich eine Lösung finden werde - diese Frage dient in erster Linie als Warnung.
Prüft das bitte nach, sofern ihr die Updates schon installiert habt.
Hier auf beiden DCs: Server 2016 1607
dcdiag ist top zufrieden
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1881860573
Url: https://administrator.de/contentid/1881860573
Ausgedruckt am: 24.11.2024 um 03:11 Uhr
22 Kommentare
Neuester Kommentar
Für mich klingt das wieder nach einer Update Verschlimmbesserung seitens Microsoft, scheint bei denen im Moment à la mode zu sein. Es kotzt mich an... im Januar hatten wir schon genug Probleme gerade mit den DC's...
sind die Shares sysvol auf beiden DC's synchron? Was sagt dcdiag?
Lass mal gut sein, auf MS zu schimpfen. Vielleicht ja nur ein lokales Problem bei uns.
Wenn Du einen DC hast (2016 1607) und die Updates schon hast, dann wäre es schön, wenn Du eine MInute Zeit hättest, selbiges selbst zu testen und mitzuteilen, ob es noch funktioniert.
Wenn Du einen DC hast (2016 1607) und die Updates schon hast, dann wäre es schön, wenn Du eine MInute Zeit hättest, selbiges selbst zu testen und mitzuteilen, ob es noch funktioniert.
@NordicMike
Nein, die Shares sind nicht synchron (wie zu erwarten fehlen die Dateien der neuen GPOs gänzlich auf dem jeweils anderen DC), jedoch, wie bereits geschrieben: dcdiag ist zufrieden, keine Fehler.
Nein, die Shares sind nicht synchron (wie zu erwarten fehlen die Dateien der neuen GPOs gänzlich auf dem jeweils anderen DC), jedoch, wie bereits geschrieben: dcdiag ist zufrieden, keine Fehler.
Habe es gerade mal bei uns versucht. Bei uns wurden gestern Abend die Updates auf beiden DCs eingespielt. GPOs lassen sich aber nach wie vor auf beiden Systemen normal öffnen. Sowohl die bestehenden als auch eine neu erstellte GPO.
Gruß
Gruß
1
ADRepstatus Tool mal durchlaufen lassen?
Ich hab auch 2DCs, 1 VM + BM.
Bis jetzt keine Probleme bezüglich GPO,
hatte heute Vormittag ein DNS Problem, den konnte ein Neustart beheben ...
Bis jetzt keine Probleme bezüglich GPO,
hatte heute Vormittag ein DNS Problem, den konnte ein Neustart beheben ...
Servus.
Evtl. hat das etwas damit zu tun?
https://www.borncity.com/blog/2022/02/08/windows-server-sonderupdate-kor ...
Cheers,
jsysde
P.S.:
Weitere OOB-Updates: https://www.borncity.com/blog/2022/02/10/net-framework-updates-8-februar ...
Evtl. hat das etwas damit zu tun?
https://www.borncity.com/blog/2022/02/08/windows-server-sonderupdate-kor ...
Cheers,
jsysde
P.S.:
Weitere OOB-Updates: https://www.borncity.com/blog/2022/02/10/net-framework-updates-8-februar ...
HI,
ohne es untersucht / getestet zu haben, wie sieht es mit DFS aus für die Verzeichnisreplikation?
Gurß
ohne es untersucht / getestet zu haben, wie sieht es mit DFS aus für die Verzeichnisreplikation?
Gurß
Hi
Warum deinstalliert du nicht einfach das letzte Update vom DC2 und dann DC1 und schaust ob der Fehler noch auftritt.
Wenn nicht -> Update
Wenn doch -> Backup?!?
Wenn aber Fehler schon länger unbemerkt ... dann Backup keine Hilfe ...
Weil wie weit willst du mit nem dc zurück
Dann doch besser nen DC03 und den zweier sterben lassen in der Hoffnung das es am 02 lieg ...
Mit freundlichen Grüßen Nemsis
Warum deinstalliert du nicht einfach das letzte Update vom DC2 und dann DC1 und schaust ob der Fehler noch auftritt.
Wenn nicht -> Update
Wenn doch -> Backup?!?
Wenn aber Fehler schon länger unbemerkt ... dann Backup keine Hilfe ...
Weil wie weit willst du mit nem dc zurück
Dann doch besser nen DC03 und den zweier sterben lassen in der Hoffnung das es am 02 lieg ...
Mit freundlichen Grüßen Nemsis
das würde ich dann vielleicht erst mal fixen. Ohne die Dateien braucht der Editor ja erst gar nicht versuchen sie zu öffnen
Wenn alle Tools glücklich sind, die Verzeichnisse aber dennoch nicht richtig replizieren, hilft meist ein Non-autorative resync
Wenn alle Tools glücklich sind, die Verzeichnisse aber dennoch nicht richtig replizieren, hilft meist ein Non-autorative resync
Ist gelöst. Ursache war ein Ntfrs Journal Wrap, dessen Ursache widerum unklar ist (Festplatte gesund, kein hartes Ausschalten, keine Stromausfälle).
Was soll's, vorgegangen nach Schema F, alles wieder gut.
Interessant war, dass das ADReplstatustool von Microsoft kein Problem erkannt hat - scheint nicht viel zu taugen.
Was soll's, vorgegangen nach Schema F, alles wieder gut.
Interessant war, dass das ADReplstatustool von Microsoft kein Problem erkannt hat - scheint nicht viel zu taugen.
1
Im Eventlog von waren Replikationsfehler ("NTFRS Journal Wrap") zu erkennen. Warum DCDiag die nicht gewertet hat ist mir nicht klar. https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/ ... ist das passende Rezept.
1
Danke für die Ergebnisse... Auf was man alles achten muss und auf was man sich nicht mehr verlassen darf...
hier identische Version, mit identischem Update aber kein Fehler. Log ist blitzeblank..
Zugriffsprobleme bestehen auch nicht. Vielleicht TCP/IP CRC fehler am switch?
Zugriffsprobleme bestehen auch nicht. Vielleicht TCP/IP CRC fehler am switch?
Lösung siehe wenige Zentimeter weiter oben
dessen Ursache widerum unklar ist (Festplatte gesund, kein hartes Ausschalten, keine Stromausfälle).
Zitat von @DerWoWusste:
Im Eventlog von waren Replikationsfehler ("NTFRS Journal Wrap") zu erkennen. Warum DCDiag die nicht gewertet hat ist mir nicht klar. https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/ ... ist das passende Rezept.
Im Eventlog von waren Replikationsfehler ("NTFRS Journal Wrap") zu erkennen. Warum DCDiag die nicht gewertet hat ist mir nicht klar. https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/ ... ist das passende Rezept.
Das würde mich aber auch etwas verunsichern. Wer sagt denn, dass es nicht wieder passiert? Da schlägt ja unter Umständen auch nicht direkt ein Monitoring an. Wie hast du die beiden DCs denn verheiratet (Netzwerk) bzw. was fürn Storage läuft da drunter? Oder sind die DCs in blech?
Ich habe nun Tasks etabliert, die auf das entsprechende Event reagieren und Warnmails schicken.
Deine zusätzlichen Fragen - ich wüsste nicht, warum das eine Rolle spielt. Die beiden sind ledig (aber vernetzt im selben Subnetz), ein Blech, ein realer und Storage? Spielt doch keine Rolle, aber es sind SSDs, jeweils im Raid1.
Deine zusätzlichen Fragen - ich wüsste nicht, warum das eine Rolle spielt. Die beiden sind ledig (aber vernetzt im selben Subnetz), ein Blech, ein realer und Storage? Spielt doch keine Rolle, aber es sind SSDs, jeweils im Raid1.
Zitat von @DerWoWusste:
Ich habe nun Tasks etabliert, die auf das entsprechende Event reagieren und Warnmails schicken.
Deine zusätzlichen Fragen - ich wüsste nicht, warum das eine Rolle spielt. Die beiden sind ledig (aber vernetzt im selben Subnetz), ein Blech, ein realer und Storage? Spielt doch keine Rolle, aber es sind SSDs, jeweils im Raid1.
Ich habe nun Tasks etabliert, die auf das entsprechende Event reagieren und Warnmails schicken.
Deine zusätzlichen Fragen - ich wüsste nicht, warum das eine Rolle spielt. Die beiden sind ledig (aber vernetzt im selben Subnetz), ein Blech, ein realer und Storage? Spielt doch keine Rolle, aber es sind SSDs, jeweils im Raid1.
ich frage deshalb weil wir ja hier öfters mal die verrücktesten Kombinationen haben. Vll sind die Platten ja iwo per NFS/iscsi gemounted und auf der Strecke gibts Packet Loss und zack könnte(!) der DC sich verschlucken.
Nee, alles 0815. War auch das erste deratige Ereignis hier überhaupt (ich administriere dieses AD seit Windows 2000).
