ADSync und MailUser

ADSync spielt eine gewichtige Rolle mit Exchange Online, da alle Empfänger immer im lokalen AD verwaltet werden müssen (siehe ADSync mit Exchange und ADSync mit Exchange Online). Wenn Sie nun externe Mitarbeiter mit einem AD-Konto benötigen, deren Postfach aber nicht in ihrer Umgebung ist, dann legen sie aus Sicht von Exchange einen "MailUser" an. Ein AD-Benutzer mit einer externen Adresse. Diese Seite beschreibt die Besonderheiten mit Exchange Online.

Auf dieser Seite arbeite mich mit zwei MailUsern, um verschiedene Änderungen gegenüberzustellen. Achten Sie bei dem Vergleich von Bildern und Daten darauf, dass Sie die richtigen Objekte vergleichen.

MailUser anlegen

Ich habe in meinem Tenant "msxfaqlab.onmicrosoft.com", der auch die Domain "uclabor.de" hat, einen MailUser angelegt, der eine Mailadresse in der externen Domain "Carius.de" hatte. Ich will ja wissen, ob der Kontakt funktioniert. Da ich aber eine Hybrid-Umgebung habe, wurde der MailUser im lokalen AD angelegt. Die externe Adresse verweist an das externe Postfach und zudem hat es folgenden UPN und MailNickName (Alias).

UserPrincipalName: frank.carius.extern@uclabor.de
MailNickName     : frankcariusextern

Ich habe die Schreibweise absichtlich unterschiedlich gewählt. Die On-Premises EmailAddressPolicy hat folgende Bildungsregel:

Die "msxfaqlab.mail.onmicrosoft.com"-Adresse wurde bei der Einrichtung des Exchange Hybrid-Mode mit dem HCW - Hybrid Configuration Wizard angelegt. Damit bekommt der MailUser folgende ProxyAdressen.

Der MailNickName (Alias) wird als UserPart verwendet und der UPN ist nicht relevant.

MailUser im M365 Admin Center

Der lokale ADSync hat das Objekt bei der nächsten Replikation zur Cloud repliziert. Zuerst habe ich mir angeschaut, was in der Cloud angekommen ist. Der MailUser findet sich natürlich im Microsoft 365 Admin Center. Allerdings ist das Admin Center zumindest im März 2023 noch nicht soweit bei "Mail" zumindest die Kontakt-Eigenschaften des MailUsers anzuzeigen.

 

Anscheinend sind MailUser nicht so häufig im Gebrauch.

ADSync zu Exchange Online

Daher habe ich zuerst einmal die die Exchange Online PowerShell bemüht.

Wie erwartet ist aus dem lokalen MailUser auch in der Cloud ein MailUser mit der gleichen "ExternalEmailAddress" geworden. Allerdings müssen sie schon genau hinschauen, denn es gibt sehr wohl einen Unterschied zwischen On-Premises und Exchange Online. Die "uclabor.de"-Adresse in Exchange Online orientiert sich am UPN und nicht an der lokalen Adresse

Lokales AD      : smtp:FrankCariusExtern@msxfaqlab.mail.onmicrosoft.com
Exchange Online : smtp:Frank.Carius.Extern@msxfaqlab.mail.onmicrosoft.com

Bildungsregel onmicrosoft.com-Adresse

Ich wollte natürlich wissen, wie Exchange Online diese Adressen genau bildet und haben dazu einen zweiten MailUser im lokalen AD, der aber nur die externe Adresse als ProxyAddress hatte und MailNickName etc entsprechend angepasst wurde. Hier ein Auszug eines LDIFDE-Export:

In Exchange On-Premises wurde der Benutzer wie folgt angezeigt:

In der Exchange Online PowerShell sieht dieser User wie folgt aus:

Exchange Online hat zwar die primäre SMTP-ProxyAddress gleich gelassen, aber drei zusätzliche Adressen addiert:

  • <mailnickname>@<tenantname>.onmicrosoft.com
    Diese Adresse wir addiert, obwohl "EmailAddressPolicyEnabled" beim dem MailUser per Default auf "False" steht.
  • <upnuserpart>@<primäre Tenantdomain>
    Die Adresse entspricht dem UPN des Users in der Cloud. Anscheinend wird einfach der UPN immer als Mailadresse mit addiert
  • X500-Adresse
    Auch wenn angeblich LegacyExchangeDN und X.500 schon lange obsolet sein sollten, werden die Adressen immer noch angelegt.

Diese Adressen sehen wir bei dem Benutzer so auch im AzureAD

Obwohl aus dem lokalen AD nur die "@carius.de"-Adresse kommt, addiert die Cloud weitere Adressen dazu, die zum Teil vom UPN-UserPart als auch vom MailNickName erstellt werden.

Beachten Sie hier, dass in dem Tenant damit eine SMTP-Adresse einer nicht im Tenant registrierten Domain erscheint.

Blockade onmicrosoft.com-Adresse

Wenn Exchange Online eine "<tenantname>.onmicrosoft.com"-Adresse anhand des MailNickName erstellt, dann interessiert mich, ob alle andere Adresse durch ADSync vielleicht blockiert werden. Ich habe daher lokal weitere Adressen addiert:

ADSync hat die Erweiterung beim nächsten Lauf auch zum AzureAD gesendet:

Allerdings kommen diese Erweiterungen nicht in Exchange Online an.

Wir können festhalten:
MailUser in der Cloud bekommen nur die externe Adresse aus dem lokalen AD und zusätzliche "OnMIcrosoft.com"-Adressen werden nicht aus dem lokalen AD übernommen

Partielle Rückreplikation

Wir wissen nun, dass nicht alle ProxyAddresses aus dem lokalen AD übernommen werden und das die Cloud sich eigene ProxyAddresses erweitert. Aber auch in die Gegenrichtung kommt nicht alles mit. Wenn Sie ADSync ohne die Checkbox bei "Exchange Hybrid" betreiben, dann werden die ProxyAddresses nicht zurück repliziert. Mit dem Haken im Exchange Hybrid Mode ist es ein paar Felder mehr.

Dies von Microsoft 365 zusätzlichen vergebenen ProxyAdressen werden durch ADSync aber nur partiell zurück repliziert. Der LegacyExchangeDN von Exchange Online kommt als X.500 Adressen und Felder wie msds-consistencyguid zurück aber die SIP-Adresse wird nicht von der Cloud zum lokalen Active Directory repliziert.

Dies ist eine Momentaufnahme im März 2023 und natürlich kann Microsoft die Regeln im ADSync anpassen.

MailUser mit Lizenz?

Normalerweise hat ein MailUser niemals eine Exchange Online Lizenz. Aber die Realität zeigt, dass dies manchmal noch passiert oder sogar erforderlich sein kann.

  • Der reguläre Weg: RemoteMailbox
    Zur Anlage eines Exchange Online Postfachs in Verbindung mit ADSync starten Sie mit einer "RemoteMailbox" im lokalen AD. Exchange Online erstellt direkt ein Postfach und sie haben dann ca. 30 Tage Zeit, eine Lizenz zuzuweisen
  • Der "Small Business" Weg
    Wenn Sie ADSync nutzen aber kein lokales Exchange verwenden, dann können Sie einfach einen AD-Benutzer ohne jegliche Exchange Properties ins AzureAD repliziere und eine Exchange Lizenz zuweisen. Auch dann erstellt Exchange Online ein Postfach und nutzt den UPN als primäre Mailadresse. Sie können leider in Exchange Online keine weiteren Adressen verwalten aber mit einer Adresse geht das auch
  • Regulärer MailUser
    Ein lokal angelegter MailUser hat per Definition ein Postfach auf einer anderen Plattform und leitet die Mail über das Feld "ExternalEmailAddress" dorthin weiter. Diese Benutzer haben regulär kein Exchange Online Postfach.
  • Cross Tenant MailUser
    Es gibt aber einen Sonderfall, wenn Postfächer "Cross Tenant" migriert werden. In dem Fall müssen Sie im Ziel entsprechende MailUser vorbereiten, damit Exchange die Inhalte übertragen kann.

Also habe ich meine beiden Test Benutzer nun entsprechend mit einer Lizenz versehen. Vorher habe ich eine der Benutzer aber eine ExchangeGUID gegen, welche z.B. das Quellpostfach eines anderen Tenants sein könnte:

ADSync hat das Feld natürlich auch ins AzureAD übertragen. Erst dann haben ich beiden MailUser-Konten in der Cloud nur eine Exchange Online Plan2 Lizenz vergeben.

Eigentlich sollte nichts passieren, da die Benutzer nicht als "RemoteMailbox" sondern als MailUser konfiguriert ist. Das ist aber ein Irrglaube, denn Exchange Online verpasst auch dem ersten MailUser ohne Exchange GUID ein Postfach. Ich finde das Objekt gar nicht mehr mit der Mailadresse, unter der es vorher als MailUser zu finden war. Ich muss nun den UPN nutzen.

Und das, obwohl das primäre Objekt im lokalen Active Directory weiterhin ein MailUser mit einer TargetAdddress nach extern ist. Interessanter finde ich aber die Veränderungen bei den ProxyAddresses.

Mit der Office 365 E3-Lizenz ändert sich:

  • Alle On-Premises Proxy
    Bei einer Mailbox in der Cloud übernimmt Exchange online "fast" alle ProxyAddresses aus dem lokalen AD.
  • Neue Primäre SMTP-Adresse
    Vorher war es noch eine Adresse der Domain "<tenant>.onmicrosoft.com" und mit der Lizenz wurde es der UPN.
  • Neue SIP-Adresse
    Vermutlich durch Teams/Skype bzw. Exchange Cloud Voice Mail hat der Benutzer auch noch eine SIP-Adresse bekommen
  • Wegfall der TargetAddress
    Die Weiterleitungsadresse zur "carius.de"-Domain wird sowohl aus dem Feld "ExternalEmailAddress" als auch aus den ProxyAddresses" entfernt.

Die Änderungen wurden auch ins AzureAD zurückgeschrieben aber haben keinen Eintrag im Auditlog hinterlassen. Alle diese Änderungen wurden nicht in die lokale On-Premises Umgebung zurückgeschrieben.

Denken Sie aber an "kleinere" Firmen, die eine Lizenz zuweisen und kein Postfach erstellt würde. Die meisten Admins würden doch sagen, dass es sich um einen "Fehler" handelt. Insofern kann ich das Verhalten schon verstehen, das MailUser ohne ExchangeGUID in dem Fall zu einer Mailbox werden.

MailUser mit Lizenz und ExchangeGUID/ExchangeMailboxGUID

Ein andere Bild zeigt sich hingegen beim Benutzer mit einer ExchangeGUID (msexch-mailboxguid).

Folgende Änderungen kann ich erkennen:

  • Objekt bleibt Mailuser
    Es findet keine Konvertierung zu einer UserMailbox statt, was im Falle einer Cross Forest Migration natürlich erwünscht ist.
  • ExternalEmailAddress unverändert
    Auch die externe Mailadresse bleibt im Feld "ExternalEmailAddress" erhalten. So bleibt die Weiterleitung an das aktive Postfach erhalten, wo immer es auch ist
  • Zusätzliche Adresse in "@msxfaqlab.mail.onmicrosoft.com"
    Neben der einfachen "@msxfaqlab.onmicroosft.com"-Adresse kommt nun auch die Hybrid-Adresse dazu.

Hier verhält sich Exchange Online so, wie ich es auch für einen Benutzer ohne ExchangeGUID erwartet hätte.

Das Zuweisen einer ExchangeGUID ist keine Aktion, die jemand im Browser durchführt. Der Admin sollte hier schon wissen, was sein Ziel ist und sich nicht wundern, wenn eine Lizenzzuweisung nicht zu einem Postfach führt.

MailUser und SIP-Adresse

Ich habe dann zu dem Exchange Plan2 noch eine Skype for Business und Microsoft Teams-Lizenz addiert. Nach einigen Minuten hat das Provisioning im Backend dann auch eine SIP-Adresse in die ProxyAddresses addiert:

In meinem Fall wurde der UPN auch zur SIP-Adresse. Auch hier ist im AzureAD die SIP-Adresse nicht bei den ProxyAddresses sondern unter den IM-Adressen zu finden:

Auch ADSync bemerkt natürlich die Änderungen in der Cloud und importiert diese aus der Cloud ins Metaverse. Aber darauf werden keine weiteren Aktionen abgeleitet:

MailUser Lizenzfehler korrigieren

Es ist also ganz klar eine Fehlkonfiguration, wenn Sie einem lokalen MailUser ohne Exchange GUID eine Microsoft 365 eine Lizenz verpassen. Wenn ihr ihren Fehler bemerkt haben dann sollten Sie erst prüfen, ob wichtige Daten in dem Doppelpostfach mit Exchange Online zu sichern sind. Ich habe dann die Lizenz wieder entfernt. Kurze Zeit später konnte ich den irrtümlich zur Mailbox aufgewerteten Benutzer wieder unter seine früheren externen Adresse ansprechen:

Er war wieder ein MailUser mit der richtigen "ExternalEMailAddress" und auch die ExchangeGUID wurde auf "00000000-0000-0000-0000-000000000000" gestellt. All das funktionierte direkt ohne dass ich mit ADSync einen neuen Delta-Sync starten musste. Allerding sehen Sie hier auch, dass die ganzen ProxyAddresses noch vorhanden sind.

Eine solche "Altlast" könnte später daher durchaus noch einmal Probleme machen, wenn andere Konten diese belegten Adressen bekommen sollten.

Bereiniung der Inkonsistenz

Zuerst habe ich einen InitialLauf des ADSync gestartet, der aber keine Korrekturen vorgenommen hat. ADSync ignoriert einfach die ProxyAddresses in der Cloud, die Microsoft selbst addiert hat. Sie erscheinen auch nicht im Connector Space. Ich kann die Proxyaddresses aber auch nicht per PowerShell ändern:

Der Fehler "Microsoft.Exchange.Configuration.DualWrite.LocStrings.UnableToWriteToAadException" dürfte uns allen bekannt sein. Er sagt schlicht, dass diese Feld durch ADSync verwaltet wird, aber was hier leider nicht ganz stimmt.

Diese Meldung kommt auch, wenn sie in ADSync nicht die Checkbox bei "Exchange Hybrid-Mode" aktiviert haben. Die ProxyAddresses werden dennoch partiell synchronisiert.

Tipp: Bei einem MailUser ist es eigentlich kein Problem, das Konto neu synchronisieren zu lassen.

Ehe Sie den Weg eines Neuaufbaus des Benutzers einschlagen, sollten Sie folgende Dinge beachten:

  • Keine Daten
    Die Benutzer sollten keine Lizenz haben, so dass sichergestellt ist, dass Sie neben dem fehlenden Exchange Postfach nicht auch noch Daten in OneDrive oder anderen Stellen haben.
  • Federation, Gast u.a.
    Wenn der Benutzer schon mit seinem AzureAD-Konto z.B. Gast in einem anderen Tenant ist oder Teams Federation etc. nutzt, dann geht dies verloren
  • Mitgliedschaft in "Cloud Only"-Gruppen
    Die Mitgliedschaft in On-Premises-AD-Gruppen kann ADSync einfach wieder herstellen aber Mitgliedschaften in CloudOnly-Gruppen, z.B. Microsoft Groups oder Microsoft Teams müssen danach neu eingerichtet werden
  • Rollenberechtigungen
    Gleiches gilt für administrative Rollen im Tenant
  • "Deleted User"-Container
    Der Neuaufbau ist nur korrekt, wenn Sie nach der Löschung des Benutzers diesen auch im AzureAD aus dem "Deleted Users"-Container entfernen. Ansonsten ist die erneute Synchronisation kein Neuaufbau sondern ein Undelete.

Für die Lösung des Benutzers im Azure AD haben Sie eigentlich zwei Optionen, wobei Option 1 wohl am schnellsten geht.

Dazu gibt es zwei Optionen:

Option Beschreibung

Option1:Löschen im AzureAD und Neusync

Sie können über das AzureAD-Portal relativ problemlos die MailUser löschen:

Mit den nächsten Schritten sollten Sie aber schnell sein, denn ADSync wird diese Löschung beim nächsten Lauf erkennen und das Objekt wieder aus dem Papierkorb zurückholen.

Ich habe schon Fälle gehabt, bei denen ADSync sich hier verhaspelt hat und nicht alle ProxyAddresses neu importiert und geschrieben hat.

Option2: ADSyncStaging OU

Wenn ich ADSync einrichte, dann habe ich eigentlich immer eine "Staging"-OU, die nicht durch ADSync gelesen wird.

So kann ich dann einen Benutzer einfach in diese OU verschieben und warten, bis ADSync das Konto in der Cloud gelöscht hat.

Option2: RemoteMailbox

Wenn Sie aber tatsächlich ein Postfach in der Cloud für den bisherigen MailUser anlegen wollen, dann können Sie ohne Umschweife aus dem MailUser auch eine Remote Mailbox mit einer Zieladresse auf ihren Tenant machen.

Get-MailUser <username> `
| foreach {`
      Enable-Remotemailbox `
         -RemoteRoutingAddress "$($_.alias)@msxfaqlab.onmicroosft.com"}

Exchange Online vergibt nach meinem Betrachtungen eine "<tenantname>.onmicrosoft.com"-Adresse anhand des Mailnickname. Kontrollieren Sie dies aber vorher.

In beiden Fällen muss ich aber die gelöschten Konten im AzureAD auch noch aus dem AzureAD-Papierkorb entfernen, wenn ich keine 30 Tage warten will:

Beim lokalen AD-Objekt müssen Sie das Feld "MS-DS-ConsistencyGUID" nicht löschen. ADSync ignoriert es, wenn er kein passendes Objekt im Ziel findet und überschreibt es mit dem neuen SourceAnchor in der Cloud. Danach startet das Spiel mit ADSync erneut.

Zusammenfassung

Wer Personen mit externen Postfächern in seinem Tenant konfigurieren muss, kann problemlos lokale AD-Konten als MailUser mit einer externen Adresse anlegen und sogar zu Exchange Online replizieren lassen. Allerdings muss sicher gestellt sein, dass diese Konten niemals eine Exchange Online Lizenz bekommen. Wenn dies erforderlich ist, sollten Sie eine RemoteMailbox anlegen, die dann auch eine Lizenz benötigt.

Ein Sonderfall ist eine Cross Tenant Migration. Hier müssen Sie aber zuerst die ExchangeGUID und optional eine ArchivGUID setzen. Dann ist auch eine Zuweisung einer Exchange Online Lizenz nicht mehr schädlich sondern sogar erwünscht, damit die Anwender nach der Migration weiter arbeiten können. Übrigens können Sie aus einem MailUser mit "Enable-RemoteMailbox" auch problemlos eine legitimes Postfach daraus machen.

Weitere Links