MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Cloud ProxyAddresses

Die Bedeutung des Felds "ProxyAddresses" im lokalen Active Directory sollten zumindest die meisten Exchange Administratoren auswendig kennen. Aber mit Blick auf die Cloud gibt es noch die ein oder andere Überraschung zu entdecken.

Beachten Sie dazu auch die Seite ADSync und MailUser.

Beachten Sie, dass das Feld "ProxyAddresses" sowohl in Entra ID als auch in Exchange Online vorhanden ist aber es zwei getrennte Fehler sind, die durch einen Entra ID Provisioning-Service verwaltet werden. Der Inhalt ist nicht immer identisch! 

Microsoft Quellen

Zuerst habe ich eine sehr umfangreiche Quelle von Microsoft gefunden:

The proxyAddresses attribute in Active Directory is a multi-value property that can contain various known address entries. For example, it can contain SMTP addresses, X500 addresses, SIP addresses, and so on. When an object is synchronized to Azure AD, the values that are specified in the proxyAddresses attribute in Active Directory are compared with Azure AD rules, and then the proxyAddresses attribute is populated in Azure AD. Therefore, the values of the proxyAddresses attribute for the object in Active Directory may not be the same as the values of the proxyAddresses attribute in Azure AD.
Quelle: How the proxyAddresses attribute is populated in Azure AD https://docs.Microsoft.com/en-us/troubleshoot/azure/active-directory/proxyaddresses-attribute-populate

Damit könnte die Seite schon wieder zu Ende sein. Aber auch wenn die Quelle sogar noch einige Fragen und deren Antworten liefert, gibt es weitere Details

The proxyAddresses attribute in Active Directory is a multi-value property that can contain various known address entries. For example, it can contain SMTP addresses, X500 addresses, and SIP addresses. When an object is synchronized to Microsoft Entra ID, the values that are specified in the mail or proxyAddresses attribute in Active Directory are copied to a shadow mail or proxyAddresses attribute in Microsoft Entra ID. Then, they are used to calculate the final proxyAddresses of the object in Microsoft Entra according to internal Microsoft Entra ID rules. The logic that populates mail, mailNickName, and proxyAddresses attributes in Microsoft Entra ID is called proxy calculation.
How the proxyAddresses attribute is populated in Microsoft Entra ID https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/user-prov-sync/proxyaddresses-attribute-populate#summary

Then, you remove the Exchange Online license and the following operation is performed as a result of proxy calculation:

- Remove the primary SMTP address in the proxyAddresses attribute corresponding to the UPN value.
- Promote the MOERA from secondary to Primary SMTP address in the proxyAddresses attribute.
- Update the mail attribute by using the primary SMTP address in the proxyAddresses attribute(MOERA).

How the proxyAddresses attribute is populated in Microsoft Entra ID
https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/user-prov-sync/proxyaddresses-attribute-populate#scenario-4-exchange-online-license-is-removed

mail and proxyAddresses are both email-related properties. The proxyAddresses property is a collection of addresses only relevant to the Microsoft Exchange server. It's used to store a list of mail addresses for a user that are tied to a single mailbox. The mail property is used as the user's email address for various purposes including user sign-in and defines the primary proxy address.
Both mail and proxyAddresses can be retrieved through the GET user API. You can update the mail via the Update user API, but can't update proxyAddresses through Microsoft Graph. When a user's mail property is updated, it triggers recalculation of proxyAddresses and the newly updated mail is set to be the primary proxy address, except in the following scenarios .....
user resource type - Microsoft Graph v1.0 https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0#mail-and-proxyaddresses-properties

ProxyAddresses an mehreren Orten

Das Feld "ProxyAddresses" ist für die Zustellung von Mails in Exchange OnPremises und Online maßgeblich. Die Felder "mail" und "MailNickName" sind eigentlich unwichtig und auch der UPN ist eigentlich losgelöst. Mit Exchange Online, Entra ID und Entra ID Connect wird das Feld aber in weitere Verzeichnisse synchronisiert und ab da wird es interessant, denn nicht alle Inhalte sind überall vorhanden. Das habe ich auf Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr schon beschrieben. Für die ProxyAddresses bedeutet dies, dass der Entra ID Identity Service die Felder beschreibt und je nach Objekt die Informationen aus anderen Feldern befüllt werden.

Knifflig wird das Bild, wenn wir wirklich ermitteln wollen, welche Instanz "autoritativ" ist. Wenn wir Entra ID Sync mal weg lassen, dann kann ich z.B. einen Benutzer in Entra ID als "Cloud Only"-User anlegen. Er bekommt dann einen UPN und aus dem UserPart wird das Feld "MailNickName" erstellt. ProxyAddresses erscheinen hier aber erst einmal nicht, zumindest solange ich noch keine Lizenzen zugewiesen habe.

Ich kann sogar in Entra ID das Feld "Mail" füllen und damit dem Benutzer eine Mailadresse zuweisen und Microsoft überträgt dieses sogar in das Feld "ProxyAddresses" in Entra ID. Die Adresse kann sogar aus einer anderen Domain sein, die nicht im Tenant hinterlegt ist. In Exchange Online erscheinen diese Adresse erst einmal nicht. Ich kann eine einmal so gesetzte Mailadresse nicht mehr leeren!. Dann behauptet Entra ID, dass das Feld in der Verwaltung von Exchange Online ist.

Wenn ich dem Benutzer dann eine Exchange Lizenz verpasse, dann kann ich auch in Exchange Online Verzeichnis ProxyAddressen sehen und ein einem CloudOnly-Postfach sogar ändern. Mit der Lizenz löscht aber Exchange z.B. die Mail-Adressen mit Domains aus den ProxyAddresses, die nicht im Tenant registriert sind.

Weitere ProxyAddresses kommen durch SharePoint Online und Teams in Form von "SPO:" und "SIP:"-Adressen hinzu, die Exchange aber nicht beeinträchtigen.

Das Verhalten ändert sich wieder, wenn die Identitäten aus dem lokalen AD mit Entra ID Sync provisioniert werden. Dann gewinnen die lokalen Proxy-Addresse, Mail, MailNickname, UPN, wenn die Domains auch im Tenant registriert sind. Erst mit Aktivierung von IsExchangeCloudManaged kann ich die ProxyAddresses wieder direkt in Exchange Online verwalten und mittels WriteBack sogar ins lokale Active Directory zurückschreiben lassen.

Anzeige

Ich starte einfach mit einem Microsoft 365 Tenant, in dem ein Benutzer mit einer Microsoft 365 E3-Lizenz versehen ist. Er hat damit nicht nur ein Exchange Postfach sondern auch Teams, OneDrive und anderen Dienste.

Ich habe die Teste auch mit einem Benutzer nachvollzogen, der nur eine Exchange Online P1-Lizenz hatte und kein OneDrive/SharePoint oder Teams. Es wurden dennoch SPO und SIP-Adressen angelegt.

Ich kann über zwei Admin-Portale und zwei PowerShell-Module die ProxyAddresses anzeigen. Aber schon da finde ich ersten interessanten Unterschiede:

  • Exchange Admin Portal
    Ein Mailbox-Benutzer in der Cloud muss natürlich Exchange Lizenz haben, so dass ich ihn im Exchange Admin Portal auch sehen und editieren könnte. das gilt nicht für Kontakte oder On-Premises Mailboxen.
  • Exchange PowerShell
    Es sollte nicht weiter verwundern, dass auch die Exchange Online PowerShell die gleichen Daten liefert:
PS C:\> Get-Mailbox aduser2 | fl identity,emailaddresses

Identity       : ADUser2
EmailAddresses : {SMTP:ADUser2@carius.onmicrosoft.com, smtp:ADUser2@carius.de,
                 SIP:df30efefafe7421ab577e3be83171d1eaduser2@carius.de,
                 SPO:SPO_9962499f-eb60-4c27-9402-cd438f673854@SPO_eef62a09-7718-4063-82db-d7582dc8916f}
  • Azure Admin Portal
    Die ProxyAdressen sind beim Benutzer "ReadOnly" und nur zum Teil sichtbar. Ich sehe nur die SMTP-Adressen und die sind auch noch "ReadOnly"

    Die SIP-Adresse ist nicht bei den Proxyaddres sichtbar sondern bei IM-Address
  • Entra ID PowerShell
    Hier sehe ich auch nur die SMTP-Adressen, die mir das Portal liefert.
PS C:\> Get-Entra IDUser -SearchString aduser2 | fl userprincipalname,proxy*

UserPrincipalName : ADUser2@carius.de
ProxyAddresses    : {smtp:ADUser2@carius.de, SMTP:ADUser2@carius.onmicrosoft.com}

Hier halten wir schon einmal fest, dass das Entra ID für diese Feld nicht autoritativ ist, sondern Exchange Online den Inhalt bestimmt. Zudem sind die Werte für SIP und SPO schon einmal sehr zufällig.

Der Benutzer ADUser2 hatte zu dem Zeitpunkt nur eine Exchange Online Plan1 Lizenz aus einem Teams Exploratory License aber weder eine Skype for Business Lizenz, noch Teams Lizenz noch OneDrive.

Dennoch hat die Cloud auch SIP und SPO-Adressen addiert.

Adresstypen

Die meisten Administratoren werden die Prefixe SMTP und "smtp" kennen. Auch SIP und SPO sind nun bekannt, Aber es gibt durchaus weitere Einträge die auch in der Cloud vorkommen können.

Beachten Sie, dass Einträge durchaus mehrfach vorkommen können aber nur ein Eintrag darf "GROSS" geschrieben sein. Das ist die primäre Adresse, mit der eine ausgehende Kommunikation gestartet wird. Es gibt Einträge wie z.B. .SIP, die nur genau einmal vorkommen dürfen.

Prefix Multivalue Bedeutung

SMTP

Ja

Diese Feld enthält alle Mailadressen, unter denen ein Anwender erreichbar ist. Die Werte müssen eindeutig sein, d.h. es darf diese nicht doppelt geben.

Bei einer Zeile muss das Prefix "Uppercase" sein, damit Exchange Online weiß, welche Quelladresse er nutzen soll.

Postfächer können nur Adressen mit im Tenant registrierten Domains haben. Nur MailContacts und MailUser können auch externe Adressen bekommen.

SPO

Nein

Diese Adresse ist wohl der Anker zur SharePoint Identität.

SIP

Nein

Die Adresse wurde Anfangs nur durch Skype for Business genutzt, damit Outlook und der SfB Client zueinander gefunden haben. Für das SIP-Routing war On-Premises schon immer das Feld "msRTCSIP-PrimaryUserAddress" maßgeblich.

If the ProxyAddresses attribute contains a sip address, also update that value as a best practice. Although the sip address in ProxyAddresses is ignored by O365 if msRTCSIP-PrimaryUserAddress is populated, , it may be used by other On-Premises components.
Quelle: Decide how to manage attributes after decommissioning
https://docs.Microsoft.com/en-us/skypeforbusiness/hybrid/cloud-consolidation-managing-attributes#method-1---manage-sip-addresses-and-phone-numbers-for-users-in-active-directory

Auch wenn Sie heute kein Skype for Business Online mehr nutzen können (Siehe SfBOnline Ende), so ist die Adresse weiterhin wichtig für die Federation mit anderen Firmen oder der eigenen On-Premises-Umgebung.

X500

Ja

X.500 Adressen sind verkappte "LegacyExchangeDN"-Adressen, die früher zum Routing genutzt wurden. Über den Weg können alte Adressen weiterhin erreichbar bleiben, wenn Anwender in andere Exchange Umgebungen migriert werden. Schon durch die Migration von Exchange On-Premises zur Cloud erhalten Sie diese Adressen.

EUM

Ja

Diese Adressen sind meist "Altlasten" einer Exchange Unified Messaging-Konfiguration, die mit Exchange 2010-2016 nutzbar war. Mittlerweile sollten diese Adresse keine Funktion mehr haben.

JRNL

?

Bei einigen Objekten habe ich diesen Adresstyp gefunden. Der Inhalt war die Mailadresse des Benutzers. Ich vermute einen Zusammenhang mit Journalfunktionen.

Ich schreibe nicht, dass das alle Adresse-Typen gibt. On-Premises können Sie auch noch "MSMAIL:" ,"CCMAIL:", "GWISE", "FAX:" und andere Felder haben. Aber nicht alles, was ADSync ausliest und in die Cloud sendet, wird dort auch angenommen.

ADSync Merge

Ich habe mit einem Cloud-Objekt angefangen, welches durch ADSync verwaltet wird aber lokal keine Einträge im Feld "ProxyAddresses" hat. Das Objekt selbst wird aber durch den Entra ID Cloud Sync verwaltet. Wir haben auch schon beschrieben, dass ich das Feld nicht direkt im Entra ID schreiben kann aber die Verwaltung mit Exchange nur in Verbindung mit einer Lizenz möglich ist. Aber ich kann ja das Feld im lokalen AD setzen und den DirSync die Arbeit machen lassen:

Also habe ich mit ADSIEDIT die Felder gesetzt.

Achtung: Dies ist nicht der Regelfall. Wenn Sie Exchange On-Premises nutzen, dann sind diese Felder lokal schon gepflegt.

In meinem Beispiel addiere ich aber nun einfach eine eigene SIP-Adresse und weitere SMTP-Adressen und lasse mich überraschen, was passiert.

Nun musste ich nur den nächsten Lauf von Entra ID Cloud Sync abwarten und die Ergebnisse anschauen. Es gab erst einmal keine Warnungen oder Fehler in den Protokollen und im Entra ID sind folgende Adressen angekommen. Sie können sehen, dass nicht alle ProxyAddresses übertragen wurden sondern nur die SMTP-Adresse mit der carius.de-Domain. Sie wurde aber sogar als primäre Adresse gesetzt und die früher führende carius.onmicrosoft.com-Adresse wurde sekundär.

Die SIP, SPO oder MSXFAQ-Adresse wird aber im Entra ID nicht angezeigt oder eingetragen.

Wichtige Aussage: Exchange Online übernimmt für Benutzer mit einer Exchange Lizenz nur die Mailadressen, deren Domain auch im Tenant registriert ist. Das gilt nicht für Kontakte ohne Lizenz

Interessanter ist hier aber die Liste der Adressen im Exchange Online Directory. Wie Sie auf der Seite "Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr" lesen können, gibt es in der Cloud mehrere Verzeichnisdienste und für die ProxyAddresses ist nun mal Exchange Online zuständig.

Hier sehen Sie auch die geänderte primäre SMTP-Adresse aber zusätzlich wurde die SIP-Adresse ersetzt. Die alte kryptische SIP-Adresse ist verschwunden aber die SPO-Adresse wurde nicht überschrieben. Das lässt Rückschlüsse auf die Funktionsweise des Verzeichnisabgleichs und die Bedeutung der ProxyAddresses zu:

  • SMTP:
    Wenn aus dem lokalen AD eine neue primäre Adresse kommt, wird diese dominant. Allerdings werden nur Adressen übernommen, die im Tenant auch als gültige DNS-Domain registriert sind.
  • SIP
    Es kann anscheinend nur genau eine SIP-Adresse geben und ein Eintrag aus dem lokalen AD überstimmt die Cloud
  • SPO
    Die SharePoint-Adresse wird wohl nur in der Cloud verwaltet und kann nicht durch einen Eintrag im lokalen AD überstimmt werden
  • MSXFAQ und andere Custom Typen
    Werden in der Cloud einfach ignoriert.

Der Versuch, diese Werte in der Cloud mit der Exchange Online PowerShell manuell zu ändern wird natürlich durch den DirSync unterbunden.

ADSync kein Back-Sync

In meinem Testlab war nun nicht der ADSync im Einsatz sondern die Cloud-Variante und die schreibt aktuell keine Daten in das lokale AD zurück. Insofern wurden die neuen ProxyAddresses aus der Cloud nicht in das lokale AD zurückgeschrieben. Mit dem richtigen ADSync ist dies aber der Fall, wie ich auf ADSync Bidirektional schon beschrieben habe. ADSync schreibt nicht nur ein paar Felder zurück, die für die Spamfilterung relevant sind, sondern auch die ProxyAddresses.

Wenn Sie den klassischen ADSync nutzen, dann hängt es von der Einstellung "Exchange Hybrid" ab, was zurückrepliziert wird. Ohne aktivierte "Exchange Hybrid"-Einstellung ist es ein OneWay-Ticket, d.h. Proxy-Adressen aus der lokalen AD-Umgebung werden in die Cloud repliziert aber nicht zurück. Es kann durchaus passieren dass Microsoft 365 eine Benutzer in der Cloud zusätzliche Adressen vergibt, die dann nicht ins lokale AD zurück kommen. Auf der Seite ADSync und MailUser habe ich dazu einige Fälle gesehen, bei denen ein MailUser in der Cloud zusätzliche Adressen bekommen hat, die aber nur partiell ins lokale AD geschrieben wurden, Hier nur ein Auszug

On-Premises Entra ID

Ich habe bei der Neuanlage nur den MailUser angelegt. ADSync hat den Kontakt im Entra ID und Exchange Online angelegt. Die Microsoft Cloud hat aber selbständig drei weitere Adressen addiert. Bei der nächsten ADSync-Replikation wurde aber NUR die X500-Adresse in das lokale AD übertragen. Schon beim Export aus der Cloud mit ADSync kommen die zusätzlichen SMTP-Adressen eines MailUser nicht mit.

Wichtig: Diese Verhalten unterscheidet sich von dem Verhalten bei Postfächern (Mailbox/RemoteMailbox). Dort werden auch SMTP-Adressen übertragen

ADSync Remove

Natürlich habe ich dann im lokalen AD das Feld "Proxy-Adresse" wieder geleert und etwas gewartet. Im Entra ID Auditlog für das Konto ADUser2 habe ich dann die Änderungen gesehen:

Das Leeren des Felds ProxyAddresses im lokalen AD hat in der Cloud nicht alle Felder entfernt. Die vorher hinzugefügte primäre On-Premises-Adresse wurde entfernt aber nun wurde nicht mehr die carius.onmicrosoft.com-Adresse wieder hergestellt, sondern die Adresse der carius.de-Domain. Das sehe ich auch in der PowerShell.

PS C:\> Get-Entra IDUser -SearchString aduser2 | fl userprincipalname,proxy*

UserPrincipalName : ADUser2@carius.de
ProxyAddresses    : {SMTP:ADUser2@carius.de, smtp:ADUser2@carius.onmicrosoft.com}
PS C:\> Get-Mailbox aduser2 | fl identity,emailaddresses

Identity       : ADUser2
EmailAddresses : {SIP:df30efefafe7421ab577e3be83171d1eaduser2onprem@carius.de, SMTP:ADUser2@carius.de,
                 smtp:ADUser2@carius.onmicrosoft.com,
                 SPO:SPO_9962499f-eb60-4c27-9402-cd438f673854@SPO_eef62a09-7718-4063-82db-d7582dc8916f}

ADSync und MailUser

Auch beim Einsatz von MailUsern gibt es einige besondere Effekte, die ich aber auf der eigenen Seite ADSync und MailUser beschrieben habe.

Orphaned ProxyAddress mit CloudOnly

Wenn Sie eine Domain von einem Tenant entfernen wollen, dann müssen Sie bei allen Benutzern, Gruppen und Apps den Verweis auf die Domain entfernen. Im wesentlichen bedeutet dies, dass Sie die primäre Mailadresse und den UPN auf eine andere Domain umstellen müssen. Vor dem Entfernen der Domain muss aber auch jede Mailadresse aus den ProxyAddresses entfernt werden.

Sofern die Objekte aus dem lokalen AD mit Entra ID Sync repliziert werden, müssen Sie die Änderungen im lokalen AD vornehmen und die Replikation starten. Anders sieht es aber aus, wenn es sich um "Cloud Only"-User handelt. Wenn die Objekte eine Exchange Mailbox haben, dann können Sie die Adresse einfach mit der Exchange Online PowerShell entfernen. Hier ein Beispiel:

param (
    $domaintoremove = "msxfaq.net"
)

Write-Host "Removing proxy addresses for domain $domaintoremove"

get-mailbox -Filter "EmailAddresses -like '*@stud.th-owl.de'" -resultsize unlimited | ForEach-Object {
    Write-Host "Processing mailbox $($_.PrimarySmtpAddress)"
    foreach ($address in $_.EmailAddresses) {
        if ($address -like "smtp:*@$($domaintoremove)") {
            Write-Host "Removing email address $address from mailbox $($_.PrimarySmtpAddress)"
            Set-Mailbox -Identity $_.PrimarySmtpAddress -EmailAddresses @{Remove=$address}
        }
    }
}

Was machen Sie aber, wenn das Postfach keine Exchange Lizenz hat aber in Entra ID dennoch die Domain hinterlegt ist. Dann können Sie die Domain nicht aus dem Tenant entfernen. Ich kann nur das Feld "Mail" setzen, was dann eine Neuberechnung antriggert:

When a user's mail property is updated, it triggers recalculation of proxyAddresses and the newly updated mail is set to be the primary proxy address
user resource type - Microsoft Graph v1.0 https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0#mail-and-proxyaddresses-properties

Nur wenn der Benutzer eine Exchange Lizenz hat, werden Mailadressen aus Domains entfernt, die nicht im Tenant registriert sind. Bei Gästen werden keine ProxyAddresses gesetzt oder gelöscht. Für CloudOnly-User gilt dies aber nicht. Ich habe folgende Schritte vorgenommen:

Schritt Aktion Ergebnis

1

Anlegen eines CloudOnly Users

UPN=CloudUser3@msxfaq.net
Keine Exchange Lizenz

Der Benutzer ist in Entra ID als MemberUser und folgenden Eigenschaften zu sehen. Der UserPart des UPN wird zum MailNickName

UPN            = CloudUser3@msxfaq.net
MailNickname   = CloudUser3
Mail           = <Leer>
OtherMail      = <Leer>
ProxyAddresses = <leer>

2

Addieren von MAIL

Ich habe dann dem User in Entra ID eine abweichende Mailadresse gegeben. Das ist bei der Nutzung von AlternateLoginID durchaus üblich. Zudem habe ich noch OtherMail gefüllt.

mail     = CloudUser3A@msxfaq.net
OtherMail= CloudUser3B@msxfaq.net

Sobald ich das Feld "Mail" pflege, wir auch ProxyAddresses gefüllt.

UPN            = CloudUser3@msxfaq.net
Mail           = CloudUser3A@msxfaq.net
OtherMail      = CloudUser3B@msxfaq.net
ProxyAddresses = smtp:CloudUser3@msxfaq.net 
ProxyAddresses = SMTP:CloudUser3A@msxfaq.net

Aber nur die Werte aus Mail und UPN werden übertragen. OtherMail blieb außen vor. Testweise habe ich auch mal eine Mailadresse aus einer Domain genutzt, die nicht im Tenant war. Auch diese wurde in Proxy Addresses übertragen.

Ich kann auch das Feld ändern 

 

 

 

3

Mail entfernen

Dann wollte ich das Feld Mail wieder löschen, um zu sehen, was mit ProxyAddresses passiert.

Interessant war, dass ich das Feld gar nicht leeren konnte.

Copilot meinte dazu: "The error you're encountering, "Invalid value specified for property 'mail' of resource 'User'," occurs because the mail attribute is not directly updatable through Microsoft Entra user provisioning in certain scenarios. This attribute is managed by Microsoft Exchange Online."

Das ist ein Stück weit komisch, da der Benutzer gar kein Exchange Online Postfach oder Lizenz hatte. Das ist aber by Design:

4

Mail ändern

Ich kann zwar das Feld "Mail" nicht leeren aber ich kann es tatsächlich ändern 

mail     = CloudUser3C@msxfaq.net 

 

Die neue Mailadresse wurde als neue primäre Proxy-Adresse addiert aber die vorherigen Adressen wurden beibehalten.

UPN            = CloudUser3@msxfaq.net
Mail           = CloudUser3C@msxfaq.net
OtherMail      = CloudUser3B@msxfaq.net
ProxyAddresses = smtp:CloudUser3@msxfaq.net 
ProxyAddresses = smtp:CloudUser3A@msxfaq.net
ProxyAddresses = SMTP:CloudUser3C@msxfaq.net

Ich kann also sehr wohl eine Adresse im Feld "mail" ändern aber nicht löschen.

5

Exchange Lizenz zuweisen

Um nun die Felder über die Exchange OnlinePowerShell oder das Exchange Admin Center zu bearbeiten musste ich eine Lizenz zuweisen.

Die Lizenz hat direkten Einfluss auf die ProxyAddresses. Das Feld wurde komplett anhand des Werts in "Mail" errechnet und frühere Proxy-Adressen sind entfallen:

UPN            = CloudUser3@msxfaq.net
Mail           = CloudUser3C@msxfaq.net
OtherMail      = CloudUser3B@msxfaq.net
ProxyAddresses = SMTP:CloudUser3C@msxfaq.net

Auch Adressen mit Domains, die nicht im Tenant definiert sind, wurden entfernt. In meinem Beispiel wurde aber keine MOERA-Adresse in der Entra ID-Anzeige addiert. Im Exchange Admin Center waren andere ProxyAddresses zu sehen

EXO:ProxyAddresses = SMTP:CloudUser3C@msxfaq.net
EXO:ProxyAddresses = smtp:CloudUser3@msxfaq.net
EXO:ProxyAddresses = SIP:CloudUser3@msxfaq.net

Hier wurde der UPN als "smtp" und "sip"-Adresse addiert 

6 

Entra ID Mail-Attribut ändern 

Ich habe nun beim Cloud User das Feld  "Mail" in Entra ID zu ändern.

mail     = CloudUser3D@msxfaq.net 

Löschen kann ich das Feld aber nciht 

Entra ID hat die Änderung angenommen und auch in die ProxyAddresses in Entra ID geschrieben.

UPN            = CloudUser3@msxfaq.net
Mail           = CloudUser3C@msxfaq.net
OtherMail      = CloudUser3B@msxfaq.net
ProxyAddresses = SMTP:CloudUser3D@msxfaq.net 
ProxyAddresses = smtp:CloudUser3C@msxfaq.net 

Mit etwas Verzögerung wurden in Exchange Online  die Adressen übernommen aber die vorherige Adresse entfernt

EXO:ProxyAddresses = SMTP:CloudUser3D@msxfaq.net
EXO:ProxyAddresses = smtp:CloudUser3@msxfaq.net
EXO:ProxyAddresses = SIP:CloudUser3@msxfaq.net

Die SIUP-Adresse erscheint nicht in Entra ID.

7 

Exchange Lizenz entfernen

Danach habe ich erst einmal wieder die Exchange Lizenz entfernt. Ich wollte wissen, wie sich das auf die ProxyAddresses auswirkt

 

Es hat einige Minuten gedauert, bis die Lizenzänderung in Exchange Online angekommen ist und die Postfächer verschwunden sind. In Exchange Online konnte ich dann keine ProxyAddresses mehr sehen. Im Entra ID sind nur die beiden Adressen zum UPN und MAIL verblieben.

ProxyAddresses = SMTP:CloudUser3D@msxfaq.net
ProxyAddresses = smtp:CloudUser3@msxfaq.net

Alle anderen Adressen wurden entfernt.

Es ist schon interessant, dass ich das Feld "mail" einmalig per Entra ID setzen, aber dann nie wieder ohne Hilfe von Exchange löschen kann. Einen Benutzer kann ich aber nur dann in Exchange Online Verwalten, wenn er auch eine Mailbox hat. Einen Kontakt kann ich nachträglich nicht daraus machen. Nur mit Entra ID Sync und einem lokalen Active Directory gelten andere Einstellungen.

Bewertung

Das Feld "ProxyAddresses" hat nicht nur in Exchange On-Premises sondern auch in der Cloud eine besondere Bedeutung. Der Inhalt ist, warum auch immer, nur teilweise im Entra ID vorhanden und dort generell nicht änderbar. Die einzige editierbare Instanz in der Cloud ist das Exchange Online Verzeichnis. Objekte, die aber durch ADSync / AADConnect oder Entra ID Cloud Sync von einem lokalen Active Directory abgeglichen werden, sind für den Cloud Admin aber Read-Only. Das hindert die Cloud selbst aber nicht daran, das Feld ebenfalls zu ändern. Diese Daten werden aber nicht ins lokale AD zurückgeschrieben.

So bekommen jeder Cloud-Anwender auch immer eine SIP und SPO-Adresse, selbst wenn er keine Lizenz für Skype for Business oder SharePoint bekommen hat. Zumindest die SIP-Adresse wird durch ADSync überschrieben, wenn es im lokalen AD einen passenden Eintrag gibt. Von der SPO-Adresse sollten Sie als Administrator aber die Finger weg lassen. Die wichtigste Funktion ist allerdings weiterhin, dass Exchange Online eingehende Mails anhand der SMTP-Adresse zustellen kann.

Weitere Links