Active Directory Connector Verbindungsvereinbarungen
Der Active Directory Connector repliziert Einträge zwischen verschiedenen Verzeichnissen über so genannte Verbindungsvereinbarungen. Verbindungsvereinbarungen sind Konfigurationseinträge, die dem ADC vorgeben, welche OUs und Objekte er von einem Verzeichnisserver zu einem anderen Verzeichnisserver replizieren soll. Es gibt derer drei:
- UserCA
Die Verbindungsvereinbarung für Benutzer und Gruppen dient dazu die Informationen über Benutzer und Verteiler, deren Mailadressen, Mitgliedschaften und zusätzliche Informationen zu replizieren.
Es kann durchaus erforderlich sein, mehrere Verbindungsvereinbarungen für verschiedene OU's. Domänen und Standorte einzurichten.
Während der Migration eines Benutzers sollte das entsprechende CA allerdings angehalten werden.
299473 The homeMDB attribute is reset after you move mailboxes from Exchange Server 5.5 to Exchange 2000 or to Exchange 2003 - PublicFolderCA
Bei Exchange 5.5 sind alle öffentlichen Ordner mit einer Mailadresse versehen. Exchange 5.5 legt dazu (verborgene) Objekte im Standard Empfängerkontainer (Recipients) an. Auch diese Informationen müssen für Exchange 2000/2003 zugänglich werden. Dazu dienst die Verbindungsvereinbarungen für öffentliche Ordner. Sie repliziert diese Objekte in die versteckte OU "Microsoft Exchange System Objects" im Active Directory. In einer native Exchange 2000/2003 Umgebung finden sich dort dann nur die Ordner als Objekte wieder, die eine Mailadresse haben.
Auch diese Verbindungsvereinbarung müssen Sie als Administrator einrichten. - ConfigCA
Zuletzt muss auch ein Abgleich der Konfigurationsinformationen erfolgen. Beide Welten müssen wissen, welche Connectoren und Server es gibt, damit Nachrichten erfolgreich zugestellt werden können. Diese Verbindungsvereinbarung richtet das Exchange 2000/2003 Setup zusammen mit dem SRS-Server automatisch für Sie ein. Sie sollten an dieser Verbindungsvereinbarung keine Einstellung verändern. Siehe auch ConfigCA.
Wenn Sie alle drei Verbindungsvereinbarungen zusammen nehmen, dann stellt sich das etwa wie folge dar:
In einer größeren Umgebung mit mehreren Exchange Standorten, Domänen und OU's reichen natürlich nicht nur drei einfache Verbindungsvereinbarungen aus. Als Richtwert können Sie sagen, dass Sie pro Standort mindestens drei Verbindungsvereinbarungen benötigen. Wenn Sie Benutzer und Verteiler noch trennen und verschiedene OU-Strukturen aufeinander abbilden müssen und zur Redundanz mehrere ADC-Server einsetzen wollen. dann vervielfacht sich die Anzahl der CAs sehr schnell.
Neben den drei verschiedenen CAs müssen Sie aber auch überlegen, welche Quellen und Ziele sie mit welchen CAs verbinden.
Exchange 5.5 zum Active Directory
Betrachten wir folgende Struktur aus zwei Active Directory Domänen und drei Exchange 5.5 Standorten mit den entsprechenden Server. Hier wird anhand einer einzigen CA für Benutzer, Kontakte und Verteiler aufgezeigt, was Sie leisten und kann und was nicht:
Punkt | Bedeutung |
---|---|
|
Die Richtung der Verbindungsvereinbarung wird vom Exchange 5.5 zum Active Directory beschrieben. Das bedeutet nicht, dass das CA unidirektional ist, sondern nur, dass die folgende Beschreibung auf diese Richtung wert legt. |
|
Eine Verbindungsvereinbarung spricht immer nur mit genau definierten Servern. Hier ist das ein Exchange 5.5 Server in der Site "Koeln" und einem DC der Domäne "DOM-DE". Sie wissen, dass natürlich auch der Exchange 5.5 Server über den DirSync Informationen der anderen Sites kennt (GAL etc.) und auch der DC als globaler Katalog eine Teilmenge anderer Domänen kennt. |
|
Das CA kann sowohl in die OU Köln als auch Bonn schreiben. Im CA können Sie aber nur eine OU als "Default Ziel"angeben. Dies bedeutet aber nur, dass der ADC hier neue Objekte anlegt, Er sucht allerdings im gesamten DC nach möglichen Zielobjekten. Dies führt daher auch dazu, dass ein Sync weiterhin stattfindet, wenn Sie einen Benutzer in einer andere OU der gleichen Domäne verschoben haben |
|
Ale Quelle ist im CA der Empfängerkontainer "Recipients" im Standort Köln angegeben. Siehe später auch (8) |
|
Die OU-Berlin kann von diesem CA auch beschrieben werden. !! Das passiert aber eher nicht da das CA keine Daten aus der Exchange 5.5. Site Berlin auslesen kann. Schließlich befragt es keinen Server der Exchange 5.5 Site "Berlin". Sie sehen, dass Sie hierfür eine weitere CA benötigen. |
|
Wie schon in (4) beschrieben, kann dieses CA nicht genutzt werden, um Objekte aus Berlin zu lesen und zu replizieren, selbst wenn die ZielOU in der Zieldomäne des CAs liegt |
|
Selbst wenn ein Postfach in der Site "Berlin" einen Benutzer aus der Domäne "Paris" als primäres Windows NT Konto hätte, würde der ADC dieses Konto nicht matchen, da der DC aus Berlin natürlich nicht "beschreibbar" ist. Allerdings würde der ADC sehr wohl erkennen, dass es diese Konto in einer anderen Domäne gibt und kein deaktiviertes Konto in der Domäne DOM-DE anlegen. In einem solchen Fall ist ein weiteres CA erforderlich. Ich hoffe ihre Umgebung ist nicht so komplex |
|
Wie schon in (4) beschrieben, kann dieses CA nicht genutzt werden, um Objekte aus Paris zu lesen und zu replizieren. |
|
Wenn Sie im CA vergessen, auch den Empfängercontainer "Extern" als Quelle anzugeben, dann werden diese Objekte nicht ausgelesen und repliziert. So ein Fall kann passieren, wenn jemand nach der Einrichtung des ADC z.B. weitere Empfängercontainer anlegt und "vergisst" diese im ADC nachzutragen |
ich hoffe dieses Bild und die Beschreibung hilft etwas bei dem Verständnis, was ein CA leisten kann und was nicht. Denken Sie immer daran:
- Quellsite und Quellcontainer
Ein CA kann nur Objekte aus der Exchange 5.5 Site lesen, in der der befragte Exchange 5.5 Server steht. Zudem müssen Sie sicherstellen, dass Sie alle erforderlichen Quellcontainer im CA auch als Quelle konfiguriert haben. (Oder einfach die Site) - Zieldomain und Zielserver
Der ADC findet ALLE Benutzer im Forrest, aber kann nur die Objekte beschreiben, die auf dem konfigurierten DC und damit der Zieldomäne liegen. Der Zielcontainer dieser CA wird nur für die Anlage von neuen Objekten genutzt. Es ist kein Filter für die Suche im Ziel
Active Directory zu Exchange 5.5
Auch die Gegenrichtung muss repliziert werden, wenn Sie migrieren wollen. Das gleiche CA mit den gleichen Servern kann folgende Daten replizieren.
Punkt | Bedeutung |
---|---|
|
Die Richtung der Verbindungsvereinbarung wird vom Active Directory zu Exchange 5.5 beschrieben. Das bedeutet nicht, dass das CA unidirektional ist, sondern nur, dass die folgende Beschreibung auf diese Richtung wert legt. |
|
Eine Verbindungsvereinbarung spricht immer nur mit genau definierten Servern. Hier ist das ein DC der Domäne "DOM-DE" und der Exchange 5.5 Server in der Site "Koeln". Sie wissen, dass natürlich auch der Exchange 5.5 Server über den DirSync Informationen der anderen Sites kennt (GAL etc.) und auch der DC als globaler Katalog eine Teilmenge anderer Domänen kennt. |
|
Ale Quelle ist im CA in diesem Beispiel nur die OU "Koeln" angegeben. |
|
Das CA kann sowohl in Empfängerkontainer "Recipients" als auch in "Extern" schreiben. Der im CA angegebene Default Container "Recipients" bestimmt nur, wo "neue" Objekte angelegt werden. Das CA sucht aber schon die ganze Organisation nach möglichen Zielen und ändert Objekte in der gleichen Site. Liegt das Ziel in einer anderen Site, dann meldet der ADC dies im Eventlog und überlässt einer anderen CA die Arbeit. Siehe später auch (5 und 7) |
|
Wurde im CA auch die OU-Berlin als Quelle mit angegeben, dann sucht der ADC auch hier nach Objekten. Werden hier neue Objekte angelegt, dann bedeutet dies, dass die Benutzer in der Site "Köln" angelegt werden!. Etwas anderes ist es, wenn der ADC hier Objekte findet aber diese in Exchange 5.5 schon in der Site "Berlin" vorhanden sind. Dann überspringt der ADC dieses Objekt, da er davon ausgeht, dass ein anderes CA die Site Berlin betreut. |
|
Diese CA kann nicht genutzt werden, um Objekte in Berlin zu schreiben, selbst wenn die Quell-OU angegeben ist. Das Objekt wird übersprungen. Siehe auch (4). |
|
Selbst wenn ein Postfach in der Site "Berlin" einen Benutzer aus der Domäne "Paris" als primäres Windows NT Konto hätte, würde der ADC dieses Konto nicht matchen, da der DC aus Berlin natürlich nicht "beschreibbar" ist. Allerdings würde der ADC sehr wohl erkennen, dass es dieses Postfach in einer anderen Site vorhanden ist und kein weiteres Postfach in Köln anlegen. In einem solchen Fall ist ein weiteres CA erforderlich. |
|
Wie schon in (3) beschrieben, kann dieses CA nicht genutzt werden, um Objekte in die Site Paris zu schreiben. |
|
In dem Beispiel wurde die OU Bonn vergessen. Die Folge davon ist, dass Änderungen in dieser OU vom CA nicht erkannt werden, selbst wenn die Benutzer auf dem Server in der Site "Koeln" ein Postfach haben sollten. Stellen Sie daher sicher, dass alle Objekte durch mindestens ein CA gelesen werden. |
Die erforderlichen CAs
Mit diesem Wissen sollten Sie nun selbst schon feststellen können, welche CAs für die Replikation dieser Umgebung erforderlich sind. Hier das ganze als vereinfachtes Bild.
CA | Bedeutung |
---|---|
|
Diese CA für die Site "Koeln" repliziert Postfächer, Verteiler,
Kontakte mit der Domäne DOM-DE. Dabei ist die OU-Köln der Zielkontainer für die EX->AD Replikation und "Recipients" der default Container für die Rückreplikation. Zusätzlich benötigen Sie ein CA für die öffentlichen Ordner. |
|
Die dritte und vierte CA sorgen für den Abgleich der Site "Berlin" mit der OU-Berlin. |
|
Die fünfte und sechste CA replizieren die Site "Paris" mit der Domäne DOM-FR |
Weitere |
Nicht eingezeichnet sind die CONFIG_CAs, die bei der Installation von Exchange 2000/2003 Servern eingerichtet werden. Wenn Sie jede Exchange 5.5 Site migrieren, dann sind am Ende mindestens dreiExchange SRS-Dienste mit dem dazugehörigen CAs konfiguriert. |
Dies bedeutet, dass Sie vor der Installation des ersten Exchange 2000/2003 Servers mindestens 6 (sechs) CAs einrichten müssen.
Das folgende Beispiel ist nur korrekt, wenn es keine "Kreuzerbindungen" gibt, z.B. dass ein Benutzer in der Domäne DOM-FR ein Postfach in der Site "Koeln" hat o.ä. Dann werden weitere CAs erforderlich.
Unterstützung durch
Net at
Work:
Wenn Sie bei so viel Funktionen, Sonderfällen, Fallen und Hinweisen den
Durchblick verloren haben, dann könnte eine aktive Unterstützung vor Ort
ihnen helfen. Sprechen Sie uns an
WICHTIG WICHTIG
Die Funktion und Bedeutung des ADC wird immer wieder unterschätzt. Der ADC ist kein einmaliger Prozess, den man halt bei der Migration einsetzen muss, sondern ist ein wichtiger unersetzbarer Bestandteil, der fehlerfrei bis zur Deinstallation des letzten Exchange 5.5 Servers funktionieren muss. Wenn der ADC nicht korrekt konfiguriert wurde oder nicht mehr funktioniert (z.B.: weil Server deinstalliert wurden, ohne das CA anzupassen, neue OUs angelegt wurden, ohne die im CA als Quelle mit anzugeben etc.) dann werden Sie sehr bald Probleme bekommen, weil die beiden Welten Exchange 5.5 und Exchange 2000/2003 nicht über den gleichen Kenntnisstand verfügen und daher den Anwendern unterschiedliche Ansichten der Adressbücher zeigen. Das führt zu unzustellbaren Mails, Irrläufern etc. etc.
Sie sollten daher den ADC auf jeden Fall überwachen. (Siehe auch ADC Diagnose). Dies gilt um so mehr, wenn Sie die "DELETE"-Funktion des ADC deaktiviert haben, d.h. Löschbefehle von einer Seite nicht auf die andere Seite repliziert werden. Siehe auch ADCDetails.