TargetAddress

Zu dieser Seite sind Schattenpostfachmigration und Forwardingsmtpaddress thematisch verwandt.

TargetAddress mit MailboxUser
Früher war das Feld offiziell nur für MailContacts und MailUser nutzbar. Sie können das Feld aber auch auf MailboxUser setzen und tatsächlich leitet Exchange dann jede Mail an das Postfach an die Target Address weiter.
Seit Exchange 2010 kann man nun aber sagen, dass die auch offiziell erlaubt ist, da Microsoft selbst für die Migration in die Cloud diesen Trick nutzt, um Mails an ein anderes Postfach zu leiten, während Inhalte noch synchronisiert werden.

Das Feld "ForwardAddress" kann ebenfalls weiter leiten, muss aber als Wert einen distinguished Name z.B. auf eine einen MailUser, MailContact o.ä. enthalten.

Das Feld TargetAddress gehört schon sehr lange zum Exchange Schema und kann theoretisch auf jedem Empfänger gesetzt werden. Allerdings sollten Sie wissen, wie sich ein Inhalt in diesem Feld auswirkt, ehe sie es außerhalb der normalen Verwendung einsetzen. Dann aber kann TargetAddress ihnen sehr gut helfen. Das erste mal habe ich diese besondere Verwendung vor vielen Jahren bei einer Migration mit den Quest Tools können gelernt und seit dem mehrfach bei Migrationen eingesetzt.

Der Normalgebrauch

Normalerweise sind im Active Directory alle Empfänger vorhanden, die Exchange als gültige Empfänger auch in der globalen Adressliste anzeigt. Die meisten Exchange Installationen pflegen im Active Directory nur die internen Empfänger wie:

  • Aktive Postfächer
  • Ressourcen Postfächer
  • Verbundene Postfächer
  • Verteiler und Abfragebasierte Verteiler
  • öffentliche Ordner

All diesen Empfängern ist gemeinsam, dass die Empfänger letztlich intern liegen und die Mail auf einem Server innerhalb ihres Active Directory landet. Aber das Active Directory und Exchange können noch mehr.

Exchange Empfängertypen

Neben den aktiven Empfängern kann das Active Directory und Exchange auch externe Ziele verwalten. Dazu zählen:

  • Mailaktiviert Kontakte
  • Mailaktivierte Benutzer

Diese Empfänger tauchen mit im Adressbuch von Outlook auf (GAL) aber die Postfächer selbst liegen außerhalb ihrer Exchange Organisation. Sie können so z.B. externe Empfänger, deren Postfach in einer anderen Firma oder einem Provider liegen, in ihre Adressbuch mit aufnehmen. Allerdings sollten sie abwägen, ob wirklich ALLE Nutzer in ihrer Exchange Organisation auch ihre privaten Kontakte sehen und nutzen sollen. Hier sind persönliche Kontakte im Postfach oder einem öffentlichen Ordner vielleicht besser.

Bei diesen beiden Objekte steht aber im Feld "TargetAddress" die externe Mailadresse, an die Exchange die Mails weitergibt.

MailUser und Zieladresse Kontakt und Zieladresse

Solche Kontakte sind auch erforderlich, wenn Sie z.B.: bei einem der anderen Empfänger eine Weiterleitung einrichten wollen. Klassischer Fall: Sie haben zwei Exchange Organisationen, die sie miteinander verbinden wollen. (Siehe auch MSXFAQ.DE - Verbinden von Organisationen und Verzeichnisabgleich)

Ein klassischer MailUser in Exchange hat folgenden wichtige Felder

  • Mail (WindowsEmailAddress)
    Das ist die angezeigte Adresse. für Exchange ist sie eigentlich nicht sonderlich wichtig. Exchange sorgt aber dafür, dass dieses Feld mit der primären Adresse in ProxyAddresses“ gleichgezogen wird.
  • ProxyAddresses (EmailAddresses)
    Die Liste aller Mailadressen, für die dieses Ziel matched, d.h. jede Mail an eine dieser Mailadressen wird an das Postfach angebunden oder die hinterlegte Zieladresse (TargetAddress) weiter geleitet.
  • TargetAddress (ExternalEMailAddress)
    Bei MailUser/Mailcontact verpflichtendes Feld, bei Mailbox nur während Migrationen. Jede Mail an eine Adresse dieses Objects (ProxyAddresses) wird an die hier hinterlegte Zieladresse weiter geleitet, die immer „außerhalb der Exchange Organisation ist. Bei klassischen MailUser/MailContact sind das Feld „Mails“, „TargetAddress̶" und die primäre ProxyAddresses identisch. Das stellt z.B. ein SET-MailUser auch sicher.

Durch das Setzen der Mailadresse über "Set-MailUser" z.B. im Rahmen des Migrationsprozess auf eine Adresse, wird nicht nur die WindowsEmailAddress geändert, sondern eben auch die primäre ProxyAddresse und auch die TargetAddresse. Beachten Sie dies in Skripten, dass die TargetAddress auch danach noch korrekt gesetzt ist.

Die klassische Weiterleitung an andere existierende Exchange Empfänger

Oft werden Kontakte aber auch zur Weiterleitung genutzt. Jedes Postfach hat unter den Zustelloptionen die Einstellung einer Weiterleitung auf dem Server.

Weiterleitung an andere Empfänger

Hier kann man natürlich eine Weiterleitung an einen anderen Empfänger in der gleichen Exchange Organisation aber auch auf einen Kontakt eintragen. Allerdings kann man hier keine Freitextadresse eintragen. Das Ziel muss im Active Directory existieren.

Weiterleiten mit TargetAddress und Postfächern

Sie können sich nun natürlich denken, was nun kommt:

Wie verhält sich Exchange, wenn Postfächer eine "TargetAddress" bekommen ?

Ich habe mir dazu die gängigen Empfängerobjekte vorgenommen und mit ADSIEDIT einfach das Feld TargetAddress" mit einer externen SMTP-Adresse gefüllt und geschaut was passiert.

Achtung:
Natürlich ist das alles nur bedingt durch die Exchange Commandlets und Anleitungen abgedeckt und ich kann nicht garantieren, dass das Verhalten nach dem nächsten Servicepack oder in der nächten Version weiterhin so vorhanden ist.

Achtung:
Die TargetAddress muss zwingend ein Postfach außerhalb der Exchange Organisation sein, da Exchange die Ziele nicht mehr intern gegen das Adressbuch prüft, sondern immer extern versendet.

Achtung:
Wenn Sie ein Postfach mit "TargetAddress" von einer Speichergruppe in eine andere Speichergruppe verschieben, dann entfernt Move-Mailbox die Targetadress ohne Rückfrage oder Warnung. Da die Platzhalterpostfächer aber keinen Inhalte haben, ist ein Verschieben eher im Bereich der Migration ein Thema und dann dieses Verhalten sogar als Vorteil gewertet werden.

"WINMAIL.DAT"
Bei Kontakten können Sie das Format der Mails per GUI einstellen. bei Postfächern allerdings nicht. Hier kann es ratsam sein, das Feld MapiRecipient auf False zu setzen, damit auch Weiterleitungen per Postfach ohne WINMAIL.DAT im alten Zielsystem ankommen.

Wir bewegen und schon ein Stück abseits der ausgetretenen Pfade bisheriger Administrator. Das erkennen sie schon daran, dass es keine GUI gibt, um eben das Feld "TargetAddress" an solchen fremden Objekten zu pflegen oder anzuzeigen.

Empfängerobjekt Exchange Version Normalzustand Sichtbar in der GUI sinnvoll möglich

User Mailbox

4.0 und höher

leer, nicht genutzt

Nein

möglich

LinkedMailbox

5.5 und höher

leer, nicht genutzt

Nein

möglich

Ressourcen Mailbox

2007 und höher

leer, nicht genutzt

Nein

möglich

Verteiler

4.0 und höher

leer, nicht genutzt

Nein

Nein
Da Exchange die Mail an die Mitglieder auffächert

Abfragebasierter Verteiler

2003 und höher

leer, nicht genutzt

Nein

Nein
Da Exchange die Mail an die Mitglieder auffächert.

öffentlicher Ordner

4.0 und höher

expf:<OrdnerGUID>

Nein

NEIN (2007)
NDR wird erzeugt

MailUser (AD-Benutzer mit Mailadresse)

2000 und höher

Externe Adresse

Ja

Erforderlich, damit das Objekt korrekt konfiguriert ist.

Mailkontakt

4.0  und höher

Externe Adresse

Ja

Erforderlich, damit das Objekt korrekt konfiguriert ist.

Interessant sind also die drei Einträge bei den verschiedenen Postfächern, die tatsächlich möglich sind. Doch wozu können diese genutzt werden?

Exchange 2007 und TargetAddress

Im Bezug auf Exchange 2007 hat die TargetAddress als "-ExternalEmailAddress" niedergeschlagen. Auch hier kann man die Adresse bei Postfächern setzen. Aber man muss einige Aktionen beachten:

  • Enable-Mailbox
    Hierbei löscht Exchange ohne Rückfrage oder Warnung eine bereits eingetragene TargetAddress. Allerdings macht eine TargetAddress bei einem Objekt, welches nicht Exchange Enabled ist, keinen Sinn. Allenfalls für Skriptentwickler, die vorher das Feld setzen würden.

RUS ist nicht immer aktiv
Wenn man mit "Enable-Mailbox" den Parameter "-PrimarySmtpAddress" verwendet, dann bewirkt das, dass auch, dass "-EmailAddressPolicyEnabled" nicht mehr aktiv ist. Ein nachfolgender Set-Mailbox -EmailAddressPolicyEnabled $true" biegt das dann wieder hin.

  • Set-Mailbox
    Trägt man bei einer bestehenden Mailbox eine targetAddress ein, dann passt SET-MAILBOX dieses Postfach beim Aufruf an:

    Die TargetAddress bleibt im System aber zusätzlich wird die Windows Mail-Adresse geändert und die ProxyAdresse um die externe Adresse erweitert.
    Hier passiert nicht. Allerdings warnt Exchange, wenn die TargetAddress nicht gültig ist.
  • Move-Mailbox
    Verschiebt man eine Mailbox, dann wird Targetaddress komplett gelöscht !!. Wenn man die Änderungen vorher wenigstens mit Set-Mailbox übernommen hat, dann bleibt die Adresse zumindest in den ProxyAddresses erhalten.

Verschiebt man eine Mailbox, dann wird die TargetAddress komplett gelöscht !!.
eine Ideale Migrationsstrategie, wenn man mehrere Datenbanken hat, die Platzhalterpostfächer in einer eigenen Datenbank hält und bei der Migration dann die Postfächer verschiebt.

  • Remove-Mailbox
    Hierbei wird natürlich wieder alles entfernt. Auch die TargetAddress ist danach verschwunden.

Man kann also sagen, das Exchange 2007 durchaus die Umleitung mit "TargetAddress" unterstützt, aber bei der Verschiebung die Einstellungen verloren gehen. Auch gibt es keine Möglichkeit, die TargetAddress per GUI oder Exchange Commandlet zu setzen. man muss also per LDAP direkt die Änderungen durchführen. Schade eigentlich.

Details zur TargetAddress

Nun ist klar, dass wir in dem Feld "TargetAddress" auch bei Postfächern andere Adressen eintragen können. Aber ein paar Dinge gibt es dabei noch zu beachten:

  • E-Mail-Typ
    Das Feld TargetAddress muss eine für Exchange gültige und routingfähige Adresse beinhalten. Das muss keine SMTP-Adresse sein. Auch eine FAX-Adresse oder andere Formate sind möglich, solange Exchange einen Leitweg dazu kennt. Wichtig ist die Angabe der Adresstyps als Präfix vor der eigentlichen Mailadressen. Eine Internet Mailadresse muss also mit "SMTP:" eingeleitet werden
  • Eindeutigkeit
    Ich habe immer wieder Warnungen oder Fehler bekommen, wenn ich mehreren Objekten die gleiche "TargetAddress" vergeben wollte. Das liegt aber weniger an der TargetAddress, sondern eher an der Überprüfung auf doppelt ProxyAddresses, die die Exchange Management Tools machen. Vermeiden Sie daher besser, dass mehrere Objekte identische Adressen erhalten
  • Extern und Intern
    Dann bleibt noch die Frage, wie sich Exchange verhält, wenn die angegeben Zieldresse schon intern vergeben ist oder Extern ist. Exchange kennt anhand seiner Empfängerrichtlinien (2003) bzw. "Accepted Domains" (2007) die SMTP-Domänen, für die Exchange zuständig ist. Nutzen wir aber das Feld "targetAddress", dann wird die Mail IMMER nach extern versendet, selbst wenn es intern einen Empfänger mit der Zieladresse als ProxyAdresse gibt.!

Gerade der letzte Punkt kann natürlich Exchange Administratoren zum Wahnsinn treiben, wenn die Mail an einen Empfänger über eine TargetAddresse weitergeleitet werden soll, aber die Mail immer über die Connectoren "nach außen" geht, statt Sie lokal zuzustellen. Das ist aber für eine andere Konfiguration von Vorteil: Wenn zwei Exchange Organisationen den gleichen Adressraum nutzen, ist diese Funktion wichtig, damit Mails auch die eigene Exchange Organisation verlassen können, auch wenn die Zieladresse eigentlich in meiner autoritativen Domain liegen. Allerdings sollten Sie über einen entsprechenden SMTP-Connector den Mails den Weg zur anderen Organisation weisen, nicht dass die Mails per DNS Richtung Internet direkt wieder bei ihnen zurückkommen.

Im Active Directory Schema können Sie gut die Definition des Felds auslesen.

TargetAddress im Schema

Der Inhalt ist per Default im globalen Katalog und wird sogar indexiert. Das sind erforderliche Voraussetzungen, dass alle Exchange Server in der Organisation die Daten schnell erhalten.

Migration und Koexistenz

Die Option, die Daten eines Postfachs an eine andere "externe" Adresse weiterzuleiten ist eine sehr interessante Funktion speziell für die Migration von Postfächern zwischen Firmen. Wenn Sie zwei Exchange Organisationen betreiben, dann können Sie diese über Connectoren und einen Verzeichnisabgleich (Siehe Verbinden von Organisationen und Verzeichnisabgleich) natürlich verbinden. Die Postfächer auf der einen Seite tauchen in der anderen Organisation als Kontakte auf. Aber wenn nun im zweiten Schritt eine Migration ansteht, dann müssen sie erst wieder die Kontakte und Benutzer mit Postfächern konvertieren. Das ist nicht wirklich sinnvoll.

Wenn Sie daher planen, dass aus einer Koexistenz eine Migration werden soll, dann können Sie anstelle von Kontakten gleich deaktiviere AD-Benutzer mit einer Mailadresse erstellen oder sogar gleich ein Postfach mit einer Weiterleitung über Target-Adressen.

Migration mit TargetAddress

Der Vorteil besteht darin, dass bei der Migration nicht erst der Zielkontakt gelöscht und durch ein Postfach ersetzt werden muss, welches dann erst die Daten aufnehmen kann und dann in der Quelle das Postfach durch einen Kontakt ersetzt werden muss. Das ist sehr viel "Unruhe" bei der Migration. Existieren jedoch auf beiden Seiten schon die Postfächer, dann kann man sogar schon vorher z.B. alle Mails älter als 6 Monate in das Ziel kopieren und bei der Umschaltung dann mit viel weniger Datenmengen hantieren.

Allerdings muss man natürlich aufpassen, dass bei einer Teilweisen Migration die Benutzer auf der einen Seite nicht mit dem alten Postfach über Stellvertreterfunktionen weiter arbeiten. Ein guter Projektplan ist zwingend erforderlich.

Unterstützung durch Net at Work:
Ich kann ihnen hier nur anbieten, dass wie sie bei solchen "Cross-Organisation" Migrationen unterstützen, damit die Ausfallzeiten minimal sind. Übrigens eignet sich dieses Verfahren mit Postfächer auch für die Migration von anderen Mailsystemen.

TargetAddress und Hybrid

Die TargetAddress hat bei einer Exchange Hybrid Bereitstellung die Funktion Mails an eine Remote Mailbox weiter zu leiten. Die Adresse wird bei der Migration durch Exchange Online und den lokalen MRS (Mailbox Replication Service) gesetzt. Sie können den Wert aber auch mit "Set-RemoteMailbox -RemoteRoutingAddress" setzen.

Im Hintergrund wird dann das Feld "Target Address" gesetzt.

TargetAddress und Autodiscover

Passend zur Migration und Weiterleitung wirken die Einträge im Feld "TargetAddress" sich auch bei Autodiscover aus. Wenn eine Mail nicht in das Postfach zugestellt wird, dann macht es auch keinen Sinn, wenn sich Outlook mit diesem Postfach verbindet. Ein Client, der einen Exchange Server in dieser Organisation per Autodiscover fragt, bekommt einen Redirect auf die Targetadresse und versucht sich dann mit einem Autodiscoverdienst dieser Domäne der TargetAdresse zu verbinden.

So ist es einfach möglich, ein Postfach von einer Exchange Organisation in eine andere Organisation zu verschieben und zumindest Outlook 2007/2010 automatisch umzuleiten.

Auch BPOS (Vorgänger von Office 365) hat diese Funktion genutzt und in einem Bild schön dokumentiert.

Target Address und "Autoritative Domains"

Eine Besonderheit gibt es zu beachten, wenn ihre Exchange Organisation z.B. für "domain.tld" autoritativ zuständig ist und die Mailadresse in "TargetAddress" auch die Forma "Username@domain.tld" hat. Je nach Exchange Version wird die Mail dann über den nächsten SMTP-Connector nach Außen transportiert oder nicht

  • E2K & E2K3 Mail wird weiter geleitet
    d.h. die Mail ist nicht unzustellbar sondern verlässt die Exchange Organisation. Sie sollten hier also sicherstellen, dass ein geeigneter Connector die Mails auch wirklich ans Ziel bringt und nicht per MX-Record eine Schleife passiert
  • Ex5.5, E2K7, & E2K10 Mail wird nicht weiter geleitet
    Hier landet die Mail in einem NDR.

Insofern sollten Sie bei TargetAddress auf der sicheren Seite sein und eindeutige Routingdomains verwenden.

Anlage: Testergebnisse

Folgender Abschnitt fasst die Ergebnisse meiner Tests mit dem Feld "TargetAddress" zusammen. Teilweise ist hier gut zu erkennen, dass eine Änderung von Feldern an den Exchange Verwaltungstools vorbei durchaus auch unerwünschte Effekte haben kann

  • öffentliche Ordner (2007 SP1)
    Der Versuch eine Mail an einen "mailaktivierten" öffentlichen Ordner über einen manuellen Eintrag in "TargetAddress" umzuleiten hat Exchange 2007 mit einer unzustellbarkeit quittiert:

  • Abfragebasierte Verteiler (2003)
    Losgelöst von der Aussage, dass eine TargetAddress bei einem Verteiler nicht sinnvoll ist, da die Mitglieder schon früher aufgefächert werden, habe ich mit Exchange 2003 ein seltsames Verhalten gesehen. Die manuell per ADSIEDIT addierte TargetAddress ist nach einigen Minuten in den ProxyAddresses aufgetaucht. Allerdings hat der RUS dabei anscheinend die Adressen als primär addiert.
    Exchange 2003 RUs Fehler bei QDSG

Es ist also durchaus ein Restrisiko vorhanden, wenn Sie mit ADSIEDIT oder anderen Skripten direkt für Exchange relevante Felder verändern.

PowerShell für TargetAddress

Da Sie die TargetAddress bei einem Postfach nicht per GUI setzen können, bleibt nur ADSIEDIT, ADModify, ADModify.NET oder natürlich PowerShell. Hier ein einfaches Skript, welches die Windows Mail-Adresse nutze, um darauf basierend eine Weiterleitung über die TargetAddress einzurichten. Hier habe ich in der OU "MigZiel" ein paar Benutzer per ADMT (samt Mail-Adresse) aus einer anderen Quelle übertragen und dann mit einer Mailbox versehen.

$Userlist = get-User `
   -Domaincontroller dc1.msxfaq.net `
   -OrganizationalUnit msxfaq.net/migziel `
   -Filter {windowsemailaddress -ne $null} `
   -RecipientTypeDetails User 

Foreach ($User in $Userlist) {
   enable-mailbox `
      -identity $User.identity `
      -PrimarySMTPAddress $User.windowsemailaddress.tostring()`
      -Domaincontroller dc1.msxfaq.net
}

Damit aber Mails an dieses Postfach weiter noch an die Quelle gehen, gibt es einen SEND-Connector mit dem Adressraum zur Quelle und hier die Weiterleitung:

Import-Module ActiveDirectory 
Get-ADUser `
   -Server dc1.msxfaq.net `
   -SearchBase "OU=Migziel,DC=msxfaq,DC=net"`
   -property mail `
   -ldapfilter "(homemdb=*)" `
  | %{Set-ADUser `
        -Identity $_.distinguishedname `
        -Server dc1.msxfaq.net `
        -Add @{targetaddress=("SMTP:"+$_.mail)}
}

Die Angabe eines expliziten DCs ist wichtig, wenn mehrere Befehle kurz hintereinander aufgerufen werden, damit die Änderungen immer auf dem gleichen DC erfolgen.

Wenn die Migration dann abgeschlossen ist und die Benutzer im Ziel arbeiten sollen, dann muss der Eintrag in TargetAddress natürlich wieder raus.

Import-Module ActiveDirectory 
Get-ADUser `
   -Server dc1.msxfaq.net `
   -SearchBase "OU=MigZiel,DC=msxfaq,DC=net"`
   -ldapfilter "(homemdb=*)" `
  | %{Set-ADUser `
        -Identity $_.distinguishedname `
        -Server dc1.msxfaq.net `
        -Clear targetaddress
}

MOERA - Microsoft Online Email Routing Address

In einigen Dokumentationen und selbst Fehlermeldungen von Microsoft kommt manchmal der Text "MOERA" vor. Diese Abkürzung bezeichnet die Microsoft Online Email Routing Address. Es handelt sich quasi auch um eine eindeutige Routing-Adresse, mit der Mails zu einem Exchange Online Postfach geroutet werden.

Jeder Office 365 Empfänger hat dazu in der Regel eine Adresse in der Form "userpart@<tenantname>.mail.onmicrosoft.com", über die das Objekt eindeutig auch für Kontakte in einer On-Premises-Umgebung adressiert werden kann. Hier eine Fehlermeldung mit "Set-UnifiedGroup".

There should be atleast one MOERA in Email Addresses. + CategoryInfo : NotSpecified: (:)
  [Set-UnifiedGroup], RecipientTaskException + FullyQualifiedErrorId :
[Server=AM1PR1001MB2007,RequestId=<guid>,TimeStamp=02/04/2020 13:26:35]
[FailureCategory=Cmdlet-RecipientTaskException] 237F131F,
Microsoft.Exchange.Management.RecipientTasks.SetUnifiedGroup
+ PSComputerName : outlook.office365.com

Azure AD calculates the MOERA from Azure AD MailNickName attribute and Azure AD initial domain as <MailNickName>@<initial domain>.
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-userprincipalname

Weitere Links