Standorte und Replikationstopologie

[MS-Wing 10]

Hallo,

 

wer kann mir folgendes Szenario erklären:

 

Mehrere Sites in AD:

Site1, Site2, Site3, Site4, Site5, Site6, Site7, Site8

 

5 Standortverknüpfungen:

Verknüpfung 1: Site1 Site2

Verknüpfung 2: Site1 Site8

Verknüpfung 3: Site1 Site3 Site4 Site5 Site6

Verknüpfung 4: Site1 Site3

Verknüpfung 5: Site3 Site7

 

Die Verknüpfungen wurden nach Kriterien generiert wie verfügbare Bandbreite und IP-Konnektivität.

 

Keine manuell aufgesetzten Verbindungen zwischen den DC's. Alles automatisch generiert.

 

Was ich nun nicht verstehe: Wieso baut ein DC aus Site 3 eine automatische Verbindung mit einem DC aus Site 2 auf? OK, IP-technisch sehen sich diese DCs, aber laut Standortverknüpfungen sollte sowas nicht passieren. Eigentlich sollten sich in dem Fall die Replikationsverbindungen nur in Site1 und Site2 abspielen. Diese sind IP mäßig auch korrekt verbunden.

 

Es scheint sowieso so als würden die DC's in allen Standorten versuchen mit allen möglichen DCs reden zu wollen ohne Rücksicht auf die Standortverknüpfungen. Dies sieht man in den Firewalllogs. Im grossen und ganzen ist die automatisch generierte Topologie nachvollziehbar. Aber es gibt eben DC-Verbindungen, die nicht zu den manuell festgelegten Standortverbindungen passen. Es sieht fast so also ob diese Standortverbindungen nur so eine Art "Vorschlag" and das AD sind, aber AD bei entsprechender Konnektivität diese Vorschläge ignoriert und so noch andere zusätzliche Verbindungen schaltet (als backup?).

 

Aber kann jemand das mal genauer erklären? Gibt es eine Möglichkeit die absolut strikte Berücksichtigung der Standortverbindungen zu erzwingen (ausser manuelle DC-Verbindungen zu generieren)?

 

mfg

 

Sascha

[grizzly999 11]

Du hast das standardmäßige Häkchen "Brücke über alle Verknüofungen" aktiviert. Damit bastelt er Standortverknüpfungsbrücken, die aber NICHT sichtbar sind in der Übersicht, und kann so, wenn es kostentechnisch günstiger ist, auch zwischen Standorten replizieren, die du nicht vorgsehen hast. Häkchen raus und nach einiger zeit (einmal durchrepliziert) , sollte sich das ganze deinen Wünschen gemäß einstellen

 

grizzly999

[MS-Wing 10]

Ja, das Häkchen war gesetzt weil default.

Danke für den Spitzen-Tipp! Ich denke das morgen alles so sein wird, wie ich es will.

[woiza 10]

Jo genau...

 

Das Häkchen findest du übrigens, wenn du unter Intersite Transports/IP auf Eigenschaften gehst. Auf Englisch heißt das Häkchen "Bridge all site links". Die Verknüpfung 4 sieht irgendwie redundant aus.

 

Gruß

 

woiza

[MS-Wing 10]

Ja, danke. Irgendwo in den grauen Zellen war noch was von "Bridge all site links" übrig. Aber es ist wohl doch mit der Zeit wegdiffundiert :p

[woiza 10]

Oh zu langsam, du hast das Häkchen ja schon gefunden. Ich sollte nicht immer so viele Beiträge mit Firefox öffnen und dann stehenlassen ohne Aktualisierung.:o

[MS-Wing 10]

Sorry, ich muss den Thread nochmal reaktivieren.

 

Ich habe das Häkchen entfernt, aber auch nach 2 Tagen gibt es immer noch Replikationsverbindungen, die nicht den Standortverknüpfungen entsprechen. Das entfernte Häkchen hat sich mittlerweile zu allen Standorten durchrepliziert, aber keine grosse Änderung sichtbar.

 

Was hat dies nun zu bedeuten? Muss ich ggf. automatisch erstellte Verknüpfungen manuell löschen? Ich dachte die Verbindungen werden automatisch den neuen Gegebenheiten (keine "Bridge all site links" mehr) angepasst.

 

Grizzly999?

[grizzly999 11]

Eigentlich sollte der KCC (ISTG) die Topolgie neu berechnung und die "falschen" Site Links entfernen.

Gibt es Einträge in den Verzeichnisdienst-Logs auf den betreffenden ISTGs?

 

Manuelles Löschen der Links geht prinzipiell, aber man sollte erst prüfen, welche NCs dadrüber repliziert werden. Dann wäre nach einem Löschen zu prüfen, ob diese NCs später, nachdem der ISTG das mitbekommen hat, über die "korrekten" Site Links repliziert werden, sonst schaffst du dir u.U. Lücken im AD.

 

 

grizzly999

[MS-Wing 10]

Nachdem das Häckchen entfernt wurde traten auf dem 2. DC der Forest-Root-Domain folgende Events auf (im 15 Minuten Takt):

Event ID 1311 und 1865 (vom NTDS KCC).

 

Die Meldung besagt das nicht genug Standortinformationen vorhanden sind um ein Spanning-Tree herzustellen. Ich habe jedoch alle Standorte und Subnetze definiert.

 

Hmm. scheint was komplizierteres zu werden...

 

Event 1311 meckert DomainDNSZones an

und Event 1865 eine andere Site...

[grizzly999 11]

Sind da VPN-Verbindungen dazwischen? Sind die 2003 Server mit SP1? Dann empfehle ich den Hotfix 898060 auf allen Servern an den Standorten.

 

Hier auch ncoh ein paar Ansätze für den 1311: Microsoft Corporation

 

 

grizzly999

[MS-Wing 10]

Update: Wir haben in einem der problematischen Standorte noch ein Problem mit DNS entdeckt (manuell angelegte Zonenreplikation (dnscmd /enlistdirectoryparition).

 

Wir versuchen das gerade zu ziehen und dann zu sehen, ob sich alles normalisiert.

Ich denke das die Fehler hiermit zu tun haben.

[woiza 10]

Habt ihr in den Sites mehrere Domänen? Die Partition DomainDNSZones existiert in jeder Domäne separat. Gehalten wird sie nur auf den DNS-Servern der DCs.

Wenn z.B. in den Sites 3 und 7 eine Domäne laufen würde, aber nur in 7 ein DNS läuft, dann würde bei deiner Topologie ja nie diese Zone in 1 oder sonstwo ankommen.

 

Ist jetzt nur ein Beispiel, weil ich ja deine Struktur nicht kenne. Aber das Prinzip dürfte klar sein.

[MS-Wing 10]

Nee, das Problem ist das wir mit dnscmd /enlistdirectoryparition eine dnspartition in einer ad-domäne enlisted haben, die aber diese Zone normalerweise über ad nicht empfangen würde.

 

Anders gesagt:

 

Domain1: Domain1-DNS Replicationscope Domain-Wide

DC in Domain2: manuelles enlisten für Domain1-DNS Zone

 

War definitiv ein Fehler, aber wir versuchen nun diese "fremde" DNS-Zone loszuwerden. Sie soll ganz normal über das Forwarding aufgelöst werden.

 

Wir haben auf dem DC in Domain2 angegeben:

dnscmd /unenlistdirectorypartition domaindnszones.domain1.irgendwas.local

 

Hoffentlich verschwindet diese Zone bald auf dem DC in Domain2

[MS-Wing 10]

Nachdem wir mit "dnscmd /unenlistdirectorypartition" die "falschen" dnszonen rausgeschmissen haben, scheint nun alles gut zu werden!

KCC meckert nicht mehr, keine roten oder gelben Einträge im Directory-Service Eventlog.

 

Und jeder DC spricht nur noch mit den DCs mit denen er auch soll (Standortverknüpfungen). So macht AD wieder Spaß!