Verzeichnisabgleich für Exchange

Nicht immer ist das Active Directory das einzige Verzeichnis. Nicht nur Exchange 5.5 hat einen Verzeichnisdienst, sondern oftmals gibt es eine NetWare NDS, andere Mailsysteme und oftmals existieren in einer Firma auch mehrere Active Directory Forests, die für Exchange 2000 so nicht nutzbar sind.

Wenn Sie nur eine Exchange 5.5 Organisation mit einer anderen Exchange 2000/2003 Organisation abgleichen möchten, dann ist ADC Interorg vermutlich ihre Lösung.

Hier kommt dann schnell der Wunsch, diese Verzeichnisse zu synchronisieren oder zumindest teilweise zu nutzen. Tatsache ist aber auch, dass Exchange 2000 nur Elemente kennt, die in seinem Forest sind. Daher müssen alle anderen Benutzer im Active Directory als Kontakte angelegt werden bzw. in Exchange 5.5. als "Benutzerdefinierte Empfänger".

Siehe auch MSXFAQ - Verbinden von Organisationen und Ex552AD und ADC Interorg und Metadirectory

One Way - One Time

Wenn es nur mal darum geht, Adressen einer fremden Quelle zu importieren Ein einmaliger "Export" eines Verzeichnisses und der Import in ein anderes ist ja noch recht einfach. Über Programme wie CSVDE oder LDIFDE können entsprechend vorformatierte Dateien importiert werden.

Die Formatkonvertierung der Quelldaten muss aber auf jeden Fall erfolgen. Hier bietet sich VBScript oder jede andere Programmiersprache an. Aber diese Methode hat auch Nachteile, wenn es regelmäßig passieren soll.

  • Löschen von Objekten
    In der Quelle gelöschte Elemente werden im Zielsystem so nicht entfernt es sei denn man löscht erst alles im Ziel vor dem Reimport
  • Datenmenge
    Auch kleine Änderungen an den Quelldaten sind immer ein voller Importzyklus und damit eine komplette Replikation im Active Directory. Dies ist nicht zu unterschätzen.
  • Offline Adressbuch
    Viele Änderungen im AD bedeuten auch für Exchange viele Änderungen beim Offline Adressbuch und damit auch für die Outlook Offline Clients viel zu replizieren
  • Richtung:
    Es geht eigentlich nur eine Richtung, da über den Weg keine vernünftige bidirektionale Replikation möglich ist. Der Master ist dominant und das Ziel ist eigentlich eine "Read-Only"-Kopie.

Daher ist diese "manuelle" Methode nur in kleinen Umfeldern möglich, wo eine Einseitigkeit reicht und die Belastung und "Dynamik" im Zielsystem nicht störend ist. So etwas kann mal per CSVDE und LDIFDE und etwas Skript nur durch Skripte mit ADSI zügig aufbauen.

One Way - Selektiv

Mit etwas mehr Aufwand an Code kann man natürlich diese Probleme schon mindern. z.B. kann man eventuell aus der Quelle direkt die Daten per LDAP auslesen und damit filtern auf "Änderungen seit dem Datum oder Versionsstand (USN) der letzten Replikation".  (Der ADC macht dies genau so). Dann müssen nur diese Änderungen zum Ziel übertragen werden. Aber immer noch ist das Ziel "Read-Only", wenn Änderungen am Ziel werden nicht zur Quelle repliziert und Änderungen an der Quelle überschreiben das Ziel.

Metadirectory

Letztlich ist das alles nur der Anfang auf dem Weg zu einem Meta Directory. Sobald erweiterte Anforderungen anfallen, dann werden Sie um eine Metadatenbank (Metaverse) nicht umhinkommen. Ein paar Beispiele:

  • Nur Änderungen übertragen
  • Replikation von Löschbefehlen
  • Anpassung von Feldinhalten
  • Selektion von Einträgen
  • bidirektionale Replikation
  • Replikation mit mehr als zwei Verzeichnisdiensten

Mit solche einem Metaverse werden die Daten eines Verzeichnisdiensts in diese Zwischendatenbank übertragen, welche dann wieder als Ausgangspunkt für andere Dienste dienen kann. Aber dann gilt es auch Konflikte zu erkennen, d.h. jemand löscht im Ziel ein importiertes Objekt, und jemand anderes ändert dieses Objekt im Quellverzeichnis. Was passiert ?

Die Perfektion ist dann die bidirektionale Replikation. Womit wir dann bei Diensten wie "Metadirectory" und anderen landen, die dann wirklich die Synchronisation mehrerer Verzeichnisdienste beherrschen und quasi für die gesamte Firmengruppe (auf der Ebene muss das dann auch aufgehängt werden) die Benutzer synchron halten.

Nebeneffekte der Verzeichnisreplikation

Wenn Sie von einer anderen Firma oder einem fremden Mailsystem (z.B. Notes oder GroupWise) nicht nur die Mailadressen sondern auch Systeminformationen (Frei/Belegt-Zeiten etc.) replizieren können (per Connector oder InterOrg Replikation Tool), dann können die Outlook Benutzer anhand der SMTP-Adresse auch diese Informationen bei Terminvereinbarungen nutzen.

Aufwand und Kosten

Ich habe versucht, einfach in wenigen Worten die Komplexität einer Verzeichnissynchronisation zwischen Exchange 2000 und anderen Datenquellen zu erläutern aber Sie können schon sehen, dass es nicht so einfach ist und es vor allem keine allgemeingültige Aussagen gibt.

Insofern kann ich ihnen auch keine Preise und Aufwände für die Realisierung nennen, solange nicht klar ist, welche Anforderungen gestellt werden und ob es fertige Software hierfür gibt oder eigene Skripte mit VBScript und ADSI ihre Wünsche erfüllen können.

Die Feinheiten des DirSync

Was so einfach klingt ist aber bei einer genaueren Betrachtung gar nicht so trivial.

  • Importierte Kontakte ignorieren
    Das Script sucht in der Quelle alle Empfänger mit einer Mailadresse um Sie im Ziel zu importieren. Es kann ja nun sein, dass Sie in beide Richtungen replizieren. Dann muss verhindert werden, dass die eigenen Postfächer, die zu Kontakten auf der anderen Seite geworden sind, wieder zurück importiert werden.
  • Nur Delta-Import
    Es kann nicht sein, dass bei jedem Durchlauf alle Kontakte immer wieder komplett importiert werden. Das würde sehr viele Änderungen im Ziel bedeuten, die zudem zu hohen Replikationsbelastungen führen werden.
  • Delete Detection
    Wenn in der Quelle ein Objekt gelöscht wird, dann muss natürlich auch im Ziel der Kontakt entfernt werden. Dazu muss das Skript erkennen, dass in der Quelle das Objekt gelöscht wurde. Das kann durch die Überwachung von "Deleted Objects" im Quell-AD erfolgen. Aber dazu der Sync oft genug laufen, ehe das "Tombstone"-Intervall abgelaufen ist. Da das Script aber für überschaubare Umgebungen ist, liest es alle Objekte der Quelle aus und vergleicht die Liste beim Importieren mit den Ziel.
  • Replikationskonflikte erkennen
    Was sollte einen Administrator in der Zielorganisation Objekte zu verändern? Da das Script keine "Meta-Datenbank" hat, kann es nicht erkennen, ob eine Änderung nun in der Quelle oder im Ziel oder sogar an beiden Stellen erfolgt ist. Das Skript implementiert eine reine "Master-Slave" Funktion, d.h. die Quelle gewinnt immer über das Ziel.
  • Doppelte Empfänger verhindern
    Wenn Firmen einen Abgleich von Adressen herstellen wollen, dann ist es nicht unwahrscheinlich, dass im Ziel schon ein Teil der Adressen besteht. Das kann beim Import natürlich nicht unberücksichtigt bleiben, da sonst doppelte Empfänger in der Adressliste erscheinen. Das Skript überspringt diese Einträge mit einer Warnung.
  • Sharing SMTP-Adressraum
    Ein Sonderfall der Replikation ist die gemeinsame Nutzung des gleichen SMTP-Adressraums. Es kann durchaus sein, dass in einer Firmengruppe mehrere Exchange Organisationen nebeneinander bestehen. In diesem Fall das die TargetAddress des angelegten Kontakts nicht die primäre SMTP-Adresse sein, sondern muss eine eigenständige Adresse (z.B.: org2.firna.de) für das Routing der Mails zwischen den Exchange Organisationen sein.
  • Fremde Mailsysteme
    Theoretisch kann das Script beliebige LDAP-Verzeichnisse miteinander verbinden. Allerdings kann das Script dann nur als Gerüst dienen, da sicherlich sowohl der Export, die Übersetzung als auch der Import angepasst werden müssen.
  • Feldanpassungen
    Verschiedene Organisationen haben unterschiedliche Vorstellungen, wie Namen gebildet werden und welche Felder welchen Inhalt haben. Das beginnt beim "DisplayName", der manchmal "Nachname, Vorname" oder "Vorname Nachname" oder auch "Nachname, Vorname (Firma)" lauten kann. Entsprechend sind Übersetzungen durchzuführen. Das ist natürlich individuell anzupassen

MultiOrgs mit Exchange 5.5

Auch für Exchange 5.5 gab es früher ein Programm, um zwei Exchange 5.5 Organisationen zu verbinden. Das Programm nannte sich "Orgsync.exe" und war im Backoffice Ressource Kit.

  • 250578 InterOrg Synchronization tool may not import some users in the global address list

The InterOrg Synchronization tool is available in the Microsoft BackOffice Resource Kit, Second Edition, and is supported on a "Commercially Reasonable" basis by Microsoft Product Support Services. Please do not confuse the InterOrg Synchronization tool with the InterOrg Replication utility für public folders, which is available on the Microsoft Exchange Server 5.5 Service Pack 2 CD-ROM.

Allerdings ist es mir selbst nie untergekommen und ich denke das Thema hast sich auch langsam erledigt.

Weitere Links

Für den leistungsfähigeren Abgleich von Verzeichnissen zwischen Organisationen gibt es natürlich auch flexiblere kommerzielle Produkte als den ADC:

Adamsync is a command-line utility that performs a one-way synchronization of data from Active Directory into ADAM. Adamsync uses an XML-based con-figuration file that drives the parameters of the ongoing synchronization

Die Liste ist sicher nicht vollständig. Hinweise werden gerne angenommen.