EXO und MailboxGUID

Im Hybrid-Mode ist es wichtig, die MailboxGUID einer OnPremises Mailbox auch zu Exchange Online zu synchronisieren, damit EXO auch weiß, dass dieser Benutzer eine lokale Mailbox hat. Ansonsten kann es passieren, dass Exchange eine zweite Mailbox anlegt. (Siehe auch Doppelpostfach mit Exchange Online). Wenn Sie aber Postfächer direkt als "RemoteMailbox" anlegen, dann vergisst Exchange und ADSync aktuell etwas. Das stört spätestens bei der Rückreplikation. Hier gibt es die Details:

Der Fehler war im Feb 2020 noch nicht behoben. Aus meiner Sicht müssten die Commandlets "New-RemoteMailbox/Enable-RemoteMailbox" das fehlende Feld setzen. Ersatzweise könnte ADSync das Feld aus der Cloud in das lokale AD replizieren.

msExchMailboxGuid im AD

Bei Exchange OnPremises ist die MailboxGUID der Klebstoff, um das AD-Konto des Benutzers mit dem Postfach in der Postfachdatenbank zu verbinden. Siehe dazu auch msExchMailboxGUID bzw. MailboxGUID. Sie können den Inhalt einfach mit Get-ADUser oder Get-Mailbox auslesen.

PS C:\> get-aduser user1 -Properties msexchmailboxguid

DistinguishedName : CN=user1,OU=Abteilung,DC=msxfaq,DC=de
Enabled           : True
GivenName         : User1
msexchmailboxguid : {150, 78, 78, 3...}
Name              : User1
ObjectClass       : user
ObjectGUID        : 9cd53e78-9de4-4a9a-abc0-6062b56ac545
SamAccountName    : user1
SID               : S-1-5-21-11949449-30417519-71842111-9813
Surname           : Carius
UserPrincipalName : user1@msxfaq.de

Da die msexchmailboxguid ein Array mit 16 Bytes ist, ist die Ausgabe natürlich abgeschnitten. Mit der Exchange PowerShell finden Sie neben der MailboxGUID auch noch die ArchivGUID

[PS] C:\>get-mailbox user1 | fl *guid*

ExchangeGuid           : 034e4e96-4332-5abc-4b39-8e4776468178
MailboxContainerGuid   :
AggregatedMailboxGuids : {}
ArchiveGuid            : 00000000-0000-0000-0000-000000000000
DisabledArchiveGuid    : 00000000-0000-0000-0000-000000000000
Guid                   : 9cd5223a-9bb4-432a-abc0-6062ab45c545

Weitere Details habe ich auf anderen Seite schon beschrieben:

Unter "Weitere Links" gibt es Verweise auf andere Seite im Internet, die verschiedene Probleme.

MailboxGuid und Exchange Online

Auch in Exchange Online nutzt Microsoft den gleichen Code und so hat auch ein Postfach in Exchange Online eine MailboxGUID und einen passenden Benutzereintrag. Die Information können Sie recht einfach über die Exchange Online PowerShell auslesen.

PS C:\> get-mailbox fctest* | ft name,alias,database,exchangeGUID,archiveguid

Name    Alias   Database           ExchangeGuid                         ArchiveGuid
----    -----   --------           ------------                         -----------
fctest1 fctest1 NAMPR20DG007-db027 6ed75be1-04c3-459c-9c1f-d2ab8d93220e 00000000-0000-0000-0000-000000000000
fctest2 fctest2 NAMPR20DG219-db112 dd7dcb39-b12f-4673-a7ee-01f3f13a1935 00000000-0000-0000-0000-000000000000
fctest3 fctest3 NAMPR20DG047-db096 4b6a3d89-c1b3-43e6-a5ed-5c7ee6450ce9 00000000-0000-0000-0000-000000000000
fctest4 fctest4 NAMPR20DG129-db114 00c1bd6c-9278-4986-9371-544fb8c36f85 00000000-0000-0000-0000-000000000000
fctest5 fctest5 NAMPR20DG140-db096 175cba6b-2c76-4722-b358-57ab14b034ec 00000000-0000-0000-0000-000000000000
fctest6 fctest6 NAMPR20DG050-db096 265cbd56-b238-473f-8902-b4c9859ad3b1 00000000-0000-0000-0000-000000000000

Exchange Online unterscheidet sich also gar nicht so stark von Exchange OnPremises.

MailboxGuid und ADSync

Sobald aber Exchange im Hybrid-Mode genutzt wird, kommt ADSync als Abgleich eine wichtige Rolle zu. Alle Informationen über Postfächer in der lokalen Exchange Installation müssen durch ADSync auch zu Exchange Online übertragen werden. ADSync Version 1.4.32.0 (Nov 2019) hatte folgende "Synchronization Rules" für das Feld msExchMailboxGUID:

  • Inbound
    Auf dem lokalen AD wird das Feld in das Metaverse importiert, wenn es sich um einen "User" oder "InetOrgPerson" handelt.

    Sie sehen aber auch, das es kein "Inbound" von Exchange Online gibt. Das Feld ist unidirektional
  • Outbound
    Aus dem Metaverse wird das Feld dafür zu Exchange Online geschrieben aber nicht zurück ins lokale Active Directory

Diese Einstellung bestätigt die Aussage, dass eine MailboxGUID nicht von Exchange Online zurück in das lokale Active Directory repliziert wird.

Diese Verhalten kann "unerwartet" sein, wenn sie z.B. Exchange Online nutzen wollen und die Benutzer durch ADSync schon repliziert werden aber eine frühere unsauber entfernte Exchange Installation nicht die Felder bereinigt hat.

Hinweis: Wenn Sie Exchange lokal früher installiert und dann "geregelt" entfernt haben, kann es dennoch passieren, dass Reste im lokalen AD beim Benutzer übrig geblieben sind.

Wenn einer der Reste eine MailboxGUID bei einem AD-Konto ist, dann kann dieser Benutzer kein Exchange Postfach erhalten.

Lokale Alt-Installation mit msExchMailboxGUID verhindert Exchange Online Mailbox

Exchange Online nutzt nämlich die Existenz einer MailboxGUID als Kriterium, dass der Benutzer ein lokales Postfach hat und daher in Exchange Online keine weitere Mailbox angelegt wird. Nur wenn auch die anderen Exchange Felder wie z.B. msExchRecipientTypeDetails und msExchRemoteRecipientType gesetzt sind.

MailboxGUID und Remote Mailbox

Es gibt zwei Wege zur Neuanlage eines Postfach in einer Exchange Hybrid Umgebung:

  • Anlage als "UserMailbox" und Migration in die Cloud
    Dieser Weg ist natürlich nur möglich, wenn Sie lokal noch eine Exchange Mailboxdatenbank haben und er dauert länger, da auch die Migration etwas Zeit dauert. Dafür ist der Prozess ausgereift und auch viele 3rd Party Tools können die notwendigen Einstellungen korrekt umsetzen
  • Direktanlage als "RemoteMailbox"
    Sie können auch direkt ein Postfach in der Cloud anlegen, indem Sie im lokalen Exchange direkt eine "RemoteMailbox" anlegen.

Wenn sie den Weg über "Remote-Mailbox" nehmen, dann könnte aber eine lokale Ausgabe aller Remote-Mailboxen und deren GUID ein gemischtes Bild zeigen

[PS] C:\>Get-RemoteMailbox | ft exchangeguid,ArchiveGUID

ExchangeGuid                                                ArchiveGuid
------------                                                -----------
20fdff52-a2e1-46e5-8a4b-9356cb954b96                        f8646e03-1cd9-4d43-bb7d-3b1af0bd2516
2a3a17fa-1663-42ea-9b1d-00a5e70f3d28                        7d259658-d915-4362-88b6-6a7ad0083c85
f3a929af-8bb2-4d6f-9016-6892fddc4a40                        00000000-0000-0000-0000-000000000000
bed2778b-8e12-42c9-ab96-3c048415817e                        45ba5bd3-aac2-4c4b-ae79-be1e21fb310c
dfd9a676-e3ce-40a5-ac9a-8ce4139bdb06                        5666ed3c-b991-42f4-b7aa-6df20551b534
dfa5234a-892f-4263-88aa-b11e9a722de6                        66abb8f0-45db-4a20-a427-ae4854d1c3f9
d23b3ab0-637f-44d1-8509-e84886a61d53                        d0823f07-b849-4988-9439-78b76adc5fad
00000000-0000-0000-0000-000000000000                        00000000-0000-0000-0000-000000000000
00000000-0000-0000-0000-000000000000                        00000000-0000-0000-0000-000000000000
00000000-0000-0000-0000-000000000000                        00000000-0000-0000-0000-000000000000
00000000-0000-0000-0000-000000000000                        00000000-0000-0000-0000-000000000000
f1d3bc15-000d-44cc-87f0-3bdebe292439                        9fc50a4c-e380-4422-8814-4847e3e6233e
247208d0-66b1-4c7f-9f07-8c2e2142c2c8                        1715f52b-a5d8-4f0e-b116-2b6bbba8505c
dfd9a676-e3ce-40a5-ac9a-8ce4139bdb06                        5666ed3c-b991-42f4-b7aa-6df20551b534

Sie sehen hier einige Test-Postfächer mit einer Exchange GUID und einer ArchiveGUID aber sie sehen auch Postfächer die eine ArchiveGUID mit dem Wert "00000000-0000-0000-0000-000000000000" haben und es gibt sogar Postfächer deren ExchangeGUID nur "00000000-0000-0000-0000-000000000000" enthält. Hier sind also alle drei Optionen vorhanden.

  • Exchange Remote Mailbox in der Cloud mit Archiv, die migriert wurden
  • Exchange Remote Mailbox ohne Archiv oder ein Archiv, von dem Exchange OnPremises nichts weiß
  • Exchange Remote Mailbox, deren GUIDs die lokale Installation nicht kennt

Das Problem ist tatsächlich real, da das Commandlet "New-RemoteMailbox" auch Anfang 2020 bei der Konfiguration der Exchange Eigenschaften keine GUID vergibt. Das führt dann aber z.B. dazu, dass dieses Postfach nicht mehr aus Exchange Online zurück auf die OnPremises-Umgebung migriert werden kann. Dazu gibt es sogar eigens einen KB-Artikel

Der Artikel beschreibt aber auch, warum dies der Fall ist und wie Sie dies lösen können. Hier müssen wir dann zwei Fälle unterscheiden:

Fall Richtige Vorgehensweise

Neue RemoteMailbox anlegen

Es reicht hier nicht einfach ein "Enable-RemoteMailbox" oder "New-RemoteMailbox" zu machen. Sie müssen auch eine MailboxGUID mitgeben.

Enabled-RemoteMailbox <MailboxName>
Set-RemoteMailbox <MailboxName> -ExchangeGUID <GUID>

Unvollständige RemoteMailbox

Wie auch in meiner Umgebung gibt es sicher viele Firmen, in denen es lokale AD-Benutzer mit Postfach in der Cloud gibt, die aber keine ExchangeGUID lokal haben. Hier sollten Sie dann dafür sorgen, dass Sie die GUID aus der Cloud auslesen und lokal nachpflegen. Sie können dazu einfach die Postfächer in der Cloud mit "Get-Mailbox" in der Exchange Online PowerShell auslesen 

# Exchange Online PowerShell
Get-Mailbox * | select alias,exchangeGUID,archiveguid | export-csv guidliste.csv

Mit dieser Liste starten Sie dann eine lokale Exchange Powershell und setzen die Werte.

foreach ($entry in (import-csv guidliste.csv) {
   Write-Host "Processing $($entry.alias)  GUID $($entry.ExchangeGUID)
   Set-RemoteMailbox `
      -identity $entry.alias `
      -ExchangeGUID $entry.exchangeGUID `
      -ArchiveGUID $entry.archiveguid
}

Bitte prüfen Sie die Funktion erst mit wenigen Objekten.

Allerdings frage ich schon schon, warum Microsoft für Exchange 2010/2013/2016/2019 nicht schon lange ein Update für die "*-RemoteMaiilbox"-Commandlets ausgeliefert hat.

MailboxGUIDund Exchange Plan

Jede Exchange Online Mailbox braucht eine entsprechende Lizenz. Es gibt mehrere Konstellationen, bei denen z.B. eine MailboxGUID durch ADSync gefüllt ist oder geleert wird. Exchange Online legt z.B. kein Postfach für einen Benutzer an, der schon eine MailboxGUID hat. Folgende Verhalten habe ich beobachtet:

Benutzer MailboxGuid in der Cloud Exchange Lizenz Ergebnis

Kein Postfach

Leer

Keine

Benutzer hat kein Postfach in der Cloud

Kein Postfach

Leer

zugewiesen

Benutzer bekommt ein Exchange Online Postfach, welches aber OnPremises nicht sichtbar ist -> lokales Nachprovisionieren mit Enable-RemoteMailbox löst das.

OnPrem Postfach

nicht gefüllt durch ADSync

keine

Benutzer hat ein lokales Postfach und ist in der Cloud als Empfänger sichtbar

OnPrem Postfach

nicht gefüllt durch ADSync

zugewiesen

 Benutzer bekommt ein Postfach in der Cloud. Klassisches Doppelpostfach mit Exchange Online-Problem

OnPrem Postfach

gefüllt durch ADSync

Keine

Benutzer hat ein lokales Postfach und ist in der Cloud als Empfänger sichtbar

OnPrem Postfach

gefüllt durch ADSync

zugewiesen

 Benutzer hat ein lokales Postfach und ist in der Cloud als Empfänger sichtbar. Die MailboxGUID sagt Exchange Online, dass es ein Postfach gibt und es gibt kein Doppelpostfach mit Exchange Online

Online Postfach

Wird durch Cloud gefüllt

zugewiesen

Das ist ein reguläres Postfach in Exchange Online. Die MailboxGUID wird bei der Migration in die Cloud mit übernommen.

 

Hinweis:
Ein Exchange Online Postfach wird erstellt, wenn das Benutzerobjekt keine MailboxGUID hat und eine Lizenz zugewiesen bekommt. Die Änderung der Lizenz triggert in der Cloud den "Enable-Mailbox". Wenn das Objekt schon eine MailboxGUID durch ADSync und Lizenz hat und Sie die MailboxGuid über ADSync entfernen bekommt es kein Postfach.

Servername und MailboxGUID

Eine Auswertung von Get-Recipient zeigt auch schön die Zusammenhänge:

PS C:\> get-recipient | ft name,servername,exchangeguid

Name                                                         ServerName    ExchangeGuid
----                                                         ----------    ------------
ADMergeGroup1                                                              00000000-0000-0000-0000-000000000000
ADUser1 UCLabor                                                            ce43d767-2f1a-4af4-a514-feb67d777d59
ADUserA4_dom2016.msxfaq.de#EXT#                                            00000000-0000-0000-0000-000000000000
EXODL1                                                                     00000000-0000-0000-0000-000000000000
FrankCarius                                                  fr2p281mb0354 32f5c989-ee0d-4c58-b806-637a91e1713c
fctest1                                                                    3b252e9a-3339-430b-aaf2-59d32bcbf2b6
PF                                                                         116f186e-e878-429a-a006-5d56c46e1935
RaumADLokaldeaktiv                                                         0f5d17bc-91ac-466c-8543-edb6a7a76c3e
RaumADremoteaktiv                                            bexp281mb0087 9f93ed45-f857-4687-9198-5a96f0acae3a
RaumNeuLokalaktiv                                                          76d3f68c-c26a-4008-b9df-ad90dba60f87
RaumNeuRemoteAktiv                                           fr0p281mb0737 98765c96-901a-4b65-a05a-87900b6f3c25
RaumNeuRemoteDeaktiv                                         bexp281mb0086 64d56837-d30e-491a-950e-a0a87831973a
Room1                                                                      b6ab5e66-8fd6-4308-9e4e-537961ffb63a
TeamPub1_c88896f3-bdb9-4461-980a-5a895a954b9d                fr3p281mb0985 c81ec6a2-77be-4d94-94dd-893ebffe7c75
TeamWebseite1_3a971998-9456-41ef-b2ec-4d457e6ff40d           fr3p281mb0890 7ec0ef06-cf75-4c46-9677-24e7c7b1329d
user1                                                        fryp281mb0861 2898b164-05dd-40af-a4a2-3e3214695fe3

Gruppen haben keine ExchangeGuid und auch keinen Server. Nur Postfächer in Exchange Online haben einen Servername und eine ExchangeGuid.

Deprovisioning

In Verbindung mit ADSync wird die ExchangeGuid in der Cloud immer durch das lokale AD vorgegeben. ADSync kennt aber keine Rückreplikation, so das beim "RemoteMoveRequest" die GUID im lokalen AD gesetzt und in der Cloud entsprechend geschrieben wird. Ein Versuch die ExchangeGuid in der Cloud in der Situation zu entfernen, schlägt fehlt:

PS C:\> Disable-Mailbox RaumADremoteaktiv -PermanentlyDisable

Confirm
Are you sure you want to perform this action?
Disabling mailbox Identity:"RaumADremoteaktiv" will remove the Exchange properties from the Active Directory user
object and mark the mailbox in the database for removal. If the mailbox has an archive or remote archive, the archive
will also be marked for removal. In the case of remote archives, this action is permanent. You can't reconnect this
user to the remote archive again.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y
Disable-Mailbox: Error on proxy command 'Disable-Mailbox -PermanentlyDisable:$True -Identity:'RaumADremoteaktiv' -Confirm:$False' to server FR2P281MB0935.DEUP281.PROD.OUTLOOK.COM: Server version 15.20.5332.0000, Proxy method PSWS:
Cmdlet error with following error message:
Microsoft.Exchange.Configuration.DualWrite.LocStrings.UnableToWriteToAadException: An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online. However, it failed. Detailed error message:
        Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration. DualWrite (Graph) RequestId: 06a3b10a-9ef9-4df4-9d1f-a93e311d28ed

Eine "Fehlbedienung" ist hier also nicht möglich. Auch der Versuch, bei dem Cloud-Objekt einer OnPremises-Mailbox die ebenfalls vorhandene ExchangeGUID zu löschen, hat auch nicht funktioniert. er "findet" die Mailbox gar nicht erst.

PS C:\> Disable-Mailbox cvmtest -PermanentlyDisable
Disable-Mailbox: The operation couldn't be performed because object 'cvmtest' couldn't be found on 'AM6P281A04DC003.DEUP281A004.PROD.OUTLOOK.COM'.

Das "Entfernen" der ExchangeGuid mit dem "-PermanentlyDisable"-Parameter funktioniert wohl nur mit Benutzern, die ein Exchange Online Postfach ohne ADSync haben.

Wenn Sie daher einem per ADSync in der Cloud verwalteten Benutzer ein Postfach geben wollen, er aber OnPremises auch ein Postfach hast, dann sollten Sie die Replikation der ExchangeGuid in ADSync abschalten.

Beachten Sie dazu die Seite zu ADSync mit Tenant2Tenant Migrationen in Verbindung mit Exchange ADSync T2T-Migration

ExchangeGuid setzen

Dann habe ich mir noch mal angeschaut, ob ich eine ExchangeGuid vieleicht setzen kann. Ich habe dazu einen "CloudOnly"-User genommen, der keine Lizenz und keine ExchangeGuid hat und einen Enable-Mailbox versucht:

PS C:\> enable-Mailbox clouduser1
WARNING: After you create a new mailbox, you must go to the Office 365 Admin Center and assign 
the mailbox a license, or it will be disabled after the grace period.
Enable-Mailbox: The following error occurred during validation in agent 'Archive ParameterSet Enforcement Agent': 
'This operation only works with Archive or PermanentlyDisable parameters.'

PS C:\> enable-Mailbox clouduser1 -Archive
Enable-Mailbox: Recipient 'clouduser1' does n't have a mailbox. The recipient must have a mailbox to enable archive.

Das ist nun auch suspekt, denn den Parameter "-PermanentlyDelete" gibt es mit Enable-Mailbox nicht und mit "-Archive" beschwert er sich über die fehlende Mailbox. Da hilft auch der Hinweis nicht weiter, man möge doch rechtzeitig eine Lizenz zuweisen.

Da scheint mit der neuen Exchange PowerShell oder dem Backend etwas nicht zu passen. Aber ich kann auch einfach eine Lizenz zuweisen und Exchange Online startet den Provisioningprozess und damit eine ExchangeGuid zu bekommen. Einen anderen Weg habe ich bislang nicht gefunden, um die ExchangeGuid zu setzen oder zu löschen.

Das ist auch ok, denn die Cloud-Version von "Enable-Mailbox" hat viel weniger Optionen. Ich kann beim Anlegen z.B. gar nicht die primäre SMTP-Adresse mitgeben.

Weitere Links