Fehlersuche mit dem ADC
Viele Funktionen das ADC sind erkennbar und kontrollierbar. Der ADC kann sehr gesprächig sein, wenn man das Diagnoseprotokoll des ADC aktiviert. Dies ist einfach mit der MMC möglich. Dazu müssen sie die Eigenschaften des ADC bearbeiten und auf der Karteikarte "Diagnoseprotokoll" die entsprechenden Einträge zu aktivieren.
Die Diagnose des ADC ist nicht nur eine Aufgabe für den Fehlerfall, sondern die ganze Zeit, in der ein ADC benötigt wird, muss die Funktion sichergestellt sein. Stoppt die Replikation an einem defekten Objekt, dann steht die komplette Verbindungsvereinbarung, prüfen Sie daher regelmäßig die Funktion des ADC
Unterstützung durch
Net at
Work:
Für die Überwachung des ADC habe och für größere Umgebungen ein Script
CheckADC entwickelt, welches Sie im Rahmen
von Support oder Dienstleitung erhalten können.
Aktivierung der Diagnosefunktion
Die Aktivierung erfolgt etwas versteckt in der MMC des ADC. Auf den Eigenschaften des ADC selbst, nicht der einzelnen CAs, wird die Funktion aktiviert. Achten Sie vorab darauf, dass ihr Eventlog ausreichend groß ist und Sie wissen, wonach sie suchen. Vielleicht ist eine Suche in den Errordateien besser geeignet.
Unter den Eigenschaften finden sich dann die entsprechenden Einträge:
Die Ergebnisse des ADC Loggings landen im Eventlog.
Interessante Eventlog IDs
Folgende ID's im Eventlog sind interessant, um die Funktion des ADC zu überwachen.
EventID | Beschreibung / Beispiel |
---|---|
8271 |
Je repliziertem Elemente wird diese Eventlog ID mit einigen Infos geschrieben. Event Type: Information |
8291 |
Diese Fehler beschreiben, dass gelöschte Objekte nicht repliziert
werden. Meist haben Sie diesen Fehler am Anfang einer Replikation, wenn
im AD noch "tombstone"-Objekte sind, die aber noch nie repliziert wurden. Der Fehler kann aber auch bedeuten, dass der ADC ein Objekt nicht replizieren kann, weil in der CA die Nutzung des LegacyExchangeDN vorgeschrieben ist, aber dieser nicht gesetzt ist. Meist ist die ein Hinweis, dass der RUS die im AD aktivierten Elemente noch nicht verarbeitet hat. |
9138 |
Diese Meldung besagt, dass irgend etwas bei ihnen auf
beiden Seiten das gleiche Objekt verändert hat, d.h. das Zielelement,
welches der ADC eigentlich ändern wollte, hat sich in der Zwischenzeit
auch geändert. Kontrollieren Sie, ob sie nicht mehrere CAs haben die sich Gegenseitig stören. The target object 'CN=fcarius,OU=Users,DC=msxfaq,DC=local'
was modified after the source object 'cn=fcarius,cn=Recipients,ou=Paderborn,o=MSXFAQ'
Consequently, the following set of Updates will not be applied to the
target object. If this warning persists, make sure that the time is
correctly set on both the source and target servers. |
8148 |
Dies ist die Meldung am Ende einer erfolgreichen Replikation. Es ist durchaus nützlich, das Auftreten dieser Meldung regelmäßig zu kontrollieren. Sie zeigt, dass das entsprechende CA noch aktiv ist: Event Type: Information |
8180 |
Wenn sehr viele Elemente zu replizieren sind, dann legt der ADC nach ca. 300 Sekunden eine Pause für 300 Sekunden ein. Damit soll verhindert werden, dass zu viele Änderungen das AD überlasten. Hier heißt es dann einfach Geduld zu haben, bis die 8148 kommt. Event Type: Information |
8274 |
Diese Meldung erhalten Sie, wenn der ADC Benutzer nicht löschen darf und statt dessen diese in den LDF bzw. CSV-Datein ablegt. Der ADC repliziert nicht mehr und die Meldung verschwindet, wenn Sie als Administrator die längst überfälligen Replikationen entfernen. Event Type: Warning |
Kontrolle mit ERR-Dateien und Delete-Dateien
Der Active Directory Connector legt in seiner Programmstruktur verschiedene Protokolldateien an, die Hinweise auf Fehler und Probleme liefern als auch offene Löschaktionen anzeigen. Wenn Sie beim ADC einstellen, dass Löschbefehle nicht ausgeführt werden, dann werden diese Aktionen in eine Datei verschrieben. Sie müssen manuell diese Aktionen durchführen, da ansonsten ihre Verzeichnisse nicht mehr synchron sind.
Die Protokolldateien liegen in der Regeln unter C:\Programme\MSADC\MSADC\xxxx, wobei xxx für den Namen der Verbindungsvereinbarung steht. Es gibt daher je Verbindungsvereinbarung auf dem, Server, auf dem das ADC läuft eigene Dateien.
Es gibt insgesamt folgende Dateien, die regelmäßig zu beachten sind.
- WIN2000.LDF
Wenn Sie in Exchange 5.5 ein Postfach löschen, und der ADC das Windows NT Konto im AD nicht löschen darf, dann werden diese Löschbefehle in der Datei WIN2000.LDF hinterlegt. Sie können diese Aktionen dann nach einer Kontrolle mit LDIFDE importieren. Das ist knifflig, da ein gelöschtes Konto auch den Verlust der SID und Berechtigungen als auch Verschlüsselungskeys bedeutet. - Win2000Failed.LDF
Hier schreibt der ADC alle fehlerhaften Importversuche in das AD hinein. Auch diese Datei sollten sie regelmäßig kontrollieren und die Ursachebeheben. Der ADC v ersucht die Replikation immer wieder, wird aber immer wieder auf den gleiche Fehler laufen, wenn z.B.: die Berechtigungen nicht ausreichen. - EX55.CSV
Werden umgekehrt im Active Directory Benutzer gelöscht, würde die Mailbox in Exchange 5.5 auch entfernt. Da dies nicht einfach rückgängig zu machen ist, wird diese Option teils deaktiviert. Das bedeutet aber, dass manuell die Postfächer zu löschen sind. - EX55ERR.CSV
Diese Datei enthält die Importfehler in Exchange 5.5, z.B.: wenn eine Änderung eines Objekts im AD nicht nach Exchange 5.5 repliziert werden kann, weil Rechte fehlen oder das Element dort ebenfalls geändert wurden. - EX55-2Failed.LDF
Umgekehrt enthält diese Datei Importfehler in das AD, d.h. Änderungen in Exchange 5.5 können, warum auch immer, nicht in das AD repliziert werden.
Den Ablagepfad zu den Protokolldateien können Sie auch anpassen. Das Basisverzeichnis kann in der Registrierung des ADC-Servers eingetragen werden.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSADC\Parameters\
"Transaction Directory":String = "C:\ADCLogs"
Stellen Sie aber sicher, dass das Dienstkonto des ADC an dieser Stelle auch die Rechte zum schreiben hat.
Weitergehende Informationen hierzu finden Sie auch unter:
- Q253829 XADM: Description of the Active Directory Connector Deletion Mechanism
- 249831 XADM: How to Delete Windows 2000 User Accounts Stored in LDF Files by the ADC für Deferred Deletion
Kontrolle mit Skripten und Drittprogrammen
Nun kann man natürlich auf dem Standpunkt stehen, dass der ADC ziemlich fehlerfrei arbeitet. Und das scheint auch oft zu sein. Aber mit jedem Service Pack wird klar, wie viele Sonderfälle ältere Versionen nicht korrekt umsetzen konnten.
Da liegt der Wunsch nahe, eine unabhängige Instanz einzusetzen, um die korrekte Funktion zu überprüfen. Leider gibt es keine frei verfügbare Programme für diese Aufgabe. Aber es gibt diverse Dritthersteller (z.B. Compaq), die entsprechende Tools entwickelt haben. Auch bei Microsoft gibt es wohl unter dem Namen "ADCCheck" ein entsprechendes Tool, welches aber noch nicht öffentlich ist. Ich habe mir aber dazu ein eigenes Tool CheckADC entwickelt.
Denkbar ist auch, dass mit VBScript oder anderen Sprachen selbst entsprechende Testroutinen entwickelt werden. So könnte ein Programm einfach die Anzahl der Empfänger in der globalen Adressliste zwischen beiden Systemen vergleichen.
Hinweise auf weitere entsprechende Programme nehmen ich gerne an.
Weitere Links
- ADC Verbindungsvereinbarungen
- ADC-Probleme
- ADC-Advanced
- ADC Matching
- ADCDetails
- ADClean
- ADCTools
- ADC-FAQ
- Exchange 2003 Deployment Tools
-
CheckADC
Überwachung des ADC per Script - Q259396 XADM: How to Set Diagnostic Logging für the Active Directory Connector
- Q253841 XADM: Troubleshooting ADC Replication Issues
Sehr guter und lesenswerter Artikel, wenn der ADC Objekte nicht repliziert.