Leistung und bewährte Methoden für Microsoft 365- und Office 365-E-Mail-Migration

Es gibt viele Möglichkeiten zum Migrieren von E-Mail-Daten für eine lokal gehostete organization zu Microsoft 365 oder Office 365. Bei der Planung einer Migration zu Microsoft 365 oder Office 365 hilft ein klares Verständnis des Datenmigrationsprozesses und der Datenmigrationsgeschwindigkeit den Administratoren, besser zu planen.

Übersicht über die Migration von E-Mails zu Microsoft 365 oder Office 365

Microsoft 365 oder Office 365 unterstützt mehrere Methoden zum Migrieren von E-Mails, Kalendern und Kontaktdaten aus Ihrer vorhandenen Messagingumgebung zu Microsoft 365 oder Office 365, wie unter Möglichkeiten zum Migrieren mehrerer E-Mail-Konten zu Microsoft 365 oder Office 365 beschrieben.

Fragen zu Netzwerk und Leistung zu Microsoft 365 oder Office 365 finden Sie unter Netzwerkplanung und Leistungsoptimierung für Microsoft 365 oder Office 365.

Häufig verwendete Migrationsmethoden

Leistung für Migrationsmethoden

In den folgenden Abschnitten werden die Workloads der Postfachmigration und die beobachteten Leistungsergebnisse für die verschiedenen Migrationsmethoden zum Migrieren von Postfächern und Postfachdaten zu Microsoft 365 oder Office 365 verglichen. Diese Ergebnisse basieren auf internen Tests und tatsächlichen Kundenmigrationen zu Microsoft 365 oder Office 365.

Workloads für die Kundenmigration

In der folgenden Tabelle werden die verschiedenen Workloads, die mit einer typischen Migration verbunden sind, sowie die entsprechenden Herausforderungen und Optionen beschrieben.

Wenn Postfächer innerhalb von Microsoft 365-Rechenzentren migriert werden, erfordert jede Postfachverschiebung oder Massenpostfachverschiebung Zeit, bis der Vorgang abgeschlossen ist. Es gibt eine Reihe von Faktoren, wie z. B. die Microsoft 365-Dienstaktivität, die sich genau auf die Zeit auswirken können. Der Dienst wurde entwickelt, um diskretionäre Workloads wie Postfachverschiebungen einzuschränken, um sicherzustellen, dass der Dienst für alle Benutzer optimal ausgeführt wird. Sie können jedoch weiterhin davon ausgehen, dass Postfachverschiebungen in Abhängigkeit von der Verfügbarkeit der Ressourcen des Diensts verarbeitet werden. Weitere Informationen zur Ressourcendrosselung finden Sie in diesem Blogbeitrag.

Geschätzte Dauer für die Postfachmigration in Exchange Online

Um Sie bei der Planung Ihrer Migration zu unterstützen, enthalten die folgenden Tabellen Richtlinien dazu, wann mit dem Abschluss von Massenpostfachmigrationen oder einzelnen Migrationen gerechnet werden kann. Diese Schätzungen basieren auf einer Datenanalyse früherer Kundenmigrationen. Da jede Umgebung einzigartig ist, kann die genaue Migrationsgeschwindigkeit variieren.

Dauer der Postfachmigration basierend auf den Profilen der Postfachgröße:

• GoLocal/Multi-Geo/Verschlüsselung in Exchange Online

  Arbeitslast	Postfachgröße (GB)	P50 (50. Perzentil Dauer) (Tage)	P90 (90. Perzentil Dauer) (Tage)
  GoLocal/Multi-Geo/Verschlüsselung	0 - 10	1	1
  GoLocal/Multi-Geo/Verschlüsselung	10 - 50	2	6
  GoLocal/Multi-Geo/Verschlüsselung	50 - 100	4	11
  GoLocal/Multi-Geo/Verschlüsselung	100 - 200	6	14
  GoLocal/Multi-Geo/Verschlüsselung	> 200	Nicht unterstützt	Nicht unterstützt

• Onboarding in Exchange Online von lokalen Exchange-Servern (gestaffelte/Übernahme/)

  Arbeitslast	Postfachgröße (GB)	P50 (50. Perzentil Dauer) (Tage)	P90 (90. Perzentil Dauer) (Tage)
  Onboarding von lokal	0 - 10	1	3
  Onboarding von lokal	10 - 50	2	6
  Onboarding von lokal	50 - 100	4	13
  Onboarding von lokal	100 - 200	10	31
  Onboarding von lokal	> 200	Nicht unterstützt	Nicht unterstützt

• Mandantenübergreifende Migration zu Exchange Online (verwenden der Microsoft-Erstanbieterlösung oder der Lösungen von Drittanbietern).

  Arbeitslast	Postfachgröße (GB)	P50 (50. Perzentil Dauer) (Tage)	P90 (90. Perzentil Dauer) (Tage)
  Mandantenübergreifend	0 - 10	1	1
  Mandantenübergreifend	10 - 50	1	2
  Mandantenübergreifend	50 - 100	2	5
  Mandantenübergreifend	100 - 200	3	6
  Mandantenübergreifend	> 200	Nicht unterstützt	Nicht unterstützt

• Spezialisiertes Onboarding für Exchange Online von Gmail/G Suite/GWS (EAC, PowerShell)

  Arbeitslast	Postfachgröße (GB)	P50 (50. Perzentil Dauer) (Tage)	P90 (90. Perzentil Dauer) (Tage)
  Spezialisiertes Gmail-Onboarding	0 - 10	1	2
  Spezialisiertes Gmail-Onboarding	10 - 50	1	8
  Spezialisiertes Gmail-Onboarding	50 - 100	3	12
  Spezialisiertes Gmail-Onboarding	100 - 200	5	19
  Spezialisiertes Gmail-Onboarding	> 200	Nicht unterstützt	Nicht unterstützt

• Onboarding in Exchange Online aus IMAP-Quellen (andere IMAP-Quellen, PowerShell, Gmail über IMAP)

  Arbeitslast	Postfachgröße (GB)	P50 (50. Perzentil Dauer) (Tage)	P90 (90. Perzentil Dauer) (Tage)
  Generisches IMAP-Onboarding	0 - 10	1	1
  Generisches IMAP-Onboarding	10 - 50	1	2
  Generisches IMAP-Onboarding	50 - 100	1	8
  Generisches IMAP-Onboarding	100 - 200	3	29
  Generisches IMAP-Onboarding	> 200	Nicht unterstützt	Nicht unterstützt

• Onboarding in Exchange Online über PST-Import

  Arbeitslast	Postfachgröße (GB)	P50 (50. Perzentil Dauer) (Tage)	P90 (90. Perzentil Dauer) (Tage)
  PST-Import	0 - 10	1	1
  PST-Import	10 - 50	1	3
  PST-Import	50 - 100	2	5
  PST-Import	100 - 200	3	6
  PST-Import	> 200	Nicht unterstützt	Nicht unterstützt

Migrationsleistungsfaktoren

Die Migration von Postfächern/E-Mails hat mehrere gemeinsame Faktoren, die sich auf die Migrationsleistung auswirken.

Allgemeine Migrationsleistungsfaktoren

In der folgenden Tabelle ist eine Liste der allgemeinen Faktoren aufgeführt, die sich auf die Migrationsleistung auswirken können. Weitere Details werden in den Abschnitten behandelt, in denen die einzelnen Migrationsmethoden beschrieben sind.

Netzwerkleistungsfaktoren

In diesem Abschnitt werden bewährte Methoden zur Verbesserung der Netzwerkleistung bei der Migration beschrieben. Die Diskussion ist allgemein ausgerichtet, da die Hardware von Drittanbietern und Internetdienstanbieter (ISPs) während der Migration die größte Auswirkung auf die Leistung des Netzwerks haben.

Verwenden Sie Exchange Analyzer, um Ihre Netzwerkkonnektivität mit Microsoft 365 oder Office 365 besser zu verstehen. Wenn Sie die Exchange Analyzer-Tests in Microsoft-Support und dem Wiederherstellungsassistenten ausführen möchten, wechseln Sie zu "Erweiterte Diagnose" > Exchange Online > Überprüfen der Exchange Online-Netzwerkkonnektivität > Ja. Informieren Sie sich über den Microsoft-Support- und Wiederherstellungs-Assistenten, um mehr über Microsoft-Support und den Wiederherstellungs-Assistenten zu erfahren.

Für eine tiefergehende Analyse von Migrationen in Ihrer Umgebung sehen Sie sich unsere Leistungsanalyse für die Postfachmigration an. Der Beitrag umfasst ein Skript, das Sie beim Analysieren von Verschiebungsanforderungen unterstützt.

Microsoft 365 und Office 365 Drosselung

Microsoft 365 und Office 365 verwenden verschiedene Drosselungsmechanismen, um die Sicherheit und Dienstverfügbarkeit sicherzustellen. Die folgenden drei Arten von Einschränkungen können sich auf die Migrationsleistung auswirken:

• Benutzereinschränkung
• Migrationsdiensteinschränkung
• Auf dem Ressourcenstatus basierende Einschränkung

Microsoft 365- und Office 365-Benutzerdrosselung

Die Benutzereinschränkung wirkt sich auf die meisten Drittanbieter-Migrationstools sowie auf die Migrationsmethode für Clientuploads aus. Diese Migrationsmethoden verwenden Clientzugriffsprotokolle wie den Remoteprozeduraufruf (Remote Procedure Call, RPC) über HTTP, um Postfachdaten zu Microsoft 365- oder Office 365-Postfächern zu migrieren. Diese Tools werden verwendet, um Daten von Plattformen wie IBM Lotus Domino und Novell GroupWise zu migrieren.

Die Benutzerdrosselung ist die restriktivste Drosselungsmethode in Microsoft 365 und Office 365. Da die Benutzereinschränkung eingerichtet wird, um einzelnen Endbenutzern entgegenzuwirken, überschreitet jede Nutzung auf Anwendungsebene die Einschränkungsrichtlinie und führt zu einer verlangsamten Datenmigration.

Microsoft 365- und Office 365-Migrationsdienstdrosselung

Die Drosselung des Migrationsdiensts betrifft alle Microsoft 365- oder Office 365-Migrationstools. Die Drosselung des Migrationsdiensts verwaltet die Parallelität der Migration und die Zuweisung von Dienstressourcen für Microsoft 365- oder Office 365-Migrationslösungen.

Die Migrationsdiensteinschränkung wirkt sich auf Migrationen aus, die mithilfe der folgenden Migrationsmethoden durchgeführt wurden:

• IMAP-Migration
• Exchange-Übernahmemigration
• Mehrstufige Exchange-Migration
• Hybridmigrationen (auf dem MRSProxy-Dienst basierende Verschiebungen in eine Hybridumgebung)

Ein Beispiel für die Migrationsdiensteinschränkung ist das Kontrollieren der Anzahl der Postfächer, die während einfacher Exchange- und IMAP-Migrationen gleichzeitig migriert werden. Der Standardwert ist 20. Das bedeutet, dass jederzeit maximal 20 Postfächer aus allen Migrationsbatches migriert werden. Sie können die Anzahl gleichzeitiger Postfachmigrationen für einen Migrationsbatch entweder im Exchange Admin Center oder in Windows PowerShell erhöhen. Weitere Informationen zum Optimieren dieser Einstellung finden Sie unter Verwalten von Migrationsbatches in Microsoft 365 oder Office 365.

Microsoft 365- oder Office 365-Drosselung der Ressourcenintegrität

Alle Migrationsmethoden unterliegen der Kontrolle durch die Verfügbarkeitseinschränkung. Die Dienstdrosselung von Microsoft 365 oder Office 365 wirkt sich jedoch nicht so stark auf Microsoft 365- oder Office 365-Migrationen aus wie die anderen zuvor beschriebenen Arten der Drosselung.

Die auf dem Ressourcenstatus basierende Einschränkung ist die am wenigsten offensive Einschränkungsmethode. Sie erfolgt, um ein Problem mit der Dienstverfügbarkeit zu verhindern, das die Endbenutzer und wichtige Dienstvorgänge beeinträchtigen könnte.

Bevor sich die Leistung des Dienstes so weit verschlechtert, dass die Leistung des Endbenutzers beeinträchtigt werden könnte, werden Hybridmigrationen verzögert, bis die Leistung wiederhergestellt ist und der Dienst zu einem Niveau unter dem Einschränkungsschwellenwert zurückkehrt.

Im Folgenden wird angezeigt, was den Kunden in Bezug auf die Dauer des Stillstands mithilfe des Get-MoveRequestStatistics - <> -IncludeReport Cmdlets angezeigt wird:

$R.REPORT.TARGETTHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 00:02:07.6222549
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:38:41.7018480
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:26:34.6588104
DISKLATENCYTHROTTLE : 1.15:45:37.7873632

$R.REPORT.SOURCETHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 3.03:21:07.7192848
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:00:00

CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:00:00
DISKLATENCYTHROTTLE : 00:20:47.1101552
MDBMAINTENANCETHROTTLE : 00:00:00

Lösung und Übung:

Wenn Sie sich in einer vergleichbaren Situation befinden, warten Sie, bis die Microsoft 365- oder Office 365-Ressourcen verfügbar sind.

Leistungsfaktoren und bewährte Methoden für Migrationen in Nicht-Hybridbereitstellungen

In diesem Abschnitt werden die Faktoren beschrieben, die sich auf Migrationen auswirken, die die IMAP-, Übernahme- oder mehrstufigen Migrationsmethoden verwenden. Darüber hinaus werden die bewährten Methoden zum Optimieren der Migrationsleistung bezeichnet.

Faktor 1: Datenquelle für Migrationen von nicht-hybriden Bereitstellungen

In der folgenden Tabelle werden die durch Quellserver in Ihrer aktuellen E-Mail-Organisation verursachten Auswirkungen auf die Migration sowie die bewährten Methoden zum Verringern dieser Auswirkungen beschrieben:

Faktor 2: Migrationsserver für Migrationen von Nicht-Hybrid-Bereitstellungen

IMAP-, Übernahme- und mehrstufige Migrationen sind über die Cloud eingeleitete Migrationsmethoden mit Datenabruf, daher sind keine dedizierten Migrationsserver erforderlich. Die Protokollhosts mit Internetzugriff (IMAP oder RPC über HTTP-Protokoll) fungieren jedoch als Migrationsserver für die Migration von Postfächern und Postfachdaten zu Microsoft 365 oder Office 365. Daher gelten die Migrationsleistungsfaktoren und bewährten Methoden, die im vorherigen Abschnitt über den Datenquellenserver für Ihre aktuelle E-Mail-Organization beschrieben wurden, auch für die Internet-Edgeserver. Für Exchange 2007-, Exchange Server 2010- und Exchange 2013-Organisationen fungiert der Clientzugriffsserver als Migrationsserver.

Weitere Informationen finden Sie unter:

• Exchange Server 2007: Überwachen von Clientzugriffsservern

• Exchange Server 2010: Clientzugriffsserverindikatoren

• Exchange Server 2013: Exchange-Workloadverwaltung

• Exchange Server 2016: Verwaltung der Benutzerworkload in Exchange Server

• Exchange Server 2019: Verwaltung der Benutzerworkload in Exchange Server

Faktor 3: Migrationsmodul für Migrationen von Nicht-Hybrid-Bereitstellungen

IMAP-, Übernahme- und mehrstufige Exchange-Migrationen werden mithilfe des Migrations-Dashboards im Exchange Admin Center durchgeführt. Dies unterliegt der Drosselung des Microsoft 365- oder Office 365-Migrationsdiensts.

Lösung und Übung:

Kunden können jetzt die Parallelität der Migration (z. B. die Anzahl der gleichzeitig zu migrierenden Postfächer) mithilfe von Windows PowerShell angeben. Der Standardwert ist 20 Postfächer. Nachdem Sie einen Migrationsbatch erstellt haben, können Sie dieses mit dem folgenden Windows PowerShell-Cmdlet auf maximal 100 erhöhen.

Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>

Weitere Informationen finden Sie unter Verwalten von Migrationsbatches in Microsoft 365 oder Office 365.

Faktor 4: Netzwerk für Migrationen von nicht hybriden Bereitstellungen

Verifizierungstests:

Je nach Migrationsmethode können Sie die folgenden Überprüfungstests ausprobieren:

• IMAP-Migrationen: Füllen Sie ein Quellpostfach vorab mit Beispieldaten auf. Stellen Sie dann über das Internet (außerhalb Ihres lokalen Netzwerks) mit einem standardmäßigen IMAP-E-Mail-Client wie Microsoft Outlook eine Verbindung mit dem Quellpostfach her, und messen Sie anschließend die Netzwerkleistung, indem Sie bestimmen, wie lange das Herunterladen aller Daten aus dem Quellpostfach dauert. Der Durchsatz sollte dem entsprechen, den Kunden mit dem IMAP-Migrationstool in Microsoft 365 oder Office 365 erzielen können, vorausgesetzt, es gibt keine weiteren Einschränkungen.

• Übernahme- und mehrstufige Exchange-Migrationen: Füllen Sie ein Quellpostfach vorab mit Beispieldaten auf. Stellen Sie dann über das Internet (außerhalb Ihres lokalen Netzwerks) eine Verbindung mit dem Quellpostfach mit Outlook mithilfe des RPC-über-HTTP-Protokolls her. Stellen Sie sicher, dass Sie eine Verbindung im Cache-Modus herstellen. Messen Sie die Leistung des Netzwerks, indem Sie überprüfen, wie lange es dauert, alle Daten aus dem Quellpostfach zu synchronisieren. Der Durchsatz sollte dem vergleichbar sein, den Kunden mit den einfachen Exchange-Migrationstools in Microsoft 365 oder Office 365 erzielen können, vorausgesetzt, es gibt keine weiteren Einschränkungen.

Während einer tatsächlichen IMAP-, Übernahme- oder mehrstufigen Exchange-Migration kommt es zu einem gewissen Mehraufwand. Der tatsächliche Durchsatz sollte jedoch den Ergebnissen dieser Überprüfungstest ähnlich sein.

Faktor 5: Microsoft 365 und Office 365 Service für Migrationen von nicht hybriden Bereitstellungen

Die auf der Ressourcenintegrität basierende Drosselung von Microsoft 365- oder Office 365-Ressourcen wirkt sich auf Migrationen aus, die die nativen einfachen Microsoft 365- oder Office 365-Migrationstools verwenden. Weitere Informationen finden Sie im Abschnitt zur integritätsbasierten Drosselung von Ressourcen bei Microsoft 365 oder Office 365.

Verschiebungsanforderungen in Microsoft 365 oder Office 365

Allgemeine Informationen zum Abrufen von Informationen zum Status für Verschiebungsanforderungen finden Sie unter Anzeigen von Verschiebungsantragseigenschaften:

• Postfach verschieben

• [Get-MoveRequestStatistics]](/powershell/module/exchangepowershell/get-moverequeststatistics)

Im Microsoft 365- oder Office 365-Dienst werden die Migrationswarteschlange und die für Migrationen zugewiesenen Dienstressourcen zwischen den Mandanten gemeinsam genutzt und wirken sich darauf aus, wie Verschiebungsanforderungen in jeder Phase des Verschiebungsprozesses verwaltet werden.

Es gibt zwei Arten von Verschiebungsanforderungen in Microsoft 365 und Office 365:

• Onboarding von "Verschiebungsanforderungen": Die Migrationen neuer Kunden gelten als Onboarding-Verschiebungsanforderungen. Diese Anforderungen weisen eine normale Priorität auf.

• Datacenter interne "Verschiebungsanforderungen": Hierbei handelt es sich um Postfachverschiebungsanforderungen, die von Rechenzentrumsbetriebsteams initiiert werden. Diese Anforderungen haben eine geringere Priorität, da die Endbenutzererfahrung nicht betroffen ist, wenn die Verschiebungsanforderung verzögert wird.

Potenzielle Auswirkungen und Verzögerungen für Verschiebungsanforderungen mit dem Status „In Warteschlange eingereiht“ und „Wird ausgeführt“

• Verschiebungsanforderungen in der Warteschlange: Dieser Status gibt an, dass die Verschiebung in die Warteschlange eingereiht wurde und darauf wartet, dass der Exchange-Postfachreplikationsdienst sie aufnimmt. Für Exchange 2003-Verschiebungsanforderungen können Benutzer in dieser Phase weiterhin auf ihre Postfächer zugreifen.

  Zwei Faktoren beeinflussen, welche Anforderung vom Postfachreplikationsdienst ausgewählt wird:

  • Priorität: Verschiebungsanforderungen in der Warteschlange mit einer höheren Priorität werden vor Verschiebungsanforderungen mit niedrigerer Priorität aufgenommen. Dadurch wird sichergestellt, dass Verschiebungsanforderungen von Kundenmigrationen immer vor internen Verschiebungsanforderungen von Datencentern verarbeitet werden.

  • Position in der Warteschlange: Wenn Verschiebungsanforderungen dieselbe Priorität haben, wird sie umso früher vom Postfachreplikationsdienst aufgenommen, je früher die Anforderung in die Warteschlange kommt. Da möglicherweise mehrere Kunden gleichzeitig Postfachmigrationen durchführen, ist es normal, dass neue Verschiebungsanforderungen in der Warteschlange verbleiben, bevor sie verarbeitet werden.

Häufig wird die Zeit, die Postfachanforderungen vor der Verarbeitung in der Warteschlange warten, während der Migrationsplanung nicht berücksichtigt. Dies führt zu Kunden, für die nicht genügend Zeit reserviert wurde, um alle geplanten Migrationen abzuschließen.

• Laufende Verschiebungsanforderungen: Dieser Status gibt an, dass die Verschiebung noch in Bearbeitung ist. Wenn es sich hierbei um die Verschiebung eines Onlinepostfachs handelt, kann der Benutzer weiterhin auf sein Postfach zugreifen.

Nachdem die Verschiebungsanforderung für das Postfach den Status "In Bearbeitung" aufweist, hat die Priorität keine Bedeutung mehr und neue Verschiebungsanforderungen werden nicht verarbeitet, bis eine vorhandene Verschiebungsanforderung mit dem Status "In Bearbeitung" abgeschlossen wird, auch wenn die neue Verschiebungsanforderung eine höhere Priorität aufweist.

Bewährte Methoden

Planung: Wie bereits erwähnt, sind Exchange 2003-Kunden mehr besorgt darüber, wann Migrationen geplant werden müssen und wie lange sie dauern werden, da Exchange 2003-Benutzer während einer Hybridmigration den Zugriff verlieren.

Bei der Planung der Anzahl der zu migrierenden Postfächer während eines bestimmten Zeitraums, sollten Sie Folgendes berücksichtigen:

• Beziehen Sie die Zeitspanne mit ein, die die Verschiebungsanforderung in der Warteschlange wartet. Diese kann wie folgt berechnet werden:

  (Gesamtzahl der zu migrierenden Postfächer) = ((Gesamtzeit) - (Durchschnittliche Warteschleifenzeit)) * (Migrationsdurchsatz)

  Dabei entspricht der Migrationsdurchsatz der Gesamtzahl der Postfächer, die pro Stunde migriert werden können.

Nehmen Sie beispielsweise an, Sie verfügen für die Migration von Postfächern über ein Zeitfenster von sechs Stunden. Wenn die durchschnittliche Warteschlangenzeit eine Stunde beträgt und Sie einen Migrationsdurchsatz von 100 Postfächern pro Stunde haben, können Sie 500 Postfächer in dem sechsstündigen Zeitrahmen migrieren: 500 = (6 - 1) * 100.

• Starten Sie die Migration früher als anfänglich geplant, um die Zeit in der Warteschlange zu verringern. Wenn sich die Postfächer in der Warteschlange befinden, können Exchange 2003-Benutzer weiterhin auf ihre Postfächer zugreifen.

Bestimmen der Warteschlangenzeit: Die Wartezeit ändert sich ständig, da Microsoft die Migrationszeitpläne der Kunden nicht verwaltet.

Um die potenzielle Zeit in der Warteschlange zu ermitteln, können Kunden eine Testverschiebung für einen Zeitpunkt ansetzen, der mehrere Stunden vor dem Beginn der eigentlichen Migration liegt. Anhand der Zeit, die sich die Anforderung in der Warteschlange befand, können Kunden dann besser einschätzen, wann die Migration gestartet werden sollte und wie viele Postfächer innerhalb eines bestimmten Zeitraums verschoben werden können.

Dies kann beispielsweise der Fall sein, wenn eine Testmigration vier Stunden vor dem Start einer geplanten Migration abgeschlossen wurde. Bei dieser Testmigration hat der Kunde eine Warteschlangenzeit von etwa einer Stunde ermittelt. Dann sollte der Kunde in Erwägung ziehen, die Migration eine Stunde früher als ursprünglich geplant zu starten, um sicherzustellen, dass genügend Zeit bleibt, um alle Migrationen abzuschließen.

Tools von Drittanbietern für Microsoft 365- oder Office 365-Migrationen

Tools von Drittanbietern werden meist in Migrationsszenarien verwendet, die Exchange nicht umfassen, z. B. von Gmail/G Suite/GWS (Google Workspace), IBM Lotus, Domino und Novell GroupWise. In diesem Abschnitt stehen die Migrationsprotokolle der Drittanbieter-Migrationstools im Mittelpunkt und weniger die eigentlichen Produkte und Migrationstools. Die folgende Tabelle enthält eine Liste von Faktoren, die für Drittanbietertools für Microsoft 365- oder Office 365-Migrationsszenarien gelten.

Faktor 1: Datenquelle für Migrationen von Drittanbietertools

Faktor 2: Migrationsserver für Migrationen von Drittanbietertools

Die meisten Tools von Drittanbietern für Microsoft 365- oder Office 365-Migrationen sind Client-initiiert und übertragen Daten per Push nach Microsoft 365 oder Office 365. Diese Tools erfordern in der Regel einen Migrationsserver. Für diese Migrationsserver gelten Faktoren wie Systemleistung, Back-End-Aufgaben und Einschränkungsrichtlinien für die Quellserver.

Lösung und Übung:

Um die Migrationsleistung bei der Verwendung eines Migrationsservers zu verbessern, wenden Sie die gleichen Best Practices wie im Abschnitt Faktor 1: Datenquelle für Migrationen von Drittanbietertools beschrieben.

Faktor 3: Migrationsmodul für Migrationen von Drittanbietertools

Für Migrationstools von Drittanbietern werden am häufigsten die Exchange-Webdienste und das RPC-über-HTTP-Protokoll verwendet.

Exchange-Webdienste:

Exchange-Webdienste ist das empfohlene Protokoll für die Migration zu Microsoft 365 oder Office 365, da es große Datenbatches unterstützt und eine bessere dienstorientierte Drosselung aufweist. In Microsoft 365 oder Office 365 verbrauchen Migrationen mithilfe von Exchange-Webdiensten im Identitätswechselmodus nicht die budgetierte Menge an Microsoft 365- oder Office 365 Exchange-Webdienstressourcen des Benutzers, sondern eine Kopie der budgetierten Ressourcen:

• Alle Identitätswechselaufrufe der Exchange-Webdienste, die über dasselbe Administratorkonto getätigt werden, werden separat vom Budget berechnet, das diesem Administratorkonto zugewiesen ist.

• Für jede Identitätswechselsitzung wird eine Schattenkopie des Budgets des tatsächlichen Benutzers erstellt. Alle Migration für diese bestimmte Sitzung verwenden diese Schattenkopie.

• Die Einschränkung bei einem Identitätswechsel ist auf die einzelne Benutzermigrationssitzung begrenzt.

• Die Drosselungsrichtlinie für Exchange-Webdienste kann im Mandanten vorübergehend geändert werden (für eine Dauer von 30, 60 oder 90 Tagen), um den Abschluss der Migration zu ermöglichen. Dies kann im Hilfebereich des Microsoft 365 Admin Center angefordert werden.

Bewährte Methoden:

• Die Migrationsleistung für Kunden, die Migrationstools von Drittanbietern mit EWA-Identitätswechsel verwenden, konkurriert mit auf Exchange-Webdiensten basierenden Migrationen und der Dienstressourcennutzung durch andere Mandanten. Daher variiert die Migrationsleistung.

• Kunden sollten nach Möglichkeit Migrationstools von Drittanbietern verwenden, die den Identitätswechsel mit Exchange-Webdiensten verwenden, da diese in der Regel schneller und effizienter sind als die Verwendung von Clientprotokollen, z. B. als das RPC-über-HTTP-Protokoll.

RPC über HTTP-Protokoll:

Herkömmliche Migrationslösungen verwenden das RPC-über-HTTP-Protokoll. Diese Methode basiert vollständig auf einem Clientzugriffsmodell wie dem von Outlook, und Skalierbarkeit und Leistung sind begrenzt, da der Microsoft 365- oder Office 365-Dienst den Zugriff unter der Annahme drosselt, dass die Nutzung durch einen Benutzer und nicht durch eine Anwendung erfolgt.

Bewährte Methoden:

• Bei Migrationstools, die das RPC-über-HTTP-Protokoll verwenden, ist es gängige Praxis, den Migrationsdurchsatz zu erhöhen, indem sie weitere Migrationsserver hinzufügen und mehrere Microsoft 365- oder Office 365-Administratorbenutzerkonten verwenden. Durch diese Vorgehensweise können Sie Parallelität bei der Dateneinschleusung erreichen und einen höheren Datendurchsatz erzielen, da jeder Administrator der Microsoft 365- und Office 365-Benutzerdrosselung unterliegt. Es liegen entsprechende Berichte vor, dass viele Unternehmenskunden mehr als 40 Migrationsserver einrichten mussten, um einen Migrationsdurchsatz von 20 bis 30 GB pro Stunde zu erreichen.

• In der Entwicklungsphase für ein Migrationstool muss die Anzahl der RPC-Vorgänge berücksichtigt werden, die zum Migrieren einer Nachricht erforderlich sind. Um dies zu veranschaulichen, haben wir Protokolle gesammelt, die von Microsoft 365- oder Office 365-Diensten für zwei (von Drittanbietern entwickelte) Migrationslösungen von Drittanbietern erfasst wurden, die von Kunden zum Migrieren von Postfächern zu Microsoft 365 oder Office 365 verwendet werden. Wir haben die beiden von Drittanbietern entwickelten Migrationslösungen verglichen. Wir haben die Migration von zwei Postfächern für jede Migrationslösung verglichen und sie auch mit dem Hochladen einer PST-Datei in Outlook verglichen. Die Ergebnisse sind hier aufgeführt.

Faktor 4: Netzwerk für Migrationen von Drittanbietertools

Bewährte Methode:

Für die Migrationslösungen von Drittanbietern, die das RPC-über-HTTP-Protokoll verwenden, folgt hier eine geeignete Möglichkeit zum Messen der potenziellen Migrationsleistung:

1. Stellen Sie vom Migrationsserver mithilfe des RPC-over-HTTP-Protokolls eine Verbindung mit dem Microsoft 365- oder Office 365-Postfach mit Outlook her. Stellen Sie sicher, dass Sie keine Verbindung im Cache-Modus herstellen.

2. Importieren Sie eine große PST-Datei mit Beispieldaten in das Microsoft 365- oder Office 365-Postfach.

3. Messen Sie die Migrationsleistung, indem Sie die Zeit für das Hochladen der PST-Datei nehmen. Der Migrationsdurchsatz sollte dem ähneln, den Kunden über ein Migrationstool von Drittanbietern erzielen können, das das RPC-über-HTTP-Protokoll verwendet, vorausgesetzt, es gibt keine weiteren Einschränkungen. Während einer tatsächlichen Migration kommt es zu einem Mehraufwand, daher kann der Durchsatz leicht abweichen.

Faktor 5: Microsoft 365 und Office 365-Dienst

Microsoft 365- und Office 365-Ressourcenintegritätsbasierte Drosselung wirkt sich auf Migrationen mit Migrationstools von Drittanbietern aus. Weitere Informationen finden Sie unter Microsoft 365- und Office 365-Ressourcenintegritätsbasierte Drosselung.