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 ?

Objekt Mailbox Mailuser Mailkontakt öffentlicher Ordner Verteiler / Abfrageverteiler

Mail

Enthält die primäre Adresse

Externe Adresse

Externe Adresse

Enthält die primäre Adresse

Enthält die primäre Adresse

TargetAddress

leer, ansonsten ist es eine Umleitung

SMTP:Externe Adresse

SMTP:Externe Adresse

nicht vorhanden

nicht vorhanden

proxyAddresses

Enthält Mail als primäre Adresse

weitere sekundäre Adressen der Organisation

Enthält primäre externe Adresse

Weitere sekundäre Adressen, z.B.: X.400 der Organisation

Enthält primäre externe Adresse

Weitere sekundäre Adressen, z.B.: X.400 der Organisation

Enthält Mail als primäre Adresse

weitere sekundäre Adressen der Organisation

Enthält Mail als primäre Adresse

weitere sekundäre Adressen der Organisation

MailNickName

vorhanden

vorhanden

vorhanden

vorhanden

vorhanden

mxExchHomeServer

DN des Homeserver

na

na

nicht vorhanden

nicht vorhanden

HomeMDB

gefüllt

na

na

 

 

HomeMTA

gefüllt

na

na

 

 

2007/2010
msExchRecipientDisplayType

1073741824

6

-

-

-

2007/2010
msExchRecipientTypeDetails

1

-

64

4096

1024

InternetExcoding

na

1310720

1310720

 

 

MDBUseDefault

True/False

na

na

 

 

MSExchangeMailboxGUID

Gefüllt

na

na

 

 

msExchUserAccountControl

0

na

na

 

 

msExchMailboxSecurityDescriptor

gefüllt

na

na

 

 

msExchALObjectVersion

gefüllt

gefüllt

gefüllt

 

 

UPN und andere Anmeldefelder

gefüllt

gefüllt

na

 

 

MAPIRecipient

True

False

False

 

 

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.

Quelle Einfacher Sync

Die Exchange Organisationen haben eigenständige SMTP-Adressräume

Shared Sync

Displayname

Displayname, eventuell um ein Firmensuffix ergänzt

Displayname, eventuell um ein Firmensuffix ergänzt

Mail

TargetAddress = "SMTP:" & Quelle.Mail
Mail = Quelle.Mail

Die Mailadresse wird aus der exklusiven SMTP-Domäne der ProxyAddresses gewonnen.

ProxyAddresses

addieren zu ProxyAddresses

= ProxyAddresses

TargetAddress (bei Kontakten und mailaktiven Benutzern)

Wird nicht verwendet, da das Feld "Mail" eine gültige Adresse enthalten sollte.

Wird nicht verwendet, da das Feld "Mail" eine gültige Adresse enthalten sollte.

Sonstige Felder

Nach Bedarf

Nach Bedarf

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:

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.

Bidirektional Replikation mit Kennzeichnung

 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.

Bidirektional mit mehreren Verzeichnisdiensten

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