Verbinden von Organisationen

Exchange ist logisch in Organisationen und Standorte bzw. Administrative Gruppen gegliedert. Dabei ist die Organisation die Grenze zwischen Exchange Installationen. Während mit Exchange 5.5 mehrere Organisationen in einer Firma auch innerhalb der gleichen Domäne bestehen konnten, gilt für Exchange 2000/2003, dass ein Active Directory Forest auch zugleich die Organisation für Exchange 2000/2003 darstellt.

Innerhalb einer Organisation können:

  • Gemeinsam Ordner genutzt werden
  • Adressen abgeglichen werden
  • Frei/Belegt Zeiten ausgetauscht werden

Alle anderen Systeme außerhalb der Organisation gelten für Exchange zuerst als "Internet" und damit als nicht vertrauenswürdig.

Achtung
Wenn Sie nicht nur die Verbindung von zwei Exchange Organisationen planen, sondern zukünftig eine Konsolidierung der Benutzer in einen Forrest per ADMT, dann sollten Sie keine Kontakte als Ziel anlegen, sondern MailBenutzer, die später mit den migrierten Konten zusammengeführt werden können. Es ist viel einfacher aus einem Mailuser einen Mailboxuser zu machen. Ein Kontakt muss immer gelöscht und als Benutzer neu angelegt werden.

Die Anforderung

Nun rücken immer mehr Firmen enger zusammen oder bilden Partnerschaften, die auch eine engere Zusammenarbeit von Exchange bedarf. Im Hinblick auf Exchange 2000 bedeutet dies:

  • Verzeichnisabgleich
    Das erste Ziel ist meist die automatische Pflege von Adressen in beiden Systemen, d.h. wenn ein neuer Mitarbeiter in einer Firma angelegt wird, sollten die anderen Firmen in ihrem Adressbuch nach kurzer Zeit diese Person auch sehen und erreichen können
  • Nachrichtenaustausch
    Es mach keinen Sinn, dass Nachrichten zwischen zwei Firmen über das unsichere Internet übertragen werden, wenn eine private Verbindung besteht. Daher sind beide Mailsysteme so zu konfigurieren, dass die Nachrichten den direkten Weg gehen
  • Frei/Belegt-Zeiten
    Wenn Partner enger zusammen arbeiten, dann ist es oft ein Wunsch, nicht nur die Partner per Mail einzuladen sondern schon im vorhinein zu sehen, welche Termine überhaupt verfügbar sind. Über eine Replikation der relevanten Informationen (bis Exchange 2003) oder Kopplung über Federation (Exchange 2007/2010) kann dieser Zugriff gewährt werden.
  • öffentliche Ordner
    Zusammenarbeit heißt mehr als nur Nachrichten zu senden. Selektive öffentliche Ordner sollen auf beiden Systemen sichtbar sein.

Damit sind die Anforderungen gestellt. Und all dies ist sogar möglich. das folgende Bild zeigt, wie Firma 1 seine Daten für Firma 2 bereitstellen kann. Natürlich kann man die gleiche Konfiguration auch bidirektional aufbauen.

Übersicht Interorg Verbindung

Schauen wir uns die einzelnen Komponenten im Details an.

Verzeichnisabgleich

Exchange 2000 pflegt alle Adressen im Active Directory als Email aktivierte Benutzer oder Kontakte. Outlook hingegen kennt neben den Exchange Server Adressen auch Kontaktordner. für die Umsetzung muss nun entschieden werden, wie die Adressen der entfernten Firma in das eigene System eingespielt werden.

  • Kontakte im AD
    Hierzu kann der ADC oder ein Skript die Adressen aus der entfernten Umgebung per LDAP
  • Kontakte im Ordner
    Ebenso sind Programme denkbar, die die Mailempfänger aus einer Firma exportieren und diese in einem gemeinsamen Kontaktordner für Outlook verfügbar machen. Damit erspart sich der Administrator viele Kontakte im Active Directory, was besonders bei weit verzweigten größeren Installationen unerwünscht ist. (Replikation und Sichtbarkeit)
  • Transport mit Import/Export
    Zuletzt muss auch der Transportweg eingerichtet werden. Nicht immer sind beide Systeme direkt per TCP/IP erreichbar, so dass LDAP als Protokoll eingesetzt werden kann. Dann gilt es Alternativen zu suchen
  • Fremdsystem
    Interessant wird es, wenn die andere Firma kein Exchange einsetzt. Dann sind andere Wege gefragt, um die Adressen z.B. als LDIF-Datei zu erhalten um diese importieren zu können. Eventuell ist der Einsatz eines gesonderten Servers mit dem Mailsystem der Gegenseite sinnvoll, um den passenden Connector (Notes, GroupWise) lokal einsetzen zu können.

Bei allen Varianten muss natürlich sicher gestellt werden, dass Löschbefehle und Veränderungen ebenso übertragen werden. Das "Hinzufügen" von neuen Benutzern ist nur die halbe Arbeit. Siehe auch Verzeichnisabgleich

In einfachen Umgebungen mit direkter TCP/IP Verbindung kann daher der ADC genutzt werden. Dabei werden Postfächer aus einer Exchange Organisation zu Kontakten im anderen Forest.

Achtung: Der ADC kann nur zwei Exchange Organisationen abgleichen, wenn eine Seite Exchange 5.5 ist und die andere Seite ein AD. Ein Abgleich zweier Active Directory Forest ist nicht möglich.
Eine Beschreibung finden Sie auf ADC Interorg

Idealerweise trenne man zu exportierende und importierte Informationen in eigenen OU's ab, da so auch Rechte zum Schreiben kontrolliert werden können.


Aber auch hierbei gibt es das ein oder anderen zu beachten. Siehe Details unter Verzeichnisabgleich und Ex552AD. Der auf dem Bild vorhandene ADC ist nicht für die Replikation zwischen zwei ADs nutzbar, sondern nur zwischen einer Exchange 5.5 Organisation mit einer Exchange 2000/2003 Organisation.

Welche Verbindung bei ihnen die beste ist, hängt von ihren Anforderungen ab. Eine komplexe Metadirectory Integration ist sehr leistungsfähig aber zugleich auch die teuerste Lösung. Die Anbindung mit dem ADC kann in vielen Fällen funktionieren, sollte aber vorsichtig getestet werden. Beide Verfahren nutzen dazu die Möglichkeit, sich bei beiden Systemen per LDAP zu verbinden und die Daten zu lesen und zu schreiben.

Die manuellen Ansätze eignen sich auch, wenn keine direkte Verbindung besteht. Der Export auf einer Seite wird nach etwas Anpassungsarbeit auf der anderen Seite importiert. Oftmals ist dieser Ansatz auch interessant, wenn die Postfächer nicht als Kontakte im Active Directory landen sollen, sondern z.B. in einem Kontaktordner.

Nachrichtenaustausch

Die Übertragung der Nachrichten erfolgt zweckmäßigerweise über SMTP. Dieses weit bekannte und verbreitete Protokoll ist leicht zu diagnostizieren, aufgrund der Nutzung eines Ports Firewall freundlich und auch die Sicherheit per TLS/SSL oder VPN und NAT-Tauglichkeit sprechen für den Einsatz. Über passende SMTP-Connectoren bzw. SEND-Connectoren verbunden können Nachrichten zwischen beiden Partnern optimiert ausgetauscht werden:

  • Schnell
    Besteht eine direkte Verbindung zwischen beiden Firmen, können über entsprechende Leitwege und Connectoren die Server direkt miteinander sprechen ohne über Internet gehen zu müssen
  • Sicher
    Sind beide Firmen per VPN verbunden oder weitern beide Mailserver derart konfiguriert, dass sie TLS (SSL) und/oder eine Autorisierung unterstützen, dann ist die Nachrichten besser gesichert
  • Komfortabel
    Wenn beide Maildomänen als "RTF-tauglich" konfiguriert werden, dann können Sogar formatierte Nachrichten mit OLE-Objekten und Terminabfragen transparent übertragen werden, ohne dass Daten und Form verloren gehen

Beim Einsatz von Exchange 2000 ist entsprechend ein SMTP-Connector einzurichten, welcher als Smarthost den Mailserver der Gegenseite über die private Leitung erreichen kann und als Adressraum die SMTP-Domäne des Empfängers hat. Nun werden alle Nachrichten an diese Domänen über den speziellen Connector direkt zur Partnerfirma geleitet.

Die Verbindung kann per VPN oder auch mittels Authentifizierung und SSL gesichert werden. Wenn beide Systeme "Exchange" Sprechen, dann kann beim Connector als Nachrichtenformat "RTF" aktiviert werden. Nun werden sogar "Terminvereinbarungen" und formatierte Nachrichten transparent übermittelt. Die den Anwender ist kaum noch ersichtlich, dass die Nachrichten die eigene Organisation verlässt und bei einer andere Firmen ankommt.

Zusammenarbeiten mit gleichem Adressraum

Ein Sonderfall ist die Nutzung des Verzeichnisabgleich für die gemeinsame Nutzung einer SMTP-Domäne in mehreren Organisationen. Hier ist ein Abgleich erforderlich, der die Empfänger zu Kontakten der anderen Seite macht und dabei eine eindeutige Adressierung erlaubt:

In diesem Fall kommt der abweichenden TargetAddress eine Bedeutung zu, anhand der die Mails von einer Organisation in die andere Geleitet werden, obwohl die Mailadresse eigentlich auch in der gleichen Organisationen vorhanden sein könnte. Voraussetzung ist natürlich, dass Exchange nicht autoritativ für diese Domäne ist. (Siehe auch MSXFAQ.DE - Empfängerrichtlinien)

Gleicher Adressraum mit "Eimerkette"

Ein Sonderfall ist eine gemeinsame Nutzung des Adressraums als Verkettung von Mailsystemen: Dies wird oft bei Migrationen durchgeführt, so dass die Mails zugestellt werden aber kein aufwändiger Verzeichnisabgleich notwendig ist.

Die Verzeichnisreplikation ist NICHT erforderlich zum Routing der Nachrichten. Nachrichten aus dem Internet werden durch den MX-Record zum linken Server (z.B.: die Exchange Organisation) geleitet. Dort ist die Domäne "nicht autoritativ", so dass Exchange Empfänger, die er lokal nicht findet, anhand des zweiten SMTP-Connectors an den rechten Server weiter gibt. Umgekehrt muss der Server rechts alle Nachrichten an die Exchange Organisation senden, die diese Nachrichten nun lokal Zustellt oder als Relay in das Internet sendet.

Allerdings hat dieses Konzept den "Nachteil", dass es zu Mailschleifen zwischen den beiden Servern kommen kann, wenn nämlich eine Mail an einen nicht existenten Empfänger adressiert wird. Dann läuft die Mail mehrfach zwischen den Systemen hin und her, bis der "Hopcount" überschritten ist oder ein anderer Mechanismus die Schleife unterbricht.

Dies kann aber recht einfach gelöst werden, indem zumindest auf dem Exchange Server in der Mitte die Benutzer des rechten Servers als Kontakte gepflegt werden, so dass die Exchange 2003 Empfängerprüfung ungültige Empfänger gleich ablehnen kann.

Free/Busy und öffentlichen Ordner

Neben dem "Messagerouting" zwischen zwei Organisationen und dem Verzeichnisabgleich der Adressbücher ist natürlich ein Zugriff auf Frei/Belegt Informationen wünschenswert. Eine solche Funktion ist sogar schon sehr viele Jahre lange relativ problemlos möglich, da zumindest bis Exchange 2003 diese Funktion eine reine Aufgabe von Outlook war und mit Exchange 2007 und höher auch von Exchange bereit gestellt wird.

Auf der Seite Frei/Belegt Zeiten sind die unterschiedlichen Funktionsweisen bereits erklärt worden. Sie müssen zu dieser Funktion nun wissen, dass Outlook auch die Frei/Belegt-Zeiten von Personen abfragt, die nicht in der gleichen Exchange Organisation. Je nach Version sucht Outlook nun in dem Free/Busy-Ordner nach einem Datensatz für den externen Benutzer oder bittet den CAS-Server, diese Daten über die Exchange Web Services (EWS) zu liefern.

Free/Busy mit Outlook 2003 und älter

Sie müssen also bei Nutzung der öffentlichen Ordner nur dafür sorgen, das die Frei/Belegt-Zeiten halbwegs aktuell in der anderen Organisation auftauchen. Das Programm IOREPL - InterOrg Replication Tool  von Microsoft sorgt dafür, indem es auf einem System läuft und regelmäßig eine Verbindung mit je einem Server herstellt. Es liest dann die angegebenen öffentlichen Ordner und übermittelt die Änderungen .

Als Besonderheit kann IOREPLauch die Frei/Belegt Zeiten auslesen und in die andere Organisation übertragen.

Die Replikation über öffentliche Ordner müssen Sie so lange betreiben, wie sie Outlook 2003 Clients unterstützen.

FreeBusy mit Exchange 2007 über EWS

Alle Outlook 2007 oder neueren Clients nutzen mit Exchange 2007 oder neuer die EWS-Dienste. Sie schauen also nicht mehr selbst im öffentlichen Ordner nach, sondern bitten den CAS-Server, die Daten zu beschaffen. Der CAS-Server schaut dann direkt oder über andere CAS-Server in das Postfach und holt die Daten. Ist das fragliche Postfach noch ein "Legacy Postfach", also Exchange 2003 oder älter, dann schaut der CAS eben in den Public Folder hinein.

Beim Zugriff auf Empfänger anderer Organisationen muss der CAS nun einen Tipp bekommen, wo er die Frei/Belegt-Daten der externen Empfänger bekommt. Ist ein CAS-Server der anderen Domäne direkt vom eigenen CAS-Server über HTTPS erreichbar, dann reicht schon die folgende Konfiguration:

$cred = get-Credetial
# Eintragen einer anderen SMTP-Domain als Federation-tauglich
Add-AvailabilityAddressSpace `
	-ForestName netatwork.de `
	-AccessMethod OrgWideFB `
	-Credentials $cred

# Definition des Accouts, welcher die eigene Org abfragen darf
Set-AvailabilityConfig -OrgWideAccount domain\serviceaccount

Der Service-Account sollte natürlich KEINE privilegierten Berechtigungen bekommen, da diese Daten ja den Partnerunternehmen übermittelt werden.

Voraussetzung ist natürlich, dass der anfragende CAS-Server über Autodiscover die EWS-Zugänge der anderen Domäne ermitteln und die angegebenen Credentials auf der anderen Seite gültig sind. Die andere Seite muss also quasi ein "Dienstkonto" für die anfragende Exchange Organisation einrichten. Das gleiche sollte dann natürlich auch in die Gegenrichtung erfolgen.

Verwendet die andere Seite noch Exchange 2003 oder älter und werden die Daten über das InterOrg Replication Tool in ihre Umgebung repliziert, wozu auch Dienstkonten und entsprechende LAN-Verbindungen erforderlich sind, dann sollten Sie den CAS-Servern dies auch sagen.

# Konfiguration der Anfrage an den anderen Forest
Add-AvailabilityAddressSpace `
	-ForestName smtpdomain.tld `
	-AccessMethod PublicFolder

Über diese Einstellung suchen die CAS-Server nur auch für Empfänge der angegebenen Domain die Free/Busy-Daten anhand eines Kontakts in den lokalen öffentlichen Ordnern. Dies wird aber sicher bald hinfällig werden, da der Weg über EWS schneller, effektiver und ohne Replikation auskommt.

Die Kopplung von Exchange Organisationen über EWS wird zukünftig noch intensiver geschehen können, z.B.: dass man sogar in das Postfach eines anderen Benutzers schauen kann, wenn die Berechtigungen über Federation oder Trusts abgesichert werden können. Aber das übersteigt den umfang der MSXFAQ, da hier nicht mehr nur ein paar Commandlets erforderlich sind.

Free Busy mit Exchange 2010

In Exchange 2010 wurde das Verfahren noch mal geändert, da die Sicherheit durch Dienstkonten und die Erfordernis von Kontakten doch nicht recht den Anforderungen der Kunden entsprochen hat. Nun kann jeder Mitarbeiter auch steuern, welche Frei/Belegt-Zeiten andere Personen sehen. Zudem ist es über ein "Clearinghouse" möglich, dass nun nicht mehr jeder mit jedem eine Federation einrichten muss.

Delegate Access

Exchange hat es mit Office 365 gelernt, dass auch zwei Exchange Organisationen miteinander zusammen arbeiten können. Im sogenannten "Hybrid-Mode" können Sie eine eigene Exchange Organisation (OnPremise) mit dem Teil in Office365 verbinden, so dass für die Anwender fast kein unterschied besteht, wo das Postfach liegt. Dieses Verfahren "soll" man auch zwischen zwei Organisationen (OnPremise) einsetzen können. Das durfte ich selbst aber noch nicht einrichten. Bislang waren Migrationen ein Thema und keine langen Koexistenzen. Daher hier erst mal nur Links

Wer sich die Mühe sparen und nur für ganz wenige einen "Dual-Zugriff" ermöglichen muss, kann diese vielleicht auch mit Outlook 2010/2013 für die fraglichen Personen erreichen:

SMTP-Adressraum Sharing

Werden nun nicht nur zwei Organisationen mit unterschiedlichen Adressen verbunden, sondern es handelt sich z.B. Um eine Verbindung zweiter Exchange Organisationen die auch noch den gleichen SMTP-Adressraum gemeinsam nutzen müssen, dann wird die Aufgabenstellung etwas erweitert. Zwar können hier wie auch bei unterschiedlichen SMTP-Domains über Kontakte die Mails entsprechende weiter geleitet werden aber zwei Dinge müssen zusätzlich berücksichtigt werden:

  • Autodiscover für Clients
    Der Autodiscover-Eintrag für eine Domain kann nur auf eine Exchange Organisation verweisen. Wenn alle Client die gleiche primäre SMTP-Domain verwenden aber ihr Postfach in unterschiedlichen Organisation haben, dann werden einige Clients den falschen CAS-Server fragen. Die TargetAddress ist dabei der Schlüssel
  • Autodiscover für Free/Busy-Sharing (CAS zu CAS)
    Aber auch die Abfrage von Frei/Belegt-Zeiten zwischen Organisationen durch die CAS-Server (Federation) erfordert eine funktionierende Namensauflösung der Domains und dass Exchange die Frei/Belegt-Zeiten auch in der anderen Organisation sucht

Dies muss entsprechend berücksichtigt und konfiguriert werden.

Weitere Links

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