Die Active Directory-Replikation stellt sicher, dass der Datentransfer zwischen Verzeichnispartitionen auf unterschiedlichen Domänencontrollern (DCs) ordnungsgemäß durchgeführt wird. Dabei achtet das AD zum einen darauf, dass bei der Replikation keine Endlosschleifen entstehen und zum anderen, die AD-Daten unabsichtlich nicht repliziert werden. Deshalb enthält jede Verzeichnispartition mehrere Replikationsmetadaten, die sich auf die Replikation der jeweiligen Verzeichnispartition beziehen. Anhand der Replikationsmetadaten verwalten die DCs den Datentransfer von Verzeichnisänderungen. Denn neben der Übertragung der eigentlichen Daten, werden vom AD zusätzliche Informationen zu dieser Änderung übertragen. In den zusätzlichen Informationen sind unter anderem die Informationen zu dem DC enthalten, auf dem die ursprüngliche Änderung durchgeführt wurde, das Datum und die Uhrzeit der Änderung.
Da es sich bei der AD-Replikation um einen hochkomplexen Vorgang handelt, benötigen die DCs einen Mechanismus, der sicherstellt, dass zwischen zwei DCs nur die erforderlichen Änderungen repliziert werden. Dazu ist es notwendig, dass die DCs Änderungen, die noch nicht repliziert wurden, ermitteln können und sofern vorhanden, anschließend nur diese erforderlichen Änderungen replizieren. Ohne einen solchen Mechanismus würde jeder DC bei jeder AD-Replikation die komplette AD-Datenbank replizieren. Deshalb verwendet das AD für die Replikationsverwaltung eine Kombination aus der Update Sequence Number (USN), den beiden Vektoren High-Watermark Vector (HWMV) sowie Up-To-Dateness Vector (UTDV) und dem Änderungsstempel, bestehend aus der Versionsnummer (versionID) und dem Zeitstempel.
Aktualisierungstypen
Auf einem beschreibbaren DC können zwei Arten von Aktualisierungen an den AD-Informationen durchgeführt werden. Dabei handelt es sich um die ursprüngliche Aktualisierung (originating update) und um die replizierte Aktualisierung (replicated update).
Eine ursprüngliche Aktualisierung (auch bekannt als Ursprungsschreibvorgang) findet auf einem DC stets dann statt, wenn ein AD-Objekt bearbeitet, gelöscht, hinzugefügt oder verschoben wird.
Eine replizierte Aktualisierung findet hingegen dann statt, wenn die auf einem anderen DC durchgeführten AD-Änderungen auf den lokalen DC repliziert werden. Zwischen dem DC, auf dem die Aktualisierung durchgeführt wurde und seinen direkten Replikationspartnern muss es sich dabei nicht unbedingt um eine direkte eins-zu-eins Replikation handeln. Eine einzelne, replizierte Aktualisierung hat möglicherweise ihren Ursprung in einer Reihe von ursprünglichen Aktualisierungen auf demselben Objekt. Diese ursprünglichen Aktualisierungen können durchaus auch auf verschiedenen DCs durchgeführt worden sein. Beispielsweise wird auf DC1 im Benutzerobjekt Yusuf die Beschreibung und zur gleichen Zeit wird im selben Benutzerobjekt auf DC2 die Mailadresse geändert. DC3 erhält nun die Änderungen die im Benutzerobjekt Yusuf vorgenommen wurden separat von DC1 und DC2. Anschließend erhält DC4 von DC3 alle Änderungen durch eine einzige replizierte Aktualisierung.
Es findet also per se für jede beliebige Änderung im AD immer eine ursprüngliche Aktualisierung auf dem DC statt, auf dem die Änderung durchgeführt wurde. Alle anderen DCs erhalten die ursprüngliche Aktualisierung dann über die AD-Replikation aber nur dann, wenn sie ein Replikat der entsprechenden Verzeichnispartition besitzen. Dabei handelt es sich bei jeder ursprünglichen Aktualisierung im AD um eine vollständige Transaktion. Entweder wird der gesamte Ursprungsschreibvorgang in die AD-Datenbank übernommen oder nichts!
Die Update Sequence Number (USN)
Für die AD-Replikation ist es elementar zu erkennen, welche Daten sich geändert haben und infolgedessen repliziert werden müssen. Dabei basiert die Erkennung der Daten die repliziert werden müssen, auf der Update Sequence Number (USN), zu Deutsch Aktualisierungssequenznummer. Die USN ist ein 64Bit Wert und wird zum schnellen Auffinden indiziert. Ein Quell-DC verwendet USNs um festzustellen, welche Änderungen bei seinen direkten Replikationspartnern, die von ihm die aktuellsten Änderungen anfordern, bereits eingegangen sind. Der Ziel-DC wiederum verwendet USNs, um zu bestimmen, welche Änderungen er von seinem Replikationspartner benötigt, die er sich dann per Pull-Replikation repliziert. Jedes Attribut in jedem Objekt hat bereits seine eigene USN!
Jeder ursprünglichen und replizierten Aktualisierung wird automatisch eine fortlaufende DC-spezifische USN zugewiesen und diese hat im Vergleich mit anderen DCs, keine Bedeutung. Wenn zum Beispiel bei einem Benutzer die E-Mailadresse (das Attribut mail) auf DC01 geändert wird, erhält die Aktualisierung der Mailadresse auf diesem DC die USN 9530. Nach der Replizierung dieser Änderung, vergibt der direkte Replikationspartner DC02 derselben Mailadresse die USN 43643. Die nächste Änderung auf DC01 würde die USN 9531 erhalten, unabhängig vom geänderten Objekt.
Die USN der einzelnen Attribute eines bestimmten Objekts, auf einem bestimmten DC, kann man sich mit dem Kommandozeilentool REPADMIN wie folgt anzeigen lassen: Repadmin /showobjmeta <DC> “<DN des entsprechenden Objekts>“. Die USN der Attribute, sind in der Repadmin-Ausgabe, in der Spalte Lok.USN zu sehen.
Lässt man sich mit demselben Befehl die USNs der Einzelnen Attribute desselben Objekts von einem anderen DC anzeigen, so erkennt man, dass sich die USNs der Attribute komplett unterscheiden.
Beide DCs besitzen zwar erkennbar über komplett verschiedene USNs für dasselbe Objekt, aber das ist in Bezug auf die AD-Replikation einer Änderung Bedeutungslos.
Werden stattdessen während einer Aktualisierung mehrere Attribute eines Objekts gleichzeitig geändert (z.B. die Straße, Postfach, Ort, Bundesland, Postleitzahl und Land eines Benutzers), erhält jedes geänderte Attribut dieselbe USN. Somit wird der gesamten Aktualisierung nur eine einzige USN zugewiesen.
Welche drei Möglichkeiten für die Zuweisung einer USN gibt es?
Wird eine Änderung im AD vorgenommen, gibt es drei Möglichkeiten für die Zuweisung einer USN. Die erste wäre, der lokale USN-Wert wird mit dem geänderten Attribut gespeichert. Im geänderten Attribut wird die USN mit dem lokalen USN Wert gekennzeichnet. Führt man diesen REPADMIN-Befehl aus Repadmin /showobjmeta <DC> “<DN des entsprechenden Objekts>“, sieht man den lokalen USN Wert der Einzelnen Attribute in der Spalte Lok.USN.
Als nächstes wird die USN für das indizierte Attribut uSNChanged im geänderten Objekt verwendet. Das system only Attribut uSNChanged, das in jedem Objekt enthalten ist, kennzeichnet die höchste USN für jedes beliebige Attribut des Objekts. Oder anders ausgedrückt, das Attribut uSNChanged enthält die USN für die letzte Änderung an einem Objekt, die auf diesem DC durchgeführt wurde. Dabei wird die lokale USN, zusammen mit dem Attribut uSNChanged sowohl bei einer ursprünglichen Aktualisierung, als auch bei einer replizierten Aktualisierung angewendet. Durch beide Aktualisierungstypen wird die lokale USN und das Attribut uSNChanged eines DCs erhöht! Wenn beispielsweise die Mailadresse (das Attribut mail) eines Benutzers geändert wird, erhält zum einen das Attribut mail, als auch das Attribut uSNChanged denselben USN Wert, z.B. 6700. Wird anschließend die Beschreibung (das Attribut description) im selben Benutzerobjekt, auf demselben DC geändert, erhält die lokale USN des Attributs description als auch uSNChanged im Benutzerobjekt denselben Wert, also 6701. Der Wert in der lokalen USN des Attributs mail bleibt jedoch weiterhin auf 6700 bestehen, da diese USN bei der letzten Änderung dem Attribut mail auf diesem DC zugeordnet wurde.
Wenn man in der MMC Active Directory-Benutzer und -Computer (dsa.msc) unter Ansicht die Option „Erweiterte Features“ aktiviert, findet man anschließend in den Eigenschaften eines Objekts, im Reiter Objekt, unter anderem die aktuelle USN (das Attribut uSNChanged) des Objekts.
Und zuletzt wird die USN im originating USN, auf Deutsch im ursprünglichen USN Wert gespeichert, die im Up-To-Dateness Vector (UTDV) verwendet wird. Dieser Wert wird nur bei einer ursprünglichen Aktualisierung festgelegt. Bei einem Ursprungsschreibvorgang auf einem DC, wird die neue USN mit jedem aktualisierten Attribut im lokalen USN Wert und zusätzlich im ursprünglichen USN Wert gespeichert. Im Gegensatz zur lokalen USN und dem Attribut uSNChanged, wird die ursprüngliche USN mit dem Wert des aktualisierten Attributs repliziert. Führt man den Befehl Repadmin /showobjmeta <DC> “<DN des entsprechenden Objekts>“ auf einem deutschen DC aus, findet man die ursprüngliche USN in der Spalte Ur. USN. Wenn zum Beispiel die Straße im Benutzerobjekt Yusuf auf dem DC geändert wird, erhält im Attribut streetAddress die lokale USN, die ursprüngliche USN und das Attribut uSNChanged denselben Wert!
Wird nun die geänderte Straße repliziert, wird neben dem geänderten Attribut streetAddress auch die ursprüngliche USN repliziert, die im Übrigen auf dem Ziel-DC nicht geändert wird. Auf dem Ziel-DC wird aber die lokale USN und das Attribut uSNChanged bearbeitet, da beide Werte DC-spezifisch sind. Die ursprüngliche USN wird so lange nicht geändert, bis das Attribut erneut aktualisiert wird.
Man kann erkennen, dass das Benutzerobjekt Yusuf Dikmenoglu auf dem R2DCON01 erstellt und das Attribut streetAddress am 25.08.2010 um 23:15:46 Uhr auf dem R2DCON02 geändert wurde.
Die höchste USN eines DCs
Jeder DC merkt sich auch in einem eigens dafür vorgesehenen Attribut, welche USN er als letztes einer lokalen AD-Änderung zugewiesen hat. Dabei kann eine lokale AD-Änderung durch eine ursprüngliche und replizierte Aktualisierung stattfinden. Die aktuelle USN eines DCs, sprich die letzte bestätigte bzw. zugewiesene USN des DCs, wird im Attribut highestCommittedUSN gespeichert. Dieses Attribut befindet sich in den Eigenschaften des rootDSE-Objekts, wobei jeder DC sein eigenes rootDSE Objekt besitzt. Mit anderen Worten: Das Attribut highestCommittedUSN enthält die höchste USN auf diesem DC!
Der Wert im Attribut highestCommittedUSN ändert sich bereits, sobald ein DC gestartet wird. Denn es werden Änderungen an der AD-Datenbank durchgeführt, auch ohne dass ein Administrator Änderungen im AD vorgenommen hat. Daher kann es sein, dass sich der Wert im Attribut highestCommittedUSN nach zwei hintereinander durchgeführten Änderungen um mehrere und nicht nur um eine einzige USN unterscheidet.
Mit REPADMIN kann man sich die höchste USN auf einem DC wie folgt Anzeigen lassen:
Repadmin /showattr <DC> “” /atts:highestCommittedUSN
Von allen DCs aus der Domäne kann man sich die Werte mit diesem Befehl anzeigen lassen:
Repadmin /showattr * “” /atts:highestCommittedUSN
Mit der AD-PowerShell kann man sich den Wert aus dem Attribut highestCommittedUSN von einem DC folgendermaßen anzeigen lassen:
Get-ADRootDSE –Server <DC> | Select highestCommittedUSN | FL
Natürlich kann man sich das Attribut highestCommittedUSN ebenfalls mit LDP anzeigen lassen. Dazu genügt es sich in LDP lediglich mit einem DC zu verbinden. Danach erhält man alle Einträge, unter anderem das Attribut highestCommittedUSN, aus dem rootDSE-Objekt von dem DC, mit dem man sich in LDP verbunden hat.
Dank des Attributs highestCommittedUSN, kann man sich die letzten durchgeführten Änderungen auf einem DC anzeigen lassen. Möchte man sich die letzten 500 Änderungen an der AD-Datenbank auf einem bestimmten DC anzeigen lassen, so kann man dies mit einem LDIFDE-Export herausfinden. Der LDIFDE-Befehl zum Export lautet wie folgt:
Ldifde /d „DC=<Domäne>,DC=<TLD> /s <DC> /x /r „(uSNChanged>=<Wert>)” /f C:\USNÄnderungen.txt
Nicht so schnell! Vorher muss man natürlich die aktuelle (höchste) USN des DCs in Erfahrung bringen. Daher gilt es zuerst eine Abfrage nach dem Attribut highestCommittedUSN durchzuführen. Mit der AD-PowerShell kann man die aktuelle USN wie folgt in Erfahrung bringen:
Get-ADRootDSE | Select highestCommittedUSN | FL
Enthält das Attribut highestCommittedUSN als Wert 5500, muss man lediglich im Ldifde-Filter „(uSNChanged>=5000)” angeben und schon werden die letzten 500 Änderungen, die in der AD-Datenbank dieses DC durchgeführt wurden, exportiert.
Der High-Watermark Vector (HWMV)
Der HWMV (auch bekannt als direct up-to-dateness vector) ist ein Mechanismus, der vom AD bei der Replikation der AD-Informationen verwendet wird, um die Replikation effizient und bandbreitenschonend durchzuführen. Der HWMV dient auch zur Ressourcenschonung, denn es verringert während einer AD-Replikation die CPU-Zeit und die Anzahl an Festplatten I/O eines DCs.
Durch den HWMV können die zwischen den DCs zu replizierenden AD-Informationen bestimmt werden. Dadurch ist es anderen DCs möglich, Änderungen basierend auf einer speziellen USN von einem Replikationspartner anzufordern.
Die Basis für den High-Watermark Vector stellt die USN einer Verzeichnispartition dar. Dabei erhöht sich der HWMV einer Verzeichnispartition auf einem DC, durch beide Aktualisierungstypen.
Der HWMV wird vom Ziel-DC für jede Verzeichnispartition und für jeden seiner direkten Replikationspartner verwaltet. Jeder DC verwaltet für jede Verzeichnispartition die er hält, eine HWMV-Tabelle. In der HWMV-Tabelle ist die höchste replizierte USN (also der HWMV) der entsprechenden Verzeichnispartition, von allen eingehenden direkten Replikationspartnern gespeichert. Mit dem HWMV verfolgt der Ziel-DC in seiner HWMV-Tabelle, welche Änderung, aus welcher Verzeichnispartition, er bereits von einem bestimmten Replikationspartner erhalten hat.
Jeder DC der kein GC ist, verwaltet je eine HWMV-Tabelle für die Schemapartition, Konfigurationspartition, Domänenpartition sowie für die beiden DNS Anwendungsverzeichnispartition (ab Windows Server 2003) „ForestDNSZones“ und „DomainDNSZones“, also insgesamt fünf HWMV-Tabellen. Ein GC in einer Gesamtstruktur mit mehreren Domänen, verwaltet zusätzlich je eine HWMV-Tabelle für jede andere Domänenpartition.
Doch letztlich handelt es sich bei dem HWMV lediglich um den aktuellen Wert im Attribut uSNChanged, den der Ziel-DC von einem bestimmten Replikationspartner erhalten hat! Wird eine Aktualisierung an einem Objekt durchgeführt, erhält automatisch auch das Attribut uSNChanged im geänderten Objekt einen höheren Wert. Der Quell-DC repliziert dann zusätzlich neben der eigentlichen Aktualisierung, das Attribut uSNChanged des zuletzt geänderten Objekts zum Ziel-DC. Der Ziel-DC wiederum, trägt den Wert aus dem mitgesendeten Attribut uSNChanged für seinen Replikationspartner, als den HWMV für die entsprechende Verzeichnispartition in seine HWMV-Tabelle ein. Und obwohl das Attribut uSNChanged mit der Aktualisierung zum Ziel-DC repliziert wurde, erhält das Attribut uSNChanged im selben Objekt auf dem Ziel-DC, nicht denselben Wert den der Quell-DC mitgeschickt hat!
Im HWMV wird neben weiteren Replikationsmetadaten, der Datenbank-GUID (Globally Unique Identifier) und der objectGUID, die beide in der Gesamtstruktur einmalig sind, und nicht der Computername des Remote-DCs gespeichert. Dadurch das sich der objectGUID zu Lebzeiten eines DCs niemals ändert, kommt es auch nicht zu Problemen, wenn sich der Computername eines DCs ändert. Bei dem Datenbank-GUID handelt es sich um das Attribut invocationId und dieser befindet sich so wie der objectGUID in der Konfigurationspartition, in den Eigenschaften des NTDS Settings Objekts eines DCs. Der LDAP-Pfad lautet: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Zwei wichtige IDs eines DCs: DC GUID und InvocationId
Den High-Watermark Vector anzeigen
Führt man den REPAMIN-Befehl Repadmin /showrepl /verbose aus, wird in der Ausgabe die HWMV USN neben dem Eintrag „/OU“ (steht für object update), für jede Verzeichnispartition von jedem Replikationspartner (und nicht der eigene HWMV!) angezeigt. Der Wert der mit der Angabe von „/OU“ angezeigt wird, ist der echte HWMV für die entsprechende Verzeichnispartition des Replikationspartners! Die object update USN ist der tatsächliche HWMV der benötigt wird, um die Attribute bzw. Objekte in der entsprechenden Verzeichnispartition zu bestimmen, die repliziert werden müssen.
Den Fortschritt innerhalb eines Replikationszyklus zeigt die object update USN an (gibt an ob gerade repliziert wird) und der USN-Wert bei „/PU“ (steht für property update), zeigt den letzten erfolgreich durchgeführten(!) Replikationszyklus an. Am Ende eines Replikationszyklus lautet die USN im object update und im property update gleich. Existiert bei /PU kein Wert, bedeutet das, dass die AD-Replikation noch nie erfolgreich durchgeführt wurde, wie es bei der Erstsynchronisation eines neuen DCs der Fall sein kann. Wenn sich die Werte im object update und im property update unterscheiden, bedeutet dies, dass ein Replikationszyklus im Gange ist. Die beiden Werte „/OU“ und „/PU“, die das Repadmin ausliest, stammen vom Attribut repsFrom. Das mehrwertige, optionale (system only) Attribut repsFrom wird nicht zwischen den DCs repliziert (aber in den GC schon) und befindet sich in den Eigenschaften der entsprechenden Verzeichnispartition! In dem Attribut ist von jedem Replikationspartner neben weiteren Replikationsmetadaten der HWMV (nicht der eigene!), gespeichert. Zum Anzeigen der Werte aus repsFrom eignet sich LDP.
Die Replikationsmetadaten eines Objekts anzeigen
Die Replikationsmetadaten eines Objekts kann man sich mit einer Abfrage nach dem mehrwertigen (multivalue) constructed Attribut msDS-ReplAttributeMetaData anzeigen lassen. Dieses Attribut zeigt die Metadaten für jedes replizierte Attribut im XML Format an. Aus den Metadaten erfährt man unter anderem, auf welchem DC ein Attribut geändert wurde. Mit REPADMIN kann man sich die Replikationsmetadaten eines Objekts folgendermaßen anzeigen lassen:
Repadmin /showattr <DC> “<DN des Objekts>” /atts: msDS-ReplAttributeMetaData
In der AD-PowerShell lautet die Abfrage wie folgt:
Get-ADObject -Server <DC> “<DN des Objekts>” -Properties msDS-ReplAttributeMetaData
Im Folgenden einfachen Beispiel wird gezeigt, was es mit dem HWMV auf sich hat
1. In einer Domäne existieren zwei DCs: DC01 und DC02. Der aktuelle HWMV der Domänenpartition von DC01 ist 20500 und von DC02 37250. In der HWMV-Tabelle auf DC01 ist der HWMV der Domänenpartition von DC02 gespeichert. Dieser lautet wie bereits genannt: 37250. In der HWMV-Tabelle für die Domänenpartition auf DC02 ist wiederum gespeichert, dass der HWMV der Domänenpartition von DC01 20500 ist.
2. Wird nun auf dem Quell-DC DC02 ein Benutzer erstellt (es wird eine ursprüngliche Aktualisierung in der Domänenpartition durchgeführt), erhöht sich der lokale HWMV der lokalen Domänenpartition von DC02, auf den neuen Wert 37258. Da aber DC01 von DC02 noch nicht benachrichtigt wurde, dass Änderungen vorliegen und demzufolge die AD-Replikation noch nicht stattgefunden hat, ist weiterhin in der HWMV-Tabelle auf DC01 als HWMV Wert für die Domänenpartition auf DC02 37250 gespeichert. Erst wenn die AD-Replikation stattgefunden hat, aktualisiert DC01 seine HWMV-Tabelle.
3. Innerhalb eines AD-Standorts versendet DC02 ab dem Gesamtstrukturfunktionsmodus Windows Server 2003 nach 15 Sekunden eine Änderungsbenachrichtigung (change notification) an DC01. Standortübergreifend wird die Benachrichtigung, dass Änderungen vorliegen, nach dem in der Standortverknüpfung konfigurierten Zeitplan verschickt. Zur Erinnerung: Bei der AD-Replikation findet per se eine Pull-Replikation und keine(!) Push-Replikation statt! Wenn DC01 die Benachrichtigung erhalten hat, dass Änderungen auf DC02 verfügbar sind, initiiert DC01 die AD-Replikation. DC01 sendet neben weiteren Replikationsmetadaten, die detaillierter im folgenden UTDV-Beispiel aufgelistet werden, den HWMV an DC02, der für DC02 in der HWMV-Tabelle auf DC01 gespeichert ist.
4. Nun, da DC02 den HWMV für die Domänenpartition kennt, den DC01 in seiner HWMV-Tabelle für DC02 gespeichert hat, sendet DC02 die Änderungen zwischen den HWMV-Werten 37250 und 37258. Letzten Endes also das Benutzerobjekt. Zeitgleich aktualisiert der Ziel-DC DC01 seinen lokalen HWMV für die Domänenpartition von 20500 auf 20508, sowie den HWMV von DC02 in seiner HWMV-Tabelle auf 37258.
Wenn es jetzt keinen anderen Mechanismus als den HWMV gäbe, würde die Änderung die gerade zu DC01 repliziert wurde, wieder zurück zu DC02 repliziert werden. Schließlich hat sich auf DC01 durch die replizierte Aktualisierung der lokale HWMV der Domänenpartition erhöht. Das bedeutet im Umkehrschluss, dass Änderungen auf DC01 vorliegen die angeblich repliziert werden müssen. Damit es zu genau dieser Endlosschleife nicht kommt, gibt es einen weiteren Vektor, nämlich den Up-To-Dateness Vector.
Der Up-To-Dateness Vector (UTDV)
So wie beim HWMV, stellt die USN die Basis für den Up-To-Dateness Vector dar. Der Up-To-Dateness Vector ist ein weiterer Mechanismus der ebenfalls dazu dient, die zu replizierenden AD-Informationen zwischen den DCs zu verwalten, damit die AD-Replikation effizient durchgeführt werden kann. Der UTDV verhindert, dass dieselbe Änderung, die der DC erhalten hat, permanent zurück repliziert wird und dadurch eine Endlosschleife entsteht. Deshalb spricht man beim UTDV auch von Propagierungsdämpfung.
Durch den Up-To-Dateness Vector (auf Deutsch Aktualitätsvektor), auch bekannt als Up-To-Date Vector, verfolgt der Ziel-DC die ursprünglichen Aktualisierungen (originating update) in allen Verzeichnispartitionen, die er von beliebigen DCs erhalten hat. Der lokale UTDV eines DCs erhöht sich dabei nur, wenn der DC selbst eine Änderung im AD, also eine ursprüngliche Aktualisierung in der lokalen AD-Datenbank durchführt. Erhält der DC eine replizierte Aktualisierung, erhöht sich lediglich sein lokaler HVMW, aber nicht der lokale UTDV! Den UTDV eines anderen DCs kennt ein DC nur dann, wenn der Quell-DC eine ursprüngliche Aktualisierung in einer Verzeichnispartition die auch auf dem Ziel-DC existiert, durchgeführt hat und die Änderung repliziert wird (was standardmäßig immer der Fall ist).
Genau wie bei den HWMV-Tabellen verwaltet jeder DC zusätzlich je eine UTDV-Tabelle für jede Verzeichnispartition, die ein DC hält. In den entsprechenden UTDV-Tabellen wird jeder beschreibbare DC aufgelistet, der jemals eine ursprüngliche Aktualisierung in einer Verzeichnispartition durchgeführt hat, was in der Praxis auf jeden beschreibbaren DC in fast allen Verzeichnispartitionen zutrifft. In einer UTDV-Tabelle speichert jeder DC die Datenbank-GUIDs (das Attribut invocationId) der Replikationspartner. Des Weiteren werden die Einträge in den entsprechenden UTDV-Tabellen für die Lebensdauer einer Verzeichnispartition verwaltet, unabhängig davon, ob der DC oder die Verzeichnispartition vom DC bereits entfernt wurde.
Jeder DC, der kein GC ist, verwaltet je eine UTDV-Tabelle für die Schemapartition, Konfigurationspartition, Domänenpartition sowie für die beiden DNS Anwendungsverzeichnispartition (ab Windows Server 2003) „ForestDNSZones“ und „DomainDNSZones“, also insgesamt fünf UTDV-Tabellen. Ein GC in einer Gesamtstruktur mit mehreren Domänen verwaltet zusätzlich je eine UTDV-Tabelle für jede andere Domänenpartition.
Für die gesamtstrukturweiten Verzeichnispartitionen Schemapartition, Konfigurationspartition sowie die Anwendungsverzeichnispartition ForestDNSZones verfolgt ein DC in der jeweiligen UTDV-Tabelle den UTDV für alle DCs in der Gesamtstruktur. Im Grunde verfolgen bei der Schemapartition alle DCs einer Gesamtstruktur lediglich den UTDV eines DCs, nämlich den vom Schemamaster. Der Schemamaster ist der Einzige DC, der in der Schemapartition Änderungen durchführen darf. Was die Konfigurationspartition und die DNS Anwendungsverzeichnispartition „ForestDNSZones“ anbetrifft, verfolgt jeder DC den UTDV, jedes DCs in der Gesamtstruktur. Denn jeder DC erstellt Objekte in der Konfigurationspartition (z.B. Verbindungsobjekte) und jeder DC erstellt SRV-Einträge in der Anwendungsverzeichnispartition „ForestDNSZones“, genauer in der Forward Lookup Zone _msdcs.Root-Domäne.de. Für die Domänenpartition und für die DNS Anwendungsverzeichnispartition „DomainDNSZones“, verwaltet jeder DC den UTDV in der entsprechenden UTDV-Tabelle, für jeden anderen DC in der Domäne. Ein GC in einer Gesamtstruktur mit mehreren Domänen, verfolgt zusätzlich die Up-To-Dateness Vektoren für jeden DC aus den anderen Domänenpartitionen.
Genau genommen spiegelt das Attribut highestCommittedUSN aus dem rootDSE-Objekts eines DCs den lokalen UTDV eines DCs wieder. In dem Attribut highestCommittedUSN speichert der DC die letzte bestätigte und somit die höchste USN eines DCs, die einer lokalen AD-Änderung zugewiesen wurde.
Den Up-To-Dateness Vector anzeigen
Die Up-To-Dateness Vektoren, die ein bestimmter DC für eine Verzeichnispartition von seinen direkten und transitiven Replikationspartnern in seiner UTDV-Tabelle gespeichert hat, kann man sich mit dem Kommandozeilenbefehl Repadmin /showutdvec <DC> <DN der Verzeichnispartition> anzeigen lassen. Der Befehl listet auf dem angegebenen DC die eigene höchste USN und die höchste USN seiner direkten sowie transitiven Replikationspartner für die angegebene Verzeichnispartition auf, die zum Zeitpunkt der Abfrage in seiner lokalen UTDV-Tabelle gespeichert sind.
Führt man den Kommandozeilenbefehl Repadmin /showutdvec <DC> <DN der Root-Domäne> auf einem DC in der Root-Domäne aus, werden die UTDV für die Domänenpartition nur von allen DCs der Root-Domäne angezeigt und nicht der GC aus der Subdomäne! Denn wie bereits geschrieben, verfolgt der UTDV nur die ursprüngliche Aktualisierung, die innerhalb einer Verzeichnispartition durchgeführt wurde, und deshalb erscheint bei der Abfrage auf dem DC in der Root-Domäne der GC aus der Subdomäne nicht auf. Ein GC hat nur das Schreibrecht in der Domäne und somit nur in der Domänenpartition, in der er selbst Mitglied ist. Es werden zwar in einem Multi-Domain Forest alle Domänenpartitionen in den GC repliziert, jedoch besitzt der GC in allen anderen Domänenpartitionen nur das Leserecht! Erst wenn man denselben(!) Repadmin-Befehl auf einem DC in der Subdomäne ausführt, wird neben den DCs der Root-Domäne auch der GC der Subdomäne angezeigt.
Das Attribut, in dem die Up-To-Dateness Vektoren der Replikationspartner gespeichert sind
Jeder UTDV ist in dem system only Attribut replUpToDateVector gespeichert, das nicht zwischen den DCs repliziert wird (aber in den GC schon) und sich in den Eigenschaften einer Verzeichnispartition befindet. In diesem Attribut werden die UTDV von allen Replikationspartnern gespeichert, die jemals eine ursprüngliche Aktualisierung in der entsprechenden Verzeichnispartition durchgeführt und repliziert haben. In dem Attribut ist aber nicht der eigene UTDV gespeichert!
Am einfachsten lassen sich die Werte des Attributs, mit LDP anzeigen. Nach dem man sich in LDP zuerst mit einem DC verbunden und anschließend mit dem AD “Gebunden” hat, kann man sich unter Durchsuchen – Suchen die Werte aus dem Attribut replUpToDateVector für die angegebene Verzeichnispartition anzeigen lassen.
Möchte man in Erfahrung bringen, welche DCs hinter den Datenbank-GUIDs stecken die einem das LDP anzeigt, so kann man das leicht herausfinden. Dazu sollte man zuerst den Repadmin-Befehl Repadmin /showutdvec <DC> <DN der Verzeichnispartition> ausführen. Bei diesem Befehl werden die Computernamen der DCs angezeigt. Wenn anschließend der gleiche Befehl, mit dem Parameter /nocache ausgeführt wird, werden die Datenbank-GUIDs angezeigt. Anhand der UTDV Werte kann man dann sehen, hinter welchem Computernamen welche Datenbank-GUID steckt.
Anhand eines einfachen Beispiels, wird die Funktionsweise des UTDV gezeigt
1. In einer Domäne existieren drei DCs: DC01, DC02 und DC03. Der aktuelle HWMV der Domänenpartition von DC01 ist 20508, von DC02 37258 und von DC03 39270. Der aktuelle UTDV von DC01 ist 20508, von DC02 37258 und von DC03 39270. In den HWMV- und den UTDV-Tabellen auf allen DCs, sind jeweils die aktuellen Werte der anderen beiden DCs gespeichert.
2. Angenommen ein Administrator ändert auf dem Quell-DC DC01 im Benutzerobjekt Yusuf die Beschreibung. Es findet also eine einzelne ursprüngliche Aktualisierung auf DC01 statt und dieser weist dem Attribut description die lokale und ursprüngliche USN 20509 zu.
Der Wert 20509 wird als lokaler HWMV und UTDV für die Domänenpartition und im Attribut highestCommittedUSN auf DC01 gespeichert. Denn das ist zu diesem Zeitpunkt, die letzte bestätigte und höchste USN auf DC01.
3. DC01 versendet nach 15 Sekunden eine Änderungsbenachrichtigung zu DC02 und nach weiteren drei Sekunden zu DC03 und informiert beide DCs, dass Änderungen in der Domänenpartition vorliegen, die repliziert werden müssen.
4. Im Gegenzug senden die Ziel-DCs DC02 sowie DC03, die folgenden Informationen zum Quell-DC DC01:
Die Verzeichnispartition, in diesem Fall die Domänenpartition, in der die Änderung durchgeführt wurde.
Die maximale Anzahl der angeforderten Objekte.
Die maximale Anzahl der angeforderten Werte.
Den HWMV für die Domänenpartition vom Quell-DC DC01, den die Ziel-DCs DC02 und DC03 in ihren HWMV-Tabellen für DC01 gespeichert haben. Anhand des mitgesendeten HWMV erkennt der Quell-DC DC01, welche Änderungen die Ziel-DCs bereits besitzen und repliziert nur die aktuellsten Änderungen. Das bedeutet, es werden lediglich die Änderungen mit einer größeren USN, als der mitgesendete HWMV angefordert (in dem Beispiel, alle Änderungen ab der HWMV USN 20508), sofern der UTDV den Vorgang nicht verwirft.
Die Ziel-DCs senden ihre gesamte UTDV-Tabelle der entsprechenden Verzeichnispartition zum Quell-DC. Die UTDV-Tabelle enthält einen Eintrag für jeden DC, der ein vollständiges Replikat der Verzeichnispartition hält. Für die Domänenpartition sind es alle DCs der Domäne, für die Konfigurationspartition sind es alle DCs der Gesamtstruktur usw.
5. Der Quell-DC DC01 wiederum, antwortet dann unter anderem mit diesen Informationen:
Die DC-GUID (das Attribut objectGUID) von DC01.
Die Datenbank-GUID (das Attribut invocationId) von DC01.
Eine Reihe von Einträgen, die die Objektaktualisierung betreffen.
Der höchste uSNChanged Wert. Diesen Wert trägt der Ziel-DC in seine HWMV-Tabelle, als den aktuellen HWMV Wert für den Quell-DC ein.
Den UTDV von DC01
6. Findet nun die eigentliche Pull-Replikation vom Quell DC DC01 zu den Ziel-DCs DC02 und DC03 statt, wird neben dem aktualisierten Attribut description auch die ursprüngliche USN 20509 zu den Ziel-DCs repliziert.
7. Wenn die Ziel-DCs diese Änderung erhalten, aktualisieren sie in ihrer HWMV- und UTDV-Tabelle der Domänenpartition, die Werte für den Quell-DC DC01 auf den neuen Wert 20509. Zusätzlich aktualisieren die Ziel-DCs ihren eigenen HWMV, jedoch nicht ihren eigenen UTDV. Die Änderung wurde schließlich auf dem Quell-DC DC01 durchgeführt. Zur Erinnerung: Der UTDV wird nur bei einer ursprünglichen und nicht bei einer replizierten Aktualisierung erhöht.
8. Nach der Replikation liegen auf den Ziel-DCs Änderungen vor, die angeblich repliziert werden müssen. Auf beiden Ziel-DCs hat sich der lokale HWMV erhöht. Der neue HWMV der Domänenpartition von DC02 ist 37259 und von DC03 39271.
Wenn nun DC02 eine Änderungsbenachrichtigung an DC03 sendet und ihn darüber informiert, dass Änderungen vorliegen, sendet im Gegenzug DC03 den HWMV zu DC02, den er für DC02 in seiner HWMV-Tabelle gespeichert hat, also 37258 und seine komplette UTDV-Tabelle. In der UTDV-Tabelle die DC03 zu DC02 sendet, stehen die Werte „DC01-UTDV Domain NC 20509“ und „DC02-UTDV Domain NC 37258“.
9. Anhand des HWMV 37258 den DC03 zu DC02 gesendet hat, geht DC02 davon aus, dass DC03 die aktuelle Änderung noch nicht erhalten hat.
Und an dieser Stelle, kommt der UTDV zum Einsatz! DC02 erkennt nämlich anhand der UTDV-Tabelle (genauer an dem Eintrag DC01-UTDV Domain NC 20509), die DC03 vor der Replikation zu DC02 gesendet hat, das DC03 bereits die Änderung von DC01 erhalten hat. Die Änderung wird also nicht erneut repliziert! Danach aktualisiert DC03 nur den HWMV und UTDV von DC02 in seinen Tabellen, auf den aktuellen Wert 37259.
10. Das gleiche Verfahren wird in umgekehrter Konstellation angewendet, also wenn DC03 die beiden anderen DCs DC01 und DC02 informiert das Änderungen vorliegen oder wenn DC01 von DC02 benachrichtigt wird. Das Einzige was passiert ist, das jeder DC in seiner HWMV- und UTDV-Tabelle, die aktuellen Werte der beiden anderen Replikationspartner einträgt.
Der Änderungsstempel
Wenn ein Objekt erstellt wird, erhält jedes einzelne Attribut für das ein Wert vergeben wurde, einen Änderungsstempel. Der Änderungsstempel besteht aus dem Ursprungsserver, dem Zeitstempel und der Versionsnummer. Wird ein Attribut geändert, werden diese drei Komponenten aktualisiert.
Die drei Komponenten bedeuten:
Ursprungsserver: Bei dem Ursprungsserver handelt es sich um den DC, auf dem die ursprüngliche Aktualisierung eines Attributs durchgeführt wurde. Dieser Wert wird mit dem aktualisierten Attribut auf die Replikationspartner repliziert.
Zeitstempel: Bei der Änderung eines Attributs, wird der Zeitpunkt der Durchführung, in Form von Datum und Uhrzeit, mit dem Attribut gespeichert. Dieser Zeitwert wird ebenfalls mit dem aktualisierten Attribut repliziert.
Versionsnummer: An der Versionsnummer lässt sich erkennen, wie oft ein Attribut geändert wurde. Bei der Erstellung eines Objekts, wird jedem Attribut das einen Wert enthält, die Versionsnummer 1 zugewiesen. Alle Attribute die keinen Wert besitzen, erhalten die Versionsnummer 0. Jedes Mal wenn sich der Wert eines Attributs ändert, erhöht sich die Versionsnummer um einen Zähler. Auch dieser Wert wird so wie die anderen beiden Komponenten auf die Replikationspartner repliziert.
Mit Repadmin lassen sich die Komponenten mit diesem Befehl Anzeigen:
Repadmin /showobjmeta <DC> <DN des Objekts>
In der Repadmin-Ausgabe befindet sich der Ursprungsserver in der Spalte Ursprüngl. DSA. Hinter dieser Komponente steckt das Attribut objectGUID eines DCs. Wie zu erkennen, befindet sich der Zeitstempel in der Spalte Ur.Zeit/Datum und die Versionsnummer in der Spalte Ver.
Mittels des Änderungsstempels wird bei einem Replikationskonflikt darüber entschieden, welche Änderung übernommen wird. Wie das AD einen Replikationskonflikt auflöst und welche Konflikte wann entstehen können, beschreibt der folgende Artikel:
Weitere Informationen:
Die Linked Value Replikation (LVR)
Die unterschiedliche Größe der AD-Datenbank
Die konstruierten Attribute abfragen
Domänencontroller vergleichen
Die Active Directory-Attribute hinter den Feldnamen
Troubleshooting replication with repadmin
How the Active Directory Replication Model Works: Active Directory
Comments are closed, but trackbacks and pingbacks are open.