CheckADC

Alle Skripte sind Muster ohne jede Gewährleistung oder Funktionsgarantie. Für Schäden bin ich nicht verantwortlich. Achten Sie auf Zeilenumbrüche bei der Übernahme.

Der Active Directory Connector ist eine wichtig Komponente bei der Migration von Exchange 5.5 nach Exchange 2000/2003. Daher gibt es zum ADC jede Menge Informationsseiten auf der MSXFAQ.DE wie z.B. Active Directory Connector Grundlagen, ADC CAs, ADC-Probleme, ADC-Advanced, ADCDetails, ADCTools und ADC-FAQ.

Aber gerade weil er so wichtig und komplex ist, hat mich immer gestört, dass die Funktionsüberprüfung mehr als spärlich ist. Sie können zwar über das Eventlog (Siehe ADC Diagnose) die Funktion im Groben überwachen, aber so richtig prächtig ist das alles nicht. Vor allem wenn Sie in einer größeren Umgebung mit vielen CA's auf verschiedenen Servern sind, ist dies keine effektive Methode mehr. Und gerade vor der Umschaltung in den Native Mode (Siehe Switch Native) möchte ich sicher sein, dass wirklich alle Objekte von Exchange 5.5 in das Active Directory und umgekehrt übernommen wurden. Aber wie kann das geprüft werden ?.

CheckADC prüft nur den Replikationsstatus der verschiedenen CAs, aber kann natürlich nicht erkennen, ob wirklich alle Quellen und Ziele miteinander repliziert sind. Hier ist GalComp geeignet, um die Objekte quantitativ zu erfassen.
Die Anzeige von CheckADC ist zu interpretieren, da CheckADC zusätzlich feststellt, welche Objekte seit der letzten Replikation geändert wurden. CheckADC kann aber nicht erkennen, ob die Änderungen auch für den ADC relevant sind. Insofern sind hier weitere Prüfungen erforderlich. Für einen aktiven Test müsste ein Objekt verändert und nach einiger Zeit die Replikation zum anderen System kontrolliert werden. Dies leistet CheckADC nicht.

ADC Funktionsweise

Werfen wir einen sehr kleinen Blick hinter die Kulissen. Der ADC arbeitet mit Verbindungsvereinbarungen, um veränderte Objekte einer Quelle zu erkennen und in das Ziel zu replizieren. Sowohl Exchange 5.5 als auch das Active Directory arbeitet dabei mit USNs. Das sind Nummern, die bei jeder Änderung erhöht werden und pro Server individuell sind.

Der ADC merkt sich nach dem Abschluss einer Replikation die zuletzt verarbeite USN. Beim nächsten Lauf fragt der ADC bei der Quelle dann gezielt nach der aktuell höchsten USN und ermittelt darauf dann die Objekte, die verändert wurden. Aus der Differenz der USNs und den davon betroffenen Objekten lässt sich die Funktion des ADC ableiten. Dies muss natürlich je Verbindungsvereinbarung für jede aktive Richtung gemacht werden. Der ADC merkt sich dabei die Informationen in folgenden Feldern des jeweiligen CA's:

Feldname Typ Bedeutung
msExchServer1ExportContainers Multivalue In diesem Feld stehen alle OUs des Active Directory, welche der ADC bei der Replikation aus dem Active Directory nach Exchange 5.5 überwachen soll
msExchServer1ImportContainer String In diese OU werden die Daten von Exchange 5.5 in das Active Directory per Default importiert.
msExchServer1NetworkAddress String Name des Domain Controllers
msExchServer1HighestUSN   Die zuletzt verarbeitete USN dieses Domain Controllers
msExchServer2ExportContainers Multivalue Dieses Feld enthält alle Empfängercontainer der Exchange 5.5 Umgebung, die der ADC in das Active Directory importieren soll
msExchServer2ImportContainer String In diesem Empfängercontainer werden neue Objekte aus dem AD in Exchange 5.5 angelegt
msExchServer2NetworkAddress String Name des Exchange 5.5 Server (oder SRS) mit der Exchange 5.5 Datenbank
msExchServer2HighestUSN String Höchste USN dieser Exchange 5.5 Verzeichnisdatenbank

Funktionsweise von CheckADC

Für die Kontrolle ist daher folgende einfache Überprüfung notwendig:

Mein Testprogramm macht nun nichts anderes, als eben jedes CA durchzugehen und für jede Verbindungsvereinbarung das jeweils passende Feld msExchServer1HighestUSN bzw. msExchServer2HighestUSN mit der USN des dazu gehörigen Servers abzufragen. Sind die USNs abweichend, müssen ein einem zweiten Schritt vom Server die veränderten Objekte für die jeweiligen Export Container abgerufen werden. Eine USN erhöht sich natürlich auch, wenn sich irgend ein Objekt im Verzeichnisdienst verändert.

Für jede Verbindungsvereinbarung werden ausgewählte Parameter in eine XML-Datei gespeichert.

Die Datei enthält unter anderem den Namen der Verbindungsvereinbarung, den Server und die ermittelten USNs und noch nicht replizierte Objekte. Das Beispiel zeigt gut, dass zwischen der aktuellen und der letzten USN insgesamt 379 Änderungen durchgeführt wurden, aber es keine Objekte der Exportcontainer betroffen hat. Diese XML-Datei ist natürlich um einiges größer, wenn Sie viele Verbindungsvereinbarungen überwachen und zudem die noch nicht replizierten Objekte mit ausgegeben werden.

Die Aufbereitung dieser Information erfolgt z.B. mit einem entsprechenden Stylesheet im Browser. Dies könnte dann so aussehen:

Wenn sie weitere CAs haben, dann enthält die Tabelle mehr Zeilen. Über das XSL-Stylesheet ist es sehr einfach möglich, die Sortierung zu ändern. Auch die Farbcodierung ist über das Stylesheet zu steuern. So wertet das Script auch aus, ob die Verbindungsvereinbarung auf "Immer", "Nie", oder "Zeitplan"  gestellt ist. Auch die Anzahl der noch nicht replizierten Objekte wird entsprechend grün, gelb oder rot angezeigt.

In größeren Umgebungen ist die Ansicht dann natürlich schon interessanter,  wie folgendes zwar verkleinerte Bild zeigt.

Die roten Bereiche zeigen CA's. bei denen sehr viele Objekte noch nicht repliziert sind. Das ist zum Teil natürlich darauf zurückzuführen, dass die CAs "deaktiviert" sind, wie die gelben Felder der letzten Spalte zeigen. Aber es ist auch gut ersichtlich, dass einige CA's wirklich ein Problem haben. unter den roten Feldern sind einige dunkelgrün gekennzeichnete CA's. Hier sind Objekte zu replizieren. Nur die hellgrün angezeigten CAs sind aktuell "in Sync".

Aufruf

Das Script wird mit den erforderlichen Berechtigungen, die verschiedenen Werte im Active Directory und Exchange 5.5 zu lesen, aufgerufen. Über Parameter ist eine Steuerung möglich:

C:\>cscript z:\CheckADC.VBS [/debug:xx] [/Target:adc-dn] [/MaxDelta:xxxx]

Die Bedeutung der Parameter ist:

Zusätzlich ist in der aktuellen Version der Pfad der XML-Ausgabedatei im Code anzupassen.

MOM Integration

Das Script ist so entwickelt, dass es erkennt, ob es mit WScript oder unter MOM2005 aufgerufen wird. Erkennt das Script den Aufruf unter MOM, so wird für jede Verbindungsvereinbarung das Ergebnis als Event oder Alert gemeldet. Ein Eintrag wird immer dann zu einem Alert, wenn die Anzahl der ausstehenden Objekte größer als der angegebene "MaxDelta"-Wert ist.

Download

Unterstützung durch Net at Work:
Bitte haben Sie Verständnis, dass sehr leistungsfähige Scripte, die weit über eine Funktion als Muster" hinausgehen, nicht öffentlich verfügbar sind. Solche Skripte sind in kleinen Umgebungen nur bedingt bis gar nicht sinnvoll einsetzbar. In größeren Umgebungen hingegen sind zu oft individuelle Anpassungen erforderlich. Sie erhalten diese nur im Rahmen von Support oder Dienstleistung.
Informationen, warum diese Skripte nicht öffentlich sind, finden Sie auf nicht public.

Diese Script ist nur sinnvoll, wenn Sie noch Exchange 5.5 und Exchange 2000/2003 im gemischten Mode betreiben und den ADC einsetzen. In einer reinen Umgebung mit Exchange 2000/2003 im Native Mode ist dieses Script nicht erforderlich.

checkadcmom.v.1.4.vbs.txt

Geplante Weiterentwicklung

Weitere Links

Keywords: VBScript Code ADC CheckADC