Replikation zwischen 2 DCs, ausstehende ACLs

Hi,

Ich habe ein Problem mit 2 DCs, die über einen SSL Site2Site Tunnel miteinander verbunden sind.

DC1 (IP 192.168.1.100) hält alle FSMO Rollen
DC2 (IP 192.168.11.100) ist einzig zur erleichterten Anmeldung am externen Standort gedacht und als Backup für den DC1

Beide DCs sind virtualisiert, DC1 ist eine ESX-VM, DC2 ist eine Hyper-V VM.

Da der Site2Site Tunnel zu langsam ist für eine direkte Hochstufung zum DC wurde DC2 im Netz von DC1 höhergestuft und dann ins entfernte Netz umgezogen.
Replikation läuft soweit, repadmin zeigt keine Fehler, dcdiag ebenso alles OK.

Was jedoch nicht passt, wenn man in die Gruppenrichtlinien-Verwaltung geht, steht das DC2 ausstehende ACL-Replikationen hat.

Get-DfsrBacklog zeigt massig ausstehende Replikationen, aber mit Update-Datum 21.08.24.
Zusätzlich habe ich zwischenzeitlich mit ROBOCOPY die SYSVOL Ordner von DC1 zu DC2 kopiert, womit die ACLs ja dann auch passen müssten, Meldung ist aber noch immer da.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 11665293190

Url: https://administrator.de/contentid/11665293190

Ausgedruckt am: 23.11.2024 um 08:11 Uhr

12 Kommentare

Neuester Kommentar

Moin,

Da der Site2Site Tunnel zu langsam ist für eine direkte Hochstufung zum DC wurde DC2 im Netz von DC1 höhergestuft und dann ins entfernte Netz umgezogen.

also dafür reichen schon 2 MBit!

sysvol freigabe vorhanden auf dc2?
hast du in AD-Standorte und Dienste das Netz eingetragen?
Frank

ja und ja, SYSVOL und NETLOGON sind beide am DC2 vorhanden und aktuell, wie gesagt um das ACL-Problem zu lösen sogar per ROBOCOPY von DC1 kopiert

Moin,

wie gesagt um das ACL-Problem zu lösen sogar per ROBOCOPY von DC1 kopiert

bist du so vorgegangen: https://serverfault.com/questions/835700/dfs-r-how-to-get-back-on-track- ..?

Gruß,
Dani

ich hatte den alten SYSVOL Ordner nicht gelöscht.
Ich versuch es gerade noch mal, Replikation gestoppt, ROBOCOPY läuft jetzt und nachher starte ich die Replikation neu.

Ich gebe Feedback, wenn es durch ist. Die Site2Site Verbindung ist nämlich sehr langsam, langsamer als 2mbit.

Aber das ist ein anderes Problemchen. 2mal Sophos UTM mit SSL-S2S verbunden, sowohl S2S wie auch normaler SSL-Remote-Zugang ist sehr langsam, obwohl schon UDP aktiv ist.. teils dauert der Zugriff auf eine 500kb-PDF 2min, obwohl beim direkten kopieren 2mb/s drin sind..

Geschwindigkeiten an den Standorten:
Standort 1: Kabel mit 1000/50
Standort 2: DSL mit 250/20

Moin,

Bzgl. Deiner S2S-Performance:
Checke die MTU. Da wird vermutlich das Problem sitzen.

Und stelle mal auf IPsec um

Moin,

Zitat von @em-pie:

Moin,

Bzgl. Deiner S2S-Performance:
Checke die MTU. Da wird vermutlich das Problem sitzen.

Und stelle mal auf IPsec um

jo... würde ich auch sagen!

Frank

IPsec ist keine Lösung, da ich noch weitere Tunnel betreibe und die Sophos UTM nur einen IPsec-Tunnel kann

MTU hab ich auch schon mehrfach angepasst, die Verbesserungen sind marginal

Ein erneutes ROBOCOPY des zuvor komplett gelöschten SYSVOL bei angehaltener Replikation brachte auch keine Verbesserung in der ACL-Problematik

Moin...

IPsec ist keine Lösung, da ich noch weitere Tunnel betreibe und die Sophos UTM nur einen IPsec-Tunnel kann

dann werf die Sophos auf dem Müll, nutze dann lieber pfSense etc...
Frank

IPsec ist keine Lösung, da ich noch weitere Tunnel betreibe und die Sophos UTM nur einen IPsec-Tunnel kann

das ist doch Grütze.
Die SG kann zweifelsfrei > 1 IPsec S2S Tunnel…
Wir hatten, wenn auch überschaubar, Tunnel zu 4 verschiedenen Zielen. Dabei nicht nur Sophos 2 Sophos, sondern auch Sophos 2 Lancom oder auch Sophos 2 Sonicwall…

hab mit MTU Anpassung jetzt in jede Richtung annährend das Maximum rausbekommen.. mit den 50 upload vom Kabel sind 5mb/s +/-0,5mb möglich, mit den 20 upload vom DSL an Standort 2 sind 2,5mb/s +/-0,5mb möglich.. reicht mir, besser wird es mit IPsec auch nicht

erklärt aber immer noch nicht, warum die ACL nicht einwandfrei repliziert werden