Active Directory Connector Probleme
Der Active Directory Connector (ADC) ist der wichtigste Teil bei der Synchronisation der beiden Verzeichnisdienste von Exchange 5.5. (DIR.EDB) und Exchange 2000. Und dass dabei mal etwas "daneben geht", liegt schon fast in der Natur der Sache. Ohne ordentliche Planung kann man zwei Verzeichnisdienste nicht sauber parallel fahren, die in der internen Funktion so unterschiedliche sind. Das fängt beim Löschen von Anwendern an und die Liste kann endlos sein.
Die meisten Dinge sind "klar", wenn sie passiert sind und sie die Funktionsweise des ADC auf die harte Tour können gelernt haben. Je mehr Sie über den ADC wissen, desto eher können Sie solche Fehler vermeiden.
Verschieben von Anwendern in OU's, Anlegen neuer OU's
Oft werden Benutzer im AD von einer OU in eine andere verschoben. Das ist soweit nicht schlimm im AD, aber im Bezug auf die Replikation des ADC schon wieder ärgerlich, da der ADC bei der Replikation vom Active Directory nach Exchange 5.5 nur die OU's auf Änderungen überwacht, die als Quelle angegeben sind. So kann es passieren, dass damit ein Benutzer in dieser OU nicht mehr vom ADC erfasst wird und langsam aber sicher die Verzeichnisse auseinanderdriften. Denken Sie daher genau daran, wenn sie z.B.: OU's verschieben oder neue OU's anlegen, oder Benutzer verschieben oder sogar Rechte auf OU's einschränken, dass im Hintergrund der ADC arbeitet. Fehler bei den Berechtigungen werden Sie im Eventlog erkennen aber nicht mehr überwachte OU's fallen oft sehr spät an unzustellbaren Mails auf.
Diese Problematik gilt nicht auf der Zielseite des ADC. Wenn Sie einen Benutzer aus einer OU in eine andere OU verschieben, dann wird der ADC Änderungen auf der Exchange 5.5 Seite auch an den verschobenen Benutzer anwenden. Über das Feld "ADCGlobalNames" findet der ADC den verschobenen Benutzer auch dann wieder, denn diese OU nicht als Exportcontainer für die Replikation von Windows nach Exchange eingetragen ist. Allerdings ist auch hier eine korrekte Berechtigung für den ADC wichtig, damit diese Funktion möglich ist.
In einer Phase der Migration sollte daher möglichst wenig unruhe in die Struktur des AD kommen. Idealerweise ist eine feste Zuordnung von Exchange 5.5 Empfängerkontainer zu Active Directory OU's, zumindest bist die Migration abgeschlossen ist.
Falsch zugeordnete Benutzer
Von der Seite Active Directory Connector (ADC) sollten Sie wissen, dass Exchange 2000 bestimmte Zuordnungen von Berechtigungen von Exchange 5.5 nicht übernehmen kann. So kann ein Windows NT-Konto nun mehr nur genau ein Postfach innehaben. Wer hier vorher nicht aufpasst, wird im nachhinein nacharbeiten müssen. Aber dies ist nicht wirklich einfach. Hier ein Beispiel:
Ein Benutzer wurde falsch zugeordnet und es wurde versucht, diesen Fehler zu lösen, in dem die Exchange 2000 Eigenschaften im AD gelöscht wurden. Der Denkansatz scheint logisch zu sein, weil der ADC dann den Benutzer nicht mehr findet und neu zuordnet. Wurde ein der Zwischenzeit auch das Exchange 5.5 Quellobjekt derart bearbeitet, dass hier mit NTDSNOMATCH nun die richtige Zuordnung getroffen werden kann, dann sollte das im Bezug auf den Anwender funktionieren. Allerdings haben die dann eine Feinheit nicht bedacht:
Wenn Sie bei dem Benutzer die Exchange Eigenschaften löschen, dann ist dieser Active Directory Benutzer nicht mehr "Mail aktiviert". Er wird es zwar nach der nächsten Replikation hoffentlich wieder aber für diesen Zeitraum ist er kein Exchange Empfänger.
Dies wird der ADC sicherlich bemerken und zwar an den Gruppenmitgliedschaften. Der ADC repliziert nicht nur Benutzer, sondern auch Mailverteiler und der Benutzet wird zwar noch in der Active Directory Gruppe enthalten sein, aber das Entfernen der Maileigenschaften ist der den ADC die Aufforderung, den Benutzer in Exchange 5.5. aus dem Verteiler zu entfernen. Und wenn dies nur für einige Minuten oder Stunden der Fall ist, so ist es sicher nicht gewollt, denn in der Zeit kann der Benutzer die entsprechenden öffentlichen Ordner ebenso wenig Erreichen wir Nachrichten an diesen Verteiler. Von der zusätzlichen Replikation und Verzögerung in Exchange 5.5 gar nicht erst zu reden.
- 256862 XADM: How to Correct Mismatched Accounts After Active Directory Connector Replication
- 274173 XADM: Documentation für the NTDSNoMatch utility
Erneute Replizierung und doppelte Änderungen
Betrachten Sie sich die unterschiede von Exchange 5.5 und Active Directory in der Art und Weise, wie die Daten repliziert werden. Exchange 5.5 repliziert immer komplette Objekte über einen Nachrichten per Mail. Das Active Directory repliziert hingegen einzelne Felder eines Objekts mittels USNs. Der ADC kann nun auf beiden Seiten nur anhand der USN die Änderungen erkennen.
Wird nun ein Element im AD verändert, so liest der ADC diese Änderung ein und schreibt diese das korrespondierende Feld in Exchange 5.5. Exchange 5.5. aber repliziert nun das gesamte Objekt. Und dieser Prozess dauert bei größeren Strukturen durchaus einige Stunden, bis der letzte Server dieses Update erhalten und verarbeitet hat. Wird in dieser Zeit das Objekt an einer anderen Stelle geändert, so ist die Gefahr groß, dass die Replikationen einen Konflikt verursachen, die Exchange 5.5 nach dem Motto "der letzte Gewinnt" löst.
Die Folgen können Sie sich selbst ausmalen. Das Ziel muss daher eine klare administrative Vorgabe sein, wer dann welche Objekte verändert und welche Pausenzeiten eingehalten werden müssen. Es ist durchaus eine sinnvolle Idee, mit eigenen Skripten (Programmieren mit Exchange) zu kontrollieren, ob alles mit rechten Dingen abläuft. Dazu gehört auch einen Überwachung des Systems samt Eventlog (Exchange überwachen und kontrollieren)
Zugehörigkeiten in Gruppen gehen verloren
Stellen Sie sich vor, sie haben eine gemischte Umgebung mit Exchange 2000 und Exchange 5.5. Der Active Directory Connector hält beide Verzeichnisse synchron.
Sie haben nun einen Benutzer, der ein Exchange 200 Postfach hat und in einer Verteilergruppe ist. Bei Exchange 2000 ist dies eine Sicherheitsgruppe. Der ADC repliziert diese Information natürlich in einen Verteiler von Exchange 5.5. Soweit ist noch alles in Ordnung. Nun beginnt das unheimliche:
Sie wollen, warum auch immer, dem Benutzer die Mailfunktion wegnehmen. Damit wird die Mailbox des Benutzers abgelöst und nach 30 Tagen (Standard) im Store gelöscht. Der ADC repliziert diese "Deaktivierung" nach Exchange 5.5, d.h. der Benutzer in Exchange 5.5 wird ebenfalls entfernt. Soweit ist noch alles wie gewünscht. Aber das ist damit leider noch nicht beendet.
Der ADC zu Exchange 5.5 erkennt, dass der Benutzer entfernt wird und nimmt ihn natürlich auch aus den Exchange 5.5 Verteilergruppen heraus. Auch dies ist noch gewollt und sinnvoll.
Unangenehm wird es aber nun, wenn eine andere Verbindungsvereinbarung die Verteiler mit den Windows 2000 Gruppen synchronisiert. Nun wird hinten herum der Benutzer aus der Windows 2000 Sicherheitsgruppe entfernt. Das Ergebnis ist nun, dass der Benutzer auch dort keine Rechte mehr hat, wo er diese durch die Mitgliedschaft in der Gruppe erhalten hat. Diese Konsequenz ist sicher nicht überall gewünscht.
Das gleiche Verhalten ist zu beobachten, wenn Sie "mismatched Accounts" auflösen wollen oder Benutzer innerhalb der Exchange 5.5. Standorte mit Exmerge verlagern.
Benutzer übernehmen
Viel ärger können Sie auch bei der Migration ihrer Benutzer von Exchange 5.5 nach Exchange 2000 bekommen. Die MMC verschiebt den Inhalte der Postfächer und ändert dann die Einträge sowohl im Exchange 5.5 Directory (auf dem Stammserver) als auch im Active Directory (auf dem Server mit dem sich die MMC verbunden hat). Leider sind das sicher nicht immer die Server, die der ADC nutzt, um die Objekte zu synchronisieren. Nun "kann" es passieren, dass das Active Directory sich schneller repliziert oder jemand anderes die gerade verschobenen Benutzer verändert, z.B. durch die Änderung eines Verteilers oder Pflege von Abteilung und oder Firma.
Das Ergebnis kann verheerend sein, wenn dabei das Exchange 5.5. Objekt auf einem anderen Server "später" verändert wird. Dann nämlich werden bei dem Exchange 5.5 Objekt z.B. die Eigenschaften der Gruppen geändert und Exchange 5.5. repliziert immer das komplett Objekt. Als Ergebnis kann es passieren, dass die Änderung des "Stammserver" in Exchange 5.5 dadurch wieder überschrieben wird. Damit hat der Benutzer faktisch zwei Stammserver und je nach Routing der Nachrichten kommen einige Nachrichten richtig an und andere in dem toten Postfach. Eine Zusammenführung ist nicht ohne interne Kenntnisse möglich.
Tipp: Verbindungsvereinbarung stoppen, bis bei de Verzeichnisse die Änderungen übernommen haben.
Wobei auch hier aufgepasst werden muss: Die Änderung der Konfiguration einer Verbindungsvereinbarung steht im AD und nicht auf dem Server. Es kann also etwas dauern, bis die Änderung vom ADC auch "erkannt" wird.
