RemoteMoveRequest ohne Hybrid

Die Funktion des "RemoteMoveRequest" habe ich schon mehrfach beschrieben und Exchange nutzt diese Technik für die Hybrid-Migration, die Tenant2Tenant Migration und sogar Org2Org OnPremises. Was sieht es mit Exchange OnPremises zu Exchange Online ohne Hybrid Mode aus und wieder zurück? Geht das auch oder muss ich dazu immer 3rd Party Tools nutzen?. Daher habe ich einen Test gemacht.

Achtung:
Diese Vorgehensweise ist von Microsoft nicht dokumentiert und eine Funktion kann nicht garantiert werden.

Einige Administratoren werden Analogien zu Org2Org Exchange 2016 entdecken.

Umgebung

Als Quelle dient mit ein Exchange 2019 OnPremises Server, der bislang keine Verbindung zu Cloud hat. Es gibt keine Hybrid-Bereitstellung und auch kein ADSync. Quasi die klassische kleine/mittlere Firma, die bislang mit Exchange nichts zu tun hat. Wenn so eine Firma zu Exchange Online wechseln wollte, dann könnten Sie sehr schnell mit eine "Cutover"-Migration umsteigen oder Hybrid einrichten und mittels RemoteMoveRequest migrieren und wären fertig.

In meinem Beispiel spiele ich aber einen "Firmenzukauf" oder eine Integration einer bisher unabhängigen Landesgesellschaft durch, die noch lokale Exchange Umgebung hat und direkt in den bestehenden Tenant überführt werden soll. Da der Zieltenant aber schon mit ADSync verbunden ist, scheide eine Cutover-Migration als Option aus.

Welche offizielle Optionen gibt es ?

  • Netzkopplung, ADSync + Hybrid
    Natürlich könnte ich als Käufer nun einen VPN-Tunnel in den AD-Forest des Zukauf einrichten, mit ADSync dann auch dessen Benutzer in den Tenant replizieren und Exchange Hybrid einrichten um zu migrieren. Aber das ist nicht mal eben gemacht und unterschiedliche Sicherheitsniveaus oder IP-Adresskonflikte und Namensauflösung können so eine Kopplung erschweren.
  • AzureAD Cloud Connect
    Diese Cloud-Version des ADSync kann auch "disconnected Forests" abgleichen und so die Anwender in den Tenant übertragen. Das hilft mir aber wenig, wenn ich das AD des Zukaufs eh abschalten will und die Benutzer später migriere.
  • 3rd Party Tools
    Ich kann die Benutzer vorher schon im Käufer-Forests als Mailbox oder Remote-Mailbox anlegen und mit 3rd Party-Tools die Mails vom Quell-Postfach ins leere Zielpostfach kopieren

Mich hat aber interessiert, wie der Remote Move Request genauer funktioniert und wie streng die Voraussetzungen erfüllt sein müssen.

Spoiler: Sie können mit einem RemoteMoveRequest problemlos Postfächer ohne ADSync oder Hybrid-Konfiguration von Exchange OnPrem zu Exchange Online migrieren!

Die Migration

Die folgende Beschreibung folgt dem Ablauf im Exchange Online Admin Portal. In der Produktion werden Sie einige vorbereitende Tätigkeiten natürlich vorab durchführen. Bitte zuerst einmal komplett lesen, damit sie nicht immer wieder unterbrechen müssen.

Der einfachste Weg für einen Administrator ist die Anlage eines Migrationsbatch über das Exchange Online Admin Portal. Wir geben dem Projekt einen Namen und möchten nach Exchange Online migrieren.

Im nächsten Schritt wählen wir natürlich die "Remote move migration" aus:

Der nächste Dialog weist sie auf die notwendigen Voraussetzungen hin.

Den MRSProxy auf dem Quell-System muss ich selbst aktivieren, denn die Quelle hat vermutlich noch keinen HCW - Hybrid Configuration Wizard verwendet, der diese Aktion durchführt.

# In der Quelle muss der MRSProxy zumindest auf dem Server aktiviert werden, der von extern erreichbar ist

Set-WebServicesVirtualDirectory `
   -identity "<Servername>\EWS (Default Web Site)" `
   -MRSProxyenabled $true

Aber Exchange Online fordert auch eine erfolgreiche Bereitstellung des Hybrid Mode. Das hat mich aber nicht abgehalten, die Migration weiter zu konfigurieren. Im darauffolgenden Schritt musste ich im Ziel natürlich einen "Migration Endpoint" anlegen. Auch das können Sie im Exchange Online Admin Center durch den Assistenten machen, indem Sie "Create a new migration endpoint" anwählen.

Der Assistent fragt danach natürlich die Zugangsdaten (Benutzername, Kennwort, Testpostfach, Exchange Server etc.) für den Endpunkt ab. Mein Endpunkte hatte dann folgende Parameter:

PS C:\> Get-MigrationEndpoint c2 | fl

Identity                               : C2
EndpointType                           : ExchangeRemoteMove
MaxConcurrentMigrations                : 20
MaxConcurrentIncrementalSyncs          : 10
RemoteServer                           : outlook.msxfaq.net
Username                               : msxfaq\migadmin
AcceptUntrustedCertificates            : False
MailboxPermission                      : Admin
IsRemote                               : True
RemoteTenant                           :
IsPublicFolderMailboxesMigrationSource : False
IsValid                                : True

Dann können wir auch schon die Benutzer auswählen, in die wir die Mails der Quelle migrieren wollen.

Hier müssen Sie wissen, dass Exchange Online in seinem eigenen Verzeichnis nach geeigneten "MailUser"-Objekten schaut. Sie müssen also im Ziel die entsprechenden Benutzer anlegen, damit sie hier als legitimes Ziel ausgewählt werde können. Das bedeutet auch, dass es im Ziel kein bestehendes Postfach geben darf. Dazu gibt es zwei Optionen:

  • CloudOnly
    Ich kann den Benutzer als "Cloud Only"-User anlegen, der damit erst einmal kein Gegenstück im lokalen AD hat. So eine Konto kann aber nach der Migration z.B. per ADSync User Matching verbunden werden. Dies geht sogar direkt im Exchange Admin Center, obwohl es einen aktiven ADSync gibt:

  • ADSync-Konto
    Ich kann aber auch im lokalen AD schon ein Benutzerkonto anlegen und durch ADSync replizieren lassen. Das wäre mein Favorit, wenn die Zielumgebung mit Exchange Hybrid konfiguriert ist. Dann sollte ich ein MailUser darauf machen und alle Verwaltungstools in der Quelle nutzen. Legen Sie den Benutzer aber nicht mit einer Mailbox oder RemoteMailbox an, sondern als "MailUser" mit der Zieladresse in der Quelle.

Natürlich mach ich das bei vielen Benutzern nicht von Hand, sondern besorge mir aus der Quelle einen "Get-Mailbox | export-clixml "mblist.xml" und nutze die Daten in Ziel, um Mailuser anzulegen und später mit den Daten nach dem Umzug auch die ProxyAddresses nachzupflegen.

Im vorletzten Schritt müssen Sie noch eine "TargetDeliveryDomain" angeben. Das ist die Domäne, an die nach Abschluss der Migration eine Weiterleitung von der Quelle ins Ziel eingerichtet wird. Die RemoteMoverequest-Migration wird nach dem Abschluss in der Quelle aus der Mailbox einen MailUser machen!

Hier stehen alle Domains ihres Tenant zur Wahl. Ich empfehle aber hier gerne die mail.onmicrosoft.com-Domain, da diese eindeutig ihrem Tenant zugeordnet ist und der MX-Record auch direkt zur Cloud zustellt. Nur wenn Sie den Exchange Online als Nebeneingang für Mailempfang geschlossen haben, dann sollten Sie eine Domain nehmen, die von der Quelle auch erreichbar ist.

Auf der Seite "Schedule" können Sie noch bestimmen, wann die Migration startet und ob diese automatisch abgeschlossen werden soll.

In diesem Fall möchte ich lieber noch einmal die Ergebnisse vor dem Abschluss anschauen. Bei einer Hybrid-Migration kann eigentlich nicht viel schief gehen. Aber hier sieht das anders aus. Die nächsten Abschnitte zeigen nun alle Fehler auf, auf die ich gestoßen bin.

Die Liste ist vermutlich nicht vollständig. Wenn Sie so migrieren und weiter Fehler gefunden und gelöst haben, ergänze ich die gerne.

Error: MissingExchangeGuidException

Der erste Fehler verhindert schon den Start der Migration. Exchange hat das Zielobjekt zwar gefunden aber als ungültig angesehen:

Error: MissingExchangeGuidException: The user object for <userid> does not have a valid ExchangeGuid property and cannot be migrated

Wobei die Aussage nur bedingt korrekt ist . Auch wenn das Quell-Objekt überhaupt nicht vorhanden ist, kommt die gleiche Meldung. Der RemoteMoveRequest sucht nämlich nicht nach dem Benutzer um die ExchangeGUID zu finden, sondern sucht pauschal nach der ExchangeGUID

Der langgediente Admin wird schon aus von Org2Org Exchange 2016 sofort wissen, woran es liegt. Exchange nutzt die Felder der MailboxGUID und der ArchiveGUID, um eine 1:1 Mapping zwischen Quelle und Ziel zu durchzuführen und zu verhindern, dass bestehende Postfächer zerstört werden. Bei Objekten vom Typ MailUser in Exchange Online und Exchange OnPremises sind diese Felder auf "00000000-0000-0000-0000-000000000000" gesetzt. Also müssen wir uns aus der Quelle die Werte für jedes Postfach besorgen.

Get-Mailbox | fl ExchangeGuid,ArchiveGuid

Und entsprechend im Ziel schreiben:

# Cloud Only User
Set-Mailuser <userid> -ExchangeGUID <guid> -ArchiveGuid <GUID>

# ADSync User im lokalen AD
Set-Mailuser <userid> -ExchangeGUID <guid> -ArchiveGuid <GUID>
Set-RemoteMaimlbox <userid> -Set-RemoteMaimlbox <userid> -ExchangeGUID <guid> -ArchiveGuid <GUID>

Wer sich am Anfang aus der Quelle alle Daten der Mailbox besorgt hat, kann hier per ForSchleife arbeiten z.B:

import-clixml | foraeach {
   Set-Mailuser `
      -Identity $.primarysmtpaddress `
      -ExchangeGUID $_.ExchangeGUID `
      -ArchiveGuid $_ArchiveGuid
}

Bei einer regulären Koexistenz im Hybrid Mode werden die Felder durch ADSync aus der lokalen Mailbox in den MailUser in Exchange Online repliziert. Nur in diesem Sonderfall gibt es ja keinen ADSync und wir müssen die Werte manuell setzen.

Übrigens können Sie eine Exchange GUID nicht gleichzeitig an zwei MailboxUser zuweisen. Das verhindert Exchange:

PS C:\> set-mailuser migdemo5 -ExchangeGuid e376c4a6-828a-404d-ada4-9feab6aa868c
set-MailUser: |Microsoft.Exchange.Configuration.ObjectModel.PropertyValueExistsException|Der Wert
"e376c4a6-828a-404d-ada4-9feab6aa868c" der Eigenschaft "ExchangeGuid" wird von einem anderen Empfängerobjekt verwendet.
Geben Sie einen eindeutigen Wert an.

Wenn Sie bei Tests mehrfach Benutzer löschen und anlegen, dann sollten Sie die gelöschten Objekte im AzureAD auf permanent löschen, da ansonsten die MailboxGUID nicht mehr eindeutig ist.

Error: NotAcceptedDomainException

Die nächste Meldung störte sich an der verwendeten Domain der Quelle. Ich weiß zwar nicht, genau, wie der RemoteMoveRequest die Daten aus der Quelle ausliest und warum ihn das stört aber es blockiert die Migration dieses Benutzers.

Error: NotAcceptedDomainException. You can't use the domain <domainname> because it's not an accepted domain for your organization.

Das ist eine wichtige Erkenntnis, dass der RemoteMoveRequest zu Exchange Online auf jeden die Domain der Quelle in ihrem Tenant als "Accepted Domain" haben muss. Ich finde das nicht schlimm, wenn die SMTP-Domain bisher noch nie in einem Tenant genutzt wurde und schnell registriert werden kann. Damit schützt Microsoft auch eine unerlaubte Migration in einen falschen Tenant und stellt sicher, dass die zukünftigen Mailadressen auch vergeben werden können. Es bedeutet aber auch, dass eine temporäre Anlage mit "onmicrosoft.com"-Adressen nicht ausreicht.

Aber es stört natürlich, wenn Sie zwar das Postfach aber nicht die Domain umziehen wollen. Bei einem CarveOut müssen die Benutzer in der Quelle daher schon auf die neue Domain umgestellt worden sein. Das könnte in einigen Fällen ein K.O.-Kriterium für eine Bordmittel-Migration sein.

Error: TargetDeliveryDomainMismatchPermanentException

Auch der nächste Fehler liefert weitere Informationen für die Vorarbeiten.

Error: TargetDeliveryDomainMismatchPermanentException: The target mailbox doesn't have an SMTP proxy matching 'msxfaqdev.mail.onmicrosoft.com'.

Auf den ersten Blick mag das überraschen aber denken Sie mal darüber nach, welche Umleitung Sie in der Quelle nach der Migration konfigurieren? Im Ziel gab es bislang ja nur einen MailUser mit einer Adresse der Quelle und der ExchangeGUID/ArchiveGUID. Das QuellSystem muss nach der Migration eine Umleitung zum Ziel einrichten und dazu eine Routingdomäne nutzen, die eindeutig auf das Postfach im Ziel verweist. Daher müssen Sie dem Zielobjekt, d.h. der MailUser, auch eine sekundäre Adresse aus dieser Domain geben. Bei CloudOnly-Benutzern geht das direkt im Exchange Admin Portal oder per PowerShell:

Wenn das Ziel im Hybrid-Mode ist, dann sollte die lokale Empfängerrichtlinie, die durch den HCW - Hybrid onfiguration Wizard erweitert wurde, das Problem schon gelöst haben.

Status auf dem Quellserver

Die Migration nutzt den MRSProxy der Quelle und wenn Sie mögen, können Sie ja die IISLogs dazu in Echtzeit betrachten:

Get-Content `
   -Path C:\inetpub\logs\LogFiles\W3SVC1\u_ex*.log `
   -Tail 0
   -Wait

Sie sollten sehr viele POST-Request auf /EWS/mrsproxy sehen.

Ich habe die Change der Analyse auch mal genutzt, weiter zu schauen, was der RemoteMoveRequest so anstellt. Da in meinem Lab genau ein RemoteMoveRequest mit genau einer Mailbox gleichzeitig aktiv war, habe ich einfach längere Zeit in dem Status belassen und mit die Zugriffe auf EWS/mrsprox.svc angeschaut, während ich in der Quelle weiter etwas verändert haben.

Sie sehen gut meine Migrationsteste am Anfang aber wenn ich einen Migrationbatch über einige Tage stehen lasse, dann finde ich in dem Beispiel einmal pro Nacht einen kleinen Delta-Lauf. Erst am Ende, wenn ich die Migration abschließe, gibt es noch mal einen letzten Sync samt Abschluss der Migration.

Geschafft "Synced"

Zurück zur Migration selbst. Die Daten es Postfachs wurden im Hintergrund aus der Quelle zu ExchangeOnline gesagut und nach einiger Zeit kehrte wieder Ruhe ein und der Migrationsjob hatte den Status "Synced" erreicht.

Das sieht so alles erst einmal gut aus und ein Blick auf die Details zeigt:

Es wurden aber schon meine knapp 50 MB Testdaten übertragen.

Hier wurden zwei Elemente übersprungen.

ACL-Probleme

Wenn ich mir hier dann aber die "View skipped item details" anschaue, dann finde ich zwei ACL-Einträge:

Die SIDs verweisen auf Berechtigungen anderer Benutzer auf das Postfach, die bei der Migration nicht erfolgreich umgesetzt werden konnten, weil diese Konten nicht im Ziel vorhanden sind. Bei mir was ein Konto ein Stellvertreter und das andere Konto das Migrationskonto mit Vollzugriff.

Wenn ADSync in einer Hybrid-Bereitstellung alle Empfänger synchronisiert, dann landet im Ziel auch die "OnPremSecurityIdentifier" und Exchange dürfte dieses Feld nutzen, um die ACLs dann anzupassen

Ich habe daher den Test wiederholt und OnPremises eine Mailbox "Migdemo5" und "Migdemo6" angelegt und beide auch im Ziel mit der MailboxGUID als MailUser angelegt. MigDemo6 hatte auf dem lokalen Postfach von "MigDemo5" Vollzugriff und dann habe ich das Postfach Migdemo5 zu Exchange Online migriert.

Sie können gut sehen, dass die Berechtigungen des Benutzers MigDemo6 tatsächlich im Ziel eingetragen wurden. Es werden also sogar Potfachrechte übertragen. Den Test hatte ich noch noch mal mit "SendAs" wiederholt. Diese Recht steht nicht im Postfach sondern im lokale AD.

Ob der RemoteMoveRequest dies nun anhand der MailboxGUID, UPN, SMTP-Adresse oder eine anderen Feld gelungen ist, kann ich nicht sagen. Die SID wird es aber wohl nicht sein, da es die in der Cloud nicht gab.

Abschluss der Migration

In meinem Beispiel habe ich die Migration abgeschlossen. Mich hat hierbei natürlich interessiert, was der RemoteMoveRequest auf beiden Seiten macht, denn ein ADSync oder einen anderen Verzeichnisabgleich gibt es nicht. Dazu habe ich vorsorglich die Objekte in der Quelle und im Ziel vor dem Abschluss des RemoteMoveRequest exportiert.

#Export lokales AD
Get-ADUser migtest4 -Properties * | Export-Clixml premig.xml

#Export in Exchange Online
Get-Recipient migtest4 | export-clixml migtest4.xml

Aufgrund der Fehler bei den Berechtigungen war der Abschluss des RemoteMoveRequest nicht direkt möglich, da die von mir eingebauten Fehler erst einmal bestätigt werden mussten . Der Status wechselte auf von "Synching" auf "NeedsApproval"

Der Job war vorher auf "Manually complete the batch" gestellt und durch das "Complete" wurde eine Zeit in der Zukunft vorgegeben. Ich habe dann einfach die Zeit auf jetzt oder etwas vorher gestellt, damit der RemoteMoveRequest ugehend abgeschlossen wurde.

Outlook merkt was

Mein Outlook, in dem ich das Quellpostfach eingebunden hatte, kam nach kurzer Zeit mit folgender Meldung:

Es hat sich also was getan.

Objektänderungen Exchange Online

Nun war ich natürlich gespannt auf die Änderungen in Quelle und Ziel. Daher habe ich nach Abschluss der Migration erneut die AD-Objekte exportiert und verglichen. In der Cloud haben sich folgende Felder geändert:


Vorher/Nachher-Vergleich mit Compare-PSObject

Die wichtigsten Änderungen:

  • Objekttyp: MailUser -> MailboxUser
    Das war zu erwarten
  • ExternalEMailAddress wurde geleert
    d.h. die Umleitung von dem Ziel in die Quelle wurde entfernt.
  • EmailAddresses
    Hier wurde nur der LegacyExchangeDN der Quelle als X500-Adresse addiert.

Damit habe ich aber auch Gewissheit, dass der Remote Move keine anderen Felder, z.B. Displayname, Surname, Givenname etc, überschreibt.

Achtung: Diese Änderungen finden in der Cloud statt. Wenn die Zielumgebung mit ADSync und lokalem Exchange Server im Hybrid-Mode ist, bleibt lokal immer noch ein "MailUser" übrig, den Sie manuell mit "Enable-RemoteMailbox" konvertieren müssen.

Objektänderungen OnPremises

Hier wird es nun interessant, da der RemoteMoveRequest von Exchange Online keinen direkten Zugriff auf das lokale AD hat und es gibt auch keinen ADSync, der Änderungen zurückschreiben könnte. Aber auch hier hat Exchange ganze Arbeit geleistet:


Vorher/Nachher-Vergleich mit Compare-PSObject

Die wichtigsten Änderungen:

  • Objekttyp: Aus der Mailbox wurde ein Mailuser
  • TargetAddress wurde ins Ziel gesetzt
  • ProxyAddresses
    haben den Exchange Online LegacyExchangeDN als X500 Adresse bekommen.
  • msexchRemoteRecipientType = 4
    Zeigt an, das die Mailbox in die Cloud migriert wurde

Natürlich wurden auch die Einträge für HomeMDB, HomeMTA etc. entfernt.

Exchange kann über dem MRSProxy also nicht nur Postfachinhalte aus der Quell ins Ziel synchronisieren. Der RemoteMoveRequest kann auch das Objekt von einer Mailbox zu einem MailUser in der Quelle verändern.

Lizenz

Denken Sie daran, dass Sie nun ein Postfach in Exchange Online haben. Wenn sie keine Lizenz zuweisen, dann wird es nach 30 Tagen wieder gelöscht.

Rückgängig

Als ich meine Testumgebung "rückgängig" machen wollte, bis ich auf einen weiteren Fehler gestoßen. Ich wollte in der Quelle einfach den MailUser wieder zu einer Mailbox machen und die alten Werte zu ExchangeGUID setzen.

[PS] C:\>Enable-Mailbox migtest4@msxfaq.net
Enable-Mailbox on this mail user is disallowed because the mailbox has been migrated.

Exchange merkt sich am Benutzerobjekt, dass es migriert wurde und verhindert eine Reaktivierung.

Woran Exchange das festmacht, habe ich nicht weiter untersucht. Ich denke es ist in msExchRecipientTypeDetails codiert.

Allerdings ist die Mailbox in der Datenbank schon noch vorhanden.

foreach ($db in get-mailboxdatabase) { `
   Get-MailboxStatistics -Database $db `
   | where {$_.disconnectReason.tostring() -eq "SoftDeleted"} `
   | Format-Table DisplayName,Database,DisconnectReason}

DisplayName   Database  DisconnectReason
-----------   --------  ----------------
migtest4      MailboxDB SoftDeleted

Allerdings verweist nun natürlich kein Active Directory Benutzer auf den Datenbankeintrag. Es reicht übrigens nicht, einem Benutzerkonto wieder die ExchangeGUID zuzuweisen. Damit kommt das Postfach nicht mehr zurück. Der korrekte Weg ist hier ein "Disable-RemoteMailbox", um die Properties komplett zu entfernen und dann wieder ein Enable-Mailbox.

Erinnern sich sich: Wir machen das alles in einer Umgebung mit lokalen Exchange Servern ohne ADSync zu einem Tenant. Da dürfte es technisch eigentlich gar keine RemoteMailbox geben.

Der Benutzer dann dann wieder ein Postfach aber es ist immer noch leer und eine "SoftDeleted"-Mailbox in der Datenbank kann auch nicht wiederverbunden werden. Wir können aber die Inhalte der "Soft deleted" Mailbox über einen "New-MailboxRestoreRequest" in die neue Datenbank überführen.

New-MailboxRestoreRequest `
   -SourceStoreMailbox "Debra Garcia" `
   -SourceDatabase MailboxDB `
   -TargetMailbox "Migtest4" `
   -AllowLegacyDNMismatch

Zusammenfassung

Wenn Sie früher schon Postfächer zwischen Exchange 2016 Organisationen (Org2Org Exchange 2016) mit einem "RemoteMoveRequest" übertragen haben und das relativ neue Feature eines T2T Exchange Online kennen, dann sollte es sie nicht verwundert haben, dass eine Migration von OnPremises zu Exchange Online auch ohne ADSync und eingerichteten Hybrid-Mode funktioniert. Allerdings müssen Sie selbst die Quelle (MRSPROXY, RemoteDomain), die Zielobjekte (ExchangeGUID, TargetAddress) und den Mailfluss einrichten. Es funktioniert auch nur, wenn es im Ziel noch kein Postfach gibt.

Der Markt für 3rd-Party Migrationstools bricht also nicht ein, nur weil ich ihnen hier einen Weg zur Migration von Exchange OnPremise in einen Tenant im Rahmen eines Mergers von Firmen beschrieben habe. Die Zusatztools haben durchaus ihre Relevant, z.B. wenn Notes, GroupWise oder andere Quellen zu migrieren oder die Postfächer im Ziel schon vorhanden sind. Aber es immer gut, Alternativen zu haben.

Weitere Links