2
Primären und Sekundären AD-Standort ohne Datenverlust wieder synchronisieren?
Hallo,
Ich verwalte einen Windows Server 2003 und einen Windows Server 2008 in einer Domäne, bestehend aus zwei Teilnetzwerken die mit einem Funk-Lan verbunden sind.
(Deshalb die zwei Domänencontroller, ich will sicher sein das beide Teile benutzbar sind wenn mal das Fun-Lan ausfällt)
Nun habe ich mich dazu entschieden den 2k8-Server zum Primären AD-Controller zu machen und dann fiel er leider aus, es gab in der Zeit also nur noch den Sekundären Domänencontroller der auch seine Arbeit gut gemacht hat...
Dann musste ich allerdings dringend etwas an ca. 100 Accounts des ADs ändern und neue Accounts hinzufügen, das tat ich also auf dem Sekundären Domänencontroller...
Jetzt meine Frage, was passiert wenn ich den 2k8-Server, Primärer Controller, wieder hinzuschalte. Holt er sich automatisch die neuen Infos vom Sekundären? Oder überschreibt er alles weil er denkt er wär der Boss (weil Primär)?
Falls letzteres der Fall sein sollte, wie kann ich das verhindern?
Danke
Catscrash
Ich verwalte einen Windows Server 2003 und einen Windows Server 2008 in einer Domäne, bestehend aus zwei Teilnetzwerken die mit einem Funk-Lan verbunden sind.
(Deshalb die zwei Domänencontroller, ich will sicher sein das beide Teile benutzbar sind wenn mal das Fun-Lan ausfällt)
Nun habe ich mich dazu entschieden den 2k8-Server zum Primären AD-Controller zu machen und dann fiel er leider aus, es gab in der Zeit also nur noch den Sekundären Domänencontroller der auch seine Arbeit gut gemacht hat...
Dann musste ich allerdings dringend etwas an ca. 100 Accounts des ADs ändern und neue Accounts hinzufügen, das tat ich also auf dem Sekundären Domänencontroller...
Jetzt meine Frage, was passiert wenn ich den 2k8-Server, Primärer Controller, wieder hinzuschalte. Holt er sich automatisch die neuen Infos vom Sekundären? Oder überschreibt er alles weil er denkt er wär der Boss (weil Primär)?
Falls letzteres der Fall sein sollte, wie kann ich das verhindern?
Danke
Catscrash
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: 102502
Url: https://administrator.de/contentid/102502
Ausgedruckt am: 04.11.2024 um 18:11 Uhr
2 Kommentare
Neuester Kommentar
Du darfst problemlos den DC wieder verbinden die Updates werden in beide Richtungen gesendet.
Wenn man sich das AD, in diesem Beispiel mal stark vereinfacht, als Tabelle vorstellt in der jedes Objekt eine ID (objectGUID) und Eigenschaften hat, dann darf jeder DC Änderungen daran vornehmen.
Jede Änderung hat dabei eine laufende Nummer (USN-update sequence number) und bezieht sich auf die (objectGUID. Der entscheidende Trick ist nun das die USN nicht gleich der Objekt ID ist sondern eine zweite, separate Tabelle darstellt, die jeder DC für seine Änderungen selber fortschreibt. Jeder DC hat also "seine" eigene USN, die wie ein Zählwerk nur hoch zählen kann, aber unabhängig von den anderen DC's ist.
Beim replizieren werden diese Änderungen an den jeweiligen Partner DC gesendet. Dazu merkt sich der Replikationspartner welche USN er von diesem DC bereits gelesen hat damit nur die neuen Einträge übertragen werden müssen. Jeder DC muss alle Updates auf "seine" Daten anwenden, da nur die Updates, nicht aber die ganzen Objekte übertragen werden. In Netzwerken mit mehreren DC's werden diese Updates anschließend auch noch an andere DC's weitergeleitet, da nicht zwingend jeder DC mit jedem repliziert.
Gruß Rafiki
Siehe auch:
Wikipedia: Flexible Single Master Operations (FSMO) oder operations masters
http://de.wikipedia.org/wiki/FSMO
Active Directory Replication Technologies
http://technet.microsoft.com/en-us/library/cc776877.aspx
dort den Abschnitt: "Changes to Attributes"
und ein Stück tiefer: Replicated Update Tracking by Domain Controllers
Wenn man sich das AD, in diesem Beispiel mal stark vereinfacht, als Tabelle vorstellt in der jedes Objekt eine ID (objectGUID) und Eigenschaften hat, dann darf jeder DC Änderungen daran vornehmen.
Jede Änderung hat dabei eine laufende Nummer (USN-update sequence number) und bezieht sich auf die (objectGUID. Der entscheidende Trick ist nun das die USN nicht gleich der Objekt ID ist sondern eine zweite, separate Tabelle darstellt, die jeder DC für seine Änderungen selber fortschreibt. Jeder DC hat also "seine" eigene USN, die wie ein Zählwerk nur hoch zählen kann, aber unabhängig von den anderen DC's ist.
Beim replizieren werden diese Änderungen an den jeweiligen Partner DC gesendet. Dazu merkt sich der Replikationspartner welche USN er von diesem DC bereits gelesen hat damit nur die neuen Einträge übertragen werden müssen. Jeder DC muss alle Updates auf "seine" Daten anwenden, da nur die Updates, nicht aber die ganzen Objekte übertragen werden. In Netzwerken mit mehreren DC's werden diese Updates anschließend auch noch an andere DC's weitergeleitet, da nicht zwingend jeder DC mit jedem repliziert.
Gruß Rafiki
Siehe auch:
Wikipedia: Flexible Single Master Operations (FSMO) oder operations masters
http://de.wikipedia.org/wiki/FSMO
Active Directory Replication Technologies
http://technet.microsoft.com/en-us/library/cc776877.aspx
dort den Abschnitt: "Changes to Attributes"
und ein Stück tiefer: Replicated Update Tracking by Domain Controllers
Active Directory replication does not primarily depend on time to determine what changes need to be propagated. Instead it uses update sequence numbers (USNs) that are assigned by a counter that is local to each domain controller. Because these USN counters are local, it is easy to ensure that they are reliable and never run backward (that is, they cannot decrease in value).
perfekt, danke für die schnelle Antwort
