PrimarySMTPAdress und Recipientpolicies
Zuerst war es nur eine Unstimmigkeit im Exchange Control Panel zur Powershell aber sehr schnell hat sich dann gezeigt, dass ein besonderes Verhalten von Enable-RemoteMailbox und New-RemoteMailbox vorliegt und auch andere Commandlets bei der Angabe einer PrimarySMTPAddress im Hintergrund eine Einstellung hinsichtlich der Empfängerrichtlinien ändern, die für den ein oder anderen Administrator überraschend sein dürfte.
Auslöser
Auf das seltsame Verhalten bin ich bei Umsetzung eines Provisioning-Skripts bei einem Kunden aufmerksam geworden. Aus der Quelle bekomme ich die primäre Adresse, welche ich bitte beim Aktivieren eines Benutzer, Kontakts oder Gruppe auch setzen soll. Da der Kunde mittlerweile die meisten Postfächer in Exchange Online betreibt, lege ich über den Weg auch RemoteMailboxen mit "Enable-RemoteMailbox" an. Damit das alles "passt", nutze ich dazu folgenden Aufruf:
Enable-RemoteMailbox ` -Identity "rmb1" ` -PrimarySMTPAddress "rmb1@uclabor.de" ` -RemoteRoutingAddress "rmb1@msxfaqlab.mail.onmicrosoft.com
Wenn ich mir dann aber den Empfänger im lokalen Exchange Control Panel anschaue, dann wird die RemoteRoutingAddress nicht in den Eigenschaften entsprechend angezeigt:
Auch in den weitere E-Mail-Adressen wird nur die primäre Adresse angezeigt. Wenn ich aber per PowerShell mit das Objekt anzeigen lasse, dann passt die Einstellungen hinsichtlich der "RemoteRoutingAddress". Es ist also nur ein Anzeigefehler im ECP. (Getestet mit Exchange 2016 CU23)
[PS] C:\>Get-RemoteMailbox rmb1 | fl PrimarySMTPAddress,EmailAddresses,RemoteRoutingAddress,EMailAddressPolicyEnabled
PrimarySmtpAddress : rmb1@uclabor.de
EmailAddresses : {SMTP:rmb1@uclabor.de}
RemoteRoutingAddress : SMTP:rmb1@msxfaqlab.mail.onmicrosoft.com
EmailAddressPolicyEnabled : False
Das Objekt würde so also schon funktionieren.
Interessant ist, dass bei einem "New-RemoteMailbox" alle Werte korrekt gesetzt werden.
Dennoch ist es natürlich nicht in Ordnung, wenn eine Remote Mailbox nicht auch die "onmicrosoft.com"-Adresse als ProxyAddresse hat und würde ich als Konfigurationsfehler ansehen. Welche Objekte davon betroffen sind, können Sie recht einfach ermitteln.
Get-RemoteMailbox | where {$_.emailaddresses -like "*@*.onmicrosoft.com"}
Die Gegenprobe mit "-notlike" funktioniert aber nicht, denn das Feld ProxyAddresses enthält fast immer mehrere Mailadressen und da ist fast immer eine Adresse dabei, die nicht auf "onmicrosoft.com" endet. Nur die Suche mit "-like" liefert die Objekte, die keine solche Adresse haben. Sie können den Test aber auf RemoteMailbox-Objekte und die RemoteRoutingAddress machen.
#Dies funktioniert nicht, da RemoteRoutingAddress ein Array ist
Get-RemoteMailbox | where {$_.RemoteRoutingAddress -notlike "*@*.onmicrosoft.com"}
# So sollte es aber wieder gehen
Get-RemoteMailbox | where {!($_.RemoteRoutingAddress -notlike "*@*.onmicrosoft.com")}
Hier sollten keine Objekte erscheinen, die ein Postfach in ihrem Tenant haben. Eine RemoteMailbox verweist quasi immer auf ein Postfach in ihrem eigenen Tenant. Es kann ganz wenige Sonderfälle geben, bei denen eine RemoteMailbox wirklich in eine andere Exchange Umgebung verweist, z.B. in "Cross Tenant" und "Cross Org"-Topologien, die aber selten oder nur temporär während Migrationen sind.
er genau hinschaut, sieht aber auch noch eine zweite Einstellung: Die Anwendung von Empfängerrichtlinien ist deaktiviert. Ich habe diese Checkbox re aktiviert aber das hat das Problem nur teilweise gelöst:
Die Remote Mailbox hat zwar nun auch eine MOERA-Adresse als ProxyAddresse aber die RemoteRoutingAddress ist immer noch falsch. Aber diesmal ist es kein Anzeigefehler sondern ein rechter Konfigurationsfehler, denn auch in der PowerShell wird nun die primäre Adresse als "RemoteRoutingAddress" angezeigt.
[PS] C:\>Get-RemoteMailbox rmb1 | fl PrimarySMTPAddress,EmailAddresses,RemoteRoutingAddress,EMailAddressPolicyEnabled
PrimarySmtpAddress : rmb1@uclabor.de
EmailAddresses : {smtp:rmb1@msxfaqlab.mail.onmicrosoft.com, SMTP:rmb1@uclabor.de}
RemoteRoutingAddress : SMTP:rmb1@uclabor.de
EmailAddressPolicyEnabled : True
Zumindest das reaktivieren der Empfängerrichtlinie ist in dem Beispiel absolut kontraproduktiv.
Abhängigkeit "PrimarySMTPAddress"
Zuerst habe ich nun prüft, ob es nur das Feld "PrimarySMTPAddress" betrifft. In meinem Fall war das Provisioning des Kunden darauf ausgelegt, dass die HR-Abteilung die primäre Mailadresse sowohl beim Entry- als auch Exit-Prozess verwaltet. Daher musste ich das Feld mit angeben und durfte nicht auf die Empfängerrichtlinien vertrauen. Als Gegenprobe habe ich eine Remote Mailbox ohne den Parameter "PrimarySMTPAddress" provisioniert.
[PS] C:\>Enable-RemoteMailbox rmb3 -RemoteRoutingAddress rmb3@msxfaqlab.mail.onmicrosoft.com
Name RecipientTypeDetails RemoteRecipientType
---- -------------------- -------------------
rmb3 RemoteUserMailbox ProvisionMailbox
[PS] C:\>Get-RemoteMailbox rmb3 | fl PrimarySMTPAddress,EmailAddresses,RemoteRoutingAddress,EMailAddressPolicyEnabled
PrimarySmtpAddress : rmb3@UCLABOR.DE
EmailAddresses : {smtp:r@UCLABOR.DE, SMTP:rmb3@UCLABOR.DE, smtp:rmb3@msxfaqlab.mail.onmicrosoft.com}
RemoteRoutingAddress : SMTP:rmb3@msxfaqlab.mail.onmicrosoft.com
EmailAddressPolicyEnabled : True
Wenn ich das Feld "PrimarySMTPAddress" weglasse, dann ermittelt Exchange anhand der Empfängerrichtlinien die primäre SMTP-Adresse als auch die ProxyAddresses, setzt dann die RemoteRoutingAddress nach Vorgabe und lässt die Checkbox bei "EmailAddressPolicyEnabled" aktiv.
Als weiteren Test habe ich eine ganz neue RemoteMailbox über die Exchange PowerShell angelegt. Das ist natürlich eher selten, dass ein Exchange Administrator über diesen Weg auch zugleich ein AD-Objekt anlegt und mit dem Exchange Split Permission Model auch nicht möglich aber hier funktioniert alles:
New-RemoteMailbox rmb2 ` -RemoteRoutingAddress rmb2@msxfaqlab.mail.onmicrosoft.com ` -PrimarySmtpAddress rmb2@uclabor.de
Hier passt alles sowohl in der Exchange Control Panel als auch über die PowerShell:
[PS] C:\>Get-RemoteMailbox rmb2 | fl PrimarySMTPAddress,EmailAddresses,RemoteRoutingAddress,EMailAddressPolicyEnabled
PrimarySmtpAddress : rmb2@uclabor.de
EmailAddresses : {smtp:rmb2@msxfaqlab.mail.onmicrosoft.com, SMTP:rmb2@uclabor.de}
RemoteRoutingAddress : SMTP:rmb2@msxfaqlab.mail.onmicrosoft.com
EmailAddressPolicyEnabled : False
Ich würde daher postulieren, dass der Fehler nur in Verbindung mit einem "Enable-RemoteMailbox" und der Angabe einer PrimarySMTPAddress auftritt. Meine Neugier war geweckt und es gibt ja noch andere Objekte, die mit "Enable-*" aktiviert und mit einer RemoteRoutingAddress versehen werden können.
| Commandlet | Ausgaben | Bewertung |
|---|---|---|
Enable-MailUser |
Enable-MailUser ` -Identity mailuser1 ` -ExternalEmailAddress mailuser1@carius.de Name RecipientType ---- ------------- MailUser1 MailUser Get-mailuser mailuser1 `
| fl PrimarySMTPAddress,EmailAddresses,`
ExternalEmailAddress,EMailAddressPolicyEnabled
PrimarySmtpAddress : mailuser1@carius.de
EmailAddresses : {smtp:Mailuser1@msxfaqlab.mail.onmicrosoft.com,
smtp:Mailuser1@UCLABOR.DE,
SMTP:mailuser1@carius.de}
EmailAddressPolicyEnabled : True
ExternalEmailAddress : SMTP:mailuser1@carius.de
|
Hier gibt es den Parameter "RemoteRoutingAddress" nicht. Stattdessen muss ich mit "ExternalEmailAddress" arbeiten. Beim ersten Test habe ich aber das Feld "PrimarySMTPAddress" nicht genutzt. Sie sehen zwei Dinge:
Das ist so bei den meisten Firmen gerade nicht erwünscht. |
| Enable-MailUser +Primary Address |
Enable-MailUser ` -Identity mailuser2 ` -PrimarySmtpAddress mailuser2@carius.de ` -ExternalEmailAddress mailuser2@carius.de Name RecipientType ---- ------------- MailUser2 MailUser Get-mailuser mailuser2 `
| fl PrimarySMTPAddress,EmailAddresses,`
ExternalEmailAddress,EMailAddressPolicyEnabled
PrimarySmtpAddress : mailuser2@carius.de
EmailAddresses : {SMTP:mailuser2@carius.de}
EmailAddressPolicyEnabled : False
ExternalEmailAddress : SMTP:mailuser2@carius.de
|
Ich habe daher den gleichen Aufruf noch einmal mit der Angabe einer PrimarySMTPAddress gestartet. Das Ergebnis unterscheidet sich grundlegend: Die ProxyAddresses haben keine zusätzlichen Adressen bekommen und die Anwendung von Empfängerrichtlinien ist deaktiviert. So sollte es aus meiner Sicht eigentlich immer sein. |
Enable-MailContact |
[PS] C:\>Enable-Mailcontact `
-Identity mailkontakt `
-ExternalEmailAddress mailcontact@carius.de
Name Alias RecipientType
---- ----- -------------
MailKontakt MailKontakt MailContact
[PS] C:\>Get-mailcontact mailkontakt `
| fl PrimarySMTPAddress,EmailAddresses,`
RemoteRoutingAddress,EMailAddressPolicyEnabled, `
ExternalEmailAddress
PrimarySmtpAddress : mailcontact@carius.de
EmailAddresses : {smtp:MailKontakt@msxfaqlab.mail.onmicrosoft.com,
smtp:MailKontakt@UCLABOR.DE,
SMTP:mailcontact@carius.de}
EmailAddressPolicyEnabled : True
ExternalEmailAddress : SMTP:mailcontact@carius.de
|
Ein Mailkontakt muss zwingend eine "ExternalEmailAddress haben. Alle anderen Felder sind optional. Ohne die Angabe einer "PrimarySMTPAddress" werden die Empfängerrichtlinien angewendet, was nicht immer sinnvoll ist, da damit eventuell ein Konflikt mit zukünftigen Adressen besteht. |
| Enable-MailContact +Primary Address |
[PS] C:\>Eenable-Mailcontact `
-Identity mailkontakt `
-ExternalEmailAddress mailcontact@carius.de `
-PrimarySmtpAddress mailco
ntact@carius.de
Name Alias RecipientType
---- ----- -------------
MailKontakt MailKontakt MailContact
[PS] C:\>Get-Mailcontact mailkontakt `
| fl PrimarySMTPAddress,EmailAddresses,`
RemoteRoutingAddress,EMailAddressPolicyEnabled,`
Externalemailaddress
PrimarySmtpAddress : mailcontact@carius.de
EmailAddresses : {SMTP:mailcontact@carius.de}
EmailAddressPolicyEnabled : False
ExternalEmailAddress : SMTP:mailcontact@carius.de
|
Wenn ich zusätzlich wieder eine "PrimarySMTPAddress" angebe, dann wird die Anwendung der Empfängerrichtlinien wieder deaktiviert. |
Die Wirkung von "PrimarySMTPAdress" ist in allen Fällen quasi identisch: Sie setzen damit nicht nur die primäre SMTP-Adresse sondern die deaktivieren auch direkt die Anwendung von Empfängerrichtlinien. Das ist von Microsoft auch entsprechend dokumentiert z.B.
If you use the PrimarySmtpAddress parameter to specify the primary email address,
the command sets the EmailAddressPolicyEnabled property of the mail contact to
False, which means the email addresses of the mail contact aren't automatically
updated by email address policies.
https://learn.microsoft.com/en-us/powershell/module/exchange/enable-mailcontact?view=exchange-ps#-primarysmtpaddress
Nicht folgen kann ich aber der Empfehlung im nächsten Satz:
We recommend that you don't set the primary email address to a value other than
the ExternalEmailAddress unless you're in a cross-forest scenario.
https://learn.microsoft.com/en-us/powershell/module/exchange/enable-mailcontact?view=exchange-ps#-primarysmtpaddress
Ich würde den Parameter "PrimarySMTPAddress" immer für alle Objekte nutzen, deren Zielpostfach nicht in meinen AcceptedDomains liegt, d.h. extern und draußen sind. Umgekehrt würde ich den Parameter "PrimarySMTPAddress" nie für eine eigene Mailbox oder RemoteMailbox nutzen, weil ich hier genau will, dass die Empfängerrichtlinie auch alle weiteren Adressen vergibt. Wenn ich hier von der Empfängerrichtlinie abweichende Adressen nutzen muss, dann muss ich mir auch selbst Gedanken über alle anderen ProxyAddresses machen.
Sie könnten z.B. eigene Empfängerrichtlinien für MailUser und MailContacts anlegen, um Konflikte mit ihrer primären SMTP-Domain zu verhindern
Dies ist für MailUser und MailContacts sogar erwünscht oder sollte sogar erzwungen werden, damit solche Objekte keine internen Mailadressen bekommen und als Weiterleiter verwenden werden können. Prüfen Sie dies z.B. mit ihren Accepted Domains
Get-MailContact `
| where { `
$_.emailaddresses -like "*@*.onmicrosoft.com" `
-or $_.emailaddresses -like "*@*.uclabor.de"`
}
Mit folgender Auswertung finden Sie nach Empfängerdetails die Anzahl der Objekte, welche anhand der Empfängerrichtlinien verwaltet werden und welche die Checkbox nicht haben. Ich baue dazu einfach die beiden Felder zu einem String zusammen:
Get-Recipient -ResultSize unlimited `
| group {"$($_.recipienttypedetails)-$($_.EmailAddressPolicyEnabled)"} `
-NoElement `
| ft -AutoSize
Im Idealfall sind alle Empfänger außer MailUser/MailContacts über Empfängerrichtlinien verwaltet. Wenn es dann natürlich so aussieht, dann haben Sie etwas Arbeit vor sich:
Count Name
----- ----
1237 MailContact-False
2032 UserMailbox-False
101 UserMailbox-True
7403 RemoteUserMailbox-False
10 RemoteUserMailbox-True
996 MailUser-False
13 MailUser-True
1 DiscoveryMailbox-False
3 MailUser-True
6936 MailUniversalSecurityGroup-False
1192 MailUniversalSecurityGroup-True
21 MailContact-True
4 RoomList-False
380 RoomMailbox-False
94 RemoteRoomMailbox-False
78 MailUniversalDistributionGroup-False
32 MailUniversalDistributionGroup-True
520 SharedMailbox-False
165 SharedMailbox-True
2881 RemoteSharedMailbox-False
52 RemoteEquipmentMailbox-False
29 EquipmentMailbox-False
Hier sind schon sehr unterschiedliche Konfigurationen am Start. Aber bitte reaktivieren Sie nun nicht auf allen Empfänger einfach die Empfängerrichtlinien. Das kann zu unerwarteten neue primären Mailadressen für Bestandspostfächer führen. Sie sollten auf jeden Fall vorher die aktuellen Adressen einmal sichern oder direkt per Skript vorher die Informationen sichern, dann die Richtlinien aktivieren und danach die Werte erneut prüfen.
Mehrstufiges Provisioning
Sie wissen nun, dass die Angabe von "PrimarySMTPAddress" die Empfängerrichtlinien anpasst. Nur aus Neugier habe ich dann mal zwei Schritte kombiniert.
- Enable-RemoteMailbox ohne
PrimarySMTPAddress
Dann sollte das Objekt ganz einfach die regulären ProxyAddresses und ExternalRoutingAddress bekommen. - Set-RemoteMailbox nur mit
PrimarySMTPAddress
Im zweiten Schritt wollte ich dann die primäre Adresse abweichend setzen.
Am Anfang sah es noch gut aus und das Setzen der gleichen PrimarySMTPAddress hat auch nichts geändert:
Aber eine abweichende PrimarySMTPAdress konnte ich nur setzen, wen ich explizit auch die Anwendung der Empfängerrichtlinien abgeschaltet habe.
Über den Weg können Sie aber schon zuerst den Empfänger anhand der Empfängerrichtlinien anlegen lassen und nachträglich dann eine abweichende Konfiguration anwenden:
Tipp: Speichern Sie sich die Rückgabe des ersten "Enable-*"-Befehls ab. Das Property "OriginatingServer" enthält den Domain Controller, auf dem das Objekt angelegt wurde. Dieses sollten Sie bei nachfolgenden "Set-*"-Commandlets als Parameter "DomainController" mit übergeben, damit Sie immer den gleichen DC nutzen und nicht von AD-Replikationen abhängig sind.
Lerneffekt
Die Funktion des Parameters "PrimarySMTPAddress" ist von Microsoft gut dokumentiert aber viele Administratoren doch nicht in der gesamten Tragweise bekannt.
- MailUser/MailContact
Wird hier beim Aktivieren keine Zieladresse als PrimarySMTPAddress sondern nur als "ExternalEmailAddress" mitgegeben, dann bleiben die Empfängerrichtlinien aktiv und auch diese Objekte bekommen ggfls. Mailadressen aus ihrer Firmendomain und blockieren ggfls. eine eigene Nutzung - RemoteMailbox
Wenn Sie hier eine PrimarySMTPAddress mitgeben, dann werden auch die Empfängerrichtlinien umgangen. Der Empfänger hat zwar ihre PrimarySMTPAddress auch als ProxyAddresses und ist erreichbar, aber er bekommt keine "onmicrosoft.com"-Adresse, was später eine Koexistenz und Migration zu Exchange Online stört. - PrimarySMTPAddress und
EmailAddressPolicyEnabled:$false
Wenn Sie eine abweichende Mailadresse mit "Set-*" setzen wollen, müssen Sie die Empfängerrichtlinien für das Objekt abschalten.
Aus meiner Sicht sollten Sie den Parameter "PrimarySMTPAddress" nur in Verbindung mit MailUser/MailContact verwenden aber nie mit anderen Exchange Empfängern. Besonders herausfordernd wird es, wenn Sie später z.B. im Rahmen einer Neustrukturierung, Umbenennung etc. die SMTP-Domains über die Empfängerrichtlinien anpassen und sich wundern, dass die wichtigen Objekte nicht aktualisiert wurden und andere Objekte überflüssigerweise aktualisiert wurden.
Haben Sie auf jeden Fall einen Blick auf die MOERA-Adresse für Exchange Online. Der Hybrid Configuration Wizard erweitert die "Default Empfängerrichtlinie" entsprechend aber diese Änderung kommt nur bei den Objekten an, bei denen "EmailAddressPolicyEnabled: True" aktiv ist. Alle anderen bekommt keine onmicrosoft.com-Adresse.
