End2End AD

Bei der Suche nach Replikationslatenzzeiten ist es manchmal sehr hilfreich, ein Objekt regelmäßig zu ändern und auf anderen Server "nachzuschauen", was davon schon angekommen an. Das Active Directory repliziert sich ja über aufsteigende USN und so kann eine Änderung eigentlich nie eine andere Änderung überholen, zumindest innerhalb der gleichen Partition.

End2End-AD Videobeschreibung
https://www.youtube.com/embed/DiIA4_u8lq0

Funktion

Ich habe nach einem Weg gesucht, wie ich auf jedem DC regelmäßig eine Änderung vornehmen kann um dann auf den anderen DC nachzuschauen, wie lange es für die Replikation dieser Änderung benötigt hat. Das Script ist schon relativ alt und daher in VBScript gehalten. Um unabhängig von zentralen Diensten und WAN-Verbindungen zu sein, lasse ich da Skript auf jedem Domain-Controller als "geplanter Task" als LocalSystem laufen. Damit bin ich unabhängig von Dienstkonten und Netzwerkverbindungen. Das Skript startet alle 5 Minuten und schreibt einfach einen Zeitstempel in ein zu definierendes Feld des eigenen Computerobjekts. Sie können dann auf einem anderen DC sich das Computerobjekt anschauen und sehen anhand des Zeitstempels, wie "alt" die Information über Änderungen auf diesem DC vermutlich ist.

Dass so eine Replikationsüberwachung sinnvoll ist, können sie z.B. auch an SCOM erkennen. Microsoft Operation Manager legt dazu aber eigenes eine OU mit Unterobjekten an:

Ich gehe dann davon aus, das der SCOM-Agent auf dem jeweiligen Server den Eintrag entsprechend vornimmt. Ich komme ohne diese zusätzliche Objekte aus, wenn ich ein freies Feld auf dem Domain Controller selbst verwende.

Sicherheit

Damit das Skript natürlich Felder auf dem Computerobjekt ändern kann, muss ich sicher sein, dass "SELBST" die entsprechende Rechte zumindest auf dem Feld hat. "Selbst" hat aber schon genau die Rechte, die auch das Computerkonto hat. Welches Feld man dazu dann heranziehen kann, ist durch die Berechtigungen auf dem AD-Objekt des Computers vorgegeben

Auch der Computer kann also eine "Persönlichen Informationen" schreiben und lesen, selbst wenn es ein Domänencontroller ist. Und das sind je nach Windows Version nur ein paar Felder.

Interessant sind davon natürlich die Felder, die auch noch im Global Catalog enthalten sind, denn dann kann man auch die Änderungen auf GCs in anderen Domänen sehen. Und man sollte das Feld auch in Active Directory Users & Computers sehen oder sogar als Spalte addieren können. Da bleiben dann nicht mehr so viele Felder übrig, wenn man GlobalCatalog, "Personal Information Set" und String nutzt:

Attribut
LDAP Name		 Attribute
Display Name		 AD User&Computers
Karteikarte/Feld		 AD User&Computers
Spalte		 Syntax MultiValued MinRange MaxRange

c

Country Abbreviation

Addresse: Country/region

Country/region

DirectoryString

FALSCH

1

3

homePhone

Home Phone

Telephones:Home

Home

DirectoryString

FALSCH

1

64

ipPhone

IP Phone Number

Telephones:IP phone

IP phone

DirectoryString

FALSCH

l

City

Address:City

City

DirectoryString

FALSCH

1

128

mSMQDigests

OctetString

WAHR

16

16

mSMQSignCertificates

OctetString

FALSCH

otherIpPhone

IP Phone Number (Others)

Telephones:IP Phone Number (Others)

IP Phone Number (Others)

DirectoryString

WAHR

st

State/Province

Address:State/province

State/province

DirectoryString

FALSCH

1

128

street

DirectoryString

FALSCH

1

1024

telephoneNumber

Telephone Number

General:Telephone number

Telephone number

DirectoryString

FALSCH

1

64

UserCert

OctetString

FALSCH

0

32767

UserCertificate

OctetString

WAHR

UserSMIMECertificate

OctetString

WAHR

Auch wenn das Feld "TelephoneNumber" eigentlich auch für Exchange, Lync, TK-Anlagen o.ä. interessant sein kann, habe ich mir hierfür entschieden, da das Feld einfach auch in der Liste von Active Directory Benutzer und Computer eingeblendet werden kann. Hier am Beispiel meines Desktop.

So können Sie natürlich auch die DCs anzeigen.

Natürlich können Sie ein beliebiges anderes Feld wählen. Ratsam ist aber immer ein Feld mit dem Typ "STRING", welches auch im GC enthalten ist. Sonst können die die Aktualität nur innerhalb der Domäne prüfen.

Skript einsetzen

Das Skript selbst habe ich aktuell nicht als EXE oder gar als "Windows Dienst" umgesetzt, sondern einfach als VBScript. Aktuell dürfte auf jedem Windows Server auch VBScript vorhanden sind während PowerShell besonders auf Windows 2000 oder 2003 noch nicht zum Standard gehört. Eine Adaption des Skripts auf PowerShell ist natürlich einfach möglich. Wenn ein Leser das Skript als "Dienst" umsetzen möchte, kann er das gerne tun.

End2End-AD.1.0.vbs.txt
Nach dem Download die Endung ändern.

Laden Sie sich das Skript einfach herunter und kopieren Sie es z.B. auf den Domain Controller. Dort müssen Sie es dann einfach als "LocalSystem" regelmäßig per Taskplaner aufrufen. Hier die wesentlichen Einstellungen.

Per Default wird der Task mit den Anmeldedaten des Users gestartet, der den Job einrichtet. Sie müssen also manuell dies auf "SYSTEM" umstellen. Wenn der Pfad zum VBScript Leerzeichen enthält, dann müssen Sie diesen in Anführungszeichen setzen. Wenn Sie dann diesen Job auf jedem DC eingerichtet und ausgeführt haben, dann sehen Sie im Active Directory die entsprechenden Zeiten.

Hinweis zur AD-Replikation
Das Skript ändert genau ein Feld alle 5 Minuten. In den meisten AD-Umgebungen ändern sich schon als Grundlast deutlich mehr Element in der gleichen Zeit, z.B. "LastLoginDate" etc., so dass ich dieses zusätzliche Volumen als nicht kritisch ansehe.

Debugging

Wenn Sie Änderungen am Skript vornehmen, dann kommen sie sehr schnell in die Notwendigkeit, das Skript auch einmal "interaktiv" auszuführen. Klar können Sie das Skript "als Benutzer" mal eben so schnell starten. Aber das ist ja dann nicht LocalSystem". Früher gab es den Umweg über "AT.EXE" oder SCHTASKS den Auftrag zu aktivieren und auf "interaktiv" zu setzen. Seit Windows Vista ist dies aber nicht mehr möglich. Aber Sysinternals hilft hier.

REM  CMD-Shell als "LocalSystem" aufrufen
psexec -i -s cmd.exe

Dann können sie mit CSCRIPT das Programm auch interaktiv starten und etwaige Fehlermeldungen erkennen.

Globale Suche

Auf die Schnelle können Sie auch über AD Users & Computers mal schnell eine Suche starten.

Hinweis:
Das Feld "telephoneNumber" ist per Default zwar im Global Catalog aber nicht indexiert. In einer großen Umgebung kann so eine "Volltextsuche" dann schon etwas länger dauern.

Hier zwei Beispiele.

Offen

Dies ist ein erstes Skript und nur ein Baustein einer Überwachung oder Auswertungslösung. Natürlich ist es noch nicht "perfekt". Auf meiner Liste stehen:

  • Windows Dienst
    Die Umsetzung als VBS mit Taskplaner ist natürlich nur ein erster Schuss. Ein EXE-Programm, welches einfach als Dienst implementiert werden kann, wäre natürlich eleganter
  • Debug-Ausgaben und Eventlogmeldungen
    Für die Fehlersuche, wenn das Programm als Dienst oder Task läuft, wäre natürlich eine Ausgabe in eine Datei oder in das Eventlog wünschenswert
  • Überwachungskomponente
    Ein zweites Skript oder auch das gleiche Skript könnte regelmäßig z.B. alle Objekte mit dem LDAP-Filter "(telephonenumber=end2end*)" suchen und die Zeiten mit der aktuellen Zeit vergleichen. So könnte sehr einfach ermittelt werden, welche Objekt schon länger nicht mehr auf dem abgefragten DC aktualisiert wurden. Aktuell beschränke ich mich auf die Anzeige in AD Users&Computers und keine löse keine Alarme o.ä. aus.

Sie sehen also, dass die Arbeit nie ausgeht.

Weitere Links