Routingdomänen

Im Rahmen einer Koexistenz und Migration mehrerer bislang autarker Systeme kommt sehr bald die Anforderung, dass eine SMTP-Domäne übergreifend bei Postfächern verschiedener Systeme genutzt wird. Diese Seite beschreibt das Konzept der Routingdomänen um diese Problemstellung zu lösen.

Vorbemerkung

Wenn mehrere für sich autarke Mailsysteme, hier eigene Exchange Organisationen, einen gemeinsamen Adressraum nutzen, muss über Weiterleitungen, Aliasse o.ä., eine Weiterleitung für Empfänger außerhalb der eigenen Umgebung realisiert werden. Bei Exchange erfolgt dies über MailUser oder MailContacts, deren Feld „TargetAddress“ idealerweise direkt ein Routing auf das Zielsystem zulässt. Es ist also eine Domäne pro Ziel erforderlich, die per Routing eindeutig bestimmbar ist und nicht anderweitig genutzt wird.

Auch wenn die Versuchung groß ist, dass eine Firma nur einen Teilmenge der Benutzer zu den anderen Organisationen übertragen will, so müssen sie zumindest alle Empfänger der gemeinsamen Domäne in alle Organisationen übertragen, da ansonsten z.B. Mailadresse unbemerkt mehrfach vergeben werden könnten.

Zwei oder mehr Firmen

Nehmen wir an zwei Firmen, die bislang getrennt waren, gehen zusammen. Dann gibt es drei Varianten, wie die Adressierung zukünftig erfolgen kann

  • Option1: Jeder behält seine Mail
    Jeder Standort hat weiterhin "seine" Maildomäne und damit ist das Routing von Extern als auch zwischen den Teilen unkritisch.
  • Option2: Nutzung einer gemeinsamen bestehenden Domäne
    Kauft eine größere Firma eine kleinere, dann wird oft ein Firmenname beibehalten. Die Postfächer der aufgekauften Firma sollten möglichst schnell ebenfalls mit der Mailadresse der Mutter senden und natürlich erreichbar sein. In dem Fall kann die Mutter z.B. über Weiterleitungen die Mails an die weiterhin vorhanden dedizierte Domain der Tochter senden. Alle auch neuen Postfächer der Tochter müssen aber weiterhin eine zusätzliche Adresse der Tochterdomäne bekommen.
  • Option3: Nutzung einer neuen gemeinsamen Domäne
    Auch in diesem Fall gibt es zwei oder mehr Exchange Organisationen die unter einem neuen gemeinsamen Namen erreichbar sind. Allerdings können und werden die Anwender ihre "alte Domäne" vielleicht noch als sekundäre Adresse behalten dürfen, so dass diese Domäne als Routingdomäne verwendet werden kann.

Zustand auf Dauer ?
So eine Mischkonstruktion ist auf Dauer den meisten Firmen zu teuer und Sie werden alles daran setzen, die Struktur zu straffen und zu vereinen.

Unabhängig davon wird jede Firme natürlich den Wunsch haben, die Adressen aus den anderen Umgebungen mit im Adressbuch zu sehen. Dazu ist ein Verzeichnisabgleich wünschenswert, der Postfächer und ggfls. Verteiler o.ä. aus einem System auf der anderen Seite entsprechend als Kontakte anlegt.

Dedizierte Routingdomains

Daher ist es sinnvoll eigene RoutingDomains dafür vorzusehen wie z.B. hamburg.msxfaq.de, bremen.msxfaq.de etc. Dabei sollte nur Benutzer mit einem Postfach an dem jeweiligen Standort eine zusätzliche Adresse aus diesen besonderen Adressraum haben. Wird ein Postfach in eine andere Organisation verschoben, dann muss das Postfach in der neuen Umgebung eine Routingadresse aus dem neuen Ziel bekommen. Die alte Adresse „kann“ es behalten, wenngleich das das Risiko von Konflikten erhöht. Alle anderen Systeme müssen dann ihre Weiterleitung auf die neue Routingdomäne für das Postfach umstellen, z.B. durch einen DirSync. Nur so wird verhindert, dass eine Mail von A über B nach C geroutet wird und nicht direkt von A nach B. Eine eindeutige Zieladresse mit der Routingdomäne als Domainpart steht im Feld „TargetAddress“ der Kontakte und verweist immer direkt auf das Postfach.

Die RoutingDomain selbst wird bei den Benutzern nie für den Versand genutzt, sondern immer nur als zusätzliche Empfangsadresse für das Routing innerhalb des Verbunds, d.h. kein Anwender versendet eine Mail mit einer Adresse aus der Routing Domäne.

Als Routingdomänen können offizielle Namen (firma1.tld, firma2.tld etc.) genutzt werden, wobei dann natürlich jedes Postfach in seiner Umgebung auch zwingend eine Adresse dieser Routingdomäne braucht. Das kann problematisch sein, wenn ein Standort mehrere Firmen hosted.

Alternativ könnten interne nicht offizielle Domänen (firma1.local, firma2.local) zum Einsatz kommen. Allerdings wird es dann z.B. schwer diese Namen für Autodiscover in von einer offiziellen CA in einem Zertifikat zu erhalten. Daher hat es sich angeboten, Subdomains eines öffentlichen Namens zu nutzen wie z.B. muenchen., hannover.  Die Nutzung des Zielnamens als Teil der Domäne erlaubt auch beim Messagetracking einfach zu erkennen, ob das eine Mail vor oder nach der Weiterleitung ist.

Hier mal ein Beispiel mit drei eigenständigen Mailsystemen, die untereinander verbunden sind aber nach extern "wie aus einem Guss" aussehen sollen.

DirSync ist wichtig

Sie sehen hier aber auch, wie wichtig die Kontakte und damit ein Verzeichnisabgleich ist. Ohne diesen wüsste eine Organisation gar nicht, wo das physikalische Postfach für einen Benutzer liegt. Ein Verzeichnisabgleich hat eine ganze Menge Vorteile:

  • Direkte schleifenfreie Zustellung
  • Vermeidung doppelt vergebener Adresse
  • Adressbuch für Anwender
  • Voraussetzung z.B. für Free/Busy-Abfragen (Siehe auch E2007 Kalender Fed)

Aber ein Verzeichnisabgleich ist auch eine Herausforderung, insbesondere wenn mehr als zwei Organisationen verbunden werden müssen. Ziel sollte sein, dass alle Organisationen alle Empfänger können, die den gemeinsamen Adressraum haben. Auf der anderen Seite sollte ein Benutzer aber nur die Routingdomäne seiner Heimatorganisation als zusätzliche Adresse haben. Wir das Postfach eines Benutzers in eine andere Organisation verschoben, bekommt der die Routingadresse des neuen Ziels und sollte seine alte Adresse verlieren.

Knifflig bei einem DirSync könnte sein:

  • Sichtbarkeit
    Auch wenn alle Empfänger in allen Welten definiert sein sollten, müssen sie nicht im Adressbuch für die Anwender "sichtbar" sein. Vielleicht sollen sichtbare Anwender auch noch ein Suffix im Displayname, z.B. " (Firma)" o.ä. bekommen.
  • Autoritative Quelle
    Vermeiden Sie möglichst "MultiMaster-Replikationen". Die Organisation mit dem Postfach ist idealerweise die autoritative Quelle und alle anderen Systeme sind "Nachläufer. Bedeutet natürlich auch eine Abstimmung bezüglich der Stammdaten und Inhalte
  • Orphaned Objekte
    Es ist nicht nur erforderlich alle Empfänger zu habe, sondern auch entfernte Objekte in allen Umgebungen zu entfernen.
  • Gruppen und Mitgliedschaften
    Gruppen können in den anderen Organisationen als "Kontakte" angelegt werden. Ein Sync als Gruppe samt Mitglieder ist keine triviale Angelegenheit
  • Andere Empfänger (DiscoveryMailbox, PublicFolder etc.)
    Mailsystem bestehen nicht nur aus Postfächern. Gerade Exchange kennt auch ein paar Systempostfächer und öffentliche Ordner, die sie vielleicht nicht replizieren möchten aber Mailadressen belegen und damit Konflikte verursachen können.

Sie könnten nun natürlich auch darauf kommen, und den DirSync einfach durch eine "Eimerkette" zu ersetzen, d.h. wenn ein System den Empfänger nicht lokal kennt, sendet er es zum nächsten und weiter zum nächsten. Irgendwann sollte das Postfach schon gefunden werden oder die Mail ist so viele Hops gelaufen, dass Sie als unzustellbar abgelehnt wird. Heute ist dieses Verfahren nicht mehr sinnvoll, da so der erste Mailserver gar nicht ungültige Empfänger sofort ablehnen kann.

Bedeutung der RoutingDomain-Adresse

Der Einsatz einer eindeutigen einer ZielUmgebung zuzuordnenden Routingdomäne ist ein sehr effektives Hilfsmitteln, um in heterogenen Umgebungen E-Mails auf dem kürzesten Weg zuzustellen, Free/Busy-Zeiten zielgerichtet abzufragen, Mailschleifen zu verhindern und natürlich ungültige Empfänger an der ersten Kontaktstelle zu erkennen und idealweise abzulehnen anstatt NDRs zu verwenden.

Sie ist aber eine rein "technische Adresse", die von den Anwendern selbst nicht wirklich bemerkt wird. Sie wird nur beim Ziel als zusätzliche Adresse und bei anderen Systemen als Weiterleitungszielt genutzt. Es muss nicht mal eine offizielle Domäne sein, aber sie darf sich natürlich nicht mit einer realen Domäne einer anderen Firma überschneiden. Da wir alle nicht wissen, welche welche Top Level Domains zukünftig noch benutzbar werden, ist es dennoch eine gute Praxis entsprechende unterdomänen einer öffentlichen Domäne zu nutzen, die sie auch wirklich besitzen.

Ob Sie die unterdomänen dann nach Standorten (z.B. berlin.msxfaq, hamburg.msxfaq.de, frankfurt.msxfaq.de nennen oder die Mailsysteme als Host hinterlegen, (z.B. ex2010norden.msxfaq, ex2010sueden.msxfaq.de) oder die Mailprodukte (z.B. notes.msxfaq.de, Groupwise.msxfaq.de, Sharepoint1.msxfaq.de) bleibt ihnen überlassen ,solange Sie allen Mailsystemen einen Leitweg zu den Domänen geben, die Zielsysteme Mails für diese Domäne annehmen und die Empfänger diese Adresse zusätzlich haben oder das Mailsystem die Adresse vorher umschreibt.

Die Routingdomäne als zusätzliche Adresse hat noch einen weiteren interessanten Vorteil. Wenn Sie sicherstellen, dass nur die Postfächer in einem bestimmten System auch eine zusätzliche Mailadresse der Routingdomäne für diese Ziel haben, dann kann dies als Kriterium für einen Export diese Objekte dienen, um diese in den jeweils anderen Systemen wieder zu importieren. Ein einfacher CSVDE kann dies dann leisten.

# Auszug aus dem Auffud in CSV2EX

CSVDE.EXE
   -s $config.sourceDC `
   -r ('"'+$config.sourcefilter+'"') `
    -l '"dn,sn,givenname,mail,proxyAddresses,msExchHideFromAddressLists"' `
    -u ` -f $config.contactcsv

if ($lastexitcode ) {
   write-Error "csv2ex:ExportCSV:Error on exporting CSVDE.exe"
}

Wenn Sie in einem Batch einen Befehl zur Lesbarkeit auf mehrere Zeilen umbrechen wollen, dann können Sie das "^" (Caret)-Zeichen nutzen.

Bei einer passenden Pflege der Stammdaten können Sie so eine vollständige Liste der zu exportierenden Objekte erhalten. Denn folgende Regeln gelten

  • Alle finalen Empfänger mit einer Adresse in der "gemeinsamen Domäne" ...
    ...benötigen zwingend eine zusätzliche Adresse mit der Routingdomäne. Die Bedeutung liegt auf "alle finalen Empfänger", denn neben Postfächern kann es auch Verteiler, öffentliche Ordner etc. geben.
  • Alle anderen Empfänger ohne Adresse aus einer gemeinsamen Domäne müssen keine Routingdomäne bekommen.
    Sie können aber auch eine Adresse aus der Routingdomäne haben und damit als "exportierbar" gekennzeichnet sein.
  • Bitte keine fremden Routingdomänen
    Kein finaler Empfänger in einer Umgebung sollte aber eine Adresse mit einer Routingdomäne einer anderen Organisation haben. Würde diese per Verzeichnisabgleich an die anderen Firmen geliefert, dann wäre eine Fehlzustellung oder Konflikte beim Verzeichnisabgleich denkbar.

Provisioning und Empfängerrichtlinien

Es ist nicht ausreichend während der Migration oder Zusammenlegung der Systeme alle Objekte entsprechend anzupassen. Auch nach dem Abgleich werden neue Mitarbeiter eingestellt, Verteiler angelegt und öffentliche Ordner "Mail-enabled". Wenn Sie zwischenzeitlich nicht die Empfängerrichtlinien entsprechend angepasst haben.

Bei der Neuanlage von Anwendern muss sichergestellt sein, dass die obigen Regeln angewendet werden. Insbesondere die Anlage der „Routingdomainadresse“ ist für den Export und Import essentiell. Ich empfehle daher die Routingdomain mit über die Empfängerrichtlinie vergeben zu lassen. Alternativ kann das natürlich auch wie bei der ersten Einrichtung per Exchange PowerShell passieren.

#Liste der Mailboxen erstellen
$mblist = get-mailbox -organizationalunit xxxx -resultsize unlimited

# Routingadresse mittels Alias addieren
$mblist | %{ `
   Set-Mailbox `
      -Identity $_.identity `
       -EmailAddresses @{add=("SMTP"+$_.alias+"@standort.msxfaq.de")} `
}

# Wem der Alias nicht gefaellt, kann auch den userpart der primaeren Adresse nehmen
# der ist aber nicht zwingend eindeutig, speziellwenn die Organisation mehrere Domains bedient
$mblist | %{ `
   Set-Mailbox `
      -Identity $_.identity  `
      -EmailAddresses @{add=("SMTP"+$_.primarysmtpaddress.local+"@standort.msxfaq.de")} `
}

Weitere Links