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 Verbinden von Organisationen und Ex552AD und ADC Interorg und Metadirectory.

Umfang

Fangen wir einfach an und behauten einmal, dass die Empfänger einer Exchange Organisation auch in einem anderen System bereitgestellt werden sollen, z.B. damit sie dort im Adressbuch erscheinen, für Frei/Belegt-Zeiten verfügbar sind oder auch nur für ein optimiertes Mailrouting genutzt werden sollen. Das ist z.B. beim Sharing eines gemeinsamen SMTP-Adressraums erforderlich. Nun gibt es in der Quelle ja nicht nur Postfächer von Benutzern sondern auch Shared Mailboxen, Raum-Mailboxen aber auch Verteilerlisten und möglicherweise noch Kontakte. Je nach Quelle kann ich im Ziel unterschiedliche Objekte anlegen lassen. Hier meine Empfehlung.

Quelle Ziel

Mailbox, Raum, Shared, Ressource
  • MailUser
    Sinnvoll, wenn man später z.B. per ADMT die Benutzer migrieren will. Ansonsten eher nicht, da er sich ggfls. Anmelden könnte oder in Lizenzzählungen zu berücksichtigen ist.
  • MailContact
    Sicherer, weil man dann weniger AD-Benutzer sondern nur Kontakte hat
  • MailForestContact
    Spezielles Objekt für DirSync, welches die Exchange PowerShell schützt
  • Remote Mailbox
    Nicht ratsam, da dieser Typ nur für Exchange Online mit Hybrid-Bereitstellung vorgesehen sid

Verteiler
  • MailContact
    Ist am einfachsten, da Mails dann zur Quelle gehen und dort aufgefächert werden. Im Ziel kann der Anwender aber nicht die Mitglieder sehen
  • Verteiler
    Aufwändiger, da dann auch alle Mitglieder auf beiden Seiten synchron gehalten werden müssen, Siehe z.B. GroupSync

Kontakt
  • Kein Objekt
    Prüfen Sie, woher die Quelle die Kontakte bekommt. Vielleicht ist es besser, die Information direkt von der originalen Quelle zu beziehen statt Kopie. Zudem sollten Sie nicht irrtümlich einen Kontakt importieren, der zu ihrer Firma gehört und als Kontakt auf der Gegenseite angelegt wurde.
  • Mail Contact
    Ansonsten können Sie natürlich einen regulären Kontakt anlegen
  • MailUser
    Wenn Sie irgendwann den Benutzer der primären Quelle in ihren Forest replizieren sollen, dann ist vielleicht ein anfangs deaktiviertes Benutzerobjekt besser

Public Folder
  • MailContact
    Wenn Sie mailaktivierte öffentliche Ordner auf der anderen Seite sehen wollen, dann sind Kontakte die passende Option

In der Liste sehen sie fast immer "MailContact" als Ziel. Dieses Objekt ist einfach zu verwalten und erfüllt die meisten Anforderungen. Allerdings kann der Anwender im Ziel nicht mehr erkennen welcher Type der Empfänger in der Quelle ist.

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.

Kommerzielle Produkte

So einen Abgleich könnten Sie nun per PowerShell oder VBScript (Siehe auch MiniSync oder CSVSync) selbst umsetzen. Aber unterschätzen Sie die Aufgabe nicht, da es durchaus Sonderfälle zu beachten gibt, z.B. Umbenennungen durch Heirat, Verlagerung von Objekten in OUs, Löschungen etc. Daher kann es interessanter sein, ein Produkt zu kaufen.

Diese Liste nicht nicht aktuell und wird von mir auch nicht weiter gepflegt

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.