MiniSync

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.

Diese Skript ist eine sehr einfache Version eines Inhaltstransfers einer LDAP-Quelle zu einem anderen LDAP-Ziel. Bislang setze ich das Skript bei Kunden ein, wobei es aber mehr oder weniger größeren Anpassungen Bedarf. Daher finden Sie es nicht als Download.

Unterstützung durch Net at Work:
Wenn Sie Daten aus einem LDAP-Verzeichnisse in ein anderes Verzeichnis regelmäßig übertragen wollen, dann können wir sie gerne bei der Lösung unterstützen. Ob dabei dann MiniSync, MIIS oder ein anderes Produkt zum Einsatz kommt, ist erst einmal offen. MiniSync kann aber in kurzer Zeit sehr günstig installiert werden.

MiniSync schreibt direkt per LDAP, was von Microsoft mit Exchange 2007/2010 nicht mehr empfohlen wird. Es funktioniert aber, wenn Sie z.B.: nach jedem Lauf ein Update-Recipient auf die Objekte ausführen.

MiniSync ist meine eigene Lösung, um die Empfänger verschiedener Exchange Organisationen abzugleichen. Das Skript liest die Mailadressen und Empfänger aus der Quelle und importiert diese als Kontakte in das Ziel. Der Prozess erfolgt nur in einer Richtung. Bidirektionale Replikation ist möglich, wenn Sie das Skript eben zweimal einsetzen.

Wichtig ist dabei die Zuordnung der Felder. In der Quelle hat ein Objekt nicht nur einen DisplayName, der im Adressbuch angezeigt wird und einen Mailadresse, sondern auch auch Proxy-Adressen. Zudem haben Kontakte ein Feld "TargetAddress". Je nach Betriebsart müssen die Felder entsprechend umgesetzt werden.

Drei Felder sind dabei entscheidend:

• Mail
  Dieses Feld enthält die primäre Mailadresse eines Empfängers. Sie ist auch mit der Default Adresse in den ProxyAddresses identisch, mit der er ausgehende Mails versendet werden. Diese Adresse ist bei einem Kontakte auf der Zielseite einzutragen. Allerdings abhängig von der Betriebsart.
  Das Feld enthält immer eine SMTP-Adresse ohne das SMTP-Prefix.
• TargetAddress
  Dieses Feld enthält bei Kontakten die Zieladressen, kann aber auch bei Postfächern genutzt werden um die Mails an externe Systeme weiter zu reichen. Dies ist aber ein besonderer Fall, der bei Migrationen zwischen Organisationen manchmal eingesetzt wird. (z.B.: mit Quest Migration Manager) Diese  Adresse besteht aus dem Typ als Prefix, einem Doppelpunkt und der eigentlichen Zieladresse.
• ProxyAddresses
  Dieses Feld enthält alle Mailadressen, unter dem der Empfänger erreichbar ist.

Das Zielobjekt einer Migration ist immer ein Exchange aktivierter Kontakt, da nur der Eintrag im Adressbuch mit einer passenden Mailadresse zählt. Nur welche Felder enthalten welche Informationen bei einem für Exchange aktivierten Objekt ?

Diese Informationen sind nun in das Ziel zu übertragen..

Dieses Skript beschränkt sich auf Exchange 2000/2003 im Active Directory. Wenn ein Verzeichnisabgleich mit anderen Verzeichnisdiensten wie z.B.: Notes, OpenLDAP o.ä. erforderlich ist, dann sprechen Sie mich gerne an. Das Prinzip ist ähnlich, nur das andere Felder genutzt werden müssen. Auch im Active Directory können Sie einem Objekt eine Mailadresse geben, ohne dass es gleich Exchange aktiviert ist. Diese Objekte werden ebenfalls ignoriert.

Betriebsarten

Sie haben nun schon gelesen, dass beim DirSync zwischen zwei Betriebsarten zu unterscheiden ist.

• Einfacher Sync
  Zwei unabhängige Organisationen mit eigenen SMTP-Domänen möchten einfach nur ihre Adressen nutzen. Dazu müssen die gewünschten Kontakte der im Ziel einfach nur die primäre SMTP-Adresse der Quelle erhalten. Der Rest erledigt das SMTP-Routing über die Connectoren
• Shared Sync
  Interessanter ist der Einsatz, wenn mehrere Exchange Organisationen den gleichen Adressraum nutzen, d.h. eine Adresse User1@example.com und User2@example.com nicht einer Organisation eindeutig zugeordnet werden kann. Ein DirSync kann dann hier die Benutzer auf der anderen Seite anlegen und entsprechende Einträge für eine eindeutige Weiterleitung vornehmen, z.B. User@example.com wird dann auf User1@org1.example.com weitergeleitet. Entsprechend kreuzweise verbundene SMTP-Connectoren können dann das Routing übernehmen. (Siehe auch Verbinden von Organisationen)

Entsprechend müssen die Felder umgesetzt werden. Dabei ist zu beachten, dass der RUS diese neuen Kontakte ebenfalls bearbeiten wird.

Um Schleifen bei einer bidirektionalen Replikation zu verhindern darf der angelegte Kontakt natürlich nicht mehr in die Quelle zurück repliziert werden. Das ist aber einfach zu verhindern, in dem vor dem Anlegen die Existenz einer entsprechenden Mailadressen geprüft wird.

Einschränken der Adressen

Nun ist es ja ein einfaches, alle Empfänger einer Organisation in einer anderen Organisation als Kontakt anzulegen. Aber vielleicht ist es gar nicht gewollt, dass wirklich alle Empfänger der anderen Seite bekannt gegeben werden sollen. Daher stellt sich die Frage nach FilterMöglichkeiten: Derer gibt es drei, die mit dem Script problemlos umzusetzen sind

• LDAP-Filter
  Analog zu den Adressbuchansichten in Exchange können Sie natürlich mit LDAP-Filtern arbeiten. Sie können z.B. eines der 16 Benutzerdefinierten Attribute als Kriterium hernehmen oder fast jedes andere Feld in den Stammdaten, um einen gewünschten Filtereffekt zu erzielen. Mit ADModify.NET können Sie solche Felder auch sehr schnell massenhaft ändern
• OU-Einstiegspunkt
  Sie können weiterhin z.B. einfach nur eine bestimmte OU exportieren lassen. Hierzu müssten Sie das Script aber kräftig ändern, da aktuell der GC gefragt wird und hier keine OU einfach als Filter angegeben werden kann. Aber eine kleine IF-Abfrage auf einen String im DN der gefundenen Gesamtliste kann hier schnell eine Lösung sein.
• Gruppenmitgliedschaft
  Weiterhin könnten Sie eine Gruppe anlegen, deren Mitglieder nur zur anderen Seite übertragen werden. Dies erlaubt sehr individuell ausgewählte Objekte zu übertragen. Allerdings muss natürlich diese Gruppe gepflegt werden
• Berechtigungen
  Das Script läuft mit einem Benutzer. Sie können nun per Berechtigungen auf dem AD bestimmte Objekte einfach "unsichtbar" machen. Allerdings kann ich hiervon nur abraten, da das Risiko einer Falschkonfiguration sehr hoch ist.

Wenn sie mehr Funktionen wünschen, dann sollten Sie vielleicht kommerzielle Tools in Betrachtung ziehen oder selbst entwickeln

Einschränkungen

Das Skript ist absichtlich einfach gehalten. Das bringt aber einige Einschränkungen mit sich:

• Source muss MAIL haben
  Jedes Quellobjekt muss eine eindeutige und einmalige Mailadresse besitzen, da dieses Feld als primärer Schlüssel genutzt wird und daraus der DN gebildet wird.
• USN-Update aber kein "DeletedItems"
  Das Skript optimiert den Durchlauf, indem es in der Beschreibung der ZielOU die höchste zuletzt verarbeitet USN merkt. Dennoch muss das Skript jedes mal alle Quellobjekte abfragen, damit gelöschte Objekte erkannt werden können
• Rename = Delete und Neu anlege
  Wird in der Quelle bei einem Objekt die primäre Mailadresse geändert, dann wird ein neues Objekt im Ziel angelegt und das alte Objekt gelöscht. Daten des alten Objekts (z.B. Gruppenmitgliedschaften) gehen hierbei leider verloren.
• Online
  Das Skript greift auf beide LDAP-Dienste "online" zu, d.h. der ausführende Computer muss auf beide Systeme zugreifen können. Einen Abgleich ist ohne Netzwerkverbindung nicht möglich.

So funktioniert es

Die Funktion ist in wenigen Schritten erklärt. Das Flussdiagramm ergänzt die Beschreibungen.

• Einlesen der Objekte in der Quelle
  Zuerst werden alle Objekte mittels ADODB-Anfrage ermittelt.
• Übertragen der Daten ins Ziel
  Für jedes Objekt wird das korrespondierende Zielobjekt gesucht und gebunden. Gelingt dies nicht, wird ein Objekt angelegt.
  Sodann werden die Felder entsprechend der Programmierung aktualisiert und das Objekt als "bearbeitet" in einem Dictionary gespeichert.
• Überzählige Objekte entfernen
  Zum Abschluss werden die Objekte in der Ziel-OU abgelaufen und gegen das Dictionary geprüft. Ist ein Objekt nicht in diesem Speicher, dann gilt es als verwaist und wird gelöscht, da es für sie anscheinend kein entsprechendes Objekt mehr in der Quelle gibt.

Hier das ganze noch mal als vereinfachtes Flussdiagramm:

Das Flussdiagramm bezeichnet einen alten Code und hat das Problem, dass z.B. zu löschende Objekte noch Werte haben können, die durch andere neue Objekte benutzt werden sollten. Daher ist es ratsam erst die alten Objekte zu entfernen, auch wenn das aufwändiger ist. Siehe dazu CSV2EX

Um den Aufwand für das Binden des Zielobjekts zu reduzieren, speichert das Skript die höchste verarbeitete USN des vorherigen Laufs im Ziel und vergleicht alle Quellobjekte gegen diese USN. Nur Objekte mit einer höheren USN werden dann weiter verarbeitet.

Die Performance von MiniSync ist natürlich von der Leistung der LDAP-Server, der Netzwerkbandbreite aber vor allem vom dem ausführenden PC abhängig. Aber Raten von 5-15 Objekte/Sekunde sind durchaus realistisch. Es wird aber wird sicher an seine Grenzen stoßen, wenn Sie ähnlich dem ADC alle 5 Minuten die Änderungen übertragen wollen.

Konfiguration

Mehrere Quellen und Ziele bedeutet, dass Sie das Script entsprechend kopieren, anpassen und aufrufen. Folgende Werte sind im Skript zu pflegen:

• Quelle
  Hier sind die Quell-OU Domäne oder der GC mit den LDAP-Filtern, der Servername und den Zugangsdaten zu definieren. Das Script verbindet sich damit mit der Quelle.
• Ziel
  Das Ziel ist eine einzelne OU, in der alle Kontakte angelegt und gepflegt werden. Optional kann hier der Servername eines bevorzugten DCs gepflegt werden. Das Benutzerkonto, welches das Skript ausführt, muss entsprechend berechtigt sein.
• Mapping
  Die Zuordnung der Fehler und etwaige Konvertierungen sind allerdings im Code selbst direkt zu erstellen.
• Mode
  Die Einstellung der Betriebsart ist wichtig, da sie entscheidet, ob die TargetAddess des Kontaktes die primäre SMTP-Adresse des Benutzers wird oder eine bestimmte sekundäre Adresse genutzt wird. Die Nutzung einer sekundären Adresse der Quelle ist hilfreich, wenn ein SMTP-Adressraum zwischen mehreren Organisationen gemeinsam genutzt wird.

Konfiguration der Quelle

Bei der Konfiguration der Quelle müssen Sie davon ausgehen, dass es sich dabei nicht um das lokale Active Directory handelt, sondern meist ein anderer Verzeichnisdienst,  d.h. ein anderer Forest oder ein ganz anderer LDAP-Server. Hier ein paar Beispiele der Konfiguration.

• Active Directory Forest
  Base: dc=domain,dc=tld
  Filter: (mail=*)
  Felder: sn, givenName, Mail
  Anmeldung: DN eines Benutzers "CN=Administrator,CN=Users,DC=domain,dc=tld (beachten Sie CN bei Users)
  Anmeldung: DN eines Benutzers "CN=MiniSync,OU=Serviceaccounts,DC=domain,dc=tld
  Anmeldung: SamAccount eines Benutzers "DOMAIN\UserNAME"
  Anmeldung: UPN eines Benutzers: "Username@upndomain.tld"
• Notes-Suche
  Base: O=NotesOrg
  Filter: (mail=*)
  Felder: sn, givenName, Mail
  Anmeldung: DN des Notes Users "CN=Admin Administrator,O=NotesOrg"
  Feld: CompanyName = Company
  Feld: Mail kann auch mehrere Einträge (Array) enthalten
• Exchange 5.5
  Hier stehen noch weitere Tests an
• OpenLDAP
  Beim Einsatz von OpenLDAP muss man sicherstellen, dass man einen "ADS_FAST_BIND" verwendet, weil sonst ADSI im Hintergrund erst das Schema abfragt, nicht fündig wird und dann keinen "Subtree-Search" verwendet. Zudem kann OpenLDAP natürlich keine 'ADS_SECURE_AUTHENTICATION". Hinzu kommt dass einige Felder wie z.B. "mail" zwar laut Definition vom Typ "String" sind, aber als Array mit einem Eintrag in ADSI ankommen.

Besonderheit "Bidirektional" und MultiPoint

MiniSync hat ursprünglich nur dazu gedient, die Benutzer einer Exchange 5.5 Organisation in ein Active Directory in eine Richtung zu übertragen. Nun kann es aber sein, dass Sie natürlich bidirektional arbeiten wollen. Hierbei ist besondere Vorsicht walten zu lassen, damit die Kontakte der Hin-Replikation nicht auf der Rückreplikation erneut repliziert werden. Natürlich könnte man vor jedem Schreiben prüfen, ob es die Mailadresse schon gibt, Aber das kostet Zeit. Man könnte auch die ZielOU der Hin-Replikation bei der Rückreplikation ausschließen. Ich bevorzuge den Trick, das Zielobjekt zu "kennzeichnen". Dazu eignet sich ein beliebiges LDAP-Feld (z.B. ExtensionAttribute13), in dem einfach die Quelle des Objekts hinterlegt wird.

 So kann per Filter einfach ein Ausschlusskriterium angewendet werden.

Manchmal kann es aber auch passieren, dass mehrere Verzeichnisdienste miteinander replizieren. Das kann z.B. eine "Dreiecksbeziehung" sein oder auch einfach eine Replikation über ein Zwischenverzeichnis (z.B. ADAM). Dann muss man die Daten natürlich weiter anpassen.

Sind die verschiedenen Verzeichnisdienste nun zudem unterschiedliche Produkte, dann kann es sehr schnell knifflig werden.

Bislang geschaffene Lösungen

MiniSync habe ich schon bei mehreren Kunden produktiv im Einsatz. Natürlich wird der Code immer an die Bedürfnisse des Kunden entsprechend angepasst oder erweitert.

• Spamabwehr mit ADAM und Ironport
  Ironport kann, wie andere Programme auch, die Gültigkeit von SMTP-Adressen per LDAP abfragen, ehe die Mail angenommen wird. Nur ist es natürlich ein Sicherheitsrisiko, wenn ein System weit vorne per LDAP direkt eine Verbindung zu einem Domaincontroller und GC aufbauen kann. Zudem bedeutet die Existenz einer Mailadresse im Active Directory ja nicht gleich, dass diese auch extern erreichbar sein darf. Daher habe ich bei einem Kunden den ADAM Dienst als LDAP-Server für Ironport installiert. Mit MiniSync werden nun von intern nur die Mailadressen von Personen nach außen repliziert, die in einer bestimmten Gruppe Mitglied sind. So können nebenbei Berechtigungen zum Empfang gesteuert werden.
• LCS-Ressourceforest
  Der Einsatz des Office 2003 Live Communications Server bei einem größeren Kunde sollte erfolgen, ohne das Schema im Anmeldeforest zu erweitern. (Testbetrieb) Diese Konfiguration ist möglich, wen ein eigener Forest für den LCS installiert wird, indem dann ähnlich zum Exchange Hosting "deaktivierte Benutzer" angelegt werden. Diese benötigen aber die SID des realen Kontos in einem besonderen Feld. Auch hier repliziert MiniSync die ausgewählten Benutzer (Mitglieder einer Gruppe) des Anmeldeforests in den Ressourceforest
• Anbindung Hicom PBX an ADAM
  Auch Telefonanlagen können mittlerweile per LDAP ein Active Directory fragen. So erlaubt eine CTI-Integration bei internen Anrufen direkt die Anzeige des Namens auf dem Telefon. Allerdings erfragt z.B. eine Hicom dazu die Telefonnummer, die leider im Active Directory nicht indexiert ist. Zudem ist das Forma der Telefonnummer im Active Directory häufig nicht "Telefonanlagenkompatibel". Auch hier hilft die Installation eines ADAM, welchen mit den Daten aus dem Active Directory füttert. Nebenbei entlasten dies die Domain Controller von den Suchen der Telefonanlage.
• Mailadressen von anderen Verzeichnisdiensten
  Bei mehreren Kunden stand die Aufgabe an, Adressen aus anderen Quelle in den Forest als Kontakte anzulegen. Das sind sowohl Adressen von anderen Notes-Servern von Partnern, OpenLDAP-Servern von einem zentralen Verzeichnisserver oder auch einer einer anderen Exchange Organisation. All das ist mit MiniSync bereits umgesetzt

Sie sehen also, dass MiniSync schon mehrfach erfolgreich im Einsatz ist und Informationen aus einem Verzeichnis relativ problemlos an ein anderes Verzeichnis übertragen kann.

Skript

Bitte haben Sie Verständnis dafür, dass dieses Skript nur im Rahmen einer Dienstleistung vor Ort verfügbar ist. Sicher ist MiniSync eine kleine Lösung die auch an die Zielsysteme angepasst werden muss. Auch ist das Thema "Verzeichnisabgleich" bei weitem nicht trivial, so dass das Schadens- und Störpotential hoch ist.

MiniSync ist nicht kostenfrei downloadbar, weil die Einrichtung eines DirSync immer Anpassungen an Quelle, Ziel und Skript erfordern. Rufen Sie einfach an.
Informationen, warum diese Skripte nicht öffentlich sind, finden Sie auf nicht public.

Weiterentwicklung

Ich hatte schon länger vor, MiniSync als Version 2 modularer zu gestalten. Das Projekt ist aber mangelt Zeit einfach nicht weiter geführt worden und durch die PowerShell sehe ich da auch keine Zukunft mehr drin. Im Archiv finden Sie noch die ersten Planungen zu MiniSync2 dokumentiert. Ich gehe davon aus, dass die nächste Version mit PowerShell arbeiten wird.

• Parametrisierung
  Wenn ich aktuell mehrere "Verbindungsvereinbarungen" nutzen will, dann muss ich dazu das Skript mehrfach kopieren und konfigurieren. Besser ist hier sicher ein Skript mit einer Prozedur oder Klasse, welche dann aus dem Hauptprogramm einfach mehrfach aufgerufen wird. So sollte die SourceOU und TargetOU spezifizierbar sein.
• Bugs
  Es passiert immer wieder, dass ein LDAP-Dienst eigentlich einen String zurückgeben sollte aber es ist dann doch ein Array mit genau einem Element. Solche "Besonderheiten" sollten noch generell und nicht nur bei Bedarf abgefangen werden.
• Dienst
  Natürlich ist ein Script, welches per Taskplaner gestartet wird, nicht wirklich professionell. Schöner wäre natürlich die Lösung als Dienst mit allem drum und dran.
• GUI
  Auch die Konfiguration über Konstanten im Script ist nicht wirklich perfekt. Eine Konfigurationsoberfläche und Speicherung der Einstellungen z.B. in einer XML-Datei oder im Active Directory wäre auch nett.
• .NET oder PowerShell
  VBScript ist sehr leistungsfähig aber hat auch einige Einschränkungen. Gerade der Einsatz von "Variant" als Datentyp steht nicht grade für sicheren Code. Aber besonders die Pflege solcher Codes ist keine Freude, wenn man eine EntwicklungsUmgebung wie Visual Studio oder Sharp Develop (Was ist .NET) kennt.
• Offline-Sync
  Das aktuelle Script erfordert einen LDAP-Zugriff auf beide Verzeichnisdienste. Es eignet sich daher nicht für den Abgleich ohne direkte Verbindung. Eine Weiterentwicklung könnte daher darin liegen, den Export in eine CSV-Datei zu legen und per Mail, FTP, WebDAV oder was auch immer zum Empfänger zu senden.
• AD-Feld: "importedFrom"
  Im Active Directory gibt es ein Feld "importedFrom"", welches diverse Abgleichprozesse (z.B. Notes transporter Suite) gerne nutzen, um die Quelle eines Objekts zu hinterlegen. Oft ist hier eine GUID enthalten, auch wenn es genau genommen nur ein "String"-Feld ist. Hier sollte sich also auch MiniSync hinterlassen
• MOM MP
  Alles was ohne Überwachung und ohne GUI im Hintergrund läuft, kann auch mal stehen bleiben. MiniSync schreibt natürlich optional Eventlog und diese können auch per MOM2005 oder anderen Programmen überwacht werden. Noch gibt es kein Management Pack

Probleme und deren Lösung

Bei der Entwicklung des Skripts bin ich natürlich über die ein oder anderen Probleme gestolpert.

• ADOSearch
  Alle Felder, die in das Ziel übernommen werden sollen, müssen natürlich in der Quelle auch lesbar sein. Da MiniSync per ADI den GC befragt, können natürlich nur Felder exportiert werden, die auch in den GC repliziert sind.
• Bind auf GC:/
  Ich bin dann auf die Idee gekommen, einfach das Quellobjekt über das Feld ADSPath zu binden. Aber auch hier steht bei einer Suche über den GC natürlich der GC-Pfad drin. Eine Bindung an den GC liefert aber auch nicht mehr Felder. Zudem bricht die Performance sehr stark ein. Wenn also Felder zu übertragen sind, die nicht im GC enthalten sind, dann muss das Skript derart angepasst werden, dass es sich mit dem passenden DC verbindet, um die Felder zu holen.
• USN Abfrage bei ADO
  Das Skript kennt die Funktion, die zuletzt bearbeitete USN auszuwerten. Dies spart viel CPU-Last beim Verarbeiten von längst replizierten Objekten. Allerdings erfolgt am Ende die Löschung entfallener Objekte. Daher kann die ADO.Abfrage sich nicht nur auf geänderte Objekte beschränken, sondern muss erst mal alle Objekte einlesen, um die überzähligen im Ziel erkennen zu können. Eine Behandlung von "Deleted-Objekts" könnte auch dies lösen, aber würde MiniSync komplizierter machen.

Weitere Links

• Verbinden von Organisationen
• Verzeichnisabgleich
• Ex552AD
• Weiterleitungen
• Routingdomäne
• MiniSync2
• CSVSync
• MIIS
• IIFP
• TargetAddress
• RTFMAIL und WINMAIL.DAT
• ADAM/AD LDS
• A GALSync PowerShell script
  http://www.wapshere.com/missmiis/a-galsync-PowerShell-script
• Synchronizing Multiple Exchange 2003 Forests
  http://technet.microsoft.com/en-us/library/bb123590%28EXCHG.65%29.aspx
  Sehr umfangreiches und interessantes Dokument
• GALSYNC v2
  http://www.wapshere.com/missmiis/galsync-v2
• Identity Integration Feature Pack 1a für Microsoft Windows Server Active Directory
  http://www.Microsoft.com/downloads/details.aspx?FamilyID=d9143610-c04d-41c4-b7ea-6f56819769d5&DisplayLang=en
  Benötigt Windows 2003 Enterprise und mindestens eine MSDE (zum Test). für den produktiven Einsatz ist ein lizenzierter SQL-Server erforderlich.
• ADAMSync für ADAM und AD
  http://www.faq-o-matic.net/2008/01/26/adam-und-eva/
• HOWTO: Dump out Contacts using CDOEX and ADO
  http://blogs.msdn.com/akashb/archive/2008/11/14/howto-dump-out-contacts-using-cdoex-and-ado.aspx
• Penrose: Virtual LDAP-Server als Proxy gegen verschiedene Backends
  http://penrose.safehaus.org/penrose/news.html
• Integration eines IBM Lotus Domino Directories in ein Microsoft Active Directory mittels ADSync
  http://www.ibm.com/developerworks/lotus/library/domino-adsync/index.html