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:

Funktionsweise von CheckADC

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

• Von Exchange 5.5 In das Active Directory
  Wenn EX5:highestCommittedUSN > ADC:msExchServer2HighestUSN then Check EX->AD
• Aus dem Active Directory nach Exchange 5.5EX
  Wenn AD:highestCommittedUSN > ADC:msExchServer1HighestUSN then Check AD->EX

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:

• Debug
  Hiermit ist eine Diagnosefunktion aktivierbar, die auf dem Bildschirm weitergehende Werte ausgibt. Je höher die Nummer, desto detaillierter die Ausgaben: 0 = nur Ausgabe,  1 = Errors,  2 = Warnungen,  3 bis 6 = Informationen
• Target
  Wird kein Target angegeben, dann durchläuft das Script alle Verbindungsvereinbarungen. Durch die Angabe des distinguished Name einer Vereinbarung wird dieser allein geprüft.
• MaxDelta
  Das Script prüft, ob die Anzahl der ausstehenden Objekte größer ist, als der angegebene Schwellenwert. Wenn dies der Fall ist, wird ein ALERT auf dem Bildschirm oder in MOM2005 generiert.

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

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

• Andere Monitoring Lösungen
  Denkbar wäre, das Script auch für Umgebungen mit anderen Programmen als MOM2005 anzupassen, so dass auch ein OpenView, uniCenter, WhatsUp, BMC Patrol oder andere Überwachungsprogramme.
• Weitere Parametrisierung
  Ebenso könnte der Ausgabepfad und andere Parameter ebenfalls per Kommandozeile übermittelt werden.
• ADCGlobalNames Behandlung In einer gemischten Umgebung haben AD-Objekte, die in einer native Exchange 200x Site sind, keinen ADCGlobalNames mehr.
• Erkennen nicht zu replizierender Objekte
  Der ADC erkennt bei den Quellobjekten auch, ob diese durch das jeweilige CA überhaupt zu replizieren sind. Das kann er z.B.: am LegacyExchangeDN festmachen. Nur Objekte, die zur Exchange 5.5 Zielsite passen, müssen repliziert werden. Aktuell listet CheckADC daher unter umständen noch zu viele Objekte auf.

Weitere Links

• MOM2005
• QStatusMOM
  Überwachung der Warteschlangen anhand des Verweilzeit der ältesten Mail
• CheckRUS mit MOM
  Überwachung der Funktion des RUS anhand der aktuellen und der von RUS zuletzt bearbeiteten USN
• WSUS
  Überwachung der Eventlog des Windows Update Clients auf den durch MOM überwachten Systemen und Warnung wenn Patches ausstehen.