Doppelpostfach mit Exchange Online

Wer Exchange Online ohne passende Provisionierung verwendet, hat sehr schnell zwei Postfächer, die er wieder zusammenführen muss. Diese Seite beschreibt, wie man es falsch macht und danach wieder heilt.

Beachten Sie dazu auch die Seiten Exchange Online Provisioning, ADSync mit Ex Online Only und ADSync mit Exchange und Doppelkonto Azure vs. Microsoft

Ausgangssituation

Meine Testumgebung sieht ziemlich genau so aus, wie die meisten Kunde ihre Umgebung betreiben.

  • Lokales Active Directory mit Exchange Schema
  • Lokaler Exchange Server mit Postfächern
  • ADSync mit Exchange Hybrid
    d.h. die Benutzer und Verteiler werden in den Office 365 Tenant repliziert
  • Exchange Online Service aktiviert und Lizenzen vorhanden

Nun schauen wir, was beim Anlegen eines neuen Benutzers so schief gehen kann.

Neues AD-Konto angelegt

Zuerst wird klassische ein Anwender im lokalen AD angelegt. Ich mache das hier mal mit AD-Users und Computers.

Noch hat der Benutzer kein Postfach o.ä. und bekommt auch erst noch mal keines. An das Exchange Team ist aber eine Mail gegangen, dass Sie doch bitte den Benutzer mit einem Postfach versehen. Das ist aber kein Automatismus und dauert etc.

ADSync triggert

Das hindert aber ADSync nicht daran, den Benutzer schon mal in Office 365 anzulegen. Entsprechend finde ich im ADSync-Log den Import aus dem lokalen AD ins Metaverse:

Folgende Felder werden übernommen:

Und beim Export in die Cloud wird der Benutzer angelegt:

Folgende Felder werden dabei in die Cloud exportiert:

Es sind also durchaus ein paar Felder mehr, als importiert werden. Bei nächsten Lauf wird ADSync aber aus der Cloud auch einige Daten wieder importieren und in das lokale Active Directory importieren.

ADSync ist also nicht nur unidirektional.

Cloudbenutzer + Lizenz = Postfach

Der Benutzer soll natürlich auch Cloud-Dienste wie Teams etc. nutzen und bekommt daher eine Office 365 E3 Lizenz. Das kann ein Administrator von Hand machen oder sie nutzen die Funktion der automatischen Lizenzierung. Er hat auf jeden Fall eine Lizenz.

Die Cloud macht nun, was sie mit einem Benutzer anstellt, der einen Lizenz für Exchange Online bekommt aber von OnPremies keine entsprechenden LDAP-Felder mitbekommen hat. Exchange Online geht davon aus, dass der Kunde vielleicht On-Premises kein Exchange hat und verpasst dem Anwender eine Mailbox:

Office 365 nutze dazu auch einfach den UPN als "primäre Mailadresse" und alle Cloud-Anwender können da Postfach umgehend sehen und sogar Mails dorthin senden. Früher konnte sich der Anwender aber nicht anmelden, da Autodiscover ja noch auf den On-Premises-Server verweist und der kennt den Benutzer noch nicht. Mittlerweile ist Outlook aber schlauer und versucht bei einem Fehler der Verbindung zu einen On-Premises-Server immer noch mal eine Anfragen gegen Office 365. Also kann der Anwender arbeiten.

ADSync Rückreplikation

ADSync bemerkt natürlich die neuen Änderungen in der Cloud und wenn ADSync auf für Exchange Hybrid eingerichtet ist, dann repliziert er auch einige Felder in das lokale AD zurück. Auch das ist im Synchronisationsstatus zu sehen. Im Vergleich zur vorherigen Rückreplikation aus Office 365 ins Metaverse sind nun einige weitere Felder hinzu gekommen:

Die haben aber nicht alle etwas mit Exchange zu tun, denn die Cloud hat anscheinend einige weitere Felder in Office 365 angelegt, die nun ins Metaverse kommen. Im lokalen Active Directory kommt nur der CloudLegacyExchangeDN in Form einer Proxy-Adresse an.

Sie könnten also hellhörig werden, wenn ein lokales AD-Objekte plötzlich eine Proxy-Adresse ohne Mailnickname/Alias hat. Eigentlich "darf" es das ja so nicht geben. Per LDAP ist das schnell zu finden.

(&(proxyaddresses=*)(!mailnickname=*))

In meinem Test-Tenant habe ich damit zuverlässig alle CloudOnly-Postfächer in meinem lokalen AD identifizieren können. Das geht natürlich nur, solange ADSync korrekt arbeitet und die On-Premises-Felder auch füllen kann.

On-Premises Postfach

Mittlerweile ist auch der Exchange Administrator bei dem Ticket angekommen und aktiviert den Benutzer für ein Postfach. Würde der Administrator nun ein "Enable-RemoteMailbox" ausführen, dann wäre die Welt in Ordnung, da ADSync als autoritative Instanz die On-Premises-Felder wie Mails, ProxyAddresses etc. in die Cloud repliziert und bestehende Felder überschreibt bzw. erweitert.

Ein Fehler ist es, wenn der Exchange Admin ein "New-Mailbox" ausführt. Dann hat der Anwender eine Mailbox "On-Premises".  Beim nächsten Sync-Lauf importiert ADSync die neuen Exchange Properties in das Metaverse. Es kommen eine MailAdresse und einige "msExch*"-Felder dazu:

Dann werden munter die Daten im Metaverse verarbeitet und am Ende in die Cloud übertragen.

Die Daten werden sogar ohne Fehler in die Cloud repliziert, d.h. es gibt keine Komponente, die aufgrund des bestehenden Konflikts Alarm schlägt

Konflikt

Wenn Sie bis jetzt aber aufgepasst haben, dann sollten Sie das Problem erkannt haben.

  • Exchange Online Postfach
    Durch die Anlage des Benutzers mit ADSync und der Zuweisung einer Lizenz hat der Anwender ein "Exchange Online-Postfach" bekommen
  • On-Premises
    Aber auch auf dem lokalen Exchange Server gibt es ein Postfach mit der identischen Mailadresse.

Der Benutzer hat ein "Split Postfach", welches auch von beiden Seiten erreicht werden kann. Mails, die zuerst von einem beliebigen On-Premises-Server geroutet werden, landen im lokalen Postfach während alle Mails von Absendern in Exchange Online landen im Online-Postfach. Dies ist natürlich kein dauerhafter Zustand und sie sollten das Problem möglichst schnell beseitigen.

Das Problem kann auch auftreten, wenn andere Prozess ähnliche Probleme verursachen, z.B. Filter in ADSync, damit Objekte nicht abgeglichen werden oder eine fehlende Aktivierung des Exchange Hybrid Mode in ADSync. ich hatte es auch schon, dass im Piloten Benutzer manuell im Ziel angelegt und mit einem Postfach versehen wurden und dann mit der Einrichtung von ADSync ein Matching erfolgte. Auch hier bleiben dann zwei Postfächer bestehen.

Ich habe mit dem Skript Compare-GAL eine Möglichkeit geschaffen, mit der sie das globale Adressbuch einer Hybrid-Umgebung prüfen können. Hier sollten dann Dubletten aber auch fehlende Postfächer auffallen. Microsoft hat mittlerweile selbst eine Beschreibung erstellt. Dennoch

Lösungsschritte

Die Lösung besteht darin, ein Postfach aufzulösen, so dass nur ein Postfach übrig bleibt. Einfach "Löschen" ist aber eine schlechte Idee denn es könnte ja noch wichtige Mails darin sein, die der Anwender noch haben möchte. Ein einfacher Export vor dem Löschen greift aber auch zu kurze, da während des Exports ebenfalls weitere Mails einkommen könnten.

Sie müssen zuerst überlegen, welches Postfach denn das "überlebende Postfach" bleiben soll. In der Regel nutzt man das länger existente Postfach, wenn das zusätzliche Postfach sehr jung ist. Dann ist die zu migrierende Datenmenge geringer.

  • Verbleibendes Postfach "eindeutig" erreichbar machen
    Das Postfach, welches bestehen bleibt, muss auch aus der anderen Welt erreichbar sein. Das kann also nicht die SMTP-Adresse sein, die auch das zu löschende Postfach hat. Wenn Sie ein On-Premises Postfach abschalten wollen, dann ist die "mail.<tenantname>onmicrosoft.com"-Adresse in der Cloud eine gute Umleitungsadresse. Wenn Sie die Cloud-Mailbox abschalten wollen, dann schauen Sie nach einer Domain oder Subdomain, die es nur On-Premises gibt
  • Weiterleitung einrichten (TargetAddress)
    Mit der eindeutigen Routingadresse zum verbleibenden Postfach können Sie nun in dem zu löschenden Postfach als Administrator eine Weiterleitung einrichten. So wird sichergestellt, dass zumindest keine neuen Mails mehr in dem doppelten Postfach ankommt. Sie können dies sowohl InPremises als auch in Exchange Online mit Set-Mailbox eintragen. Dieses Feld ist nicht durch ADSync gesperrt
PS C:\> Set-Mailbox <mamilboxid> -ForwardingSmtpAddress <zieladresse>
  • Export der Inhalte
    Ehe wir die Mailbox löschen, sollten wir vielleicht die darin enthaltenen Mails exportieren. Das kann der Anwender per Outlook in eine PST-Datei machen. Sie könnten natürlich auch als Administrator per eDiscovery durchführen. Denkbar ist auch ein Export mit 3rd Party Tools per EWS oder Graph.
  • LegacyExchangeDN aufschreiben
    Dieser Wert sollte später als X.500 Adresse in der verbleibenden Mailbox addiert werden, damit Mails und Termine weiter funktionieren.
  • Entfernen der Mailbox / Anlegen des Mailobjekts
    Im nächsten Schritt geht es dann um das Entfernen der Mailbox und dem Ersetzen durch ein Mailobjekt, welches die Weiterleitung zum richtigen Postfach enthält. Dieser Schritt ist pro Umgebung unterschiedlich.
  • Import der Inhalte
    Die aus dem doppelten Postfach exportierten Elemente können Sie jeder Zeit wieder in die vorhandene Mailbox importieren. Eine PST-Datei können Sie dem Anwender direkt zum Import bereitstellen.

Statt einem Export und Import über PST-Dateien o.ä. gibt es natürlich auch 3rd Party Tools. Siehe dazu auch 3rd-Party Migrationstools. Wenn das Zielpostfach in der Cloud ist, sie nur an Mails interessiert sind und die Quelle per IMAP4 erreichbar ist, dann könnte auch eine IMAP4 Migration mit Exchange Online funktionieren.

Primäre Cloud Mailbox

Ich habe mich dazu entschiede, die Cloud-Mailbox beizubehalten und die lokale Mailbox durch eine Remote-Mailbox zu ersetzen. Meine Schritte waren:

Aktion Check

Targetaddress

Das Setzen der TargetAddress ist bei Migrationen eine gut bekannte Lösung zur Weiterleitung von Mails. In diesem Fall setze ich beim lokalen Postfach diese Adresse auf die Exchange Online Adresse.

# Lokales AD
Set-ADUser `
   -Identity fctest6 `
   -Replace @{targetAddress=("fctest6@fcarius.mail.onmicrosoft.com")}

Verwechseln Sie die TargetAddress nicht mit dem Feld ForwardingSmtpAddress.

Inhalte sichern

Vor dem nächsten Schritt sollten Sie nun die Inhalte des lokalen Postfachs bei Bedarf exportiere. Das kann durch den Anwender selbst und Outlook erfolgen oder als Administrator mit

# Eventuell müssen Sie ihrem Administrator erst noch die Berechtigungen geben
New-ManagementRoleAssignment `
   -Role "Mailbox Import Export" `
   -User AdminUser

# Export der Mailbox in eine PST-Datei 
New-MailboxExportRequest `
   -Mailbox fctest6 `
   -FilePath \\servername\verzeichnis\fctest6.pst

 

Disable-Mailbox

Es gibt natürlich keinen passenden Befehl, um eine Mailbox mal so eben zu einer Remote-Mailbox umzustellen. Das macht ja eigentlich Exchange während der Migration eines Postfachs in die Cloud. Das geht aber nicht, da es schon ein Postfach in der Cloud gibt. Also bleibt nur die "Sicherung" einiger Informationen vor dem Entfernen.

# Sicherung ausgewählter alter Informationen
$oldmailbox= get-mailbox fctest6

# Löschen der lokalen Mailbox
Disable-Mailbox `
   -identity fctest6

Für den Fall, dass Sie nun unterbrechen, dann erkennt ADSync "erkennt" diese Löschung und repliziert die Löschung einiger Felder  in die Cloud. Das Postfach in der Cloud bleibt davon aber unberührt weiter bestehen. Sogar die ProxyAdresses in der Cloud bleiben weiterhin da.

PS C:\> (Get-Mailbox fctest6).emailaddresses
SMTP:fctest6@uclabor.de
smtp:fctest6@fcarius.mail.onmicrosoft.com
X500:/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=75212c67fda746b89f2d5e6c4cfc08b9-Doppe
SPO:SPO_d5bdc27a-f187-4f77-ab4c-fa519d3dcb40@SPO_3c6855ff-e39f-4d09-a473-33807598ce4b
smtp:fctest6@fcarius.onmicrosoft.com

Durch die Löschung werden allerdings sehr viele Felder geleert, z.B.

  • Mail
  • Mailnickname
  • ProxyAddresses
  • TargetAddress

Es bleiben aber auch einige Reste übrig oder werden gesetzt, z.B. wie "msExchPreviousrecipientTypeDetails", msExchRecipientSoftdeletedStatus, msExchUMDtfmap und msExchWhenMailboxCreated. Die sollen uns aber nicht weiter stören.

RemoteMaibox anlegen

Nun aktivieren wir das lokale AD-Konto als RemoteMailbox in der Cloud.

#Aktiveren als RemoteMailbox in der lokalen Exchange PowerShell
Enable-Remotemailbox `
   -identity fctest6 `
   -RemoteroutingAddress "fctest6@fcarius.mail.onmicrosoft.com"

Wenn der Benutzer weitere Mailadressen hatte, die nicht durch Empfängerrichtlinien addiert wurde, dann kann ich die nun noch ändern.

# Zusätzliche Adresse addieren in der lokalen Exchange PowerShell
Set-RemoteMailbox `
   -identity fctest6 `
   -Emailaddresses $oldmailbox.emailaddresses

Exchange Online GUID setzen

Bei einem Postfach, welches in die Cloud migriert wurde, enthält die lokale RemoteMailbox die Exchange Online GUID des Benutzers in der Cloud.

Dies ist nur dann wichtig, wenn Sie das Postfach wieder einmal aus der Cloud nach "On-Premises" migrieren wollen. Dann sollten Sie die GUID aus der Cloud auslesen und der remote-Mailbox zuweisen.

# Exchange Online PowerShell
(Get-Mailbox fctest6).exchangeguid.guid

Den Wert kann ich dann im lokalen Active Directory wieder hinterlegen.

# On-Premises Exchange PowerShell
Set-RemoteMailbox “user identity” -ExchangeGuid “Exchange Online guid”

Damit sind wir am Ende des "Durchlauf" angekommen, wie man ein Exchange Postfach falsch provisioniert, zu einem Doppelpostfach kommt und wie man das Problem dann wieder löst. Damit sollte ihre OnPremise Exchange Umgebung wieder glücklich sein und den Empfänger im Adressbuch sehen. Mails an den Empfänger gehen dann aber in die Mailbox in Exchange Online

Exchange Online Postfach entfernen

Wenn das On-Premises Postfach übrig bleiben soll, dann muss ich das Cloud Postfach entfernen. Aus meiner Sicht geht das nur über folgenden Trick:

Aktion Check

Targetaddress

Das Feld "Targetaddress" gibt es in der Art nicht und selbst wenn, wäre ADSync vermutlich dominant. Sie können aber eine Regel im Postfach anlegen, welche die Mails z.B. an das andere Postfach sendet. Bislang habe ich aber immer die Cloud-Mailbox einfach entfernt. Es sollte aber pber die ForwardingSmtpAddress möglich sein, die Mail zu dem On-Premises-Postfach zu senden.

Set-Mailbox `
   -Identtiy fctest6 `
   -ForwardingSmtpAddress "fctest6@uclabor.de"

Entfernen der Exchange Online Lizenz

Die Office 365 E3/E5 u.a. kann er gerne behalten, aber die Einzelkomponenten Exchange Plan 1/2 wird deaktiviert.

Achtung: ggfls. müssen Sie noch andere Lizenzen temporär entfernen

Damit "verschwindet" das Exchange Postfach in der Cloud. Es kann allerdings einige Zeit dauern, bis die Mailbox in der Cloud tatsächlich dann auch verschwindet. Diese "Änderung" in Exchange Online wird von ADSync auch bemerkt aber es wird nichts repliziert.

"Mailbox-Info" entfernen

Exchange Online löscht ein Postfach nicht sofort, wenn Sie die Lizenz entfernen, Es könnte ja "aus Versehen" passiert sein. Daher bleibt beim Benutzer immer noch die Information erhalten, dass er ein Postfach gehabt hat. Sobald Sie eine Lizenz innerhalb der 30 Tage "Grace-Period" wieder zuweisen, hat er sein "altes Postfach" wieder. Daher gibt es seit ca. 2018 eine Option diese Information am Benutzer zu entfernen.

Set-User `
   -identity <username> `
   -PermanentlyClearPreviousMailboxInfo

# Permanently Clear Previous Mailbox Info 
#https://techcommunity.microsoft.com/t5/exchange-team-blog/permanently-clear-previous-mailbox-info/ba-p/607619

Die Sicherheitsabfrage ist aber zumindest in der deutschen Übersetzung eher missverständlich.

Das Ziel dieser Aktion ist das Leeren der Felder "msExchMailboxGUID" und "msExchArchiveGUID" in der Cloud.

ADSync triggern und prüfen

Normalerweise sollte die Cloud nach dem Löschen des Postfachs alleine erkennen, dass der Benutzer nun dank der On-Premises-Eigenschaften ein Mail-Kontakt in Exchange Online ist. Bislang hat das bei mir auch immer funktioniert und ADSync muss dazu auch nicht weiter tun. Wenn sich das Problem aber nicht alleine löst, dann könnte ein voller Abgleich vielleicht helfen.

Start-ADSyncSchedule `
   -PolicyType Initial

Im lokalen AD hat sich ja nichts geändert aber wir wollen, dass die msExchMailboxGUID und msExchArchiveGUID in die Cloud übertragen wird. Nur dann "versteht" Exchange Online, dass der Benutzer ein lokales Postfach hat. Danach sollten Sie im Exchange Online Portal einen MailUser sehen.

Lizenz wieder zuweisen

Wenn das Postfach On-Premises liegt und sie eine normale Exchange User-CAL haben, braucht es streng genommen keine Cloud-Lizenz. Aber viele Firmen lizenzieren CALs schon über die Cloud und wollen vielleicht auch migrieren. Da der Benutzer in der Cloud nun aber ein "Kontakt" ist, wird Exchange Online keine Mailbox aktivieren, wenn ich eine Lizenz zuweise.

Zudem ist er dann gleich richtig provisioniert, wenn ich ihn später einmal in die Cloud migrieren.

Zusammenfassung

Wer beim Provisioning schludert und eine gewisse Reihenfolge nicht einhält, kann Situationen schaffen, die nicht funktionieren und sich auch nicht selbst wieder heilen. Die vorzeitige Zuweisung eines Exchange Online Plan an ein Cloud-Konto, dessen Exchange Properties nicht gleich mit repliziert wurden oder das nicht abgestimmte Vorgehen eines On-Premises-Admin führt sehr oft zu Situationen, deren Lösung aufwändig sein kann.

Weitere Links