Attribute für AD User : uSNChanged
Das Active Directory Attribut uSNChanged speichert die lokale Update Sequenz Nummer (USN) des jeweiligen Domänencontrollers im Moment der letzten Änderung am betreffenden Benutzerobjekt. Da jeder DC eigene USN-Werte hat, ist der Wert von uSNChanged für einen Benutzer auf jedem Domänencontroller unterschiedlich - das Attribut wird also nicht zwischen DCs repliziert!
uSNChanged
LDAP Name | uSNChanged |
Datentyp | Integer8 (64 bit signed numeric) |
Multivalue (Array) | Nein |
System Flags | 0x13 |
Search Flags | 0x09 |
Im Global Catalog? | Ja |
Attribute ID | 1.2.840.113556.1.2.120 |
AD DB Attributname | USN-Changed |
ADSI datatype | 10 - LargeInteger |
LDAP syntax | 1.2.840.113556.1.4.906 - Microsoft Large Integer |
Wird verwendet in ... | > W2K |
Schema Doku | Microsoft - MSDN |
Es existiert auch noch ein Wert, der bei der Erzeugung des Objekts geschrieben wird: uSNCreated.
Der Wert von uSNChanged kann nur durch das System selbst geändert werden - aber man kann ihn per Script auslesen. Als Large Integer Wert muß das uSNChanged Attribut in Scripts besonders behandelt werden. Es handelt sich hier um numerische Werte von 8 Byte (64 bit) Länge - aus diesem Grund werden sie oft auch Integer8 Werte genannt:
Minimum value: -9223372036854775808 (-2^63) or hex 0x8000000000000000 |
Maximum value: 9223372036854775807 (2^63 - 1) orhex 0x7FFFFFFFFFFFFFFF |
Integer8 Werte müssen in VBScripts in zwei Teilen (dem so genannten HighPart und LowPart) ausgelesen werden. Man kann diese Teil dann aber zu einer Zahl zusammenfügen. Ein Beispiel:
Ein LDAP Filter, der alle Objekte sucht, die ab einer bestimmten Update Sequenz Nummer geändert wurden, könnte so aussehen:
(uSNChanged>=504031)
Das uSNChanged Attribut wird für die technische Abwicklung der inkrementellen Active Directory Replikation benötigt - der Domänencontroller kann hier feststellen, welche Änderungen er an andere DCs replizieren muß. Die USN Werte sind Nummern, die der Domänencontroller bei jeder Änderung innerhalb der gesamten AD Datenbank um eins erhöht.
Die Bedeutung dieser Werte wird in den folgenden Videos erläutert:
http://youtu.be/NVOdnVBAC00?hd=1
Deutlich wird: Jeder DC führt seine eigene Nummerierung der Vektoren und dementsprechend auch eigene USN-Werte für alle Objekte und Attribute in seiner Datenbank. Nicht deutlich wird hingegen, wie denn diese Werte nun verwendet werden, um diejenigen Attribute zu ermitteln, die tatsächlich zu replizieren sind. Dafür schauen wir uns den letzten Replikationsvorgang des Videos nochmals im Detail an: Auf DC2 wurden gerade die Attribute für Passwort und EMail-Adressierung geändert. DC1 löst nun die Replikation aus:
http://youtu.be/SDPJVMPAcDw;hd=1
Um das interne Entscheidungsverfahren für die inkrementelle Replikation noch mehr zu verdeutlichen, soll dem Szenario ein weiteres Detail hinzugefügt werden: Es wurde noch nicht zwischen DC1 und DC2 repliziert, auf DC2 wurden gerade die Attribute für Passwort und EMail-Adressierung geändert. Zusätzlich dazu wird nun ein Attribut auf einem anderen DC geändert. Die Änderung ist unseren beiden DCs bekannt. Wie merkt DC2 nun, dass genau diese Änderung in der nächsten Replikation NICHT zu DC1 gesendet werden muss? Schauen wir uns dafür wieder ein Video an.
http://youtu.be/bDFNoW2U03c?hd=1
Der für einen
Domänencontroller aktuell geltende gobale USN-Wert kann im RootDSE-Eintrag als Attribut highestCommitedUSN untersucht werden (der