11
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.
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.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-ID: 11665293190
Url: https://administrator.de/contentid/11665293190
Printed on: September 1, 2024 at 00:09 o'clock
11 Comments
Latest comment
Moin,
also dafür reichen schon 2 MBit!
sysvol freigabe vorhanden auf dc2?
hast du in AD-Standorte und Dienste das Netz eingetragen?
Frank
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,
Gruß,
Dani
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
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
Bzgl. Deiner S2S-Performance:
Checke die MTU. Da wird vermutlich das Problem sitzen.
Und stelle mal auf IPsec um
1
Moin,
Frank
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!Moin,
Bzgl. Deiner S2S-Performance:
Checke die MTU. Da wird vermutlich das Problem sitzen.
Und stelle mal auf IPsec um
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
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...
Frank
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
erklärt aber immer noch nicht, warum die ACL nicht einwandfrei repliziert werden
