RemoteMailbox Provisioning

Ich möchte auf dieser Seite eine Besonderheit der Felder "RemoteRoutingaddress" und ProxyAddresses bei einer Exchange Online Mailbox vorstellen, die mich zuerst verunsichert hat. Wenn ich die RemoteRoutingAddress angebe, ist sie nicht automatisch in den ProxyAddresses. Funktioniert dann Exchange Online?

Basisfunktion

Wer schon mit Exchange Hybrid gearbeitet hat, sollte den Zusammenhang zwischen einer "Exchange Online Mailbox" und der dazugehörigen OnPremises "RemoteMailbox" kennen. Zu jedem Postfach in der Cloud gehört lokal das passende Gegenstück, damit lokale Exchange Server wissen wie Sie die Mails in die Cloud übertragen können. Dazu werden an dem lokalen AD-Objekt die Exchange Properties entsprechend gepflegt. Das sind im wesentlichen die folgenden Felder:

Exchange Parameter AD-Feld Bedeutung

WindowsEmailAddress

Mail

Das Feld ist für Exchange gar nicht wichtig, aber wird gerne mit aufgeführt und überall sichtbar

PrimarySMTPAddress

 

Der Parameter hat kein eigenes Feld im AD sondern setzt das Feld Mail und ProxyAddresses bzw. gibt die primäre SMTP-Adresse aus den ProxyAddresses wiedere

EmailAddresses

ProxyAddresses

Dies ist die Liste der Mailadressen, über welcher dieser Empfänger aufgelöst und gefunden werden kann

RemoteRoutingAddress

Targetaddress

Diese Feld weist Exchange an, die Mail an die angegebene Adresse weiter zu reichen und ist bei einer RemoteMailbox Pflicht. Bei Migrationen kann das Feld übrigens auch bei Postfächern gesetzt werden

Alias

mailnickname

Der Kurzname, welcher für den Zugriff per PowerShell und die Bildung von Adressen über Empfängerrichtlinien genutzt werden kann.
RecipientTypeDetails
RecipientType

msExchangeRecipienttype

Über diese Feld wird der Type der Mailbox gesteuert

Es gibt natürlich noch ein paar weitere Felder aber diese sind erst mal die Wichtigsten. Für das Mailrouting von OnPremises zu Exchange Online muss nun sichergestellt sein, das die Adresse in "RemoteRoutingAddress" über einen passenden SendConnector zum Tenant geroutet wird und das Empfängerobjekt im Ziel auch diese Adresse als ProxyAddresses hat.

Das Feld "ProxyAddresses" in Exchange Online wird natürlich über ADSync anhand der lokalen Einstellungen konfiguriert und synchronisiert und das Feld "RemoteRoutingAddress" landet nicht in Exchange Online.

Kurzfassung

Für die eiligen Leser habe ich hier das Ergebnis vorweg genommen. Die Ergebnisse basieren auf Exchange 2016 CU23 und Exchange 2019 CU14. Ich würde es strenggenommen auch nicht als Fehler bezeichnen aber sie müssen beim Provisioning mit Enable-RemoteMailbox im Vergleich zu New-RemoteMailbox das leicht unterschiedliche Verhalten kennen um die Einstellung korrigieren zu können.

Szenario  EmailAddressPolicyEnabled ProxyAddresse Ergebnis 
New-RemoteMailbox `
   -Name `
   -Password `
   -UserPrincipalName

True 

OK

Wenn Sie mit New-RemoteMailbox einen neuen AD-Benutzer samt Exchange Online Postfach anlegen, dann generiert das Commandlet nicht nur eine korrekte RemoteRoutingAddress sondern addiert diese auch als Mailadresse in ProxyAddresses und damit ist das Mailrouting sichergestellt. Die primäre SMTP-Adresse wird aus den Empfängerrichtlinien abgeleitet.

 
New-RemoteMailbox `
   -Name `
   -Password `
   -UserPrincipalName `
   -PrimarySMTPAddress

False

OK

Wenn Sie mit New-RemoteMailbox einen neuen AD-Benutzer samt Exchange Online Postfach anlegen, dann generiert das Commandlet nicht nur eine korrekte RemoteRoutingAddress sondern addiert diese auch als Mailadresse in ProxyAddresses und damit ist das Mailrouting sichergestellt. Da ich hier aber die primäre SMTP-Adresse mit angegeben habe, wird die Anwendung der Empfängerrichtlinien abgeschaltet.

 
Enabe-RemoteMailbox
   -Identity  
   -RemoteroutingAddress

True 

OK 

Wird ein bestehendes AD-Konto als RemoteMailbox aktiviert, dann kann Enable-RemoteMailbox die RemoteRoutingAddres nicht korrekt selbst ermitteln (Bug?). Ich muss diese manuell angeben. Aber auch dann wird diese zu den ProxyAddresses addiert. Die primäre SMTP-Adresse wird aus den Empfängerrichtlinien abgeleitet.

 
New-RemoteMailbox `
   -Identity  
   -RemoteroutingAddress
   -PrimarySMTPAddress

False! 

FAIL 

Wenn ich aber einen bestehenden Benutzer mit einem Exchange Online Postfach versehe UND neben der Remote Routing Address auch die primäre Adresse vergebe, dann wird nicht nur die Anwendung der Empfängerrichtlinien unterbunden, sondern auch die Remoteroutingaddress nicht in die ProxyAddresses aufgenommen.

Es ist also genau ein Fall, bei dem die Neuanlage einer RemoteMailbox nicht in den ProxyAddresses landet und damit auch von ADSync nicht zu Exchange Online repliziert wird und eine Zustellung von Mails ggfls. unmöglich ist. Aus meiner Sicht ist dies ein Fehler, den sie aber über den richtigen Einsatz von Skripten vermeiden und beheben können.

Das "Problem" fällt zudem nicht auf, wenn Exchange Online zufällig eigenständig eine MOERA - Microsoft Online Email Routing Address vergibt, die zufällig mit ihrer RemoteRoutingAddress übereinstimmt. Wenn der MX-Record auf Exchange Online verweist, dann könnte der Fehler auch lange unbemerkt bleiben, weil kaum Mails über die Weiterleitung geroutet werden.

Bin ich betroffen?

Wenn Sie einmal schnell prüfen wollen, ob ihre Umgebung davon getroffen ist, dann können Sie in einer Exchange OnPremises Powershell folgende Befehle ausführen

# Wenn Sie mehrere Domains haben, sollte Exchange alle Domains des Forests durchsuchen
Set-ADServerSettings -Viewentireforest $true 

$problems = Get-RemoteMailbox -Resultsize unlimited `
            | foreach { 
                 if ($_.emailaddresses.smtpaddress -notcontains $_.remoteroutingaddress.smtpaddress){
                    $_
                 }
              }

$problems.count

Wenn ihr Aufruf ein "0" liefert, haben Sie keine "RemoteMailbox"-Objekte, die unvollständig provisioniert sind. Ansonsten können Sie mit der Liste dann die fehlenden Adressen nachprovisionieren.

$problems | foreach {`
   Write-Host "Add:$($_.remoteroutingaddress.smtpaddress)";  `
   Set-Remotemailbox `
      -Identity $_.distinguishedname `
      -EmailAddresses @{add=$_.remoteroutingaddress.smtpaddress} `
}

Denken Sie daran, dass die Änderungen erst einmal im lokalen Active Directory durchgeführt werden und nach erfolgter Replikation

New-ADUSer

Zuerst habe ich mit der regulären MMS für Benutzer und Computer ein Benutzerkonto angelegt. Das könnten Sie zwar auch mit "New-RemoteMailbox" auf einen Schlag machen, aber ich trenne gerne die Rollen "User Admin" von "Exchange Admin". Auch Microsoft hast das in Exchange Online und Teams umgesetzt. Das Anlegen von Identitäten sollte das Identity-Management machen. Die entsprechenden Felder habe ich mit LDIFDE exportiert:

dn: CN=RemoteMailbox1,OU=Regular Users,OU=Accounts,DC=UCLABOR,DC=DE
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: RemoteMailbox1
distinguishedName: 
 CN=RemoteMailbox1,OU=Regular Users,OU=Accounts,DC=UCLABOR,DC=DE
instanceType: 4
whenCreated: 20250217082959.0Z
whenChanged: 20250217082959.0Z
displayName: RemoteMailbox1
uSNCreated: 17290293
uSNChanged: 17290299
name: RemoteMailbox1
objectGUID:: B7R0bUUtDk2AUOuuWg8uGA==
userAccountControl: 512
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA0onT9XUf2TDF2PNaCQgAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: RemoteMailbox1
sAMAccountType: 805306368
userPrincipalName: RemoteMailbox1@UCLABOR.DE
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=UCLABOR,DC=DE
dSCorePropagationData: 16010101000000.0Z

Soweit ist hier alles noch in Ordnung und sollte niemand überraschen. Vermutlich haben Sie noch ein paar Felder mehr, wenn sie auch Vorname, Nachname, Straße und Gruppenmitgliedschaften etc. pflegen. Für meinen Testfall reicht dies aber aus.

Enable-RemoteMailbox

Den vorhandenen Benutzer konnte ich dann mit "Enable-RemoteMailbox" für ein Exchange Online Postfach aktivieren.

Enable-RemoteMailbox `
   -Identity remotemailbox1 `
   -Alias remotemailboxalias `
   -PrimarySmtpAddress remotemailbox1@uclabor.de `
   -RemoteRoutingAddress rmb1@msxfaqlab.mail.onmicrosoft.com `
   -ACLableSyncedObjectEnabled

Für Remote Mailbox sind natürlich einige Parameter wie "RemoteRoutingAddress" verpflichtend. Früher hat Microsoft wohl noch geschrieben, dass allein das Feld "Identity" relevant wäre und der Rest von Exchange selbst ermittelt würde. Dem ist aber nicht so, wie ein neuer User mit Enable-Mailbox liefert

Die Fehlermeldung sagt deutlich:

The address '@msxfaqlab.mail.onmicrosoft.com' is invalid: "@msxfaqlab.mail.onmicrosoft.com" isn't a valid SM
address. The domain name can't contain spaces and it has to have a prefix and a suffix, such as example.com.

Das Commandlet kann anhand der vorgefundenen Daten keine adäquate RemoteRoutingAddress festlegen. Allerdings erkennt Exchange OnPremises schon, dass  "msxfaqlab.mail.onmicrosoft.com" vermutlich die Zieldomain ist. Bei der Einrichtung des Hybrid Mode wurde die "Remote-Domain" mit der Option "TargetDeliveryDomain = True" angelegt.

[PS] C:\>Get-RemoteDomain | ft name,TargetDeliveryDomain

Name                                             TargetDeliveryDomain
----                                             --------------------
Default                                                         False
Hybrid Domain - msxfaqlab.mail.onmicrosoft.com                   True
Hybrid Domain - msxfaqlab.onmicrosoft.com                       False

Auch die Empfängerrichtlinien wurden erweitert.

[PS] C:\>Get-EmailAddressPolicy |fl RecipientFilter,enabled*

RecipientFilter                   : Alias -ne $null
EnabledPrimarySMTPAddressTemplate : %s.%g@UCLABOR.DE
EnabledEmailAddressTemplates      : {smtp:%1g%s@UCLABOR.DE,
                                     SMTP:%s.%g@UCLABOR.DE,
                                     smtp:%m@msxfaqlab.mail.onmicrosoft.com}

Das "%m" steht natürlich für den "Alias" und der ist bei dem User noch gar nicht gesetzt.

Ein weiterer LDIFDE-Export und Vergleich zeigt die neu hinzugekommenen und geänderten Felder.

uSNChanged: 17290307
proxyAddresses: SMTP:remotemailbox1@uclabor.de
showInAddressBook:
 CN=All Recipients(VLV),CN=All System Address Lists,CN=Address Lists Container,
 CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=UC
 LABOR,DC=DE
showInAddressBook:
 CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Co
 ntainer,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configurati
 on,DC=UCLABOR,DC=DE
showInAddressBook:
 CN=All Users,CN=All Address Lists,CN=Address Lists Container,CN=First Organiza
 tion,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=UCLABOR,DC=DE
legacyExchangeDN:
 /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Re
 cipients/cn=3b0d452e12f345b1bc06c184a5bee5d4-Remot
mail: remotemailbox1@uclabor.de
msExchUMDtmfMap: emailAddress:73668362452691
msExchUMDtmfMap: lastNameFirstName:73668362452691
msExchUMDtmfMap: firstNameLastName:73668362452691
msExchRecipientTypeDetails: 2147483648
mailNickname: remotemailboxalias
msExchRecipientDisplayType: -1073741818
msExchRemoteRecipientType: 1
msExchVersion: 88218628259840
targetAddress: SMTP:rmb1@msxfaqlab.mail.onmicrosoft.com
msExchPoliciesExcluded: {26491cfc-9e50-4857-861b-0cb8df22b5d7}

Hier sollten ihnen drei Dinge auffallen:

  • Korrekte "Targetaddress"
    Die Zieladresse für das Postfach ist das Exchange Online Postfach mit de passenden SMTP-Adresse
  • ProxyAddresses
    Hier stehen alle Mailadressen drin. Aktuell sehen sie aber, dass hier genau eine Adresse, nämlich die primäre SMTP-Adresse steht aber keine "onmicrosoft.com"-Adresse
  • "msExchPoliciesExcluded"
    Wer genau hingeschaut hat, sieht die letzte Zeile "msExchPoliciesExcluded: {26491cfc-9e50-4857-861b-0cb8df22b5d7}". Da ich die "PrimarySMTP-Address" von Hand angegeben habe, werden die Empfängerrichtlinien außer Kraft gesetzt!

Das wird in der weiteren Analyse von von Bedeutung sein.

New-RemoteMailbox

Interessanterweise funktioniert das mit "New-RemoteMailbox problemlos und ist dort auch dokumentiert:


Quelle: https://learn.microsoft.com/en-us/powershell/module/exchange/new-remotemailbox?view=exchange-ps  

Ein Test hat das bestätigt. Ich musste die Identität, das Kennwort und den UPN angeben.

Entsprechend wurde ein AD-Benutzer mit RemoteMailbox angelegt:

[PS] C:\>Get-RemoteMailbox test7@uclabor.de | fl remote*,alias,samaccountname,primarysmtpaddress,userprincipalname,emailaddresses,EmailAddressPolicyEnabled 

RemoteRoutingAddress      : SMTP:test7@msxfaqlab.mail.onmicrosoft.com
RemoteRecipientType       : ProvisionMailbox
Alias                     : test7
SamAccountName            : test7
PrimarySmtpAddress        : test7@UCLABOR.DE
UserPrincipalName         : test7@uclabor.de
EmailAddresses            : {SMTP:test7@UCLABOR.DE,
                            smtp:test7@msxfaqlab.mail.onmicrosoft.com}
EmailAddressPolicyEnabled : True

Diesen Testuser "Test7" betrachte ich aber nicht weiter.

ADSync

Mein "RemoteMailbox1"-Benutzer hat mittlerweile ADSync gesehen und zu Microsoft 365 repliziert. 

Auch hier sehen wir im Metaverse sowohl die "TargetAddress" als auch die "ProxyAdresses".

Entra ID

Ein Blick ins Entra ID zeigt aber eine etwas andere Information. Hier hat Exchange Online sich die Freiheit genommen, zwei weitere Adressen zu addieren, die im lokalen Active Directory nicht vorhanden sind.

Diese zusätzliche Adressen werden auch nicht aus Exchange Online ins lokale AD zurückgeschrieben.

Exchange Online

Auch ohne Exchange Online Lizenz hat der neue Benutzer nun 30 Tage ein Postfach und die entsprechenden Eigenschaften:

Hier sehen sie ebenfalls, dass das Feld "ProxyAddresses" nicht exakt dem Einsatz im lokalen Active Directory entspricht, sondern zusätzliche Einträge hat.

Exchange Online hat diesem Cloud-Postfach auch eine "<tenantname>.onmicrosoft.com"-Adresse basierend auf dem Alias verpasst, obwohl es in Exchange Online keine Empfängerrichtlinien gibt und diese Adresse im lokalen Active Directory nicht vorhanden ist. Sollten sie zufällig diese Adresse als RemoteRoutingAddress verwenden, funktioniert zufällig auch das Mailrouting.

Im lokalen Active Directory hat ein anderer Hintergrundprozess noch eine X.500-Adresse in der Zwischenzeit addiert, die aber keine weitere Bewandtnis hat.

Testmail

Nach meinen Verständnis habe ich aber durch die manuelle Anlage eines AD-Kontos mit nachträglicher Aktivierung mit "Enable-RemoteMailbox" ein Problem beim Mailrouting. Die RemoteRoutingadress verweist auf eine MOERA - Microsoft Online Email Routing Address, die in der Cloud vielleicht nicht hinterlegt ist. Also habe ich eine Testmail über den lokalen Exchange Server eingeliefert.

Sie wurde nicht zugestellt, da Exchange Online die Zieladresse nicht finden konnte und daher mit einem "550 5.4.1 Recipient addres rejected: Access denied." abgelehnt hat.

In meinem Fall ist das ja auch nachvollziehbar.

Ursache und Korrektur

Wir wissen nun um die Problematik, dass ein Provisioning im lokalen Active Directory eine Mailadresse als "RemoteRoutingAddress" angeben kann, die das Objekt in Exchange Online gar nicht hat. Sie können natürlich Glück haben, dass die Adresse in der Cloud anderweitig durch Exchange Online addiert wurde und daher die Zustellung erfolgreich ist. Darauf würde ich mich aber nicht verlassen und Support-Tickets, weil Mails nicht zugestellt wurden, vermeide ich lieber von vorneherein. Wir sollten also immer dafür sorgen, dass die SMTP-Adresse in "RemoteRoutingAddress" auch immer in dem Feld "ProxyAddresses" als sekundäre Adresse erscheint. Wir müssen in dem Fall mit "Enable-RemoteMailbox" dafür sorgen, dass die RemoteRoutingAddress auch in den ProxyAddresses enthalten ist. Sie können entweder die Liste vom Anfang als Input verwenden oder einfach versuchen die Adresse an alle Postfächer addieren.

Get-RemoteMailbox `
| foreach {`
   Write-Host "Add:$($_.remoteroutingaddress.smtpaddress)";  `
   Set-Remotemailbox `
      -Identity $_.distinguishedname `
      -EmailAddresses @{add=$_.remoteroutingaddress.smtpaddress} `
}

Wenn die Adresse schon vorhanden ist, gibt es einfach eine gelbe Warnung, dass das Objekt nicht geändert wurde. Eine Kontrolle danach zeigt, dass die fehlende Adresse addiert wurde.

Eine Testmail an "remotemailbox@uclabor.de" an den OnPremises Exchange Server wurde an die hinterlegte Mailadresse gesendet aber diesmal von Exchange Online akzeptiert.

Eine Kontrolle in Exchange Online zeigte, dass die Mail zugestellt wurde. 

Enable-MailUser

Enable-RemoteMailbox ist nur ein Commandlet, welches neben einer primären SMTP-Adresse auch eine externe Adresse benötigt. Die Anlage einer externen Mailbox mittels "Enable-MailUser" verhält sich genauso. Sobald ich mit "-PrimarySMTPAddress" eine eigene Adresse hinterlege, wird nur diese auch in die ProxyAddresses addiert. Die "ExternalRoutingAddress" fehlt.

Enable-MailUser mailuser1 -ExternalEmailAddress mailuser1@msxfaq.de -PrimarySmtpAddress mailuser1@msxfaq.com

get-MailUser mailuser1 |fl emailaddresses,EmailAddressPolicyEnabled

emailaddresses             : {SMTP:mailuser1@msxfaq.com}
EmailAddressPolicyEnabled  : False

Auch hier schaltet "PrimarySMTPAddress" die Empfängerrichtlinien ab. Das ist hier aber nicht schlimm, da Sie solche Objekte normalerweise nur für Empfänger außerhalb ihrer Umgebung verwenden und daher keine eingehende Mail an die ExternalRoutingaddress gesendet werden.

Zwischenstand

Ich habe diese Verhalten an Microsoft gemeldet aber bin nicht sicher, ob es überhaupt korrigiert wird. Der Fall dürfte eher selten auftreten und da es nur neue Postfächer betrifft, die dann am Anfang keine Mails empfangen können, ist der Schaden überschaubar. Administratoren sollten die Unstimmigkeit selbst schnell finden und beheben können. Es zeigt aber wieder, dass Sie alle Skripte und Lösungen auf ihre Funktion unter verschiedenen Konstellationen prüfen sollten und auch eine nachträglich Konsistenzprüfung der AD-Objekte und Exchange Empfänger von Vorteil sein kann.

Weitere Links