Org2Org Exchange 2016

Diese Seite beschreibt, wie ich Postfächer einer On-Premises Exchange Quellorganisation allein über das Internet in eine andere Exchange On-Premises-Umgebung mit Bordmitteln migrieren kann. Mit Office 365 als Ziel ist es dank Staging, Cutover und Hybrid nicht sonderlich schwer. Wenn ich aber nur "On-Premises" arbeite, muss ich doch auch Postfächer verschieben können.

Warum das Ganze?

Wen eine Firma mit Exchange eine andere Firma mit Exchange aufkauft, dann wird man in der Regel erst mal die Netzwerk koppeln, Trusts einrichten und das Mailrouting und Free/Busy einrichten, damit die interne Kommunikation nun auch intern bleibt und eine Zusammenarbeit möglich ist. Für diese Umgebung gibt es fertige Beschreibungen einer Cross Org Migration mit ADTM und "Prepare-MoveRequest" etc. Was macht man aber, wenn die abgebende Firma nur einen Teil der Postfächer abgibt, keine LAN-Verbindung oder Trust möglich ist und damit LDAP für einen Verzeichnis abgleich wegfällt.

Also müssen wir andere Wege einschlagen, denn technisch kann Exchange über den Mailbox Replikation Service problemlos auch Postfächer von anderen Servern übertragen. Einziges Protokoll ist dabei HTTPS, wobei der Zielserver sich die Daten "zieht". Dazu müssen aber bestimmte Voraussetzungen erfüllt sein. Ich vermute, dass dieser Fall eher selten ist aber er hilft beim Verständnis, wie Exchange tickt und die Migration umsetzt.

Bitte denken Sie aber immer auch daran, dass es durchaus auch Programme von Drittherstellern gibt, die andere Optionen ermöglichen. So gibt es kommerzielle Tools, die per EWS z.B. Postfächer synchronisieren oder über Agenten die Daten vor Ort extrahieren, komprimiert übertragen und im Ziel wieder importieren.

Die Umgebung

Für die Beschreibung auf dieser Seite gehen wir von folgender einfachen Umgebung aus. Auf der linken Seite gibt es eine Exchange 2010/2013/2016 Umgebung, deren Exchange Server über das Internet erreichbar sind während auf der rechten Seite eine Exchange 2016-Umgebung befindet.

Die Quelle ist über /EWS über das Internet erreichbar aber es gibt weder eine direkte Verbindung der beiden grünen Netzwerke, z.B. weil Sie überlappende IP-Adressen haben oder es einfach nicht gewollt ist. Unterschiedliche Security-Anforderungen könnte ein weiterer Grund sein, warum die Netzwerke nicht verbunden werden dürfen. Entsprechend ist es auch nicht möglich, intern die anderen Server per HTTPs oder LDAP zu erreichen und auch Kerberos und Trusts sind nicht möglich.

Es sind also erschwerte Bedingungen, unter denen eine Migration von Postfächern erfolgen muss. Es ist aber dennoch direkt möglich und sie sparen sich damit den ansonsten erforderlichen PST-Export/Transfer/Import.

Diese Migration basiert auf dem Mailbox Replication Service (MRS) auf der Quelle und kann daher nicht genutzt werden, dann die Quelle ein Office 365-Tenant ist. Dann bleibt nur der Weg über Hybrid Mode oder PST-Export/Import.

Übersicht der Migration

Ehe ich auch die einzelnen Schritt eingehe, möchte ich einen kleinen Überblick dieser besonderen Art der Migration geben.

Die Schritte sind schnell erzählt

  • In der Quelle muss der Export der Postfächer aktiviert werden
    Dazu muss einmal der MRSProxy erreichbar sein und ein Dienstkonto für das Abziehen der Postfachdaten vorliegen. Ggfls. sind noch Firewall-Regeln, Reverse-Proxy und Zertifikate ein Thema
  • Im Ziel muss die Quelle als Migrationsendpunkt angelegt werden
    Hier ist die URL und das Dienstkonto zu hinterlegen. Auch hier sind eventuell DNS-Auflösung, ausgehender Proxy u.a. anzupassen.
  • Objekte aus der Quelle extrahieren
    Die relevanten Objekte sollten in der Quelle in eine CSV/XML-Datei für das Ziel importiert werden. Neben den üblichen Feldern wie Name, Vorname, Straße etc. sind insbesondere die Felder Mail, ProxyAddresses, msExchangeGUID und die msexchArchivGUID erforderlich, da diese im Ziel zum "Matching" genutzt werden. Auch Verteiler mit Mitgliedern sind wünschenswert, damit die Anwender möglichst vollständig weiter arbeiten können.
  • Import im Ziel
    Mit den Export-Daten der Quelle werden nun die AD-Konten und Verteilergruppen im Ziel angelegt oder ergänzt.
  • Move Request Synchronisation starten
    Nun können im Ziel die Inhalte der Postfächer schon von der Quelle ins Ziel übertragen werden. Seit Exchange 2013 kann der Job so eingestellt werden, dass er am Ende anhält und alle 24h weiter die Änderungen überträgt. So können Sie sehr viele Benutzer in einzelnen Batches übertragen und am Ende viele auf einen Schlag umstellen.
  • Mailrouting Umstellen
    Wenn Sie alle Benutzer einer kompletten SMTP-Domain umgestellt haben, dann sollte sie vor dem Ende der Migration auch das Mailrouting umstellen. Dabei können Sie auch den Autodiscover-Eintrag gleich mit anpassen.
  • Move Request umstellen
    Ewig sollte der Verzeichnisabgleich nicht laufen. Wenn Sie alle Daten "drüben" haben, können Sie die Migration abschließen.

In Bezug auf die Empfänger und Inhalte stellt sich die Umstellung wie folgt dar:

Die drei großen Phasen sind:

  • Empfänger übertragen
    Per PowerShell kann man die Stammdaten exportieren und im Ziel mit der Target-Address importieren. Jedem Postfach in der Quelle wird ein MailUser im Ziel zugeordnet und Verteiler sollten auch übertragen werden.
  • Mit Exchange Bordmitteln werden die Daten synchronisiert
    Per MRS zieht sich das Zielsystem die Mailboxinhalte der angegebenen Benutzer und synchronisiert diese Daten alle 24h
  • Migration abschließen und Umschaltung
    Am Ende wird die Migration abgeschlossen, wobei Exchange aus dem MailUser dann eine Mailbox macht und auf der anderen Seite die Mailbox zu einem MailUser konvertiert.

Nun ein paar weitere Anmerkungen und Details zu den einzelnen Phasen.

Vorarbeiten im Quell-Forest

Bei der Migration von Server zu Server erfolgt der Zugriff per HTTPS auf den Mailbox Replication Service. Dazu sind einige Vorarbeiten erforderlich.

  • Dienstkonto
    Sie benötigen in der Quelle ein Anmeldekonto, welches sehr umfangreiche Rechte hat. In der Regel "Domain Admin" und "Exchange Admin". Ein Grund liegt sicher auch darin, dass zum einen der Zugriff auf den MRSProxy natürlich nur hoch privilegierten Benutzern erlaubt ist und zudem die lokalen Postfächer am Ende der Migration konvertiert werden.
  • Erreichbarkeit per HTTS
    Der Quellserver muss vom Zielserver per HTTPS erreichbar sein. Da kann ziemlich viel "dazwischen" sein, was die Migration stört, speziell wenn die Migration "über das Internet" erfolgt:
    • Ausgehender Proxy
      Die meisten Exchange Server dürfen nicht einfach mal so im Internet surfen. Da steht in der Regel ein Proxy mit Authentifizierung davor, der vielleicht sogar noch SSL-Aufbrechen und URL-Filterung macht. Ratsam ist die Verbindung zu dem bekannten und vertrauten Ziel möglichst ungefiltert zu routen. Diese Anforderung gilt natürlich erst einmal für den Ziel-Forest, der die Postfächer von der Quelle abgeholt.
    • Veröffentlichung
      Auch auf der Zielseite ist es nicht immer möglich, das virtuelle Verzeichnis "/ews/mrsproxy.svc" direkt frei zu geben. Viele Firmen machen eine Pre-Authentication der Clients oder schalten ein Portal davor. Hier müsste die Quell-Organisation z.B. anhand der IP-Adresse als Ausnahme geführt werden.
    • Zertifikate
      Der abrufender Server im Ziel muss dem von der Quelle präsentierten Zertifikat vertrauen. Idealerweise sind dies öffentliche Zertifikate mit passendem Namen.
  • Auf dem Server muss der MRSProxy laufen
    Diese Funktion ist per Default nicht aktiv und muss erst aktiviert werden.
Ab Exchange 2010 SP2. davor musste man die WEB.CONFIG editieren
Set-WebServicesVirtualDirectory `
   -Identity "EWS (Default Web Site)" `
   -MRSProxyEnabled $true `
   -MRSProxyMaxConnections 50

In Office 365 gibt es den Mailbox Replication Service (MRS) nicht. Sie können diesen Weg also nicht nutzen, um Postfächer aus einem Tenant zu exportieren oder zwischen Tenants zu verschieben. Hier bleibt nur der Export per PST-Datei, 3rd-Party Tools, die auf EWS aufsetzen oder eine Migration über den Hybrid-Mode. Nur in die Gegenrichtung nutzt Office 365 den MRSProxy ihrer On-Premises Umgebung um die Postfächer im Hybrid Mode zu verschieben. Bei Cutover- oder Staging-Migrationen kommt RPC/HTTP zum Einsatz, bei dem das Dienstkonto "Vollzugriff" auf jede Mailbox braucht. Diese beiden Migrationswege sind nicht On-Premises nutzbar

Die weiteren Vorarbeiten betreffen die Empfänger und werden in einem eigenen Abschnitt beschrieben.

Vorarbeiten im Ziel-Forest

Damit das Zielsystem die Daten von der Quelle abrufen kann, sind auf dem Server ebenfalls Anpassungen erforderlich. Zuerst muss der Server natürlich per HTTPS die Quelle erreichen und da gibt es schon zwei Hürden, wenn die Kommunikation nicht intern direkt sondern über das Internet erfolgt:

  • Ausgehender Proxy
    Die meisten Exchange Server dürfen nicht einfach mal so im Internet surfen. Da steht in der Regel ein Proxy mit Authentifizierung davor, der vielleicht sogar noch SSL-Aufbrechen und URL-Filterung macht. Ratsam ist die Verbindung zu dem bekannten und vertrauten Ziel möglichst ungefiltert zu routen. Diese Anforderung gilt natürlich erst einmal für den Zielforest, der die Postfächer von der Quelle abgeholt.
  • Zertifikate
    Der abrufender Server im Ziel muss dem von der Quelle präsentierten Zertifikat vertrauen. Idealerweise sind dies öffentliche Zertifikate mit passendem Namen.
  • SMTP-Domains, Accepted Domains, Empfängerrichtlinien
    Achten Sie darauf, dass die Zielumgebung auch für die Domänen zuständig ist, die sie später mit umstellen. Zumindest muss die die Mails an die Domäne annehmen, an die aus der Quelle die Mails weiter geleitet werden.

Der einfachste Weg die Funktion des Migration Endpunkts zu testen geht über die Powershell:

$cred = get-credential
Test-MigrationServerAvailability `
   -Credentials $cred `
   -RemoteServer "owa.msxfaq.net" `
   -ExchangeRemoteMove:$true

Result             : Success
Message            :
ConnectionSettings : <ExchangeConnectionSettings HasAdminPrivilege="True" HasAutodiscovery="False" HasMrsProxy="True"
                     AutodiscoverUrl="" IncomingEmailAddress="" IncomingRPCProxyServer="owa.msxfaq.net"
                     IncomingExchangeServer="owa.msxfaq.net" IncomingNSPIServer="" IncomingDomain=""
                     IncomingUserName="svc_exchange" EncryptedIncomingPassword="xxxxxxxxxxxxxxxxxxxxxxxxxxx
                     xxxxxxxxxxxxxxxxxxxxxx==" IncomingAuthentication="Basic" ServerVersion="" TargetDomainName=""
                     SourceMailboxLegDn="" PublicFolderDatabaseServerLegacyDN="" IsPublicFolderMailboxesMigrationSource="False" />
SupportsCutover    : False
ErrorDetail        :
IsValid            : True
Identity           :
ObjectState        : New

Hier ist dann gut zu sehen, dass "HasAdminPriviledges" als auch "HasMrsProxy" auf true stehen aber Autodiscover anscheinend noch nicht korrekt ist. Das ist für die Migration aber nicht kritisch, wenn ein statischer Hostname mitgegeben wird..

Benutzer und Verteiler vorbereiten

Die Exchange Migration überträgt eigentlich nur die Postfachinhalte. Exchange kümmert sich aber nicht um die eigentlichen Empfänger und stellt hierzu auch keine Tools bereit. Das stimmt so aber nicht ganz, denn mit dem Skript "Prepare-Moverequest.ps1" hat Microsoft sehr wohl ein Skript, welches per LDAP aus einer Quelle die Benutzer liest und im Ziel dann bestehende Benutzer nach verschiedenen Kriterien sucht und aktualisiert oder neue Benutzer anlegt. Es kennt sogar Ressource Forest Szenarien mit Linked Mailboxen. Für Verteiler und öffentliche Ordner ist das Skript aber blind. Zudem gibt es eine zweite Lösung von Microsoft in Form einen Skript zur Integration in ILM (Identity Lifecycle Manager, später FIM und dann MIM). In meinem Beispiel muss ich eine anderen Weg wählen, zudem Sie aber einige Fakten vorab kennen sollten:

 Note that you can move Exchange 2010 and Exchange 2013 mailboxes to an Exchange 2016 forest.
To move a mailbox from an Exchange forest to an Exchange 2016 forest, the Exchange 2016 target forest needs to contain a valid mail-enabled User with a specified set of Active Directory attributes.
Quelle:  Prepare Mailboxes for Cross-Forest Move Requests https://technet.microsoft.com/en-us/library/ee633491(v=exchg.141).aspx

Zudem müssen einige Felder im Ziel "passen", d.h. sie exportieren diese am besten aus der Quelle und addieren Sie im Ziel. Am wichtigsten sind die folgenden drei Attribute

  • msExchMailboxGUID
    Dieses Feld wird genutzt, um das Quellpostfach auf das Zielpostfach zu matchen
  • msExchArchiveGUID and msExchArchiveName
    Diese Werte sind für eventuell vorhandene Archivmailboxen relevant.

Natürlich müssen die Anwender auch normale MailUser sein, d.h. all die anderen Felder sind auch wichtig und irgendwie sollten Sie natürlich auch alle Proxy-Addresses aus der Quelle in das Ziel übernehmen. Ich habe daher per PowerShell die Daten aus der Quelle exportiert und im Ziel entsprechende Benutzer angelegt. Auf das "Matching" bestehender Benutzer habe ich verzichtet, da es in dem Beispiel nicht passiert. Es wäre aber nicht schwer beim Anlegen z.B. erst mal nach bestehenden Benutzern zu suchen. Letztlich ist für Postfächer das Prinzip recht einfach.

# Export in der Quelle, ggfls. noch filtern
get-mailbox | export-clixml mailbox.xml

Diese Datei kopiere ich dann auf das Ziel um dort die User wieder anzulegen. Das könnte wie folgt aussehen.

# Startkennwort abfragen
$passwd = Read-Host -AsSecureString 

#Import und User anlegen
foreach ($mailbox in (import-clixml mailbox.xml)) {
   $mailUser = New-MailUser `
      -organizationalunit "ou=Users,dc=msxfaq,dc=de"
      -name $_.name `
      -password $passwd `
      -externalemailaddress $_.primarysmtpaddress

   Set-MailUser ` 
      -identity $mailUser.identity `
      -exchangeguid $_.exchangeguid `
      -ArchiveGuid $_.archiveguid `
      -Archivename $_.archivename 
}

Natürlich können Sie auch noch andere Felder wie Vorname, Nachname, Firma etc. übertragen und auch die ProxyAddresses sind vielleicht interessant. Auch könnte man den alten "LegacyExchangeDN" vielleicht als X.500 Adresse in die ProxyAddresses addieren. Den Typ (User, Room, Shared) der späteren Mailbox kann ich hier aber noch nicht angeben. Das hier soll ja nur ein Beispiel sein. In vielen Firmen darf ich als Exchange Admin gar keine "AD-Benutzer" anlegen, sondern nur bestehende "aktivieren".

Etwas anspruchsvoller wird es mit der Übertragung der Gruppen. Hier reicht es ja nicht für eine Verteilergruppe einen Kontakt auf der anderen Seite anzulegen. Diesmal muss für jede Verteilergruppe auf einer Seite auch auf der anderen Seite ein Verteiler angelegt und die Mitglieder gepflegt werden. Das ist schon anspruchsvoller, da man als Mitglieder nur die Objekte addieren kann, die schon vorhanden sind. Die MailUser ist ja schon da aber andere Verteiler vielleicht noch nicht (Rekursion) und spätestens wenn nicht alle Postfächer sondern nur eine Teilmenge migriert wird und die zurück gebliebenen auch nicht als Kontakte vorhanden sind, gibt es hier Unstimmigkeiten.

Auf der Seite GroupSync habe ich einen Code veröffentlicht, der die Mitglieder von Verteilern in der Quelle anhand ihrer SMTP-Adresse in CSV-Dateien exportiert und im Ziel die Objekte wieder sucht und aktualisiert. Damit kann man auch die Übernahme machen.

Ich kann in diesem Abschnitt keine "fertige Lösung" liefern, da jede Migration sich unterscheidet. Selbst große Lösungen wie Prepare-Moverequest, ILM und andere Tools erfordern eine Anpassung und ich wollte hier keine Skripte erstellen, die hunderte Zeilen lang sind, zumal es meist ein einmaliger Prozess ist. Schauen Sie sich an, was benötigt wird und in der Regel kommen Sie mit einigen Zeilen PowerShell hin.

Migration-Endpoint anlegen

Beim Erstellen der Migrationsanforderung können Sie alle benötigten Parameter immer wieder angeben. Einfacher ist aber die Hinterlegung der Quelle als "Migrationspunkt", hinter dem dann der Server und das Dienstkonto gespeichert sind. Bei der eigentlichen Erstellung des Migrationsauftrags  kann darauf verwiesen werden. Der Endpunkt kann sehr einfach sogar per ECP angelegt werden

Der Assistent fragt dann die benötigten Daten ab:

Interessant ist hier, dass Exchange die Admin Credentials in der Form "Domain\Username" anfordert. Da frage ich mich dann natürlich wie er per Autodiscover dann versucht das Zielsystem zu ermitteln. Ein Blick in das "MSExchange Management"-Eventlog des Zielserver verrät aber, was da passiert:

Log Name:      MSExchange Management
Source:        MSExchange CmdletLogs
Date:          22.02.2018 23:49:32
Event ID:      1
Task Category: General
Level:         Information
Keywords:      Classic User:          N/A
Computer:      EX16.msxfaq.net
Description:
Cmdlet suceeded. Cmdlet 
Test-MigrationServerAvailability, parameters 
   -Credentials "System.Management.Automation.PSCredential" 
   -Autodiscover "True"
   -ExchangeRemoteMove "True" 
   -EmailAddress "migration@msxfaq.net".

Wenn der Endpunkt nicht per Autodiscover ermittelt werden kann, dann fragt Exchange nach dem FQDN des Servers.

Wenn dann der Zugriff auf den MRS-Endpunkt erfolgreich war, können Sie diese Konfiguration unter einen Namen abspeichern:

Exchange kann durchaus mehrere Migrationsendpunkte speichern. Die Anlage kann natürlich auf per PowerShell erfolgen

Migration beauftragen

Die Verlagerung eines Postfachs von einem Exchange Server zu einem anderen erfolgt komplett im Hintergrund durch den "Mailbox Replication Server". Der Zielserver ist dabei die aktive Komponenten. Dort wird der Auftrag platziert. Die Migration eines Postfachs oder mehrerer Postfächer können Sie per ECP anlegen.

Im ersten Schritt müssen Sie die Benutzer auswählen, die sie migrieren wollen.

Über das "+" können Sie MailUser aus ihrem lokalen Active Directory direkt auswählen. Beachten Sie aber, dass diese Objekte entsprechend vorbereitet sein müssen. Ein Benutzer kann auch immer nur in genau einem Migrationsbatch enthalten sein. Wenn Sie also irrtümlich einen Benutzer erneut in eine MIgration aufnehmen, dann wird der dort alleine wieder entfernt.

Wenn ihnen die Auswahl der Benutzer zu mühselig ist, dann können Sie auch eine CSV-Datei mit den Mailadressen der relevanten Benutzer hochladen. Wenn Sie wie in meinem Fall genau einen Endpunkt haben, dann ist die Auswahl des Endpunkts nur eine Bestätigung

Ansonsten werden Sie hier dann nach den gleichen Informationen gefragt, die sie bei der Anlage des Migrationsendpunkts angeben, d.h. Benutzername und Kennwort eines Administrators der Quelle und ggfls. den Servernamen. Exchange nutzt dann einen temporären Migrationsendpunkt für genau diesen Job. Dann müssen sie dem Job noch einen Namen geben und die Zieldatenbank für Postfach und ggfls. Archiv

Zuletzt geben Se noch eine Kontaktperson an, die über den Status per Mail informiert wird und bestimmen, wann der Job startet und ob er automatisch die Umstellung vornehmen soll.

In der Job-Übersicht sehen Sie die verschiedenen Aufträge und ihr aktueller Status. Dieser Job war natürlich sehr schnell abgeschlossen und daher ist rechts auch das "Migrationsbatch abschließen" schon aktiv:

Über die Details können Sie sich für jedes Postfach in dem Job die Informationen anzeigen lassen, wie viele Elemente synchronisiert und übersprungen worden.

Während der Synchronisation bleibt das Objekt im Ziel weiterhin ein "MailUser", obwohl es natürlich eine passende Datenbank gibt.

[PS] C:\>get-recipient User1 |fl *

Identity                           : msxfaq.net/Demoaccounts/User1
Alias                              : User1
ArchiveGuid                        : 00000000-0000-0000-0000-000000000000
EmailAddresses                     : {smtp:User1@msxfaq.net,User1@msxfaq.de}
ExternalEmailAddress               : SMTP:User1@msxfaq.net
DisplayName                        : User1
FirstName                          : User1
HiddenFromAddressListsEnabled      : False
EmailAddressPolicyEnabled          : True
LastName                           :
Name                               : User1
Office                             :
ObjectCategory                     : msxfaq.net/Configuration/Schema/Person
OrganizationalUnit                 : msxfaq.net/Demoaccounts
PrimarySmtpAddress                 : User1@msxfaq.net
RecipientType                      : MailUser
RecipientTypeDetails               : MailUser
SamAccountName                     : User1
ServerLegacyDN                     :
ServerName                         :
AddressListMembership              : {\All Users, \Default Global Address List, \Globale Standardadressliste}
OwaMailboxPolicy                   :
AddressBookPolicy                  :
SharingPolicy                      :
RetentionPolicy                    :
ShouldUseDefaultRetentionPolicy    : False
MailboxMoveTargetMDB               : Mailboxes
MailboxMoveSourceMDB               :
MailboxMoveFlags                   : CrossOrg, Pull, Suspend
MailboxMoveRemoteHostName          : owa.msxfaq.net
MailboxMoveBatchName               : MigrationService:MIG4
MailboxMoveStatus                  : AutoSuspended
MailboxRelease                     :
ArchiveRelease                     :
IsValidSecurityPrincipal           : False
LitigationHoldEnabled              : False
Capabilities                       : {}
ArchiveState                       : None
SKUAssigned                        :
WhenMailboxCreated                 :
UsageLocation                      :
ExchangeGuid                       : c3066a58-dffc-4fbb-8b2a-01570254b570
ArchiveStatus                      : None
ExchangeVersion                    : 0.10 (14.0.100.0)
Guid                               : 91a953ff-614d-459d-a995-47ffa8beea72
ObjectClass                        : {top, person, organizationalPerson, User}
WhenChanged                        : 23.02.2018 17:27:37
WhenCreated                        : 22.02.2018 23:42:50
WhenChangedUTC                     : 23.02.2018 16:27:37
WhenCreatedUTC                     : 22.02.2018 22:42:50
OrganizationId                     :
Id                                 : msxfaq.net/Demoaccounts/User1
OriginatingServer                  : DC1.msxfaq.net
IsValid                            : True

Der Request sollte nicht allzu lange in diesem Status verbleiben. Er hat im Ziel ja ein Postfach angelegt, zu dem es aber kein AD-Konto gibt. Es ist aus Sicht des Ziel-Systems ein "Deleted Postfach" und je nach Einstellung auf dem Store (Default 30 Tage) wird des danach wieder gelöscht. Zudem synchronisiert der Exchange 2013/2016-Zielserver die Mailbox alle 24h.

Job abschließen

Wenn der Status, wie hier, dann ein "AutoSuspended" ist, dann sind alle Mails schon im Ziel und sie können den Migrationsjob abschließen. Auch das geht per ECP und per PowerShell. Nachdem die Synchronisation aller Postfächer erfolgt ist, können Sie Exchange anweisen den Job abzuschließen

Oder natürlich per GUI

Nach einiger Zeit sollte der Batch dann den Status "Abgeschlossen" haben.

Exchange hat keine Logik um diese Batches aufzuräumen. Sie müssen also schon selbst später dafür sorgen diese Batches zu löschen.

Was beim "Abschliessen" dann passiert ist schnell erzählt:

  • Exchange trägt in der Quelle eine Weiterleitung ein
    So werden Mails an die Quelle nun an das Ziel gesendet. Die "Zielzustellungsdomäne" haben Sie beim Erstellen des Migration-Endpunkts ja angegeben. Diese Weiterleitung dort zum einen dafür, dass Mails an das alte System wieder an das Zielsystem weiter geleitet werden. Wichtiger ist aber, dass der Client bei einem Autodiscover nun eine Umleitung auf diese Zieldomäne erhält.
  • Der MailUser im Ziel wird zu einer Mailbox ohne Weiterleitung.
    Nun landen Mails schon im neuen Posttach

In der Quelle wurde aus der Mailbox nun ein MailUser, wie folgender Auszug bestätigt:

DeliverToMailboxAndForward             : False
ExchangeGuid                           : c3066a58-dffc-4fbb-8b2a-01570254b570
ArchiveGuid                            : 00000000-0000-0000-0000-000000000000
ArchiveName                            : {}
ArchiveQuota                           : 100 GB (107,374,182,400 bytes)
ArchiveWarningQuota                    : 90 GB (96,636,764,160 bytes)
ProhibitSendQuota                      : Unlimited
ProhibitSendReceiveQuota               : Unlimited
IssueWarningQuota                      : Unlimited
ForwardingAddress                      :
ArchiveDatabase                        :
ArchiveStatus                          : None
DisabledArchiveDatabase                :
DisabledArchiveGuid                    : 00000000-0000-0000-0000-000000000000
MailboxProvisioningConstraint          :
MailboxRegion                          :
MailboxRegionLastUpdateTime            :
MailboxProvisioningPreferences         : {}
ExchangeUserAccountControl             : None
ExternalEmailAddress                   : SMTP:User1@msxfaq.de
UsePreferMessageFormat                 : False
JournalArchiveAddress                  :
MessageFormat                          : Text
MessageBodyFormat                      : Text
MacAttachmentFormat                    : BinHex
ProtocolSettings                       : {RemotePowerShell§1}
RecipientLimits                        : Unlimited
SamAccountName                         : use1
UseMapiRichTextFormat                  : UseDefaultSettings 
UserPrincipalName                      : User1@msxfaq.de
WindowsLiveID                          :
MicrosoftOnlineServicesID              :
MailboxMoveTargetMDB                   :
MailboxMoveSourceMDB                   :
MailboxMoveFlags                       : None
MailboxMoveRemoteHostName              :
MailboxMoveBatchName                   :
MailboxMoveStatus                      : None
MailboxRelease                         :
ArchiveRelease                         :
ImmutableId                            :
PersistedCapabilities                  : {}
SKUAssigned                            :
ResetPasswordOnNextLogon               : False
WhenMailboxCreated                     : 11.01.2018 20:47:51
LitigationHoldEnabled                  : False
SingleItemRecoveryEnabled              : False
ComplianceTagHoldApplied               : False
DelayHoldApplied                       : False
RetentionHoldEnabled                   : False
EndDateForRetentionHold                :
StartDateForRetentionHold              :
RetentionComment                       :
RetentionUrl                           :
LitigationHoldDate                     :
LitigationHoldOwner                    :
RetainDeletedItemsFor                  : 14.00:00:00
CalendarVersionStoreDisabled           : False
UsageLocation                          :
MailboxLocations                       : {}
IsSoftDeletedByRemove                  : False
IsSoftDeletedByDisable                 : False
tWhenSoftDeleted                        :
InPlaceHolds                           : {}
RecoverableItemsQuota                  : 30 GB (32,212,254,720 bytes)
RecoverableItemsWarningQuota           : 20 GB (21,474,836,480 bytes) 
UserCertificate                        : {} 
UserSMimeCertificate                   : {}
AccountDisabled                        : False
StsRefreshTokensValidFrom              :
DataEncryptionPolicy                   :
OtherMail                              :
GuestInfo                              :
Extensions                             : {}
HasPicture                             : False
HasSpokenName                          : False
IsDirSynced                            : False
AcceptMessagesOnlyFrom                 : {}
AcceptMessagesOnlyFromDLMembers        : {}
AcceptMessagesOnlyFromSendersOrMembers : {}
AddressListMembership                  : {\All Mail Users(VLV), \Alle Benutzer, \All Recipients(VLV),
                                         \new-globaladdresslist}
AdministrativeUnits                    : {}
Alias                                  : User1
BypassModerationFromSendersOrMembers   : {}
OrganizationalUnit                     : msxfaq.de/org2orge2016
DisplayName                            : User1
EmailAddresses                         : {SMTP:User1@msxfaq.de, smtp:User1-b@msxfaq.de, X500:/o=msxfaq
                                         /ou=Exchange Administrative Group
                                         (FYDIBOHF23SPDLT)/cn=Recipients/cn=User1,
                                         x500:/o=ExchangeLabs/ou=Exchange Administrative Group
                                         (FYDIBOHF23SPDLT)/cn=Recipients/cn=User1...}
GrantSendOnBehalfTo                    : {}
ExternalDirectoryObjectId              :
HiddenFromAddressListsEnabled          : False
LastExchangeChangedTime                :
LegacyExchangeDN                       : /o=msxfaq/ou=Exchange Administrative Group
                                         (FYDIBOHF23SPDLT)/cn=Recipients/cn=User1
MaxSendSize                            : Unlimited
MaxReceiveSize                         : Unlimited
ModeratedBy                            : {}
ModerationEnabled                      : False
EmailAddressPolicyEnabled              : True
PrimarySmtpAddress                     : Hans@netatwork.de
RecipientType                          : MailUser
RecipientTypeDetails                   : MailUser
WindowsEmailAddress                    : Hans@netatwork.de
Identity                               : msxfaq.de/org2orge2016/User1
Name                                   : User1

Vergessen Sie aber nicht, dass Sie für diese Umstellung natürlich auch die anderen Randbedingungen erfüllen müssen wie:

  • Umstellen MX-Record
    Neue Mails sollten gleich beim Ziel aufkommen
  • Anpassung SPF
    Stellen Sie sicher, dass ausgehende Mails von dem neuen System auch im Internet angenommen werden
  • Umstellen Autodiscover
    Die Clients sollten auch in der neuen Umgebung per Autodiscover eine Antwort bekommen.
  • Mailbox-Typ anpassen
    Ich habe noch keine Räume oder Shared Mailboxes migriert aber denke nicht, dass der Typ hier angepasst wird. Das ist dann noch eine Nacharbeit nach der Umstellung.
  • LegacyExchangeDN und X500
    Das neue Postfach im Ziel hat leider nicht den alten LegacyExchangeDN als X500 Adresse bekommen. Dies kann man aber noch anpassen
  • Berechtigungen und Calendar Agenten
    Gerade auf "Shared Mailbox" oder Räume sind durch die Migration die Berechtigungen und AutoAccept-Funktionen nicht mit gekommen.
  • Regeln und OOF
    Ihre Anwender sollten auch noch mal prüfen, ob die Regeln und Out of Office-Einstellungen noch passen. In der Regel kommen Sie nicht mit oder wenn Sie mitkommen, dann funktionieren sie nicht auf Anhieb, da eventuell Abhängigkeiten an der Exchange Organisation hängen.

Es bleibt also schon etwas zu tun und vielleicht können Sie nun ermessen, warum es durchaus einen Markt für Dritthersteller gibt, die sich

Mögliche Fehler

Fehler bei der Migration sehen Sie sowohl in der Übersicht als auch bei den Details jeder einzelnen Mailbox. Das geht natürlich auch per PowerShell. Der Befehl "Get-MigrationUser" liefert nicht das Dienstkonto der Migration sondern die aktuell in der Migration befindlichen Benutzer.

Get-MigrationUser |fl

Identity                  : User1@msxfaq.net
Guid                      : 4f70d8ae-2169-40b0-afb9-f4b72b6e657a
Identifier                : User1@msxfaq.net
BatchId                   : Mig1
MailboxIdentifier         : User1@msxfaq.net
RecipientType             : MailUser
SkippedItemCount          : 0
SyncedItemCount           : 0
MailboxGuid               : 00000000-0000-0000-0000-000000000000
MailboxLegacyDN           :
RequestGuid               : 00000000-0000-0000-0000-000000000000
LastSuccessfulSyncTime    :
Status                    : Failed
State                     :
Flags                     :
WorkflowStep              :
WorkflowStage             :
TriggeredAction           :
ErrorSummary              : Das Benutzerobjekt für 'User1@msxfaq.net' besitzt keine gültige ExchangeGuid-Eigenschaft und kann
                            nicht migriert werden.
StatusSummary             : Failed
LastSubscriptionCheckTime :
SupportedActions          : Remove
IsValid                   : True

In dem Beispiel habe ich vergessen im Zielkonto das Feld "ExchangeGUID" zu setzen. Das wird durch Prepare-Moverequest.ps1 normalerweise gesetzt. Wenn ich aber das Skript nicht genutzt habe, dann muss ich das Feld selbst setzen.

So gibt es noch ganz viele andere Fehler. Mit der Beschreibung finden Sie im Internet aber in den meisten Fällen auch die Ursache und Wege zur Lösung.

Cleanup/Rückbau

Vergessen Sie nicht hinterher den Migrationsbatch wieder zu beseitigen. Zudem sind die Postfachdaten und das Postfach nun im Ziel angekommen aber hat natürlich eine neue Mailadresse. Mails an die alte Domäne werden immer noch über den alten Exchange Server und eine dort eingerichtete Weiterleitung in das Ziel übertragen. Wenn Sie also die komplette SMTP-Domäne mit allen Empfängern verlagert haben, dann sollten Sie auch das eingehende Mailrouting entsprechend umstellen, damit die alte Umgebung nichts mehr mit den Mails am Hut hat.

Aber auch ausgehend muss man noch mal hinschauen. Wenn die Ziel Postfächer nämlich weiter die alte Domäne verwenden sollten, dann muss diese als "Primär" eingestellt werden. Das ist mit Empfängerrichtlinien relativ schnell umgesetzt. Vergessen Sie dabei aber nicht, dass der neue Server dann vorab schon mal im SPF-Record als "erlaubter Sender" eingetragen sein sollte und auch ihr ausgehender Spamfilter die neue Domain kennen sollte.

Weitere Links